Context and Memory Management for Claude Applications and Agents

A Claude application should treat active context as a bounded, task-specific working set and durable memory as explicit application-owned state. Put only the instructions, evidence, recent decisions, and tool results needed for the current step into the model's context window. Persist facts, user preferences, workflow state, and source records outside the model with ownership, access, retention, and provenance controls; retrieve only the subset relevant to a later request.

Control long-running work with a lifecycle: observe context growth and quality, remove or summarize stale material, prune bulky tool output after extracting durable facts, compact only with traceable loss, and isolate unrelated or specialized work in subagents or separate workflow steps. Neither a large context window nor Claude Code project memory creates hidden permanent model state. The application must decide what is stored, what is selected, and what is allowed back into active context.

Architecture Overview: Four Different Kinds of State

The context window documentation describes the bounded space available to a model request. That space may include instructions, messages, examples, retrieved material, tool definitions and results, and generated content under the current request contract. Limits and accounting vary by model and feature, so the architecture should rely on current documentation rather than a permanent numeric assumption.

Separate four kinds of state:

State type	Lifetime	Owner	Appropriate contents
Active context	Current request or working conversation	Application or agent harness	Instructions, relevant evidence, recent decisions, current tool results
Transient workflow state	Current multi-step operation	Workflow controller	Step status, correlation IDs, pending actions, intermediate artifacts
Durable application memory	Across sessions or operations	Application data layer	Approved facts, user preferences, entity state, summaries with provenance
Source-of-truth records	Business-defined retention period	Owning system	Authoritative documents, transactions, identities, permissions, audit evidence

The model does not become the owner of any row merely because the data appears in a prompt. Active context is a projection assembled for the current task; durable memory and source records remain governed outside it.

Context is not storage

Information in a request can influence that response, but the model should not be assumed to retain it as an application database. A later request has only the context supplied through the supported interaction. If continuity matters, the application must persist the necessary state and deliberately reintroduce an authorized representation.

Memory is not automatically context

Persisting a fact does not mean every future request should receive it. Retrieval and selection are separate decisions. A memory item should have an owner, scope, provenance, sensitivity classification, freshness or validity signal, and deletion policy. The context builder then selects only items that are relevant and permitted for the current user, tenant, task, and step.

Design a Context Assembly Pipeline

Context quality depends more on selection than accumulation. Anthropic's context-engineering guidance emphasizes finding the smallest useful set of tokens for the desired behavior. A practical pipeline can assemble context in this order:

Establish the current objective, output contract, and trust boundary.
Add stable instructions required for this task.
Load current workflow state and the most recent unresolved decisions.
Retrieve source records or memories by relevance, authorization, and freshness.
Add tool definitions and only the tool results needed for the next decision.
Reserve space for the expected response and any supported reasoning behavior.
Record which sources and memory items were selected so the decision can be diagnosed.

This is an application architecture recommendation, not a promise that one ordering suits every model or task. Prompt wording and component placement belong to prompt engineering; context architecture decides which governed information is eligible to be present.

Select by relevance, authority, and recency

Similarity alone is not a sufficient retrieval rule. A semantically close memory can be stale, unauthorized, contradicted by a source-of-truth record, or irrelevant to the current workflow state. Rank or filter candidates using dimensions such as:

task relevance;
source authority and provenance;
user, tenant, and role authorization;
creation and last-confirmed time;
workflow or entity scope;
conflict with newer records; and
expected value relative to token cost.

When records conflict, preserve the conflict for application or human resolution rather than asking the model to choose silently.

Detect Context Drift and Bloat

Context bloat is growth that no longer contributes enough value to justify its attention and token cost. Context drift occurs when stale assumptions, repeated summaries, irrelevant history, or conflicting instructions pull the work away from the current objective.

Useful signals include:

token use grows while task quality stays flat or falls;
the model repeats resolved history instead of acting on current state;
old requirements reappear after a decision changed;
duplicate summaries disagree;
unrelated tool output dominates recent context;
the agent asks for information already present but poorly organized; and
outputs cite stale memory instead of authoritative current records.

These are diagnostic indicators, not proof of a single cause. Evaluation and trace analysis should determine whether the issue comes from context selection, prompt design, model behavior, a tool, or an application defect.

Observe the context builder, not private reasoning

Log application-owned evidence: source identifiers, memory versions, selection reasons, token estimates or usage, tool-result sizes, pruning decisions, compaction events, and workflow step boundaries. Do not claim access to hidden model state or private reasoning. The observable system is the request assembled by the application and the response and metadata returned through documented interfaces.

Prune Tool Output Without Losing Durable Facts

Tool results are a common source of context pressure. Search results, logs, repository listings, query output, and document extracts can be useful for one step but excessive afterward. A safe pruning process separates the raw artifact from the facts that future steps need.

For each large result:

Preserve the raw artifact outside context when retention and security policy allow it.
Extract decisions, identifiers, citations, or unresolved questions needed later.
Record provenance that links the extracted facts to the source artifact.
Replace or remove the bulky result only after the next-step requirements are known.
Make the original retrievable when later verification is necessary and authorized.

Do not prune merely by age. A short old constraint may be more important than a large recent log. Pruning should use task value, authority, and future verification needs.

Use context editing as a controlled mechanism

The current context editing documentation describes supported mechanisms for managing eligible stale context as a conversation grows. Treat context editing as one implementation option inside the lifecycle, not as a substitute for application-owned state design.

Before enabling it, verify the exact model, API, trigger, eligible content, and interaction with other features. Define what information must never be removed without an external record. Observe when edits occur and test whether the retained context still supports the task.

Compact Long-Running Context Deliberately

Compaction replaces detailed prior context with a smaller representation. It is useful when the work must continue but the full history no longer fits the desired working set. It is also lossy: a summary can omit conditions, uncertainty, rejected alternatives, or source provenance.

