Almost every AI product ships with a chat window, so almost every business assumes that is what deploying AI looks like: a box where somebody types a request and an agent does something. It is a fine interface for a demo. It is a poor one for an operation, and it is the reason a lot of agent projects stall the moment they meet real volume.
The interface that works is older and less glamorous. It is a queue.
Chat is a request. A queue is a system.
A chat window handles one thing at a time, for one person, who has to be there. An operation is thousands of things, arriving on their own schedule, that need to be done whether anyone is watching or not.
A queue holds items: a call that came in, a document that arrived, a record that needs updating, a ticket that needs routing. Each item has a state. Agents pick items up, do the work, and move them to done, or to a person when they cannot. Nobody has to type anything. The work arrives, gets done, and leaves a trail.
That trail is the second reason a queue beats chat. Every item records which agent touched it, what it did, and whether a person checked. When a customer asks "who changed my booking", there is an answer.
The exception path is the product
The agents will handle most of the items. Not all. A caller says something the flow does not cover. An invoice has a total that does not match its lines. A ticket is angrier than the categories allow for. These are exceptions, and how you handle them decides whether the system works.
In a queue, an exception is just an item with a different state. It waits for a person. The person sees what the agent did, what it was unsure about, and decides. The decision goes back into the record, and often into the next version of the agent, because every exception is a training example you did not have to invent.
In a chat window, an exception is a wrong answer sent to a customer.
What the person on the queue does
We say "people hold the edges" a lot. This is what it means in practice.
- Reviews the exceptions. A handful a day at first, fewer over time.
- Samples the successes. A percentage of items the agents marked done, checked at random, so drift is caught before a customer catches it.
- Feeds the flow. Patterns in the exceptions become new rules, new examples, or new steps for the agents.
- Owns the number. The person on the queue is the one who can say, on Friday, what happened this week and why.
None of this is a full-time job for most workflows. It is part of a role that already exists, and it is usually a role that gets more interesting rather than less.
An agent that is right ninety-five per cent of the time is only useful if the other five per cent lands in front of a person, with the context to decide in thirty seconds.
Confidence is what routes the item
Under the hood, what puts an item in front of a person is a score. The agent finishes a step with a confidence, checked against a threshold you set per task. High confidence, the item moves on. Low confidence, it waits. The threshold is a dial: turn it up when the stakes are high, down as the agent proves itself on the sample checks.
This is also how a system can go live before it is perfect. Set the threshold high on day one and the people on the queue see most of the work. As the agents earn trust, on evidence, the threshold comes down and the people see less. Nothing is switched on in one terrifying moment.
The weekly report falls out of it
Because everything is an item with a state, the report writes itself. Items in, items done, exceptions and how they were resolved, and what changed in the flow this week. That report is the same one we send to every client, and it is why the "is it working" conversation is short.
Build the queue first
If you are starting an agent project, our advice is to build the queue before you build the clever part. Define the item. Define the states. Define who reviews what. Then put an agent on it, and let it earn its way from "review everything" to "review the exceptions".
It is less exciting than a chat window. It is the reason the thing is still running a year later.