An AI agent on the inbound line that can retrieve the order, change it in the ERP, and hand over to a human with full context when it should. The market has already answered whether this works. The question that remains is control.
Inbound customer calls, answered by an AI agent that can actually retrieve and change orders in the ERP - and pass the call to a human, with full context, when it should. Not a phone tree with better manners. An agent with hands.
Notably, this demand has moved past can-it-work: versions of the pattern already run in production in the market. The open question we kept hearing is control - whose rules govern what the agent may touch.
Heard from a customer-operations leader at an enterprise B2B manufacturer. Paraphrased.
The demo is a patient caller, a clean line and a happy path. Production is a half-remembered order number over forklift noise, at volume, with money on the line. Three failure modes decide whether this works, and none of them shows up in the demo.
When the model layer changes underneath a tuned agent, tested behavior drifts. The provider ships the update either way - the re-validation is your team's problem, on your team's time.
On shared capacity, response times degrade in the one channel where milliseconds can be heard. A pause that would go unnoticed in a dashboard sounds like doubt on a phone call - and callers hang up on doubt.
An agent that touches order data needs deterministic execution. The LLM may interpret the caller. The order change itself must go through governed systems, rules and audit - the same way, every time.
These are patterns we see across the market, not a description of any one company.
Directional on purpose. The cost pools are consistent wherever this pattern comes up; the sizes are yours to measure, in your own call volumes.
Calls that land outside staffed hours wait for staffed hours. The choice today is to roster people around the clock or let the late call go to voicemail.
The line answers whenever the phone rings. The agent does not queue, roster or run out of shift.
Order changes get transcribed from a notepad after the call ends. Whatever lands wrong comes back as a wrong delivery, and then as the callback about the wrong delivery.
The change lands in the system of record while the customer is still on the line. Nothing gets transcribed afterwards, so nothing gets mistranscribed.
The team spends its day as a switchboard - answering, looking up, routing - while the calls that genuinely need judgment wait behind the routine ones.
Routine traffic stops landing on the desk. The hours move to the exceptions, which is also where customers feel the difference.
Two engines run in production today - Analytical Lab Reports and account Knowledge Twins. Everything else on this map is an extension on the same foundation.
Voice is an interface adapter feeding that same reasoning pipeline. The LLM sits behind the platform with its behavior pinned by your evals, so the agent survives model churn instead of drifting with it. And the order change never travels through the model - it goes to your ERP through governed integrations, with rules and an audit trail around every write.
The account context the agent speaks from - who is calling, what they buy, what they asked for last time - is the Knowledge Twin mechanism, scoped to the caller.
Who own coverage, response times and the relationship the phone line carries.
Who know which order changes are routine and which ones bite - the rules the agent has to inherit.
As the control owner: model choice, evals, integration boundaries and the audit trail.
It runs where your orders live: inside your infrastructure, inside your boundary. You choose the models, you can move the workloads, and the economics of every call stay under your control.
Back to the AI ROI MapBring your three most common order changes and your ugliest exception. We will walk the exact path each one takes: what the model decides, what the ERP executes, and where the human comes in.
On-prem. Your data never leaves your boundary.