How AI-Powered Vending Works: Inside the StudioX Mission

Harry has made the operational case for why a vending fleet leaks money between visits. I want to open the hood on the system that closes the gap, because "AI runs the vending operation" is the kind of sentence that hides all the interesting engineering. What actually runs is a StudioX Mission — not a monolithic model that "manages vending," but a small org chart of specialist agents coordinated by a reasoning core, every step of which you can watch as it happens, with a single deliberate place where a human says yes. I lead the Missions team, so let me describe the machine honestly, including the parts that are read-only and the parts that never act without approval.

A Mission, not a model call

A Mission takes a goal in plain language, reasons about it, delegates to specialist agents, and returns a result with every decision traced. It runs inside your perimeter, wired to your own machines and back-office systems. The vending Mission's standing goal is roughly: "Keep this fleet stocked, healthy, and priced well — surface any action that touches money or dispatch for approval."

Two tiers do the work. Tier 1, the reasoning core, is the project manager: it reads the situation and the roster of available agents and decides, one round at a time, which single agent should act next, accumulating results until it judges the request answered. Tier 2, the agent planner, takes the goal handed to a chosen agent, discovers what that agent can actually do — its tools, its knowledge bases, its workflows — decomposes the goal into ordered steps, and executes them. None of this is a hard-coded pipeline. Routing, planning, and the final "are we done" check are all model decisions, which is why the same Mission handles "forecast demand for the hospital machines this week" and "why is machine 412 failing" without a branch of custom code for each.

The roster

Each specialist AI Worker is backed by its own StudioX bot with its own knowledge base, so knowledge stays isolated — the agent that reads telemetry never answers from the pricing policy, and vice versa. For a vending operation the roster maps cleanly onto the four jobs the fleet actually needs:

• Demand Agent — forecasts what each machine will sell and when each slot will run low, reading sales history and location patterns. Read-only.
• Route Agent — turns those forecasts into a proposed restock plan: which machines need a visit, which can be skipped, in what order. It proposes; it does not dispatch.
• Maintenance Agent — watches machine telemetry for the early signs of trouble — a validator jamming, a chiller drifting warm, a compressor cycling wrong — and flags the fault with its evidence. Read-only.
• Pricing Agent — spots slow-moving or high-demand lines and proposes a price adjustment within the guardrails your policy defines. It proposes a number; it never changes the number itself.

Enterprise Knowledge is what makes it your operation

An agent's forecast is only as good as what it knows about your business, and that grounding comes from Enterprise Knowledge — StudioX knowledge bases that encode your planograms, your location profiles, your pricing guardrails, your maintenance runbooks. When the Demand Agent forecasts the hospital lobby, it retrieves that machine's actual product mix and history, not a generic curve. When the Pricing Agent proposes a nudge, it first pulls the policy that says how far it is allowed to move a price and for which lines. The agent reasons over the full retrieved context internally but hands the reasoning core back only the relevant slice — the forecast, the flagged fault, the proposed number — so the project manager works from answers, not raw dumps.

Watching it reason: observations

The property that makes a Mission trustworthy is that you never have to take its word. As the reasoning core routes and each agent plans and executes, every phase streams to the Explain rail as observations, over Server-Sent Events, in true execution order — the routing decision, the capability discovery, each planned step, the validation of that step, the final answer check. For a vending operation this is the difference between "the system says visit these eleven machines" and "the system says visit these eleven machines because the Demand Agent forecast three of them to stock out by Thursday and the Maintenance Agent flagged a warm chiller at the fourth — here is the telemetry it read." Each step is validated by a separate model call, and a step that refused or returned the wrong kind of result is retried once, so a flaky telemetry fetch does not silently produce a hollow plan.

Where the tools come from: MCP integrations

The agents have to reach real systems — machine telemetry feeds, the POS or payment records, the ERP that holds inventory, the dispatch scheduler. In StudioX those connections are Model Context Protocol (MCP) integrations: tools registered at runtime rather than built as bespoke integration projects. An agent discovers the available tools when it runs, so the day you connect a new telemetry vendor or a new payment source, the Mission can read it immediately — no code change, no redeploy. This is what lets the same Mission fit your stack instead of forcing you onto ours, and it is the same enterprise integrations mechanism we use across every domain.

The one gate that matters: decision queue and human-in-the-loop

Reading telemetry and forecasting demand are safe; changing a price, dispatching a driver, or placing a replenishment order is not. So the read-only work — forecasting, fault detection, route math — runs autonomously, but any action with real-world consequence is never taken silently. Instead the Mission's final synthesis emits a [REQUEST_APPROVAL] block. The route layer turns that into a decision queue row and emails the responsible operator a magic-link approve/reject URL; in chat it becomes an "awaiting approval" status. Nothing hits your pricing system or your dispatch board until a person clicks approve. That is human-in-the-loop by construction, not by policy — and it is why an operator can let this run against four hundred machines without lying awake about it.

For the browsable side — the fleet health view, the pending decisions, the forecast dashboards — the Mission emits a [REQUEST_PORTAL] block that becomes a Portal: a structured surface where the operator reviews everything in one place.

That is the whole machine: a reasoning core, four legible agents grounded in Enterprise Knowledge, observations you can audit, MCP integrations to your real systems, and a single approval gate on every action that touches money or dispatch. For the leadership case, see Harry's why it matters; to watch it run against a real fleet with real numbers, read in practice. Everything here is standard StudioX AI Missions architecture — the vending fleet is just a particularly honest place to see it work.