AI-Powered Vending in Practice: A Fleet's First Quarter

Let me tell you about a mid-sized operator I'll call Northline, because their first quarter with a vending Mission is the cleanest before-and-after I have, and because nothing about it asked them to rip out their machines or retrain their drivers. Roughly 380 machines across offices, hospitals, transit hubs, and gyms; six route drivers; one operations manager, Dana, who spent most of her week reacting. When I first sat with her she could recite the fleet's problems from memory — two locations that always sold out, a cluster of machines she was "pretty sure" got over-serviced, and a running suspicion that some faults sat undetected for days. She was right on all three. Most operators are.

The "before" week

Here is a normal week at Northline before the Mission. Routes ran on a fixed loop set months earlier and rarely revisited. Drivers restocked whatever was in front of them, which meant busy machines got the same weekly visit as sleepy ones — the transit-hub machine that emptied by Wednesday and the back-office machine that was still three-quarters full both got exactly one Thursday visit. Faults surfaced by complaint: a jammed validator at a gym went four days before a member emailed, four days of a machine taking no cash. Pricing hadn't moved in a year, so slow lines sat slow and popular lines never captured the demand they could have. Dana had telemetry dashboards, but dashboards report — they don't act — and she did not have the hours to reason machine-by-machine over 380 of them. So the fleet ran on averages, and averages leave money on the table at both ends.

Turning it on

We stood up the vending Mission inside Northline's own perimeter in a few days. The agents were wired to their existing systems through MCP integrations — machine telemetry, the payment/POS records, the inventory ERP, and the dispatch scheduler — no integration project, just registering the tools the agents would discover at runtime. We loaded their planograms, location profiles, and a pricing policy that set hard guardrails (no line moves more than a set percentage, certain locations frozen entirely) into Enterprise Knowledge. Critically, we turned nothing loose: every action that touched money or dispatch was routed to the decision queue for Dana or a driver-lead to approve. The forecasting, fault-watching, and route math ran on their own; the doing waited on a human.

The "after" week

A month in, the shape of Dana's week had changed. Each morning she opened a Portal instead of a dozen dashboards. Waiting for her was a proposed route for the day — the Demand Agent had forecast which machines would run low, the Route Agent had assembled a visit list that skipped the three-quarters-full back-office machine and prioritized the transit hub, and the whole plan sat in the decision queue with its reasoning attached. She could open the observations and see why each machine was on the list: "forecast to stock out of its top two lines by Wednesday," or "Maintenance Agent flagged the chiller trending warm — see telemetry." She approved the route with one click, adjusted one stop she knew about for a local reason the system didn't, and the drivers rolled with a plan that matched reality instead of a calendar.

The gym validator that used to fail silently now behaved completely differently. The morning it started jamming, the Maintenance Agent caught the pattern in the payment telemetry and raised a flag; a service visit was proposed and approved the same day. Four days of dead cash-handling became a few hours. And when the Pricing Agent proposed nudging a slow line down and a consistently sold-out line up — each within the guardrails from the policy Enterprise Knowledge held — those landed in the queue as suggestions with the demand evidence, not as changes already made. Dana approved most, rejected a couple on judgment, and prices finally started tracking demand.

The thing that earned her trust was not that the Mission was clever. It was that it never did anything to her business on its own. It proposed; a person approved. Ambient reasoning over 380 machines, with the operator's hand on every action that spent money or moved a driver.

The numbers Dana cared about

By the end of the quarter the picture was concrete. Stockouts on top-selling lines fell sharply as restocks started following forecasts instead of the calendar — the transit hub and the two chronic locations stopped going dark mid-week. Roughly one in five route stops that used to happen simply stopped happening: visits to machines that didn't need them, now skipped, which returned real driver hours and fuel to the operation without adding a single head. Mean time to detect a fault dropped from days to hours, which showed up both as recovered sales and as one avoided chiller spoilage event that would have meant discarded stock and a compliance headache. And the price nudges, small individually, added up to a measurable margin improvement on exactly the lines where demand supported it.

None of these are moon-shot numbers, and I would be suspicious of anyone who promised they were. They are the ordinary compounding wins of an operation that stopped flying blind between visits — each one a few percent, together the difference between a fleet that runs on averages and one that runs on what's actually happening.

A realistic rollout

If you are considering this, the honest path is incremental, and it matches how we deploy everywhere. Start read-only: let the Demand and Maintenance Agents run in observe mode for two or three weeks, producing forecasts and fault flags that a human simply reads. This builds trust and tunes the Enterprise Knowledge against your real fleet before anything acts. Then turn on the decision queue for one action type — routing is the safe first choice, since a proposed visit list is easy to sanity-check. Add pricing next, with tight guardrails you can loosen as confidence grows. Keep every money-or-dispatch action behind human approval indefinitely; that gate is not training wheels you remove, it is the design. Most operators are approving routes within the first fortnight and pricing within the first month.

Northline did not become a different company. Its machines, its drivers, and its manager were the same. What changed is that the coordination that used to run on Dana's memory and a fixed loop now runs as a StudioX Mission embedded in the business applications she already used, freeing her to make the calls only she could make. For the leadership framing of why this is worth doing, see why it matters; for the architecture underneath that one-click approval, Trevor lays out the agents and gates in how it works. It is the same pattern we bring to every operations-heavy fleet with AI Missions — vending just makes the payoff unusually easy to count.