Context Engineering and Memory Management for Production Agent Systems

anthropic · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Production AI agent context and memory management

Anthropic's Applied AI team needed a way for production agent fleets to improve on organization-specific tasks over time. Raw model intelligence did not carry enough local task, codebase, preference, and failure context, while naive context injection and in-band memory hit context-window, concurrency, staleness, and governance limits at production scale.

Constraints:

• Context must steer agents without overloading the model context window.
• Memory updates must remain safe when many agents and humans collaborate over long-running workspaces.
• Organization-wide memory must be protected from stale, incorrect, or malicious updates.
• Continual learning should improve future runs without taking too much capacity away from the current task.
• The memory substrate should stay portable across product surfaces and agent systems.

Architecture

Anthropic describes a layered memory architecture: session agents use markdown/file-system memory for normal in-band recall and updates; production guardrails add versioning, hashing-based concurrency control, permissions, and portability; and an out-of-band 'dreaming' process batches transcripts and memory stores into a separate review workflow that proposes memory changes with human acceptance.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  session-agents["Session agents"] --> file-system-memory-store["File-system memory store"]
  session-agents --> memory-guardrails["Memory guardrails"]
  transcript-analysis-subjects["Transcript analysis subjects"] --> dreaming-orchestrator["Dreaming orchestrator"]
  file-system-memory-store --> transcript-analysis-subjects
  dreaming-orchestrator --> human-reviewer["Human reviewer"]
  human-reviewer --> file-system-memory-store

Components

Data flow

During normal sessions, agents read and write file-system memories. Separately, dreaming takes the memory store plus session transcripts and tool metadata, has subject agents analyze them, and lets an orchestrator propose memory-store changes with supporting prevalence evidence for a human to accept or reject.

Why this architecture

The architecture separates fast in-session learning from slower fleet-level memory curation. File systems give agents a simple, searchable memory interface, while dreaming gives dedicated capacity and cross-session visibility to identify recurring failures that single sessions cannot see.

Models used: Claude Code · Dedicated memory/dreaming agents

Scale

• The memory architecture is aimed at many-agent production environments, not single sessions.
  “when I deploy thousands of agents all working off the same memory system. And the solution that we've adopted here is to have this hashing system.”transcript, stated
• The design targets long-running workspaces and codebases that evolve over time.
  “Once you think about scaling those things into architectures with many agents, agents that run over a very long time, situations where you will continue to work and develop on a workspace or code base over a long period of time”transcript, stated

Alternatives considered (roads not taken)

Simple session-start CLAUDE.md context injection only

Rejected because: It was effective but unbounded files create context-window management problems as preferences and organization knowledge grow.

In-band memory curation only

Rejected because: The task agent has split attention and cannot see recurring cross-session or cross-fleet failure patterns.

Unconstrained autonomous writes to shared memory

Rejected because: Incorrect or stale organization-wide writes would propagate to all agents, so production memory needs versioning, concurrency, and permissions.

Patterns

agent-memory (context)

Agents use a markdown/file-system memory store that they can search, index, read, and update, rather than relying only on prompt-injected context.

tool-use-orchestration (orchestration)

The memory interface deliberately leans on ordinary file-system tools such as bash and grep, letting the agent search and progressively disclose relevant memory.

safety-policy-enforcement (governance)

Shared memory writes are constrained by versioning, hash-based concurrency checks, and permissions so one agent cannot casually corrupt organization-wide context.

batch-offline-processing (operations)

Dreaming runs asynchronously and in batch over memories plus transcripts, using dedicated resources to identify recurring patterns and propose memory updates.

human-in-the-loop-gate (governance)

The dreaming process proposes memory changes and supporting evidence, but the individual reviewer decides which memory updates to accept or reject.

Tradeoffs

Memory substrate design

Chose file-system markdown memories over opinionated bespoke memory tools.

Rationale: File systems preserve agent autonomy and progressive disclosure because agents are already strong at searching ordinary files with tools like bash and grep.

Continual-learning path

Chose out-of-band dreaming in addition to in-band memory over forcing the task agent to curate all future memory during the current session.

Rationale: Dreaming spends dedicated tokens on learning and sees cross-session patterns, while in-band agents suffer from split focus and limited visibility.

Autonomous memory writes

Chose guardrailed writes with versioning, hashes, and permissions over fully open autonomous updates to shared memory.

Rationale: The benefits of autonomous memory only hold in production if incorrect, stale, or malicious memory updates can be audited, rolled back, and scoped.

Gotchas (what bit them)

Simple context files can become a new context-management problem.

Root cause: Important preferences and organization knowledge accumulate in files injected at session start, eventually consuming context and becoming hard to manage.

Resolution: Treat markdown memory as a searchable file-system substrate rather than an ever-growing prompt prefix.

Shared autonomous memory creates concurrency and blast-radius risks.

Root cause: Multiple agents may write the same memory, and an incorrect organization-wide memory update would affect every agent reading it.

Resolution: Use versioning, hash checks before commit, and read/write permissions by memory scope.

In-band memory curation cannot see fleet-wide repeated failures.

Root cause: A single agent session only sees its own context and has to split resources between the current task and future-memory improvement.

Resolution: Add out-of-band dreaming with dedicated transcript review and cross-session pattern detection.

Evaluation

The talk reports production observations rather than a formal benchmark: memory effectiveness is judged by repeated-task improvement, faster one-shot task completion, and reduced agent cost/latency.

Metrics: accuracy on repeated tasks · speed and latency · token/cost reduction through better one-shot task completion

Outcomes

• Agents improve on repeated tasks because memory captures prior mistakes and task-specific context.
• Effective memory can reduce speed, latency, and cost by making agents more likely to complete tasks in one shot.
• Out-of-band dreaming provides a path toward fleet-level continual learning across sessions.

The talk positions the design for production fleets with many agents, long-running workspaces, and shared memory systems; it gives thousands of agents as the motivating concurrency example.