Volume X · Managing Context and Trust

Caching a Context, Isolating a Subagent

Context is expensive and bounded, and the last eight lectures have been building agents that consume more of it than a single chat turn ever did — a tool schema here, a search trace there, a whole subagent's worth of exploration somewhere else. This lecture is about two answers to that pressure that look similar but are not: one makes a single context cheaper to reuse, the other stops a context from growing in the first place.

Reusing what you already paid to process

Every turn of a long-running agent conversation resends everything that came before it — the system prompt, the tool definitions, the accumulated history — because a model has no memory between API calls. Anthropic's prompt-caching documentation (platform.claude.com/docs/en/build-with-claude/prompt-caching) describes two ways to avoid reprocessing that repeated prefix from scratch every time. The first is automatic: the growing multi-turn history is cached without any explicit marking. The second is explicit — up to four cache_control breakpoints can be placed on specific content blocks in a request, giving fine-grained control over exactly which sections are cached. Adding more breakpoints does not change what a request costs on its own; billing follows what is actually cached and read, and breakpoints only control the granularity of how the cached content is sectioned.

A cached section has a minimum lifetime: five minutes for the standard ephemeral cache, or sixty minutes for an extended TTL requested explicitly with "cache_control": {"type": "ephemeral", "ttl": "1h"}. Each time a cached section is hit again within its window, the cache is refreshed at no extra cost — a conversation that keeps returning within five minutes keeps its long system prompt warm indefinitely. The pricing shape is the whole incentive: a cache write costs 25% more than an ordinary base input token (at the 5-minute TTL), but a cache read costs only 10% of the base input price. Pay the premium once on the first turn, and every subsequent turn that hits the same cached prefix reads it back at a tenth of the price — a large win specifically on the pattern this whole track's agents fall into: a long, unchanging system prompt and tool-definition block, resent turn after turn, with only a small amount of new content appended each time.

Not letting the context grow at all

Caching answers "this context is expensive to reprocess" by making the reprocessing cheap. It does nothing about a second problem: a context that keeps growing, turn over turn, as an agent explores. Anthropic's account of its own multi-agent research system (anthropic.com/engineering/multi-agent-research-system) describes a different fix — subagent isolation — aimed at that growth itself. Each subagent gets its own context window, with its own tools, its own prompt, and its own independent exploration trajectory; only its synthesized findings return to the lead agent, never its raw exploration trace. The source states the rationale directly: "Each subagent also provides separation of concerns — distinct tools, prompts, and exploration trajectories — which reduces path dependency and enables thorough, independent investigations." The lead agent's own context stays small no matter how much a subagent had to read, discard, and retry to get its answer — that churn is contained in a box the orchestrator never has to hold.

This is the structural half of Lecture 16's orchestrator-worker pattern, seen from the context-budget side rather than the coordination side: the same architecture that lets an orchestrator delegate work in parallel is also the reason the orchestrator's own context does not balloon with every worker's dead ends. And it is not free. The same source discloses that agents in general use roughly 4× the tokens of a plain chat turn, and the multi-agent research system specifically uses roughly 15× the tokens of a single chat interaction — framed by Anthropic explicitly as a cost/value tradeoff, suited only "for tasks where the value of the outcome outweighs the increased performance [cost]." Isolation buys a clean main context by spending tokens elsewhere, not by spending fewer tokens overall.

Where isolation went wrong before it worked

The same source is candid about early failure modes it had to fix before subagent isolation paid off. Early prototypes spawned up to fifty subagents for what were, in fact, simple queries — delegation with no sense of proportion to the task. Separately, subagents duplicated each other's work because task boundaries between them were left unclear, each one independently re-covering ground another had already covered. Both were fixed the same way: giving the lead agent explicit objectives, explicit output formats, and non-overlapping task boundaries assigned per subagent, so delegation stayed proportional to the task and subagents stopped stepping on each other.

Two answers, not one

Put side by side, caching and isolation stop looking like variations on the same idea. Caching accepts that a context will be resent again and again, and makes the resending cheap — a pricing and latency optimization applied to a single, continuously growing context. Isolation refuses the premise: instead of accepting that exploration has to happen inside the context an orchestrator carries forward, it moves the exploration somewhere else entirely, at the price of the token multiplier disclosed above. Cross- referencing Lecture 16's orchestrator-worker numbers again is the point — the multiplier that made multi-agent coordination expensive there is the same multiplier paid here for keeping one context window clean.