State boundaries for recoverable execution

01Define state at the task boundary

Long tasks can fail because of the model, a tool, the network or changing business data. A conversation transcript alone cannot establish which actions completed or which results are stale. An execution framework needs distinct representations for intent, runtime state and artifact evidence.

The Axis architecture discussion starts with a task contract: input references, permitted tools, completion criteria and budgets. Nodes need distinguishable pending, running, completed, waiting and failed states. Outputs reference concrete artifacts instead of treating a natural-language summary as proof of success.

02What events and checkpoints preserve

Events record what happened: a tool was requested, a result arrived, a version was verified. A checkpoint records the resumable state: completed nodes, pending dependencies, input revisions and required context. Linking the two supports both efficient resumption and an explanation of how that state arose.

Durable workflow systems provide a useful engineering reference for event history and replay. Temporal documents the need for generated commands to remain consistent with recorded history during replay. This is a design reference, not a claim that Axis uses the same implementation or offers the same guarantees.

03Replay is not permission to repeat effects

Resuming computation differs from repeating a payment, database write or notification. An external write may succeed even when its response is lost. Retrying a timeout without checking can duplicate the effect. Tool contracts must declare action semantics and how to inspect a previous request.

Possible mechanisms include request identifiers, idempotency keys, pre-write revision checks and result lookup. With a non-idempotent system, inspect external state before continuing, compensating or awaiting a decision. Recoverability means an evidenced next step, not universal automatic rollback.

• Read-only computation: recompute against an unchanged input version.
• Idempotent write: verify the same logical request identifier.
• Non-idempotent action: inspect external facts before resuming.

04Parallel nodes need merge conditions

Parallel agents may return results based on different data revisions. A join must check completed dependencies, compatible output types and valid references. Concatenating prose from conflicting branches merely hides the disagreement.

We treat merging as an explicit step: validate input revisions, check artifact constraints, record conflicts and rerun only affected branches when appropriate. Execution graphs also need loop budgets and termination criteria to prevent repeated attempts without new evidence.

05Test recovery by injecting failures

Recovery should be tested against repeatable interruptions: a lost tool response after success, a worker interruption, a stale checkpoint, changed external data and partial branch failure. Each case needs an allowed final state and effects that must not repeat.

Evaluation records should capture the resume point, extra calls, duplicate writes, artifact revision and final judgment. This note proposes an Axis-related architecture and validation direction; actual guarantees depend on implementation, test coverage and deployment conditions.