The demo wowed the room. The agent took a vague instruction, broke it into steps, called a few tools, and came back with the right answer in seconds. Everyone nodded. Then someone at the back asked the only question that mattered. What happens when this is handling ten thousand requests instead of one? Nobody had a clean answer, and the meeting moved on as if the question had been rhetorical.
It was not rhetorical. The space between a slick agentic demo and a system that holds up in production is real, and it is well documented. The good news for any owner who has sat in that room is that the failure modes are predictable. You do not need to write the code to ask the right questions. You only need to know where these systems tend to break, so you can put the right oversight in place before you commit rather than finding out at ten thousand requests.
What is the demo-to-deployment chasm?
The demo-to-deployment chasm is the gap between an agentic system that runs one clean request beautifully and one that holds up at production volume. A demo keeps things simple. Production rarely does. Once agents start delegating to other agents, retrying failed steps, and choosing their own tools, the coordination overhead grows almost exponentially and becomes the part of the system that breaks first.
Practitioners gave it that name because the pattern is so reliable. The bottleneck moves. In the demo, the slow or fragile part is the model call itself. In production, the fragile part is the coordination between all the moving pieces. Agents wait on other agents, race conditions appear in pipelines that run things in parallel, and failures cascade in ways that are genuinely hard to reproduce in a test environment. The traditional workflow tools built for predictable, step-by-step processes struggle here, so teams end up building their own coordination layer, which then becomes the hardest part of the whole stack to maintain.
Why does a system that works at 100 requests collapse at 10,000?
Because the coordination scales faster than the work does. An orchestration pattern that runs beautifully at 100 requests a minute can collapse entirely at 10,000, and the reason is that every added agent, retry and tool choice multiplies the number of ways the parts can interact. The limit you hit at volume is how all those parts coordinate under load, and that grows far faster than the request count itself.
This is why a demo tells you so little about production behaviour. At low volume there is slack in the system, so a clumsy coordination pattern still gets the right answer. Push the volume up and the slack disappears. Failures that appeared once in a thousand runs now appear constantly, and they interact. The research on multi-agent systems is honest about this. The recurring failure modes are documented, but the precise way a large multi-agent system behaves at scale is still emerging in 2025 and 2026. Treat the failure modes as real and the at-scale specifics as something to watch closely, not assume.
Where do agentic systems actually break in production?
They break in four documented ways, and each has a name. Infinite loops, where an agent repeats a task without progress because nothing tells it when to stop. Hallucinated planning, where the agent produces a plan that looks fine but cannot run with the tools it has. Unsafe tool use, where a valid action turns destructive because the agent holds too much privilege. And cost that behaves nothing like a normal software bill.
The first three share a cause, which is too much freedom and too little constraint. The fixes are concrete. A loop needs a stop condition, a maximum number of retries, a step limit, or a runtime threshold. A plan that cannot run needs clear definitions of what each tool can and cannot do, and for higher-risk work, a check between the planning step and the execution step. An action that could be destructive needs the principle of least privilege, where tools are split into read, write and delete tiers and the dangerous ones sit behind human approval.
The fourth, cost, catches people out because it does not scale linearly. Each agent action involves one or more model calls. A workflow that costs fifteen cents per run looks reasonable until you are processing 500,000 requests a day, and a single edge case can trigger a chain of retries that costs many times the normal path. There is a fifth pattern worth knowing about, which is emergent behaviour. Failures in multi-agent systems often come from how the agents interact rather than one broken part, and an agent that adapts can start optimising for its own past behaviour rather than the business goal, drifting off course without an obvious warning sign.
When should a leader push back, and when is it worth committing?
Push back when the demo cannot answer the production questions. If nobody can tell you the stop conditions, the tool permissions, or what happens when the agent gets a step wrong, the system is not ready for your operation, however good the demo looked. Commit when the build team can show you those answers, and when the first use case is bounded, reversible, and cheap to get wrong while you learn.
The mismatch to watch for is a demo that proves the agent can do the task and a leader who reads that as proof the agent can do the task safely, at volume, every time. Those are different claims. The demo earns the first. Only observability, cost controls and human checkpoints earn the second. The EU AI Act points the same way for higher-risk uses, requiring that systems be designed so a person can effectively supervise and step in, and the NIST AI Risk Management Framework sets out the same govern-and-monitor discipline. That is a sensible bar to hold even where the rules do not strictly apply, because the cost of prevention is small next to the cost of an agent acting wrongly in your name.
What should you ask before you sign off?
Four questions get a non-technical leader most of the way to a defensible decision. What are the stop conditions that prevent this agent looping forever? What permissions does each tool hold, and do destructive actions sit behind human approval? When something goes wrong, how will we see why the agent chose each step? And what is the cost ceiling per request, retries included?
The third question is the one vendors least like, because observability for agentic systems is still immature. Traditional monitoring tracks speed and accuracy, but an agent might take a twelve-step path to one answer, and you need to see why it chose one tool over another and why it retried a step three times. The behaviour is non-deterministic, so the same input can produce different paths, which means you cannot reliably capture a failure and replay it. A practical safeguard for the edge cases these systems will hit is confidence-based escalation, where the system asks for a human review when its own uncertainty crosses a threshold. None of these questions require you to write code. They require the people building or selling the system to show their working, which is exactly what good oversight looks like.
If you want a second pair of eyes on an agentic proposal before you commit, book a conversation and bring the demo notes.
