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?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because context distillation is the standard architectural solution to cumulative context growth in multi-step pipelines. Rather than carrying raw tool output forward, the orchestrator records only the distilled summary from the summarization subagent.
Full explanation below image
Full Explanation
B is correct because context distillation is the standard architectural solution to cumulative context growth in multi-step pipelines. 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. B 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. D 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. A 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.