The agent is stopped. The order is still open. The payment status is uncertain. The customer is waiting.
A kill switch can prevent additional unwanted activity. It does not necessarily restore the service, reconcile the account or undo what happened before containment.
DN’s thesis: autonomous finance needs separate evidence for stopping a system and recovering the business process it affected. The distance between those outcomes is the recovery gap.
What Matters
- Containment and recovery are separate outcomes. Record each against a predefined criterion.
- Reconcile external state. An agent’s memory or completion message does not establish what a payment processor, exchange or ledger recorded.
- Replay can repeat a side effect. Verify the original action and the scope of duplicate protection before retrying.
- Some losses remain. Service restoration does not mean every financial consequence has been reversed.
- Define restart ownership. A green dashboard should not silently substitute for an accountable decision.
- Keep incomplete incidents visible. Recovery statistics that omit unresolved cases can mislead.
Evidence Block
Source review: 13 October 2026. DN has not run a vendor recovery benchmark. The framework and examples below are editorial proposals, not measured recovery times.
NIST SP 800-61 Revision 3 treats incident response as part of broader cybersecurity risk management, including recovery. DN applies that distinction to agent workflows without claiming that the publication certifies financial recovery.[1]
LangGraph documents persistence through checkpointers and stores, supporting continuity and recovery-related workflows. Recorded graph state remains different from independently verified state in external services.[2]
Stripe documents idempotent requests for retrying supported operations. Its API versions have different handling details. This is an example of service-specific duplicate protection, not a guarantee that every agent tool or payment rail behaves the same way.[3]
Evidence boundary: feature documentation supports implementation questions. It does not establish end-to-end recovery performance, universal exactly-once execution or reversal of settled transactions.
The Stop Button Solves Only One Part of the Incident
Imagine a hypothetical trading agent that submits an order, receives a timeout and prepares another request. The operator detects the problem and stops the process.
The first order may already exist at the venue. The second may be queued elsewhere. Local state may contain neither confirmation. Restarting from the last saved step could reproduce the uncertainty or submit another action.
This example is not an incident report. It shows why recovery must begin with evidence about the affected business state, not merely whether the model has stopped generating instructions.
The same issue appears in less dramatic workflows. An agent may update a customer record but fail before creating the audit entry. A restored process can be technically healthy while the records remain inconsistent.
Five States to Keep Distinct
| State | Question | Evidence |
|---|---|---|
| Detected | Has the problem been identified? | Alert, observation or verified discrepancy. |
| Contained | Are additional unwanted actions blocked within the defined scope? | Execution and authority-layer checks. |
| Reconciled | Do we know what happened and what remains pending? | Authoritative external records and unresolved-state list. |
| Service restored | Does the defined service target work again? | Validation against the agreed acceptance criteria. |
| Financially remediated | Which consequences were repaired, compensated or left unresolved? | Accounting, remediation and dispute evidence. |
These states need not form a single neat sequence. Service can resume through manual fallback while financial remediation continues. Report that explicitly rather than declaring the whole incident “resolved.”
A Checkpoint Is Not a Receipt
A checkpoint preserves information about the application at a particular point. An external action can happen between a recorded checkpoint and a later failure.
The practical recovery question is whether the stored state accurately represents the external effects relevant to the next action. Durable storage improves continuity, but the application must still handle the boundary between its own records and other systems.
Test both directions: an external action completed before local confirmation, and local intent recorded before an external action completed. The correct next step depends on what the receiving system can prove.
Recovered memory can also contain the instruction that caused the problem. Restoring it unchanged may restore the failure condition. Preserve evidence while reviewing the repaired workflow and its inputs.
Exactly What Does a Retry Guarantee?
Idempotency can help a service recognise repeated requests for the same operation. Its guarantee depends on the endpoint, key, parameters, retention period and implementation.
A connector that generates a fresh key for every retry may defeat the intended duplicate protection. A multi-step workflow can also repeat one action even if another step is protected.
Do not infer end-to-end exactly-once behaviour from a single API feature. Record where duplicate protection exists, where it does not and how an uncertain result is reconciled.
Where an action cannot be undone, a compensating action is a new operation with its own authority, cost and possible failure. It is not equivalent to erasing history.
DN Recovery Evidence Planner
Review one incident or one simulated failure scenario. Choose “Evidence recorded” only for evidence relevant to the actual configuration and recovery target. This planner does not authorise restart or operate a system.
The script makes no external requests, transmits no inputs and changes no credentials or transactions. Inputs are not persisted by the tool. Ordinary site analytics operate separately.
Measure Recovery With Declared Endpoints
Record timestamps for detection, verified containment and verified service restoration. If the same incident is contained at minute 5 and the defined service is restored at minute 65, the illustrative recovery gap is 60 minutes.
That arithmetic is not a benchmark result. It is only meaningful when the start and end criteria are clear. “Process restarted” and “reconciled service functioning” describe different endpoints.
Track the remaining unresolved actions and losses separately. A service restored by humans is also different from restored autonomous operation.
Averages alone can hide difficult cases. Report the sample size, median, tail durations, ongoing incidents and observation cut-off. Do not assign incomplete cases a zero duration or exclude them without explanation.
A Proposed DN Sandbox Test
- Define the target service. Specify accepted output, authority boundaries and acceptable fallback.
- Create synthetic state. Include known balances, orders or records and an independent reference.
- Inject a controlled failure. For example, lose a response after a mock action succeeds.
- Verify containment. Check that additional unwanted actions do not proceed within the test scope.
- Reconcile effects. Establish completed, pending, failed and unknown operations.
- Exercise recovery. Use the documented procedure, recording human work and additional actions.
- Validate restoration. Confirm the target service and test relevant boundaries again.
- Publish limitations. Describe what the simulation omits and which conclusions cannot transfer to production.
These are proposed tests, not experiments DN has completed. Use mock systems or appropriate sandboxes for consequential actions.
The Economic Cost After Containment
Compute may stop accruing while costs continue elsewhere: specialist investigation, manual processing, delayed service and unresolved obligations.
Record observed labour and direct costs before modelling opportunity costs. A hypothetical revenue loss should not be labelled a measured incident cost.
Recovery capability can therefore matter even when two systems have similar normal-operation performance. The useful comparison is the combined cost and quality of service across normal and disrupted conditions.
The Signal
Look for shorter time to establish authoritative state, fewer unresolved actions and validated restoration with less human effort under comparable failure scenarios.
DN Alpha Thesis
As agents gain consequential authority, recovery evidence could become a procurement differentiator. Systems that make state legible and support controlled remediation may create value beyond normal-operation speed.
This is a conditional thesis. It weakens if consequences remain trivial, failures are cheaply handled by existing systems or recovery claims fail to survive realistic tests.
Methodology and Falsification
DN’s planner organises seven self-reported evidence areas. Known gaps and unknowns remain distinct. The output is not a safety score, a verified maturity rating or a restart approval.
Its checklist is incomplete by design: recovery depends on the service, legal obligations, counterparties and technical architecture. Evidence must remain current and independently reviewable.
Test the thesis through matched simulated failures and documented service targets. If the framework does not improve reconciliation, restoration or evidence quality, revise it. Faster restart that creates duplicate actions does not establish better recovery.
Continue Through the DN Toolkit
- Agent Kill-Switch Guide: containment and residual authority.
- DN Agent Trust Dataset: financial-control evidence.
- Agentic Finance Guide: execution and accountability.
- DN Dictionary: checkpoints, finality and idempotency.
Sources
- NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
- LangGraph: Persistence documentation. Feature documentation, not independent recovery testing.
- Stripe: Idempotent requests. Service-specific API behaviour; consult the applicable version.
Frequently Asked Questions
What is the AI agent recovery gap?
DN uses the term for the interval and unresolved work between verified containment and verified restoration of a defined service.
Does stopping an agent reverse its actions?
No. Completed actions and submitted operations may require separate reconciliation or remediation.
Does a checkpoint prove financial recovery?
No. A checkpoint describes recorded application state. External systems may contain effects that must be checked independently.
Is every retry safe?
No. Check whether the original action occurred and whether the service provides applicable idempotency or duplicate-prevention guarantees.
Can every financial action be reversed?
No. Some outcomes are irreversible or require a separate compensating action, cooperation from another party or a formal dispute process.
Does the DN planner authorise a restart?
No. It organises self-reported evidence. The accountable operator must decide using the actual system and incident context.
What if recovery is still incomplete?
Keep unresolved cases visible, record their age and describe the remaining service limitations. Do not exclude them from reporting.
Is manual service a valid recovery outcome?
It can be, if the predefined service target is met. Report manual fallback separately from restoration of autonomous operation.
Disclosure: DN’s framework, planner and scenarios are editorial work. No measured vendor ranking, recovery guarantee, legal determination or investment recommendation is presented.
