Abstract

The Agent Came Back, the Payment Never Left: Evidence-Based Recovery for Long-Running AI Agents Across Restarts, Failover, Migration and Provider Switching

Long-running AI agents survive process restarts, failover, live migration, provider substitution and connectivity loss, but their external operations do not stop when the process does. A payment may already have been accepted. A callback may arrive at the old endpoint. A second runtime may still be active. A quota reservation may be missing from the snapshot. The replacement tool may have different side effects. A restored checkpoint, a new lease or a received callback is therefore not evidence that an operation did not happen, that it is final, or that the new runtime may act. Getting this wrong means duplicate payments, split-brain agents acting twice, overspent quotas and silently lost work.

This disclosure describes a vendor-neutral, non-actuating method for reconstructing recovery state from evidence. The original mandate is kept separate from execution state, and task, instance, generation, logical operation, attempt and external transaction identities are tracked separately. Outstanding operations and their exposure, including spent nonces, reserved quota and pending liabilities, are enumerated before handoff. A new, never-reused execution generation is fenced at the actual effect boundary, in the manner of fencing tokens, so that a stale owner cannot cause effects. Callbacks arriving at old or new endpoints are authenticated, correlated and deduplicated as historical evidence without granting ownership. Authorization use and quota are reconciled across regions so that an unknown reservation is never restored as available. Resumption requires current authority, semantic equivalence of the substitute provider’s tool and proven retry safety; under connectivity loss, only bounded, non-effective work continues. Two separate three-valued verdicts are produced, one for continuation evidence and one for external-outcome evidence, so that an unknown outcome is never rewritten as success, failure or cancellation.

The document provides a 48-stage, six-phase engineering workflow with gated flowcharts, six detailed embodiments, a typeset 20-page mathematical specification (J-M01 to J-M52) with conditional proofs and counterexamples, and 40 engineering checkpoints. It compares the method with durable workflow engines, CRIU and VM live migration, leader leases and fencing tokens, consensus, idempotency keys, webhook signing, distributed rate limiting, API versioning and saga patterns. A non-actuating reference evaluator in Python, JavaScript and Go passes 122 shared synthetic test vectors. It is not a consensus protocol or an enforcement mechanism; the laboratory is synthetic, self-authored and not peer reviewed.

Industry relevance: The problem addressed applies to AI developers building long-running and background agents (for example Anthropic’s Claude Code and Agent SDK, OpenAI’s background execution and cloud coding agents, Google’s Vertex AI Agent Engine, Microsoft’s Azure AI Foundry Agent Service and AWS’s Bedrock AgentCore). It also applies to durable execution platforms such as Temporal, AWS Step Functions and Azure Durable Functions, to cloud providers performing live migration, and to payment and API providers relying on idempotency keys, webhooks and quotas. This industry-relevance statement is AI-generated and does not assert that any named company uses, implements or infringes the disclosed method. Readers are strongly advised to read the original PCT filings before drawing any conclusion.

This disclosure is based on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026, which claims priority from PCT/IB2026/053385, filed April 2026 and publicly disclosed 4 June 2026. The author is open to strategic collaboration, licensing or acquihire discussions.

Keywords: long-running AI agents; persistent agents; background agents; agent restart and recovery; failover; live migration; checkpoint and restore; durable execution; fencing tokens; execution generation; split-brain prevention; stale owner; outstanding operations; late callbacks; webhook correlation; idempotency; retry safety; duplicate payment prevention; distributed quota reconciliation; authorization continuity; provider substitution; tool semantic equivalence; partition tolerance; three-valued logic; AI agent safety.

Suggested CPC classes (for search): G06F 11/1438; G06F 11/2023; G06F 9/4856; G06F 11/1471; G06F 9/526; H04L 67/1095; H04L 67/148; G06N 5/04.


Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS