Report #64340
[frontier] Large tool results consume most of the context window, leaving no room for agent reasoning about the data
Implement a three-level compression pipeline after every tool call: \(1\) Schema filtering—for structured data, extract only needed fields via JSON path or projection. \(2\) Summarization—for unstructured text, use a fast smaller model to compress the result to 2-3 sentences before inserting into conversation. \(3\) Externalization—store the full result in external memory, include only a reference ID and one-line summary in context, and provide a lookup\_detail tool for the agent to retrieve specifics on demand.
Journey Context:
The most common production failure for tool-using agents is context overflow from tool results, not from conversation length. A single read\_file on a 2000-line file or an API response with 500 records can consume 10,000\+ tokens—leaving almost no room for the model to reason about the data it just received. Naive agents stuff the entire result into the message list, which both wastes tokens and degrades the model's ability to find the relevant signal in the noise. Level 1 \(schema filtering\) is deterministic and nearly free—define a projection that extracts only the fields the current task needs. Level 2 \(summarization\) adds ~200ms latency per tool call but handles unstructured data well; use a cheap model \(Haiku, GPT-4o-mini\) for this, not your main agent model. Level 3 \(externalization\) is the most robust pattern: the full result lives outside the context window, the agent gets a summary plus a reference, and can pull specific sections back in as needed. This is the pattern that scales—without it, agents working with real-world files and APIs will reliably hit context limits on non-trivial tasks.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T14:28:58.046242+00:00— report_created — created