Written by: Andrew Wilson, Senior Technical Solutions Architect
The demo everyone claps for
The demo is familiar: an agent reads a statement, flags a discrepancy, drafts a correction, and the room applauds. It rarely answers the harder question: what happens when the machine dies at 2:47 a.m., halfway through step three of nine
A demo runs for ninety seconds. A production workflow may run for months. Servers reboot, APIs time out, deployments happen mid-task, and human decisions arrive days later. What matters is whether execution survives.
That is the role of durable execution: recording workflow progress and recovery data outside the running process. If the worker disappears, another can continue without starting again. It draws the line between an agent that can be demoed and one that can be operated.
Why agentic workflows need it
Agents create three challenges
- They are probabilistic. Repeating a model call may produce a different result. Recovery cannot simply replay every instruction.
- They are long-running. A reconciliation may run overnight. An onboarding case may pause for a week awaiting approval. Neither belongs in process memory.
- They produce side effects. Agents may send messages, create cases, update a ledger, or initiate payments. A failure can occur after acceptance but before the workflow records the response. Retrying without deduplication can duplicate the effect.
An operator needs to know what outcome was committed, not merely whether the code ran.
What durable execution does and does not guarantee
A durable workflow records progress and inputs in a durable store, then uses that history to recover. Four concerns matter:
- Recovery points: completed work is recorded so the workflow can resume. “The function returned” is not necessarily “the business effect committed.”
- Idempotency: externally visible operations receive stable business keys, and the receiving system recognizes a retry. This supports effectively-once outcomes when the receiver participates in the design; it does not make arbitrary calls exactly-once.
- Coordination: timers, queues, approvals, retries, timeouts, and escalation state outlive the worker. The workflow must remain parked until approval arrives.
- History and replay: execution history supports recovery, diagnosis, and audit. Non-deterministic or external steps need recorded results, versioning, or an explicit re-evaluation policy.
In financial services, durable execution is not a substitute for ledger transactions, payment controls, or reconciliation. It coordinates them and makes decisions recoverable.
The discipline is not new: reliable systems make important state explicit, durable, and reviewable. Durable execution gives exception handling the persistence it depends on.
What failure looks like in a bank
Reconciliation is a natural candidate for agentic automation: it is repeatable, exception-heavy, and often scheduled. Accenture’s Top Banking Trends for 2026 reports that 57% of banking IT executives expect AI-agent adoption to be broad or fully embedded in risk, compliance, and fraud detection within three years. It also cites 56% expecting broad adoption in credit assessment, loan processing, and KYC-related functions.
Those figures are forecasts, not proof of readiness. They raise the architectural bar: an overnight reconciliation agent needs a recoverable unit of work, clear retries, idempotent writes, and an operator-visible record.
Onboarding has a different failure shape. A workflow may fan out across identity verification, sanctions screening, and ownership checks, then pause for a maker-checker decision. If approval takes a week, it must persist its waiting state. Re-running the case is slow and potentially unsafe.
In a regulated institution, “the process died and we re-ran it” is not enough. The institution needs to know which inputs, decisions, effects, retries, and approvals shaped the result.
How we apply the pattern at Finaira
At Finaira, workflow history is the durable source of execution state; process memory is disposable. No engine can infer the correct business transaction boundary for us.
Our principles are:
- Persist state at meaningful boundaries, including waiting, approval, timeout, and escalation states.
- Assign stable idempotency keys to side effects and make receiving systems enforce deduplication wherever possible.
- Separate model decisions from business actions. A model may recommend a correction; a governed service or human approval determines whether it is committed.
- Classify failures: retry transient infrastructure failures with bounded policies, park unavailable dependencies or decisions, and escalate when risk policy requires it.
- Treat execution history as an operational record, with required access, retention, redaction, and segregation controls.
An execution history is not automatically a compliant audit trail. It becomes evidence only when its integrity, provenance, access, retention, and data-handling rules are tested.
What the customer actually gets
A bank buys the ability to operate a workflow within controls, recover it, prevent duplicate effects, pause for judgment, and explain the result. “Durable execution” alone is a feature name, not a purchase order.
The architecture review starts with a standard failure-mode question: what happens if the worker disappears immediately before or after each external effect? The answer should identify the recovery point, idempotency key, reconciliation path, owner, and evidence.
If those answers are missing, a more capable model will not fix the production problem. It will just make the failure louder.
What it costs and where it belongs
Durable execution adds storage, integration work, and discipline. Teams must model state machines, define boundaries, test crash points, and operate recovery, not just the happy path.
Not every interaction needs it. A stateless chat response usually does not. The case changes when an agent can change a system of record, trigger a financial action, wait on a human, or carry a regulatory obligation. Then durability is part of the safety case.
The least interesting part of agentic AI is often the part that determines whether it works. In financial services, that is exactly where the expertise belongs.
References
- Accenture, “Top Banking Trends for 2026”
- Antonio Gulli, Agentic Design Patterns, Chapter 12, “Exception Handling and Recovery”