“The agent remembers that it was working on the refund” is not a recovery plan.

Memory and execution state are related, but they answer different questions:

Memory
= information that may be useful later

Execution state
= what is happening in this task right now
Diagram with two separate paths. Long-term memory is retrieved as candidate information for context assembly and the planner. Durable execution state records the current run, steps, attempts, tool operations, leases and external effects for the runtime.
Memory supplies candidate information. The runtime reads durable execution state to decide what the task can safely do next.

Three stores are often confused#

An agent system commonly has at least three different kinds of information:

StoreQuestion it answersExample
MemoryWhat may help with a later task?A user prefers a short incident summary.
ContextWhat evidence should this model call see now?Current deployment, selected logs, task constraints.
Execution stateWhat has this run done, and what can happen next?Refund operation is unknown; reconciliation is required.

Context is a derived input. It can include retrieved memory and selected run state, but it is not the authority for either. The model sees context. Trusted runtime code decides which evidence is admitted and which state transition is legal.

This distinction becomes important as soon as an agent can call tools, wait for an approval, or resume on another worker. Designing the Context Layer for Production AI Agents covers evidence assembly and the boundary between model context and stored state.

What belongs in memory#

Memory is information whose usefulness can extend beyond the current run. Examples include a user’s preferred report format, a verified service ownership fact, or a concise result that can help a later investigation.

That does not mean “save every conversation.” A memory write needs provenance and a reason to persist. Is this a user-provided preference or an inference? Is it still true? Which tenant or user may retrieve it? Does it contain sensitive data? When should it expire? Can the person correct it?

Memory retrieval returns candidates, not instructions. A previous task summary should not override current policy or trusted system configuration. Retrieved text must retain its source and authority so the context builder can reject stale or untrusted material.

What belongs in execution state#

Execution state describes one logical task and the external effects it may have produced. A practical run may record:

run_id
step_id and step status
attempt number and timestamps
tool operation ID and normalized argument hash
provider account and external reference
approval binding
worker lease and fencing token
last verified outcome
next legal transition

Those fields are not useful “memories” to retrieve into an unrelated future conversation. They are a control record. Updates need explicit state transitions and concurrency rules because two workers may otherwise believe they own the same task.

The transcript can contain a tool result, but the runtime still needs to know whether that result was durably committed. It can contain a plan to call a tool, but a plan does not prove the call happened. It can contain a summary that omits an unknown side effect. None of those messages is a substitute for the operation ledger.

A refund failure makes the difference visible#

Suppose an agent decides a refund should be issued. The payment provider accepts the refund. The worker crashes before writing the provider reference to the local run record. A replacement worker starts from the last saved checkpoint.

The memory store may contain useful facts about the customer or prior conversations. It cannot establish whether this refund already committed. The prompt transcript may end before the response. That also cannot establish whether the provider applied the request.

The execution record needs an explicit state such as outcome_unknown, plus the stable operation ID used for the refund. Recovery queries or otherwise reconciles the provider using that identity. If the refund exists, the worker records the external reference and advances. If the provider proves it does not exist, the system can retry with the original idempotency key where supported. If the result remains ambiguous, the run pauses for manual resolution.

memory: customer preference, prior verified facts
context: current refund request + policy + relevant account evidence
execution state: operation_id, provider status, attempt, owner, next transition

Putting the operation status in memory is dangerous because memory systems are generally retrieved and summarized for relevance. Recovery state must be complete enough to enforce a decision, not merely likely to appear in the next prompt.

The full recovery design, including operation identity and reconciliation, is in Designing Long-Running AI Agents That Survive Failures.

Compaction does not change the source of truth#

Long tasks often compact a transcript or create a handoff summary. That can reduce context size, but it creates a new derived artifact with its own failure modes. A summary can omit an uncommitted tool call, flatten an uncertainty into a fact, or remove the identifier needed to reconcile an external action.

Keep the canonical step and operation state outside the summary. The context builder can include a compact handoff view, but the runtime should load pending operations, ownership, approvals, and next legal transitions directly from the durable record.

When a run resumes, rebuild context from:

  1. The current task objective and constraints.
  2. Verified execution state and open operation status.
  3. Fresh authorized evidence needed for the next decision.
  4. Relevant memory with provenance and validity rules.

Do not replay every old message just because it exists. Do not trust a generated summary more than the records from which it was built.

Give the stores different write rules#

Memory usually tolerates a retrieval-oriented lifecycle: candidate creation, validation, scope checks, expiry, correction, and deletion. Execution state needs stronger transition semantics: compare the expected version, verify current ownership, record the result, and reject illegal transitions.

For example, a useful execution transition might be:

TOOL_PREPARED -> TOOL_RUNNING -> TOOL_COMMITTED
                              -> TOOL_STATUS_UNKNOWN
                              -> TOOL_REJECTED

Only trusted runtime code should make that transition after observing the provider result or completing reconciliation. A model can recommend “retry.” It cannot turn an unknown operation into a failed operation by saying so.

Leases and fencing protect ownership. If worker A pauses, its lease expires, and worker B takes over with a higher fencing token, worker A must not later write a stale result as if it still owned the run. Memory retrieval has no role in deciding which worker is authoritative.

A short review checklist#

When reviewing an agent’s persistence design, ask:

  • Can a future task use this information, or does it describe one active run?
  • Does the value have provenance, tenant scope, freshness, and a retention rule?
  • Can a replacement worker determine whether an external effect happened?
  • Is an unknown provider result represented explicitly?
  • Can context compaction omit or distort a value without changing the durable source of truth?
  • Can a stale worker write after losing ownership?

If an answer about a current action depends on what the model happens to remember, the system has mixed a control record with retrieved information. Separate them before adding a larger memory system.