Key takeaways
- Assistants answer; agents act. Answers need accuracy, while actions need bounds, logs and undo.
- Start agents on frequent, low-stakes, reversible decisions such as pick lists and markdowns, not on host contracts or capital spend.
- Set a mode per action type (Suggest, Approve or Auto), with numeric guardrails, data-freshness checks and a kill switch.
- Design approvals against fatigue: approve by exception, show the diff and the reason, and fall back to a safe default when nobody answers.
- Pair every agent goal with a counter-metric so it can't cut visits by emptying shelves.
Much of the AI that has arrived in vending software is a chat box on top of a dashboard. It’s useful: ask which machines are low on cold brew, or which sites lost money last month, and you get an answer in seconds instead of a spreadsheet afternoon. But after the answer, the operator still does the work. An agent is different. It drafts the pick list and publishes it, re-sequences the route, marks down the sandwiches and opens the service ticket. That’s where the real time savings are. It’s also where the design problems start, because software that acts can be wrong in ways that cost money before anyone notices.
Assistants vs. agents
| Assistant | Agent | |
|---|---|---|
| What it produces | Answers, summaries, suggestions | Actions in your systems |
| Who does the work | A person | The software, within limits |
| Typical failure | A wrong or invented answer | A wrong action, repeated at scale |
| What you need to trust it | Accurate, sourced answers | Bounded permissions, logs, undo |
| Where it saves time | Analysis | Routine daily decisions |
Both are useful. They’re different products with different risks, and “AI-powered” on a brochure doesn’t tell you which one you’re getting.
What’s real in 2026, and what isn’t
At the NAMA Show in Los Angeles this April, the AI conversation centered on loss prevention and operational efficiency, and large vending software vendors are adding assistants for questions and planogram suggestions. That’s real progress. Here’s a candid map of what agents can do reliably today.
Real, and worth doing now:
- Drafting pre-kitting pick lists from forecasts and current inventory
- Re-sequencing today’s route when a stop drops out or a machine goes down
- Proposing and applying small price changes, especially expiry markdowns, within limits
- Opening and prioritizing service tickets from telemetry, such as a temperature drift or a reader fault
- Drafting restock orders to suppliers for review
- Answering plain-English questions about your own data, with the query behind each answer
Not ready, or not wise, to hand over:
- Choosing new sites or signing host agreements
- Committing capital, such as hardware purchases
- Communicating with hosts or customers without review
- Anything that moves money without a ceiling
The pattern: agents earn their keep on decisions that are frequent, low-stakes, reversible and measurable. A pick list happens every night, a bad one costs a few carry-back units, it’s easy to correct and you know how accurate it was by morning. A host contract is none of those things.
Set a mode per action type
The most important design decision is that autonomy isn’t one switch. Each action type gets its own mode:
- Suggest: the agent proposes; a person decides and acts.
- Approve: the agent prepares the action; a person approves it and the agent executes.
- Auto: the agent acts within guardrails and reports what it did.
| Action type | Sensible starting mode | Can graduate to |
|---|---|---|
| Answer questions about the business | Auto (read-only) | Stays Auto |
| Draft and publish pick lists | Approve | Auto, with exceptions flagged |
| Re-sequence today’s route | Approve | Auto for small changes |
| Expiry markdowns within guardrails | Approve | Auto |
| Open and prioritize service tickets | Auto | Stays Auto |
| Dispatch a technician (costs money) | Approve | Auto for critical faults at covered sites |
| Draft supplier restock orders | Suggest | Approve, with a spend cap |
| Planogram changes | Suggest | Approve |
Guardrails that matter
Guardrails are what make Auto safe. The useful ones are concrete:
- Numeric bounds. “Maximum ±15% per price change.” “Never below cost.” “No supplier order over $2,000 without approval.”
- Scope. Which devices, sites or categories the agent may touch. A hospital with a strict nutrition policy might be off-limits for price changes entirely.
- Rate limits. A cap on price changes per item per day.
- Data freshness. Don’t act on a device whose telemetry is stale. An 8Kava device that loses its connection keeps selling and buffers transactions for up to 72 hours, but its data arrives late, and an agent acting on yesterday’s inventory will over-fill.
- Escalation triggers. Unusually large changes, new SKUs and low-confidence forecasts go to a person regardless of mode.
- Undo. Prefer actions that can be reversed, and make reversal one click.
- An audit log. Every action, with its inputs, its reason and who or what approved it.
- A kill switch per action type, so pausing pricing doesn’t also pause pick lists.
Designing approvals people will actually do
Approval mode fails in a predictable way. The agent asks for too much, people stop reading and start tapping “approve.” Rubber-stamping is worse than Auto, because it creates the appearance of oversight without the substance.
Do the approval math. An illustrative example: a 120-device operator kits about 60 devices a night. If a manager reviews every list at 45 seconds each, that’s 45 minutes before dawn, every day. Switch to approval by exception, where only lists that differ from the expected pattern by more than 20%, include a new SKU or touch a flagged device need review, and perhaps 8 lists need eyes: about 6 minutes. The manager spends those minutes on the lists that deserve them.
Other principles that work:
- Show the diff. “Adds 6 cold brew, removes 4 sparkling water versus last week” beats a full list.
- Give the reason in one line, with the data behind it: “Sold out by 1 p.m. on 3 of the last 4 visits.”
- Batch approvals into one morning review that works on a phone.
- Choose a safe fallback. If nobody approves by the deadline, fall back to a conservative rule-based list, not to auto-approval. The route still runs, and the agent never gains permissions through silence.
- Track the override rate. If people edit a third of the agent’s proposals, either the agent or its guardrails are wrong. If they never edit anything and spend two seconds per approval, audit a sample.
Earning autonomy
An agent should watch before it acts. After that, each action type earns promotion on its own record. A reasonable promotion rule might be 30 consecutive approvals without material edits, with stable counter-metrics, before an action moves from Approve to Auto for a group of sites. Demotion should be automatic: an unusual outcome, a spike in overrides or a data outage pushes the action back to Approve until someone looks.
What a useful audit entry looks like
A log is only useful if a tired person can read it at 6 a.m. A good entry answers five questions at a glance:
- What: “Marked down turkey wraps 15% on the cooler in Building C, second floor.”
- Why: “Projected surplus of 3 units before Friday 2 p.m.; sales pace below forecast since Wednesday.”
- Under which rule: “Expiry ladder, step 1; cost floor respected; second change today for this item.”
- Who approved: “Auto, under the rule promoted to Auto two weeks ago.”
- How to undo: one rollback button, with a note on what happens if you press it.
If an entry can’t explain its “why” in one sentence, the action shouldn’t have been automatic.
How agents go wrong
- Acting on stale data: offline devices, late DEX reads, planograms that don’t match the field.
- Feedback loops: a markdown sells out an item, and a naive forecast reads that as rising demand. Each module needs to know what the others did.
- Single-metric goals: told only to minimize visits, an agent will happily let shelves empty. Pair every goal with a counter-metric, such as visits with out-of-stocks, or waste with sales.
- Confident wrong answers: a plain-English answer with no query behind it is a guess. Ask for the numbers and where they came from.
- Permission creep: modes that drift toward Auto without a recorded decision.
A buyer’s checklist for “agentic” claims
- Does it take actions, or only suggest them?
- Can you set Suggest, Approve or Auto per action type?
- Can you set numeric guardrails and scopes?
- Is every action logged with its inputs and reason?
- Can price changes and other reversible actions be rolled back in one step?
- What happens when data is stale or a device is offline?
- Can you export the log and the data behind it?
Where to start on Monday
Pick one action type and one region. Pick lists are the usual winner, for the reasons above; our pre-kitting and dynamic routing guide covers the mechanics. Run it in Approve mode with exception-based review for a month. Track carry-back, out-of-stocks and the override rate. Promote it only when those numbers say so, then add expiry markdowns next, with tight bounds. Agents earn trust the way new drivers do: one route at a time.
How 8Kava approaches this
Kava Agent works across forecasting, pricing, routing, maintenance and suppliers. Every action type is set to Suggest, Approve or Auto, guardrails such as “max ±15%” and “never below cost” are set by the operator, every action lands in the audit log, and price changes roll back with one click. It observes for 14 days before proposing autonomous actions. Kava Agent is part of the Autopilot plan (see pricing), and For Operators shows how it fits a route business.