Long-running Claude workflows need an explicit context lifecycle. A context window is the request content available to a model for a response, and conversation history, tool definitions, tool results, and output all consume that budget. Design what should remain available for the next decision, what can be summarized or retrieved again, and what must be stored outside the conversation.

Architecture Overview: Preserve Decisions, Not Every Token

Context growth is not merely a capacity issue. As a conversation becomes large, relevant evidence can become harder to locate or compete with stale detail. Call this context degradation or "context rot" as an engineering risk, not as a vendor-guaranteed metric. The response is a context budget: retain durable constraints, current task state, source references, and unresolved decisions; remove verbose traces that no later step needs.

This is separate from evaluation design. Context mechanisms manage what the model can see; evaluations determine whether a system’s behavior satisfies criteria. Do not use a compaction summary as evidence that an output is correct, and do not place a grading policy inside a context-pruning rule.

Set a Context Budget and an Escalation Point

Start with the selected model’s documented context window and output limits. Those limits, as well as feature availability, depend on the selected model and can change. Anthropic’s context-window documentation advises monitoring long-running conversations and identifies server-side compaction as the primary strategy for them.

Set an application budget below the hard limit. Reserve capacity for a useful response, required tool results, and a concise state handoff. Track input tokens, output tokens, tool-result volume, and compaction events per session. The exact threshold is an architectural recommendation that should be calibrated against representative workloads rather than copied from a generic example.

When a workflow crosses its budget, it should compact, retrieve a smaller evidence set, create a durable handoff, or stop and ask an operator to narrow the task. Never silently discard policy constraints or authorization context merely to make a request fit.

Compaction and Context Editing

Anthropic documents server-side compaction for long-running conversations. It also documents context editing for more fine-grained control, including strategies for clearing thinking blocks and tool results; these documented features use versioned beta interfaces and must be rechecked for model and platform support before adoption.

Compaction is useful when the important decision state can be represented as a concise summary with source pointers. As an application-designed provenance and retention recommendation, include a session identifier, the input range it represents, unresolved questions, and references to the original records. For sensitive or regulated workflows, the application owner should apply the same retention and access policy to a summary as to the data it describes.

Clear Low-Value Tool History Carefully

Tool definitions and accumulated tool_result blocks consume the context window. Anthropic documents tool search, programmatic tool calling, prompt caching, and context editing as distinct ways to address tool-context bloat.

Clear a tool result only after extracting the durable facts needed later: a resource identifier, version or timestamp, validation outcome, and a short evidence summary. Do not clear the only record of a privileged action or a safety-relevant failure. As a recommended application audit design, keep a protected log outside the model context when an operator must later reconstruct the workflow.

Persistent State and Prompt Caching

Persistent application state is an architectural choice for information that must survive a session, be audited, or be shared across workers. Store structured task state in an application-controlled system and pass only the current slice needed for the next model decision. The Claude Agent SDK documents sessions that maintain context across exchanges and can be resumed or forked; use the current SDK documentation to verify implementation details for the chosen language.

Prompt caching is a different cost mechanism, not a context-reduction mechanism. Anthropic documents that it does not reduce the number of tokens in context; it reduces the cost of repeated stable prefixes on cache hits. It also does not create durable workflow memory or replace authorization and retention controls. Treat caching configuration and cache economics as version-sensitive operational details and verify them before deployment.

Common Context-Control Mistakes

The common mistake is carrying every raw tool result forward because it might be useful later. This starves the current task of attention and makes failures harder to isolate. The opposite mistake is compressing too early and losing the source reference, policy constraint, or unresolved ambiguity that a later stage needs.

Use a written keep/remove policy for each artifact class. Rehydrate original evidence when a later decision needs it rather than relying on a summary beyond its purpose. Model windows, context-editing capabilities, and tool features are not universal, so make each optimization optional with a safe fallback.

Conclusion

Reliable context control preserves decision-relevant state while limiting accumulated conversation and tool history. Budget capacity, compact with provenance, clear only recoverable low-value content, and keep durable state outside the prompt when it must outlive a turn. Evaluate the resulting behavior separately, with explicit success criteria and diagnostic controls.

Authoritative Sources