State, memory & recovery

Pause. Approve.Resume properly.

Keep the work intact when a task pauses or a connection fails. Preserve state, recheck permissions and resume without blindly repeating completed actions.

Explore the capability
ENGINEERING FOCUS
01Checkpoint the task
02Wait for approval
03Recheck and resume

A conversation is not a state machine.

The workflow needs a reliable record of what was requested, what succeeded and what remains. Reusable memory is a separate decision: what should be retained, for whom and for how long?

01

Track the work.

Persist task state and checkpoints. Use operation identifiers and reconciliation to distinguish a retry from a new action.

02

Control what is remembered.

Scope memory by user or project. Track its source, version and retention. Sensitive or stale information should not quietly acquire permanent authority.

03

Recover with context.

Recheck permissions, current data and approval validity before resuming. Provide cancellation and an operator-visible path out of a stalled task.

A possible workflowIllustrative example.

A draft waits overnight for approval. On resumption, the workflow rechecks access and avoids creating a duplicate record.

Stored state means stored data. Choose a persistence model that meets the actual retention, residency and deletion requirements.

A closer look

Good questions.
Straight answers.

Is memory the same as model training?

No. Application memory stores information for later retrieval. It does not necessarily change the underlying model.

Can every action be retried safely?

No. Some actions need idempotency support or a check of the target system before retrying. Design recovery around the actual operation.

Technical reference: Anthropic: managed agent sessions (opens in a new tab)