in early 2026 a group of researchers ran a benchmark on a standard crm. they built a six-task agentic workflow, something a human could complete in about twenty minutes. then they ran it 10 consecutive times. end-to-end success rate: 25%.
in the same window, langchain's 2026 state of ai agents report landed. 57% of organizations say they have agents in production. 32% of them cite quality as the number one barrier to scaling those agents.
these two numbers describe the same reality from different angles. agents are in production. agents do not work. both things are true at once, and the gap between them is the most interesting place to do engineering in 2026.
this is how i think about building in that gap.
the math of compounding failure
traditional software reliability is about nines. three nines is 99.9%. four is 99.99%. you plan for five on critical paths and you feel bad when you drop to three.
agents live in a different universe. a well-tuned single agentic step (meaning "the model plus its tool call plus its output parsing plus the downstream effect") succeeds maybe 90% of the time. 95% on a good day with a narrow task. now chain six of those steps into a workflow.
- 95% per step, 6 steps: 73.5% end to end
- 90% per step, 6 steps: 53.1% end to end
- 85% per step, 6 steps: 37.7% end to end
- 80% per step, 6 steps: 26.2% end to end
the 25% benchmark number isn't an accident. it's what ~80% step reliability compounds to over six steps. nothing catastrophic broke. every step was slightly brittle, and the brittleness multiplied.
this is the first thing i try to explain to anyone starting to build agents. you are not working on a two-nines problem. you are working on a compounding problem. the design rules are different, and they are different in a way that changes what the system architecture has to do.
the demo-to-production cliff
i've shipped a lot of software: web apps, microservices, infra, mobile, ml pipelines. in all of them there's a gap between "works in the demo" and "works in production." in agents, that gap is the largest i've ever seen.
the reason is simple. the surface of a demo is narrow: one user, one flow, one dataset, one network condition, one day of the week. the model was not trained to behave on that narrow surface. it was trained on the entire internet. the behavior you get in the demo is a lucky projection of a much bigger distribution, and the moment you widen the surface even slightly, the distribution widens with it.
your demo ran three times and succeeded all three. production will run 10,000 times with varied inputs and succeed 2,500.
this is not the model being bad. this is how stochastic systems behave on a distribution they were never specifically tuned for. the mental shift is to stop expecting the agent to behave like a function and start treating it as a stochastic component embedded in a deterministic system, where the deterministic system has to carry the uncertainty.
the failure modes that actually bite
here are the failure modes i've hit in production on regent and mailpilot, ranked by how often they've cost me a late night.
context drift. the agent starts on task a and, three tool calls in, has talked itself into task b, which was never what the user asked for. this is especially common when a tool partially satisfies an earlier interpretation. the fix is not prompting. the fix is a plan the agent commits to at step 1 and is measured against at every subsequent step.
infinite loops with budget burn. the agent retries the same action with slightly different parameters forever. this is the one that costs real money. public benchmarks report cases of 20+ llm calls for a single user query when the agent gets stuck. the fix is a hard step budget and an escape hatch when the budget trips.
silent tool failures. the tool returned a non-200 or a weird payload, and the agent interpreted the error text as data. the agent then proceeds confidently on fictional state. the fix is typed tool wrappers that either return structured success or throw structured failure, never ambiguous strings.
confidently wrong output. the model produces perfectly formatted json that happens to be semantically wrong. this is the scary one, because your schema validator passes it. the fix is semantic checks as a validation step, not just shape checks.
memory retrieval misses. the agent couldn't find the right past event in memory, so it acted as if the event didn't exist, and now there are duplicate records. the fix is retrieval auditing and idempotency keys at the write layer.
parameter malformation on tool calls. the model invents a field that doesn't exist on the tool schema, or omits a required one. this happens more often than you'd think on long tool lists. the fix is strict schema enforcement with one retry on validation failure, then hard fail.
none of these are solved by a better prompt. none of them are solved by a bigger model. all of them are solved by the system around the agent.
designing for 25%
here's the counterintuitive move that worked for me. stop designing agent systems for the reliability you wish you had. design them for the reliability you measurably have.
on regent, i assume any given agent step has an 80% success rate. if i string six of them together, i assume 25% end-to-end reliability without intervention. then i build the intervention into the system. every tactic below is there because i already did the math on compounding failure and refused to accept it as the final number.
1. every action is idempotent. the agent can retry anything without side effects. that means upserts, not inserts. deduping keys on writes. no "send email" that actually sends until a separate confirmation step has verified the payload.
2. no irreversible action without a human or second-agent check. payments, production deploys, outbound messages, data deletion. the agent prepares. a human (or a second agent running a much stricter check) commits. this is slow. it is also the reason my systems don't end up on hacker news for the wrong reasons.
3. bounded steps with tripwires. every agent loop has a hard step budget (8 to 12 for multi-step tasks). every loop has tripwires: if the agent repeats the same tool with the same parameters twice, it trips. if a retrieval returns zero results three times in a row, it trips. if the estimated confidence drops below a floor, it trips. a tripped agent doesn't try harder. it stops and hands off.
4. structured outputs with semantic validation. every tool call and every final response is a typed schema. on validation failure, one retry, then hard fail. shape validation catches roughly 30% of the bugs. semantic validation (does the date make sense, does the customer exist, does the amount match the invoice) catches another 40%. the remaining 30% is what evals and humans catch.
5. evals run on every change, not after complaints. i treat evals the way i used to treat unit tests: they run before the change merges, not after users start reporting issues. the regent eval suite runs on every prompt edit, every model version bump, every tool change, every schema update. it takes about 90 seconds. it has caught regressions that would otherwise have shipped.
6. observability designed for agents specifically. not just logs, not just traces. the trace has to include the full context at each step, the tool call and response, the plan the agent committed to, the deviation from that plan, and a running token budget. generic apm does not cut it for this. the instrumentation is custom, and it is worth it.
7. fall back to the deterministic path. the agent is not the only way to do the task. for every agentic flow i have, there is a deterministic fallback that does not use an llm at all. it's less capable. it handles fewer cases. but when the agent trips a tripwire or exceeds its budget, the system falls back to it. the fallback has saved me from every minor outage i've had in the last six months.
what doesn't work
i've tried the shortcuts. none of them work.
"just prompt better." you can prompt-engineer your way from 80% to 85% step reliability. not to 99%. not even to 95%. the ceiling is the model's distributional behavior, not your phrasing. past a point, the marginal return on prompt tweaking is indistinguishable from noise.
"just use a bigger model." the 240x cost collapse and the 1m-token windows did not make agents reliable. they made them cheaper and more capable per step. the compounding still compounds. the step budget still burns. a smarter agent with no guardrails fails in more sophisticated ways, not fewer ways.
"just add guardrails." guardrails is a marketing word for "more middleware." they help. they are not the system. the system is the whole pipeline: retry semantics, observability, eval loop, fallback path, idempotency, bounded loops. guardrails are one component in that list, not a replacement for the others.
"wait for the next model." the next model will be better. it will also be asked to do harder things, because the bar moves with the capability. the ratio of capability to demand has not meaningfully shifted for any production builder i know. the job stays the same. the failure modes just get more interesting.
the honest framing
here's what i've converged on after two years of shipping agents to users.
agents are powerful. agents are unreliable. those two facts are not in tension. they are the premise. the job of an ai engineer in 2026 is to build the deterministic system around the stochastic component so that the combined thing is both powerful and reliable.
if you resent the stochasticity, you are in the wrong field. if you expect it to go away with the next model, you are going to spend the next five years being disappointed. if you treat it as a fixed input and design around it, you get to ship things that neither a pure-code nor a pure-ai approach could ship on its own.
that's the 25% agent. it's not a failure mode. it's the starting point. the 25% is the model. the other 75% is the system you build around it.
and the system is where all the interesting engineering lives in 2026.