Shy Ruparel on AI agent reliability and recovery after failures

I’m Shy Ruparel, a developer advocate at Temporal. Agents are increasingly part of business operations, but deciding to use them is not the same as running dependable systems in production. I want to discuss four gaps our survey surfaced and demonstrate one approach to recovery.

Finance runs on long workflows, not isolated model calls. Loan origination, identity and anti-money-laundering checks, fraud reviews and payments span multiple systems, days and people. An agent inserted into that process inherits the consequences of all those dependencies.

Temporal’s 2026 State of Development survey, fielded by Qualtrics, included 554 engineers and engineering leaders already using AI agents. It is a survey of that selected group, not a census of all engineers. The slides distinguish its findings from figures drawn from other reports.

The first gap is use versus production. In the surveyed groups, daily use rose from 47.3% in the previous survey to 80.8% in this one. Yet 49.1% said agents were running in production or core to how they ship. Using an assistant every day and operating an agent in production are different commitments.

The second gap is trust versus experience. Some 85.5% of respondents trusted agent output at least somewhat, including 24.7% who expressed complete trust. I am personally more skeptical than that, and the reported failure frequency makes the contrast particularly interesting.

In the same survey, 41.1% reported agent issues daily or more often, including 16.4% continuously or hourly. Both trust and frequent problems can coexist; those percentages do not by themselves tell us which individual respondents belong to both groups.

Teams describing themselves as successful were 1.7 times as likely to report continuous or frequent issues. We speculate that they may look harder and notice more, but that interpretation needs further study. The lesson I draw is to plan for failure rather than assuming expertise can eliminate it.

Security was another constraint: around 40% of the surveyed teams cited it as a blocker to autonomous agents. That subject deserves its own discussion. Here I focus on what happens when a process fails and the system has to recover.

The third gap is moving from prototype to production-ready code. In our survey, 51.3% reported doing that in hours or less. But at organizations with more than 5,000 employees, roughly one in five reported a process taking months, compared with about one in 20 elsewhere.

I suspect approvals, audit trails and reliability requirements explain some of the difference for large regulated organizations, but the survey did not establish that cause. A bank or payments company has to ensure a process can be audited and that a transaction is not lost.

The fourth gap is seeing a failure versus recovering from it. Respondents identified tracking state across services, at 35.7%, and isolating and debugging issues, at 30.9%, as leading productivity blockers. Another 22.2% said crashes and restarts caused lost progress and repeated work.

A different survey last year asked about fragile state management, but the questions differ, so I would not call those results a trend line. I do think the consistent theme is that state matters as agents enter longer, more consequential workflows.

Logs and traces can show that an agent failed, but recovery may still depend on a person reading a trace and repairing state manually. Only 13% of respondents said they were very confident in observing and debugging AI workflows at scale. Visibility alone is not the same as a safe recovery.

To illustrate, I use a synthetic $2,500 payout with a real Temporal workflow and a local language model. The nine-stage example reserves funds, asks an agent to investigate a suspicious transaction and prepare a brief, and waits for a human to approve or reject it.

I intentionally stop the worker to simulate a crash. Without preserved workflow state, the external bank may still have reserved funds while the application has lost the information needed to proceed. A team would need recovery, retry and reconciliation logic to handle that mismatch.

Temporal’s durable execution approach records workflow progress in an event history. The workflow makes deterministic decisions; nondeterministic or side-effecting work such as model and bank calls runs in activities. A human approval arrives as a signal and can be recorded even while no worker is running.

When a worker resumes, it can replay the recorded history and continue from completed work. A call that was in flight when the worker died may need a retry; completed activities need not be repeated. That distinction matters for both external effects and the cost of rerunning model calls.

In the live example, I enter the synthetic payout details, trigger the investigation and stop the worker before approving. The approval signal is recorded while the worker is down. The live restart takes longer than expected, so I switch to a recorded demonstration to show the intended continuation.

The recorded event history shows the completed AI activities, the approval signal and the later bank-submission step. I explain that new workers pick up the workflow without repeating completed model work. This example demonstrates the particular workflow shown, not a guarantee that every integration is automatically safe.

I relate the demo to survey concerns: state, debugging, cost, retries, human approval, long-running work and crash recovery. In the example, replay restores workflow variables and a configured retry policy handles eligible failures. External operations still need appropriate handling when an activity is retried.

The agent’s role is bounded: it provides advice, while the workflow owns the transaction and a person approves it. In the demonstrated design, if the model cannot produce a brief, the payout workflow can continue with a fallback for human review. The example separates the AI component from the money-moving process.

The same history can support debugging and replay, reducing the gap between the record an engineer inspects and the state used to resume work. I also mention OpenAI Codex and Replit agents as production users of Temporal; those are examples I cite in the talk.

A bad model response can be handled as an activity failure and retried according to a policy. My closing argument is that agent reliability needs both observability and a way to preserve progress and recover. The survey details are available in Temporal’s State of Development report.