Quick answer
Agent Executor’s durability model combines an append-oriented event log with snapshot-backed actor resumption on compatible compute platforms. The log preserves execution history used by the controller; snapshots can reduce the work needed to restore an isolated actor. Together they can help a long-running agent recover after infrastructure failure or a deliberate interruption.
They do not automatically provide exactly-once business actions, valid replay across versions, complete backups, or a correct resumed result. Those guarantees depend on application semantics, external systems, storage operations, and the pinned AX and compute revisions.
Event log, snapshot, and business state are different
| State surface | What it can represent | Main risk |
|---|---|---|
| AX event log | Conversation and execution events used for runtime history and recovery | Loss, corruption, retention mismatch, or incompatible schema |
| Actor snapshot | A restorable compute or filesystem image on a compatible platform | Stale secrets, unsafe files, incompatible runtime, or missing external state |
| Tool system | Orders, tickets, messages, records, deployments, or other side effects | Duplicate or partially completed actions during retry |
| Model and prompt context | Instructions and reasoning inputs for the next step | Nondeterminism or behavior change after a model/version update |
A snapshot can restore a process without rolling back a payment. An event replay can reconstruct runtime state without knowing whether an API call completed just before a crash. Design recovery around these split-brain moments.
What the current repository shows
The sample local ax.yaml uses SQLite for the event log. The Kubernetes deployment guide documents PostgreSQL and expects an AX_EVENTLOG_DSN for an existing database, with an optional bundled PostgreSQL deployment for testing. The same guide requires an AX_SNAPSHOTS_BUCKET for its Agent Substrate path.
Those examples establish supported project paths, not universal production defaults. A production design still needs database availability, authentication, encryption, backup, point-in-time recovery, schema migration, retention, deletion, capacity, and disaster-recovery decisions. A bundled test database is not a production recommendation.
Resumption acceptance tests
Build a failure matrix for a task with one reversible side effect:
- Interrupt before the tool call is emitted.
- Interrupt after emission but before the result reaches AX.
- Interrupt after the tool commits but before the event log records completion.
- Interrupt during event-log append.
- Disconnect the client while the actor continues.
- Restart the AX server while the actor is active.
- Evict or suspend the actor, then restore it from the supported compute layer.
- Upgrade AX with an incomplete conversation, then attempt resume and rollback.
For every point, verify the terminal execution state, log sequence, snapshot version, external side effect, retry count, user-visible response, and operator alert. A passed happy-path --resume command is only the beginning.
Make side effects replay-safe
Every consequential tool call should carry an operation identifier stable across retries. The downstream system should either reject a duplicate or return the prior result. Where that is impossible, record a reconciliation state such as “unknown outcome” and require a read-before-retry or human decision.
Separate retry policy by operation. A read can often retry automatically; an email, transfer, deletion, or deployment may need a confirmation barrier. Cancellation also needs a defined result: stopping the harness stream does not prove an external operation was reversed.
Read the session consistency guide for sequence and client recovery. Use the Preview production-readiness guide for version and migration gates.
Backup and migration questions
Before a bounded rollout, answer these with tested evidence:
- Can the event log be restored to a new runtime without the original cluster?
- Which snapshot objects map to which conversation, actor, image, and code version?
- Are secrets embedded in snapshots, and how are they rotated or deleted?
- What happens when a current binary reads an older log or snapshot?
- Can an operator quarantine a corrupt conversation without affecting other tenants?
- Can legal deletion remove events, snapshots, logs, and downstream artifacts consistently?
- How are abandoned executions detected and reconciled?
The local readiness checklist turns these questions into a release gate.
Frequently asked questions
How does AX support durable execution?
The published design uses an event log for durable execution state and snapshot-backed actor resumption on compatible compute.
Does resume mean exactly once?
No. Exactly-once business behavior requires idempotency and reconciliation in every side-effecting system.
Does every deployment support actor snapshots?
Do not assume so. The repository qualifies compute-layer resumption by compatible platform, and the Kubernetes guide is experimental.
Official sources
Source check: August 12, 2026; AX revision 2bcc1637b3c106c16963c5c5464aedb46c6da031. Verify current storage implementations, resumption protocols, snapshot compatibility, and migration behavior before use.