The definition of a durable agent
Definition 1.0 · From Durable Agents (2026), Chapter 4 · Last revised
Venkat Chitturi · Founder & CEO, Technoidentity ·
“Durable agent” is a technical category. It has a definition. If your agent has the five properties below, it is durable. If it does not, it is fragile. This is testable.
The distinction is not about capability. A fragile agent can be clever. A durable agent can be less clever and outperform it through reliability. The distinction is about survival.
Why agents are different
When a database corrupts at two in the morning, the system stops loudly. Queries fail. Alarms fire. The on-call engineer is paged. Within fifteen minutes everyone knows there is a problem.
When an agent degrades, the system keeps running. Tickets keep getting routed. Loans keep getting approved. The decisions are systematically worse, and nobody notices for hours, sometimes days. By then the agent has operated in a degraded state at scale, and nobody can say where the good decisions stop and the bad ones start.
That is invisible failure. It is what separates agents from every other kind of software you have run, and it is why durability is the foundation rather than a feature you add once the happy path works.
What a durable agent is not
- Every system works on the happy path. It is not durable until it works on the unhappy one.
- It is not an agent with high accuracy on a validation set. Many of the agents that failed had good accuracy. Accuracy is necessary and not sufficient.
- It is not an agent with a good demo. Demos get buy-in. They say nothing about production.
- It is not an agent on reliable infrastructure. Reliable infrastructure is necessary. The orchestration still has to handle failure.
- It is not more intelligent than a fragile agent. Same model, same data, same prompt. The difference is the system around it.
The Five Properties
One example runs through all five: a claims-processing agent at an insurer. It gathers documents, checks eligibility, runs fraud detection, evaluates medical necessity, calculates the benefit and routes for approval.
- Recoverable01
- Resumable02
- Auditable03
- Replaceable04
- Coordinated05
- 01
Recoverable
A recoverable agent survives infrastructure failure and resumes from exactly where it stopped. No lost work. No manual reconstruction of state. No ambiguity about what happened.
In traditional software, recovery means try again, and that works when the operation is idempotent. Agent workflows break the assumption. An agent that has spent ten minutes reasoning through a case holds that reasoning in a context window. If the process restarts, the context is gone. Retrying is not resuming.
- In the example
- the server dies after the fraud check completes and before the necessity evaluation begins. The agent does not rerun the fraud check. It picks up the necessity evaluation with the fraud result already on disk.
- Without it
- work is lost. Someone reconstructs state by hand. The failure surfaces when a claimant calls three days later asking where their approval is.
- 02
Resumable
A resumable agent pauses mid-workflow, waits as long as it has to, and resumes from that exact point without losing context or corrupting state.
Recoverable handles failure. Resumable handles intent. A person needs to review before the agent continues. A compliance gate needs a signature. A dependent system is down until morning. The agent pauses, waits, and carries on from where it was.
- In the example
- the benefit exceeds the adjuster's authority limit. The agent pauses. A specialist reviews it the next morning, or three days later. They approve. The agent completes the approval from the pause point.
- Without it
- two bad options. The agent completes work it should have waited on. Or the review happens and the whole workflow runs again from the top.
- 03
Auditable
An auditable agent produces a complete, verifiable record of every decision. What went in, what logic applied, what tools were consulted, whether other agents were involved, what came out, whether a person intervened, when, and why.
This is where durable agents live or die in production. Auditability is not a compliance checkbox. It is the architecture of explainability.
- In the example
- six months on, a regulator asks how a claim was approved. One query returns the input documents, every model call and its version, the exact prompt, every tool call, the fraud service's response, the specialist's note, timestamps, confidence. The decision is reconstructable.
- Without it
- you have approval logs and not decision logs. Outcomes and not reasoning. You cannot explain your own decisions.
Why a workflow history is not an audit trail
A durable execution engine records everything that ran: every step, every retry, every result. That is an execution record, and it is valuable. It is not a decision record.
An execution record tells you the fraud check returned a score of 0.31 at 14:23:17. A decision record tells you that the agent, running model version 4.2 under policy version 7, treated that score as below threshold because of rule R-14; that the specialist saw exactly this and approved; and that a proposed action to also adjust the customer’s tier was refused because it was outside the agent’s authority.
The first is a by-product of the runtime. The second is something you design. No platform can design it for you, because no platform knows what your decision is.
- 04
Replaceable
A replaceable agent's model can be swapped without rebuilding the workflow. The architecture is model-agnostic.
Agents built on one model version are trapped. The prompts are tuned to it. The tool bindings assume its behaviour. The error handling expects its failure modes. Upgrading means revalidating the whole agent.
- In the example
- the claims workflow was built on a locally hosted fine-tuned model. A stronger hosted model arrives. Swap the model configuration, adjust the prompt, test the inference path. Orchestration, persistence and routing are untouched.
- Without it
- a model upgrade is an engineering project. You cannot A/B test. You fall behind.
- 05
Coordinated
A coordinated agent takes part in multi-agent systems without race conditions, deadlocks or inconsistent state. Two agents can work on the same object without corrupting it. A handoff from one agent to another carries full context and is guaranteed to arrive.
- In the example
- three agents evaluate a claim in parallel — one for coverage, one for medical necessity, one for benefit. An orchestrated workflow keeps them off each other's work, merges the outputs, and sends disagreements to a person. Six minutes instead of fifteen. No duplicate work. No question of who decided.
- Without it
- coverage says approve. Necessity says decline. Benefit calculates the payout anyway. Three answers, no decision, and no record of which one won.
Two kinds of agent
The five properties apply to every agent. What they demand depends on what the agent does.
An agent that reads, summarises, recommends or routes changes nothing in the business by itself. A person acts on its output. For that agent, tool-calling on a durable execution engine, with human review as a pause point, is the right shape, provided the decision record is designed.
An agent that writes to a system of record — issues a credential, posts an entry, corrects an account, grants access — is different. If it fails halfway, the business has changed. For that agent, Recoverable means compensation and Auditable means a record of authority and refusals. That is the subject of What happens at step four of five.
Why this is a category
- Durability is separate from intelligence.
- You can have a dull durable agent and a brilliant fragile one. Most organisations would rather run the first.
- Durability is achievable.
- Companies are running durable agents today. The category is not aspirational. It is operational.
- Durability requires intentional architecture.
- You cannot stumble into it. You build for it, or you rebuild.
Note on versions. An earlier article by the author described four properties. The book’s five supersede it and are the definition on this page.
Which category are you building for?