Inside Starbucks’ AI Inventory Collapse and How FDEs Could Have Prevented It

On a winter morning in a busy Starbucks back room, a shift supervisor stands in front of a cramped fridge with an iPad, scanning half-empty milk crates while mobile orders pile up. Scenes like this mirror worker and analyst accounts of Starbucks’ short-lived AI inventory program, which repeatedly miscounted and mislabeled stock before the company scrapped it across North America.

Starbucks didn’t suffer a mysterious AI failure–though that’s a popular narrative around this story. The key failure was less around the tech itself and more about the implementation: It’s not that the models couldn’t count milk; it’s that the company tried to bolt sophisticated tools onto brittle systems and thinning staff, instead of embedding engineers in the reality of its stores and supply chain. 

The AI that could count everything—except milk

In late 2025, Starbucks rolled out an AI-powered “Automated Counting” system across thousands of North American stores as part of a push to automate inventory assessments and address product shortages that executives had said were hurting sales.

The worker-facing tool ran on tablets and was used to scan shelves and automatically tally milk and other beverage ingredients that employees had previously counted manually.

The system was promoted as a way to give Starbucks better visibility into store-level inventory. However, Reuters’ reporting noted that a Starbucks launch video showed the tool scanning a row of syrup bottles and correctly counting several of them while failing to recognize a peppermint syrup bottle in the middle. 

In practice, the tool struggled. It often miscounted and incorrectly labeled items, especially items that looked similar in shape and form, like oat milk and whole mil. Less than a year after rollout, Starbucks reversed course. An internal memo told employees, “Effective immediately, Automated Counting will be phased out… Beverage ingredients and milk will now be counted in the same manner as other inventory categories within your coffeehouse.” 

Publicly, Starbucks said it ended the program “to standardize inventory counting across coffeehouses as we continue to emphasize consistency and execution at scale,” while pointing to “more frequent, daily restocking of stores” and “ongoing supply chain enhancements.” 

Without insights from the actual baristas and store managers who needed the tool to work, Starbucks was forced to backpedal on A that could not earn trust in the environment it was supposed to improve. 

Automation as a staffing strategy and the ensuing public walk-back

The inventory system sat inside a larger automation story. In recent years, Starbucks invested in new equipment and automated systems in its US stores, including the Siren Craft System, while reducing in-store labor on the assumption that machines would offset the cuts. 

By spring 2025, that bet had unraveled in public. Coverage of CEO Brian Niccol’s comments reports him saying that “cutting staff in favor of automation has failed” for Starbucks. He acknowledged that the company had been “removing labor from the stores… with the hope that equipment could offset the removal of the labor,” and concluded that “wasn’t an accurate assumption.” 

Niccol added, “Equipment doesn’t solve the customer experience that we need to provide, but rather staffing the stores and deploying with this technology behind it does.” It’s not that Starbucks bought the wrong tools; it asked those tools to do the wrong job.

Where Starbucks’ AI implementation went wrong

Strip away the acronyms and headlines, and Starbucks’ misstep looks familiar: an organization rushed to deploy a new technology without making sure it would hold up in the messiest parts of reality. 

Demos instead of dependability

The inventory AI was introduced as part of a plan to address product shortages. In Starbucks’ own launch video, the tool counted several syrup bottles while failing to recognize a peppermint bottle sitting between them. 

‍

The bar for operational AI is not whether it can impress in a demo; it is whether employees feel comfortable turning their backs on it while they do something else.

Testing that avoided the worst-case

Accounts from workers and commentators describe the realities of Starbucks back rooms as cluttered, inconsistent, and full of edge cases that are difficult for brittle computer-vision systems. Yet the tool was deployed widely before it had earned trust in those conditions, as its nine-month lifespan and swift retirement underscore. 

It’s not that the AI could not handle complexity in principle; the complexity it faced in the wild never truly set its requirements.

Using AI to patch structural problems

Starbucks executives had already identified supply-chain issues and product shortages as a drag on sales before the AI tool was scrapped. That meant the company was trying to use an AI layer to improve visibility inside a supply system that was already under strain. 

When imperfect processes feed a new AI pipeline, the result is often bad data at greater speed. It’s not that AI was the wrong instrument; it was aimed at a problem that was mainly structural.

Automation as extraction, not partnership

Niccol’s own comments set out the problem clearly: Starbucks tried to remove labor while assuming equipment could carry the load, and then had to publicly acknowledge that strategy had failed. Workers were left managing tools that added complexity instead of reducing it.

What a forward-deployed engineer actually is, and how they make a difference

“forward-deployed engineer” is not a Starbucks term, but it describes a model that could have corrected many of the company’s missteps. Silicon Valley Product Group defines forward-deployed engineers as engineers and product creators who spend intense time embedded with customers in order to learn the problem space and discover solutions that achieve the necessary outcome. 

Where a traditional engineer might ship features from afar, an FDE lives with the customer’s workflows and constraints, adjusting the product in real time based on what actually happens on the ground. 

It’s not about putting an engineer closer to the business. It is about putting an engineer in the business long enough to see how it really works.

Seen through that lens, several of Starbucks’ missteps look preventable. 

Designing for “milk in the wild,” not “milk in the lab”

An embedded engineer piloting Automated Counting would have focused testing on the worst back rooms: cramped, poorly lit storage with mixed cartons and seasonal products. Those are the exact kinds of conditions that surfaced in reporting on the tool’s failures. 

That feedback could have narrowed the rollout or limited the tool’s use cases until dependability improved. It’s not that you need perfect AI to ship; you need AI whose imperfections are clearly mapped and safely contained. 

Building corrections and overrides into the workflow

Baristas and commentators have said they often had to audit and correct the AI’s counts, turning a promised time-saver into extra work. An FDE watching that would have prioritized fast overrides, visible uncertainty indicators and feedback loops that learn from corrections—patterns common in mature customer-embedded engineering models.

It’s not about telling staff to trust the AI. It’s about giving them proof that the AI learns when they correct it.

Keeping AI assistive while staffing stabilizes

Niccol has already conceded that Starbucks needed to bring back more staff and pull back from some automation. An embedded engineering model would more likely have argued for measuring the tool’s real gains before using it to justify labor cuts. 

It’s not that automation can never support leaner operations; using it as a pretext to cut early almost guarantees instability.

Making AI fit the supply chain that actually exists

In explaining the decision to retire Automated Counting, Starbucks emphasized standardizing inventory counting and making broader supply-chain improvements.That is an implicit acknowledgment that process and systems changes were needed alongside any AI deployment.

An FDE working with operations and IT teams would likely have seen early that AI alone could not fix inconsistent data and processes, and might have sequenced foundational work before, or alongside, the pilot. It’s not that Starbucks’ AI ambitions were misguided; they were under-served by the way the company chose to deploy and govern them.

The lesson for leaders betting on AI

Starbucks is not uniquely clumsy, and its experience is not an argument against AI in retail. It is a reminder that large-scale AI initiatives tend to fail at the seams between technology and reality, not in the abstract capabilities of the models. 

The pattern to avoid is central teams and vendors designing from afar, then discovering, expensively, that the field disagrees. The pattern to copy is older: send capable people to live with the problem until they understand it well enough to design something that fits.

forward-deployed engineers are one way to make that habit structural. They put product, engineering, and operations in the same space and keep them there long enough for technology to be shaped by how work actually happens, not just by how a slide deck says it should. 

Changing the org chart by putting engineers on the front line may matter more than changing the model.