How Do You Manage Context in Long-Running Claude Agents (Memory Tool + Context Editing)?

What breaks when a Claude agent runs too long?

A single Claude call has a fixed context window. A long-running agent does not respect that fixedness: every tool call, every result, every reasoning step accumulates. Two failure modes follow.

First, context exhaustion: the agent simply runs out of room and the run fails mid-task. Second, the lost-in-the-middle effect: even before you hit the hard limit, the model attends less to content buried in the middle of a bloated window, so accuracy quietly degrades. Domain 5 of the CCA-F is built around recognizing these two failures and picking the right fix.

The two layers: trim inside, persist outside

Anthropic ships two distinct capabilities for this, and the exam wants you to know they are not interchangeable.

Exam-format facts here are reported by Anthropic from its own evaluation (🟡 reported; the 84% figure is workload-dependent, so reproduce before trusting it on your stack). The capability shapes - editing clears in-window, memory persists out-of-window - are first-hand from the platform docs (🟢 first-hand).

How it actually works: just-in-time context

The design pattern Anthropic recommends is just-in-time context retrieval. Instead of loading everything the agent might need into the opening prompt, the agent stores what it learns in memory and pulls it back only when a step requires it. The active window stays focused on what is relevant right now, which lowers cost and sidesteps the lost-in-the-middle effect.

Worked example - a 100-turn research agent

1. Turns 1-20: the agent runs web searches; each returns a bulky result block. The window fills fast.
2. Context editing fires: as the limit nears, stale search results from turns 1-10 are cleared. The conversation continues instead of failing.
3. But the agent still needs the key finding from turn 7. Before that result was cleared, the agent wrote it to a memory file ("finding_7: vendor X has no SOC2").
4. Turn 60: the agent reads memory, retrieves finding_7, and uses it - even though the original result left the window 40 turns ago.
5. Result: the run completes. Editing kept the window alive; memory kept the important fact.

A name for it: Trim-and-Persist

Trim-and-Persist: a long-running agent needs two context layers that do opposite jobs. The TRIM layer (context editing plus server-side compaction) keeps the active window small by removing stale content. The PERSIST layer (the memory tool) keeps the important content alive by writing it outside the window. Get the split wrong - trimming without persisting - and the agent forgets the one fact it needed at turn 60.

Naming the split makes the exam easier: when a Domain 5 scenario says "the agent lost track of an earlier decision," the answer is almost always a PERSIST failure (no memory), not a TRIM failure.

Why it matters for the CCA-F exam

Domain 5, Context Management and Reliability, is 15% of the CCA-F on its own, but its reach is larger because reliability concepts recur inside the other four domains: a Domain 1 multi-agent question often turns on how sub-agents hand off context, and a Domain 3 Claude Code question can turn on compaction behavior. The distractors in this domain reward precision:

• Confusing the memory tool with RAG (memory carries the agent's own working state; RAG retrieves external reference knowledge).
• Reaching for a bigger model or a bigger window when the real fix is clearing stale tool results.
• Assuming compaction alone is enough, when the critical fact needed memory to survive the summary.

Start at the Claude Certified Architect certification hub for the full Domain 5 blueprint, ground the mechanics on the context window primitive, then go applied with handling long prompts and context update sequencing. For the authoritative API behavior, read Anthropic's own context-management documentation and memory-tool guide before you rely on a specific number.

How to apply it in one sitting

1. Name the failure first. Context exhaustion (the run dies) or quiet accuracy drop (lost-in-the-middle)? The fix differs.
2. Turn on the TRIM layer for tool-heavy agents: server-side compaction as the base, context editing to clear stale tool results.
3. Add the PERSIST layer for anything that must survive a trim: write plans, decisions, and key findings to memory, and read them back just-in-time.
4. Test on a long run, not a short one. These problems only appear past the window limit - a 5-turn demo will never surface them.

Long-running reliability is the difference between an agent that demos well and one that survives production. Trim what is stale, persist what is critical, and the 100th turn behaves like the first.