Why Your AI Agent Works in the Demo and Stalls in Production

An agent that nails a scripted demo stalls in production because reliability compounds multiplicatively across steps, not additively. A 95%-per-step agent chaining 20 tool calls succeeds end-to-end only about 36% of the time. The demo ran one happy path. Production runs the long tail. Shorten the loop, make each step independently verifiable, and build step-level evalsAn eval suite is a versioned set of test cases that measures whether outputs are good. before adding more autonomy.

Every agent demo we’ve watched follows the same arc: five or six steps, a clean input, a live audience, and a confident finish. Nobody in the room asks what happens on step 14 when a tool call returns malformed JSON, because step 14 never comes up. It comes up in production, on day three, for a customer nobody was watching over their shoulder. By then the agent has already taken three more steps on top of the bad one.

Why does a 95%-reliable agent fail more than half the time?

A single 95%-reliable step succeeds 95% of the time, by definition. Chain N of them, and if each step succeeds independently, the end-to-end success rate is 0.95 raised to the N. That curve is modeled and illustrative, not a measured production number. The compounding effect is real:

This is the single fact that most agent demos hide by construction. A demo is one run through a script the builder already knows works. It exercises exactly one path through the distribution, the happy one. Production does not get to pick its path. It runs every input a real user sends, across every step in the chain. The 20th step inherits the accumulated failure probability of the 19 before it. An agent that “basically works” at the demo’s 5-step depth can look solid. Stretch the same workflow to 15 or 20 steps, and it becomes a coin flip.

What breaks between the demo and production?

Tool-call reliability. Every external call an agent makes is another factor in the product above: an API call, a database query, or a call to another model. Each one fails in its own way. The agent can generate malformed arguments with high confidence. A vendor’s schema can drift after the prompt was written. An endpoint can turn flaky or slow and time out mid-chain. A demo hits two or three tools, always in a state the builder tested. Production hits as many tools as the workflow needs, in whatever state the upstream system happens to be in that day.

Non-determinism. The same input can produce a different plan on a different run, because the model is sampling, not executing a fixed program. That shows up as retry loops that burn budget without converging. It also shows up as a plan that branches away from the intended workflow with no error. The result looks plausible step by step but ends up nowhere useful.

State and context erosion. Long transcripts accumulate the agent’s own prior outputs as context, and an early mistake does not stay contained. It becomes input to every later step, so the agent reasons forward from a premise that was already wrong. By step 15, an agent can be confidently building on an error it made at step 3. Nothing in the transcript flags that the foundation is bad.

How do you make an agent reliable enough to ship?

The most reliable fix for a known workflow is often less agent. A fixed pipeline lets the model handle only the steps that need judgment. Deterministic code handles everything else, on the same “skip the build if you don’t need it” logic we apply to build-vs-buy decisions generally. Free-form autonomy is worth the added reliability cost only where the workflow is unpredictable. It should never be the default choice.

An eval suite that only grades the final output can’t tell you which of 20 steps is dragging the product down. Step-level evals independently verify each step’s output against a known-good expectation. A regression at step 6 then gets caught at step 6, instead of surfacing three weeks later as a dip in end-to-end success.

GuardrailsGuardrails are the checks that keep an LLM or agent inside acceptable bounds in production. matter too. Constrained tool schemas reject malformed arguments before they execute. Output validation runs on every step, instead of trusting the model’s own confidence. Bounded retries make a stuck step fail loudly instead of looping silently. Human checkpoints sit before any irreversible action, such as a payment, a delete, or a customer email.

Step-level tracing closes the loop. If a failure can’t be traced to the specific step and tool call that caused it, every fix is a guess. ObservabilityObservability captures traces of every prompt, retrieval, tool call, and response for debugging. on each step’s input, output, latency, and outcome turns “the agent did something wrong somewhere” into a specific, fixable defect.

What this doesn’t tell you (honest limits)

The 0.95^n model assumes every step is independent and uniformly reliable, and neither assumption fully holds in a real system. Failures are often correlated: a bad upstream API response can degrade several downstream steps at once rather than failing them independently. A step with a retry or a self-correction pass has higher effective reliability than a single blind attempt. The agent gets a second look before the failure propagates. The precise percentages here are illustrative, not a production SLA. The point of the curve is its shape. Reliability decays multiplicatively, so step count is a lever you can pull. It is not a fixed cost of doing agentic work.

Shipping one anyway

None of this is an argument against agents. It’s an argument against shipping one the way it looked in the demo. The agents we’ve put into production run on the same discipline as any other reliability-critical system. That means fewer steps than the demo used, an eval at each step, and tracing that shows exactly where a chain broke. CodeHerder is built to make exactly this visible for coding agents. It traces what every agent does, step by step, in real time. A stall in production becomes a specific, findable defect instead of a mystery. If your agent impressed in the room but stalled on real traffic, that’s usually a step-count and observability problem, not a model problem. Happy to help find which step it is.

For a diagnostic breakdown of the specific failures behind a stalled agent, see the field guide entries below. Four entries cover unbounded agent loops, tool argument hallucination, silent tool failure, and context overflow dropping the task.