An orchestrator agent needs to pass the results of a web search tool call (which returned 8,000 tokens of HTML) to a summarization subagent, then pass the summary to a final drafting agent. The orchestrator's context window is being exhausted after three such pipelines in a single conversation thread. What architectural pattern best addresses this?

The best pattern is context distillation at each pipeline stage: the summarization agent's output replaces the raw tool result in the orchestrator's context, so the orchestrator carries only summaries forward rather than raw HTML. Rather than carrying raw tool output forward, the orchestrator records only the distilled summary from the summarization subagent. Each subsequent pipeline stage adds only a compact summary to the orchestrator's context instead of thousands of tokens of raw HTML. This keeps the orchestrator's context bounded regardless of pipeline depth. The gzip-compressed binary content option is wrong because the API does not accept gzip-compressed binary content in tool_result blocks; content must be transmitted as text or base64-encoded data for image types; this approach would fail at the API level. The max_tokens option is wrong because max_tokens controls the length of the model's output, not the size of the input context window; it does not address context window exhaustion from long input. The separate orchestrator instances option is wrong because splitting into separate orchestrator instances does not solve the context growth problem — each instance faces the same problem independently if the same raw HTML approach is used — and adds complexity without addressing the root cause.