A compaction record should preserve:

current objective and completion criteria;
confirmed decisions and their owners;
unresolved questions and blockers;
authoritative source references;
state needed to resume the workflow;
safety, privacy, and authorization constraints; and
a pointer to retained raw history where policy permits.

Validate compaction by resuming a representative task from the compacted state. If an engineer cannot tell what remains true, what is uncertain, and where evidence came from, the summary is too aggressive.

Keep summaries versioned and replaceable

Do not accumulate summary after summary indefinitely. Mark the input range, generation time, schema or format, and source references for each compacted artifact. When the underlying facts change, replace or invalidate the summary. A compacted narrative without provenance can become a durable source of drift.

Isolate Work with Subagents and Workflow Steps

Isolation can protect the main context from specialist detail. The Claude Agent SDK documentation provides the current development surface for agent workflows, while Anthropic's context-engineering guidance discusses subagents as a way to separate context-intensive work.

Use a subagent or separate workflow step when:

a bounded task needs a large specialist context;
only a concise result should return to the coordinator;
different tools or permissions are appropriate;
parallel work would otherwise mix unrelated evidence; or
a clean context improves failure isolation.

Define the handoff contract before delegation: objective, allowed sources, tools, output form, provenance requirements, and stop conditions. Return a typed result or concise evidence package rather than the entire specialist transcript.

Isolation is not always beneficial. A small linear task may lose more through handoff than it gains from a separate context. Agent and workflow architecture determines whether delegation is appropriate; this article defines the context boundary once that choice is made.

Keep Prompt Caching Separate from Memory

Prompt caching can reuse eligible processing for stable repeated prefixes under the current feature contract. It is an optimization boundary, not durable memory. A cache does not decide which facts are valid, retrieve user history, enforce authorization, or replace the application's source-of-truth storage.

The context architect should identify stable prefix boundaries and coordinate them with content selection. The model-selection and cost process determines whether current cache behavior improves economics. Any cached prefix must still contain only data authorized for the current reuse scope, and eligibility, lifetime, accounting, and feature support must be rechecked.

Do Not Confuse Claude Code Memory with Application Memory

Claude Code has documented instruction and memory behavior, including CLAUDE.md, described in How Claude remembers your project. Those files and supported memory scopes help Claude Code operate in a development environment. They are not a production application's user-memory database, conversation store, authorization system, or business source of truth.

Keep the boundary explicit:

Claude Code project guidance belongs to the repository and development workflow;
application memory belongs to the application's governed data architecture;
active Claude API context is assembled for a request; and
business records remain in the systems that own them.

Copying production user data into project memory to create “continuity” would blur access, retention, and environment boundaries. Use an application memory service or owning business store instead.

Context and Memory Lifecycle Controls

Every context or memory class should have a lifecycle:

Stage	Context control	Durable-memory control
Create	Label source, trust, task, and expected lifetime	Record owner, provenance, scope, sensitivity, and purpose
Select	Filter for relevance, authorization, freshness, and token value	Retrieve through explicit query and access policy
Use	Preserve source identity and isolate untrusted content	Avoid mutating authoritative records through model inference alone
Observe	Track size, selected items, pruning, compaction, and outcome	Track reads, writes, conflicts, staleness, and deletion obligations
Update	Replace stale context and invalidate superseded summaries	Version or reconcile facts against source-of-truth systems
Remove	Clear after task completion or policy trigger	Apply retention, user request, and legal or business policy

This lifecycle makes memory debuggable. When an output is wrong, the team can ask whether the needed fact was absent, an unauthorized item was selected, a stale summary overrode a current record, or compaction removed a critical condition.

Common Context and Memory Mistakes

Treating the context window as a database. Persist required state explicitly and rebuild authorized context for each task.
Retrieving by similarity alone. Relevance must be combined with authority, freshness, scope, and access control.
Keeping all tool output. Preserve raw evidence externally and retain only the facts needed for future steps.
Pruning without provenance. A summary that cannot be traced to evidence is difficult to verify or correct.
Compacting repeatedly without invalidation. Layered summaries amplify omissions and stale assumptions.
Assuming a larger context solves drift. More tokens can carry more irrelevant or conflicting material.
Using prompt caching as memory. Caching optimizes eligible repeated processing; it does not own state or retrieval policy.
Confusing Claude Code memory with application memory. Development instructions are not production user or business state.
Claiming hidden persistent model knowledge. Design only around state the application stores and context it can observe supplying.
Delegating without a handoff contract. Subagent isolation helps only when objectives, tools, evidence, and outputs are bounded.

Relevance to Claude Certified Developer – Foundations

The CCDV-F Context Engineering scope covers context versus durable memory, context-window management, drift and bloat, tool-output pruning, compaction, and isolation through subagents or multi-step workflows. Agent Patterns and Frameworks adds the need to manage memory and context within agent systems, while token management makes context selection an operational resource decision.

The durable skill is deciding where state belongs and how it moves: an owning system persists authoritative records; a memory layer stores governed reusable state; a context builder selects a bounded working set; and an agent or workflow isolates specialist work when that improves control. Current model limits and feature behavior may change, but those ownership boundaries remain reviewable.

Conclusion

Reliable context engineering is selective, observable, and explicit. Keep active context small enough to serve the current task, preserve durable state outside the model, retrieve by relevance and authority, prune tool output without losing provenance, compact with known loss, and isolate specialist work behind a clear handoff.

No Claude surface should be treated as hidden permanent memory. Application state, Claude API context, Claude Code project memory, prompt caches, and source-of-truth records have different owners and lifecycles. Keeping them separate reduces drift, data leakage, token waste, and debugging ambiguity in long-running Claude applications and agents.