Memory, context, and recovery

A model’s context window contains the instructions and data available during one inference. An agent runtime assembles that context from system policy, the user goal, recent events, summaries, retrieved evidence, and tool definitions. The window is finite, and including more material can make relevant constraints harder to locate.

Do not append every raw observation forever. Instead, maintain structured state outside the prompt and build a task-specific view. For a research agent, the model may need the required fields, unresolved gaps, compact evidence entries, recent tool errors, and remaining budget. Full page text can stay in an artifact store and be retrieved when needed.

Compression introduces risk. A summary might drop a caveat such as “price excludes tax.” Preserve critical facts in typed fields with provenance instead of relying only on prose summaries. Mark summaries with their source event range and version so they can be regenerated.

Task state should be explicit and serializable. A practical record might include:

• task ID, owner, goal, and authorization scope;
• plan items and status;
• evidence objects with source IDs;
• action events and tool-result references;
• generated artifacts and versions;
• budgets consumed and remaining;
• checkpoint version, current status, and stop reason.

This state supports inspection and restart. It also prevents cross-task leakage. Supplier facts from one customer’s confidential project should not silently appear in another customer’s run.

Use optimistic versioning or another concurrency control when multiple workers can update the same task. Without it, a delayed tool result might overwrite newer progress. The state transition should say, for example, “apply observation to checkpoint version 12”; if the current version is 14, reconcile or reject rather than writing blindly.

Longer-lived agent memory may store user preferences, reusable facts, prior outcomes, or learned procedures. Retention is not automatically beneficial. Stored information can become stale, conflict with current instructions, leak across accounts, or preserve data the user expected to disappear.

For every memory category, define:

• why it improves a future task;
• who can read, correct, and delete it;
• how provenance and time are recorded;
• when it expires or is reverified;
• whether the user has consented;
• how tenant boundaries are enforced.

“The user prefers concise weekly reports” can be a transparent, editable preference. “The vendor is trustworthy” is a risky conclusion if it lacks date, evidence, and scope. Prefer source-linked facts over broad judgments.

Retrieval from memory is also an action that should be logged. The final result should distinguish a fact retrieved from current evidence from a preference or fact carried from an earlier task.

An agent cannot recover well from a generic “something went wrong.” Normalize failures into categories:

• transient timeout or rate limit;
• authentication or permission denial;
• malformed action arguments;
• resource not found;
• ambiguous or conflicting evidence;
• policy rejection;
• corrupted or incompatible state;
• exhausted budget.

Each category gets a bounded response. A transient timeout may retry with backoff. Invalid arguments may be repaired once after returning validation details. Permission denial should not trigger repeated attempts or attempts through another tool. Conflicting evidence should become visible state and may require review.

A retry is appropriate only when repeating the operation could produce a different safe outcome. Retrying a permanent permission_denied error wastes time and may resemble abuse. Retrying an external side effect is dangerous unless the operation is idempotent.

Create checkpoints after meaningful transitions: a tool observation is validated, an artifact is written, or approval state changes. Store enough information to resume without replaying successful side effects.

Suppose an agent creates a draft issue in a project tracker, then crashes before recording the returned issue ID. On restart it may create a duplicate. Prevent this with an idempotency key derived from the task and action, and record intent before execution:

1. persist issue_create proposed with idempotency key;
2. call the tool;
3. persist returned external ID and succeeded;
4. continue from the new checkpoint.

If the process fails between steps two and three, recovery queries by idempotency key instead of blindly creating again. For tools without idempotency support, use a reconciliation step or require human review before replay.

Recovery does not always mean automatic continuation. After repeated timeouts, uncertain side-effect status, or state corruption, the safest outcome may be needs_review. The handoff should include the goal, completed work, evidence, attempted actions, exact failure, external effects that may have occurred, and recommended next step.

Avoid claiming success because a tool request was accepted. Verify the result. Avoid discarding partial work because one step failed. A resumable architecture preserves supported findings while clearly marking gaps.

One concrete anti-pattern is an endlessly growing chat transcript treated as database, audit log, and memory at once. It is hard to query, difficult to redact, and fragile under truncation. Separate structured state, append-only events, large artifacts, and model context. Then each layer can have appropriate integrity and retention controls.