Context Compaction Strategies for Claude Agents

Context compaction strategies are the deliberate techniques architects use to keep an LLM's working memory coherent, accurate, and within window limits as an agentic session grows. Without a compaction plan, a Claude agent accumulates raw tool results, conversation turns, and retrieved facts until attention degrades or the context window fills entirely. Getting this right is not optional at scale; it is a prerequisite for agents that remain reliable beyond the first few turns.

For CCAR-F candidates, this matters directly. Context Management & Reliability accounts for 15% of the exam's 60 items, making it one of the three largest domains alongside Agentic Architecture (27%) and Claude Code Configuration & Workflows (20%).

What goes wrong when context grows unchecked?

Three failure modes appear most often in production and in exam scenarios.

Attention dilution. As context length grows, the model distributes attention across more tokens. Evidence from the middle of a long context window is systematically underweighted relative to content at the start and end. This is often called the "lost-in-the-middle" effect, and it degrades retrieval quality even when no token limit has been reached.

Stale data contamination. In long-running workflows, stale context accumulates when earlier tool results are contradicted by later ones but never pruned. The model may attempt to reconcile irreconcilable facts, producing confident but incorrect outputs.

Window exhaustion. Once the context window is full, either the request fails or the provider silently truncates older tokens. Both outcomes are difficult to detect without instrumentation, and both are avoidable with early architectural decisions.

These are not edge cases. Domain 5 task statements specifically ask candidates to diagnose and pre-empt all three failure patterns.

What are the core context compaction strategies?

Four principal approaches cover the majority of production use cases. Each is appropriate to a different part of the context lifecycle.

None of these is universally superior. The CCAR-F exam rewards selecting the strategy that matches the observed failure mode, not the strategy that minimises token count for its own sake.

How does progressive summarisation work in practice?

Progressive summarisation is the most commonly deployed compaction technique and the one most frequently tested in Domain 5. The approach has three phases:

1. Establish a summarisation threshold, typically a token count at which the oldest N turns are collapsed.
2. At threshold, invoke a summarisation call that produces a structured block capturing decisions made, facts established, and open questions.
3. Inject the summary at the top of the next session using summary injection before new user turns are appended.

A well-designed summary block looks like this:

{
  "session_summary": {
    "decisions": [
      "Switched to batch API for cost reasons",
      "Caching enabled for system prompt"
    ],
    "established_facts": [
      "User database has 4.2M records",
      "Region: eu-west-1"
    ],
    "open_questions": ["Retry policy not yet confirmed"],
    "last_updated": "2026-08-18T10:30:00Z"
  }
}

The structural discipline matters. A free-text summary is difficult for downstream agents to parse reliably. A typed schema lets subagents consume exactly the fields they need without re-reading the full prior session.

The failure mode architects commonly overlook is progressive summarisation without schema validation. Summaries that drift from the original facts introduce the same stale-data problem they were designed to solve, just one layer removed.

How does subagent isolation change the compaction calculus?

Subagent context isolation is a structural approach rather than a compression technique. Instead of shrinking a shared context, it limits which context each agent ever receives.

In a hub-and-spoke architecture, the coordinator holds the canonical state and passes only the relevant slice to each subagent. The subagent's context is narrow by design: it receives task parameters, the relevant facts from the summary block, and the tools it needs to act. It returns a structured result. It never sees the full session history.

This approach prevents context accumulation at source. Each subagent starts with a clean, bounded context rather than inheriting the coordinator's growing one. The coordination cost is real: the coordinator must track what each subagent knows and ensure that handoffs are structured and complete. Dropped fields at handoff are a common failure pattern in poorly designed isolation schemes.

How do MCP tools fit into a context compaction strategy?

Model Context Protocol integration changes the economics of context compaction. When external data lives behind an MCP server, it need not occupy permanent space in the model context. The agent queries the server at the moment of need and lets the result fall out of context after acting on it.

# Avoid loading all relevant documents into context upfront:
# context.extend(load_all_docs())  # expensive, grows unbounded

# Fetch from MCP at the moment of need instead:
result = mcp_client.call_tool("search_docs", {"query": relevant_query})
# Use result this turn; do not persist it into the rolling context

This deferred-fetch pattern keeps the persistent context slim. The risk is latency and availability: each MCP call adds a round-trip, and a slow or unavailable tool stalls the agent. Architects must weigh the compaction benefit against the reliability cost, particularly for tools called repeatedly across many turns.

Domain 2 (Tool Design & MCP Integration) accounts for 18% of the CCAR-F exam and tests exactly this trade-off. Pulling data into permanent context is appropriate when it is referenced many times within a session and is small enough not to crowd out other signal. MCP-fetched data is appropriate when it is large, may change between sessions, or is used only once per turn.

How do you keep context fresh in long-running workflows?

Freshness is a distinct problem from compaction. A compacted context can still be stale if the underlying facts have changed since they were summarised. The two problems require different solutions.

Version-tagged facts. Include a retrieved_at timestamp on any persisted fact block. The coordinator compares timestamps against known data update frequencies and re-fetches when a fact may be stale.

Invalidation hooks. In event-driven architectures, external writes or API callbacks trigger a context refresh at the coordinator level. This is more reliable than polling but requires event-source infrastructure to be in place.

Cross-turn validation. Before acting on a fact that has persisted across multiple turns, the agent runs a lightweight verification call against the authoritative source. This adds latency but eliminates the class of errors where the model acts confidently on outdated information.

All three techniques increase overhead. The exam consistently rewards proportionate solutions: apply freshness validation to facts that are high-stakes and likely to change; accept stale risk for facts that are stable or low-consequence.

How do you trace bad outputs back to context inputs?

Debugging a context-related failure requires treating the context as a first-class audit artefact. Logging only model outputs misses the most important diagnostic signal.

A minimum viable context audit trail includes:

Turn N:
  context_hash: sha256(full_context_sent)
  token_count: 14832
  summary_injected: true (version 3, generated 2026-08-18T09:14:22Z)
  mcp_calls: [search_docs (210ms), read_record (44ms)]
  output_hash: sha256(model_response)

When output quality degrades, comparing context hashes across turns pinpoints exactly when a bad summary was injected or when a stale fact entered the active window. Without this log, root-cause analysis relies on guesswork rather than engineering.

This connects directly to the structured context passing patterns covered in Domain 1. Systems that pass context as typed, versioned objects are far easier to audit than systems that grow context by raw text concatenation.

How do context compaction strategies map to the CCAR-F exam?

Domain 5 (Context Management & Reliability) accounts for 15% of the CCAR-F exam, or roughly nine questions in a 60-item sitting. The domain covers five areas: diagnosing context degradation, choosing a compaction strategy, implementing summarisation with validation, designing freshness checks, and tracing failures back to their context inputs.

The scenario-based format of the exam surfaces the difference between treating compaction as a runtime afterthought and treating it as an upfront architectural decision. Candidates who can name all four strategies but cannot match them to failure modes tend to select answers that address symptoms rather than root causes, which is the wrong answer in most scenarios.

As of 3 June 2026, more than 10,000 individuals have passed a Claude Partner Network certification exam, reflecting how quickly this field is professionalising. Architects who demonstrate systematic context management competence, not just familiarity with the vocabulary, have a measurable edge in that competition.

The concept library at /concepts covers 174 atomic concepts across the five CCAR-F domains, including the full set of context management patterns tested in Domain 5.