Everybody's Agents Break at the Same Rate.

Eighty-one percent of engineers now use AI agents every day. Forty-one percent hit problems with them every day.

Both numbers come from the same survey, and neither one is the interesting part.

Temporal published its State of Development 2026 report on August 25. Five hundred fifty-four respondents, two thirds of them in the US, most with six to fifteen years of experience. Daily agent use climbed to 80.8 percent from 47.3 percent a year ago. Nearly half say agents are in production or core to shipping.

The Finding That Should Have Been the Headline

Buried under the adoption numbers is this: the teams succeeding with agents run into problems just as often as the teams that are struggling. They are not experiencing fewer failures. They are handling them better.

Sit with that for a second, because it kills the premise most AI programs are built on.

Now the part you should know before you believe any of it. Temporal sells durable execution. Retries, state management, recovery from partial failure. A report concluding that recovery separates the winners is a report that sells exactly what Temporal makes. That is about as direct a conflict as I have written about this month, and I am not going to pretend otherwise.

Here is why the finding survives its source anyway. It is checkable. You do not have to trust Temporal or me. Pull your last ten agent incidents and ask how long each one took to notice, contain, and recover. If your answer is that you do not track that, you have learned something more useful than any survey could tell you.

Failure Rate Was Never Available as a Lever

The reason the finding is not surprising once you look at it: nobody actually gets to choose their agent failure rate.

These systems are nondeterministic by construction. They call external services that go down, return malformed data, and change their contracts without telling you. The model underneath gets updated. The prompt that worked in March degrades in August for reasons nobody logged. A retrieval index drifts. Somebody renames a column.

You can reduce failures at the margin, and you should. But you cannot drive them to zero, and the effort spent trying is effort not spent on the thing that actually differentiates.

Twenty years of operations research figured this out about servers and we all agreed to stop pretending machines do not fail. Then agents arrived and a lot of smart people started chasing the same ghost again.

What Recovery Actually Means

Recovery is not a retry loop. Four things do the work.

State that survives the failure. If an agent dies at step seven of nine and the only way forward is starting at step one, you do not have recovery, you have a restart. Durable state is the difference between a hiccup and an incident.

Idempotency everywhere it touches something real. An agent that might run twice will eventually run twice. If the second run sends a second invoice, that is not an agent problem, it is a design problem.

A blast radius somebody chose on purpose. What can this thing touch, how much can it spend, how many records can it modify before something stops it. If nobody has written that down, the answer is everything.

A human handoff that works at 2 a.m. Not an alert into a channel nobody reads. A path where a person can see what the agent was doing, why it stopped, and what state it left behind.

The Temporal respondents named their own blockers along these lines. Roughly a third cite state tracking, debugging, and cost management as what is holding them back. Those are not model problems. Not one of them gets solved by a better prompt.

The Number That Should Worry You More

The same survey found 85.5 percent trust agent output at least somewhat, and 24.7 percent trust it completely.

Set that next to 41.1 percent hitting issues daily, and 16.4 percent hitting them hourly.

A quarter of these engineers completely trust systems that break for four in ten of them every day. That gap between confidence and reliability is not a technology problem either. It is what happens when the failures are quiet, the output looks plausible, and nobody has been forced to look closely.

Plausible-looking wrong answers are the whole difficulty. A server that goes down announces itself. An agent that quietly does the wrong thing does not.

What I'd Do This Week

Time your last five agent incidents. Detection to containment to recovery. If you cannot produce those numbers, that is the finding and you can stop reading here.

Find every place an agent writes to something real. Payments, tickets, emails, records, deployments. Make each one idempotent or gated. Do this before the next model upgrade, not after.

Write down the blast radius. Money, records, systems, time. One page. Anything not on it is currently unlimited.

Kill one retry loop and build one checkpoint instead. Retries paper over failure. Checkpoints let you resume from it. They are not the same thing and one of them scales.

Run a drill. Break an agent on purpose during business hours and watch how long it takes somebody to notice. That number will tell you more than any vendor report, including the one this post is built on.

The Part That Matters

Everyone is measuring the wrong thing. Accuracy on a benchmark, hallucination rate, how impressive the demo was.

The teams that make agents work in production have quietly given up on reliability as the goal. They assume the thing will break, and they spend their engineering budget on what happens next.

Failure was never the variable.

Recovery was.