Put two findings from the same survey next to each other and the week's most-quoted adoption statistic stops being good news: 85.5% of engineers say they trust agent output at least somewhat, and 41.1% say they hit agent-related issues daily or more, with 9.0% saying continuously. There is no reading of those two numbers under which the trust is well calibrated. What makes the combination stable rather than a crisis is the thing the survey cannot see — the error handler is a person, absorbing failures one at a time, and no dashboard anywhere has a line for the hours they spend doing it.
What the report actually says
Temporal published its 2026 State of Development Report on AI agents in late August. The survey ran from 29 April to 25 May 2026 across the US and UK and, after low-quality responses were removed, covers 554 software engineers, architects, infrastructure contributors and engineering leaders. The headline is adoption, and it is genuinely steep.
| Finding | Figure | What it is measuring |
|---|---|---|
| Use agents daily or more | 80.8%, up from 47.3% | Self-reported frequency — a 70.8% relative jump in a year |
| Agents "improved" or "revolutionised" productivity | 91.1% | Perceived value, unbounded and uncompared |
| Trust agent output at least somewhat | 85.5% | A disposition, not a delegation decision |
| Hit agent-related issues daily or more | 41.1% (9.0% continuously) | Encountered failures, undefined and unpriced |
| Top blocker to using agents more | Tracking state, 35.7% | What engineers name, then debugging, then cost |
Take the report's framing at face value first, because it is defensible. Its argument is that adoption outran infrastructure: engineers picked up agents faster than their organisations built the systems to run them, and the teams pulling ahead are the ones that solved state, cost and reliability. That is a coherent story and the blocker data supports it. It is also, precisely, the story a durable-execution company is in business to tell, and the survey was designed by people who already believed it. That does not make it wrong. It makes it worth checking against the numbers that were not the headline.
"Trust" is the wrong variable, and the survey inherits the mistake
"Do you trust agent output?" aggregates over every action an agent might take, and the aggregate has almost no operational content. Trusting a summary of a stack trace and trusting a database migration are different decisions with different reversal costs, and an engineer who answers "somewhat" is describing a feeling about a category. The decision that governs blast radius is not a scalar at all: it is a list of which specific actions may run unreviewed, which need approval, and which are never delegated — the ladder that autonomy levels lays out, and the thing most teams have never written down.
This matters because the two numbers only look contradictory under the scalar reading. Under the per-action reading they are perfectly consistent and considerably more worrying: engineers have high trust in the class of output they review, are shipping faster than ever, and are hitting failures daily in the actions they no longer review. The survey cannot tell those apart, and neither can a team that has only ever discussed trust as a mood.
The practical replacement for the question is two lines in a run record. For every action class an agent can perform, what fraction of runs was reviewed by a human before the action landed, and what fraction of reviewed actions was changed? A high review rate with a near-zero change rate is a control you can safely loosen. A low review rate with a high change rate is where your 41.1% lives.
Engineers named the blocker they can see
State tracking at 35.7%, then debugging, then cost. Read that as a ranking of visibility rather than of cause. State is what you are staring at in the debugger when a run fails halfway and cannot be resumed; it is legible, nameable and has a product category attached to it. That is exactly the kind of answer a survey elicits, and it is why "tracking state" beats answers like "we never defined what done means for this task" — which is upstream of it, harder to name in a checkbox, and considerably more likely to be the actual defect.
State really is a hard problem and the durable-execution engines really do solve part of it; the wiki's own comparison of where an agent's transcript lives covers what they do and do not fix. But notice what a resumable run buys you and what it does not. It buys you the ability to continue a run that crashed. It does not tell you whether the run should have continued, whether the work it had already done was correct, or whether resuming it will repeat a side effect. Those are eval and idempotency questions, and they are the ones a daily failure rate is usually made of — see idempotency and retries, where four stacked retry sources mean every write tool fires twice unless you construct exactly-once deliberately.
The tell that the blocker ranking is about visibility: cost placed third, in a population where 41.1% report daily failures. A daily failure rate is a cost — the retried run, the discarded output, the engineer's afternoon — and it ranks below cost because none of it arrives as a line item. The provider bill is legible. The labour absorbing the failures is not.
The error handler is a person
Here is the mechanism that makes 41.1% survivable. In a conventional service a failure hits a code path — a retry, a fallback, an alert — and terminates in an incident record and an error budget somebody reviews at the end of the sprint. In an agent workflow the failure is usually caught by the engineer sitting in front of it, who rewrites the prompt, reruns the task, or does the work by hand, and the path ends there. Nothing is emitted. No alert fires because the human already handled it, which is the definition of a handled error and also the reason it never becomes data.
This is why the aggregate can look so strange. Each individual failure is cheap — a minute, a rerun, a slightly different prompt — and cheap-and-frequent is the profile that never gets escalated. It is also the profile that quietly sets your team's throughput ceiling, because the minutes are real and the person spending them is the most expensive component in the loop. The economics page on the cost of human review makes the same argument from the other end: the reviewer is ten to fifty times the token cost and is the one line that does not shrink when the model gets better.
The fix is not to eliminate the failures, which is not on offer. It is to make the handling visible, and that costs almost nothing: one field on the run record for "a human intervened", set by whatever surface the intervention happened on. Once a week's runs carry it, you can rank task classes by intervention rate and discover that the daily failure rate is not evenly spread — it is two or three task classes generating most of it, which is an actionable finding and the one thing a survey can never give you about your own system.
Throughput went up. Review did not.
The report's most under-discussed number is that 51.3% now go from prototype to production-ready code in hours or faster, and 26.9% in minutes or faster. Set that beside the daily failure rate and the shape of the risk becomes clear: the generation step got dramatically faster and nothing downstream of it did. Review capacity is unchanged, because it is bounded by human attention, and the number of changes arriving at it went up several-fold.
That is the same bottleneck the background coding agents playbook argues about pull requests — an agent that opens twelve a day adds nothing if the team merges four — restated at the level of a whole organisation. A queue whose arrival rate multiplies and whose service rate is flat does not degrade gracefully; it either grows without bound or the service rate silently drops, which in a review queue means approvals get shallower. Nobody decides to review less carefully. It happens because the alternative is a queue that never empties.
The hiring findings sit oddly alongside this and are worth one paragraph of caution: 56.7% believe it will be harder for junior engineers to find jobs and 45.5% say the same of senior engineers, while only 26.4% of companies report slowing or stopping hiring. Engineers' expectations have moved considerably further than their employers' behaviour has. Both numbers are self-reported by the same population, so the gap is a fact about sentiment, not about the labour market, and it should be read that way.
How much of this to believe
The caveats are ordinary and they matter. This is a vendor survey, which shapes what was asked as much as how it is framed. The population is self-selected, 554 respondents across two countries, and every figure is self-reported — including "productivity improved", which is measured against no baseline and by people who chose to answer a survey about agents. "Agent-related issue" is undefined, so it spans a hallucinated import and a production outage. And "daily agent use" in a survey of software engineers is heavily a coding assistant, which is a different animal from an autonomous agent taking actions in production; do not read the 80.8% as deployment.
What survives all of that is the internal comparison, because both figures come from the same instrument and the same respondents. Whatever bias inflated the trust number would inflate the failure number too, and the failure number is high anyway. A population that reports failing daily and trusting anyway is telling you something real about how agent work is currently absorbed, and it is the finding worth taking away from a report whose headline is adoption.
The one number to steal for your own team is not in the report at all. Take a week of runs, count what fraction ended with a person intervening, and split it by task class. If the answer resembles 41%, you now know which two or three classes to fix — and unlike a trust score, it moves when you fix them.
FAQ
Is a 41.1% daily failure rate actually bad, or is that normal for new tooling?
It is unremarkable for tooling you drive by hand and unacceptable for anything acting unattended, and the survey cannot tell you which of those it measured. That is why the interesting version of the question is per action class rather than in aggregate. A code-completion suggestion failing daily is a rounding error on your day; a scheduled agent writing to a system of record failing daily is an incident you have not opened yet.
Does the report show that durable execution is what teams need?
It shows that state tracking is what engineers name first when asked what blocks them, which is a real signal and a partial answer. Resumability fixes runs that crash; it does not fix runs that complete incorrectly, and it does not stop a resumed run from repeating a side effect unless you also built idempotency. If your daily failures are wrong outputs rather than lost progress, a durable-execution engine will not move the number.
Why does trusting agent output "at least somewhat" tell us so little?
Because it aggregates across actions with wildly different reversal costs and asks about a disposition rather than a delegation. The operational question is which actions may run without review, and it has a different answer for reading a file, drafting a message, and issuing a refund. A team can be at 85% on the survey question and have never written the second list down.
Should I be worried that adoption jumped 70.8% in a year?
Not by itself — a fast-rising adoption curve is what a useful tool looks like. Worry about the pairing: adoption rose, self-reported time-to-production collapsed to hours or minutes for half the respondents, and review capacity did not change, because it is bounded by people. That combination is where approvals get shallower without anyone deciding to make them shallower.
What is the cheapest instrumentation that would answer this for my own team?
One boolean per run for "a human intervened", written by whatever surface the intervention happened on, plus the task class. That is enough to rank task classes by intervention rate within a week and to tell a genuinely reliable agent apart from one whose failures are being quietly absorbed. Everything else in agent observability is more useful, and none of it is cheaper.
Further reading
On this wiki:
- Autonomy levels — trust as a per-action ladder rather than a scalar.
- Idempotency & retries — why a resumed run repeats a side effect unless you built exactly-once.
- The cost of human review — the line item that does not shrink when the model improves.
- Background coding agents — throughput rising into a flat review queue.
- Production feedback signals — turning the intervention into data.
- Temporal vs Restate vs Inngest vs DBOS — what the durable-execution engines behind the report's framing actually fix.
Sources:
- Temporal — The State of Development 2026 — the report, 554 respondents, surveyed 29 April to 25 May 2026.