Trimming a Tool’s Output Is Three Decisions, Not One

Once you accept that a tool’s raw output should not enter context unchanged, the reflex is to treat trimming as a single technique with one implementation: strip the payload down to what the agent needs and pass along the remainder. That framing hides the actual decision. There is no single trim. There are three distinct strategies, they trade away different resources to buy the reduction, and they fail in different ways when misapplied. Field-level filtering keeps a named set of fields and discards whatever else came back. Summarization hands the raw output to a cheaper model and takes back a condensed version. Reference indirection parks the full payload in an external store and gives the agent nothing but a pointer to it. These are not three flavors of the same move. One is deterministic and free, one is adaptive and costs a model call, and one does not reduce the output at all but defers the entire cost until the agent proves it needs the data. Choosing among them is not a matter of preference. It is dictated by properties of the output itself: whether its shape holds still, how much of it there is, and whether the agent will actually reach for the parts you are inclined to strip.

The reason the choice cannot be left to habit is that each strategy has a failure mode the others do not, and the failure only shows up under the conditions the wrong strategy cannot handle. A fixed field list applied to an output whose shape shifts will silently miss the field it was supposed to keep. A summarization step applied to data that has to be recalled exactly will quietly distort it. Reference indirection applied to a payload the agent needs on nearly every call adds a round trip and an external store for no benefit. Choose by reflex and the system holds up in the case you rehearsed and gives way in the one the reflex never accounted for. Pick by the output’s properties and each piece of tool output gets the reduction its shape actually supports.

Field-level filtering is the deterministic default

The cheapest reduction is the one that involves no reasoning. With field-level filtering, the adapter around the tool holds a declared set of fields the agent depends on. A response comes back, the adapter pulls out only those, drops the rest, and only that pared result crosses into context. Nothing is asked of a model. The extraction is a mechanical walk over the response structure, cheap enough that latency does not move, and it lands on the identical result call after call. That determinism is the point. When you can enumerate in advance the fields that matter, filtering guarantees the reduction rather than hoping for it, and it does so at effectively zero marginal cost. This is why it should be the default whenever it is available: nothing else trims for free and trims the same way every time.

What filtering demands in return is a stable, versioned output shape. The allow list is a static contract, and a static contract only holds if the thing it describes does not move underneath it. Rename a field, bury it a level deeper, or spread it across two keys in a new revision of the interface, and the allow list throws nothing. It quietly stops matching, loses the field it existed to preserve, and the agent carries on reasoning minus something it used to have. Silent and well downstream, it is among the hardest failures to trace: the trim layer reports success, the tool reports success, and the only symptom is that the agent’s answers have quietly gotten worse. Filtering is the right default precisely because it is deterministic, and deterministic is exactly what makes its failure invisible. That is a reason to instrument it, not a reason to avoid it, but it does bound where filtering belongs. It belongs on outputs whose schema you own or whose versioning you trust, and it becomes a liability the moment the shape of the data is something you are guessing at rather than something you control.

Summarization buys adaptability with a model call and a lossy step

When the output’s shape is not stable, a fixed field list has nothing to hold onto, and the reduction has to become adaptive. Summarization gets there by standing a smaller, cheaper model in front of the main agent, ahead of the tool result. It receives the untouched payload plus a short brief on the goal the main agent is pursuing, and sends back a condensed view scoped to that goal. Because the reducer is a model reading whatever arrived rather than a rule matching fixed keys, it adapts to structures a static list could never anticipate. An output that varies across providers, changes between versions, or is generated freeform rather than from a schema is exactly the case summarization handles and filtering cannot. The cost of that adaptability is that trimming is no longer free or deterministic. Each call now carries an extra model invocation and the latency that comes with it, and the reduction is no longer guaranteed to be identical from one call to the next.

The added latency is the obvious cost and usually the smaller one. The arithmetic behind summarization is favorable more often than it looks, because the token pressure removed from every subsequent turn tends to dwarf the cost of the one small call that removed it. A large payload compressed to a fraction of its size pays back the reducer call across every turn that would otherwise have carried the full weight. The subtler cost is that summarization is a lossy, nondeterministic step, and both of those words matter. Lossy means the reducer decides what to keep, and its judgment about relevance can differ from the main agent’s actual need. A field the reducer treated as incidental may be the one the agent required, and once the summary has replaced the raw output in context, that field is simply gone. Nondeterministic means the reducer is a model, so it can compress correctly on one call and distort on the next, and it can introduce a detail that was never in the source. This disqualifies summarization for any output that has to be recalled exactly. Compressing a description down to its gist is what summarization is for. Compressing an identifier, a numeric total, or a value that a later step will act on is asking a probabilistic step to preserve something that has to be preserved precisely, and that is a mismatch between the mechanism and the requirement.

Reference indirection defers the cost instead of paying it

Filtering and summarization are variations on the same underlying move: reduce the output eagerly, at the adapter, before it enters context, and decide up front what survives. Reference indirection does something categorically different. It does not reduce the output at all. It puts the entire payload in an external store and hands back nothing but a short handle to it. The agent proceeds on the identifier alone. If it reaches a point where it genuinely needs the detail, it issues a targeted fetch against that identifier and pulls back exactly what it requires. The distinction is between deciding what to keep and deciding when to pay. Filtering and summarization both answer the question “what part of this output survives into context.” Reference indirection refuses that question and answers a different one: “does this output need to be in context at all, yet.” For a large payload that the agent will probably not need in full, that reframing is the whole win. A cost that would otherwise be guaranteed on every call becomes conditional, incurred only on the calls where the agent actually reaches for the data. Plenty of tasks run to completion and never issue the fetch at all, which means the payload never touches context and never costs a token there.

The condition that makes indirection pay is that the fetch is genuinely uncommon. The strategy trades a cost you would always pay for one you pay only sometimes, and that trade earns out only when the sometimes is rare. If the agent ends up fetching the full payload on nearly every call, indirection has bought nothing and added two things: the round trip to retrieve the data it always needed anyway, and an external store to operate and keep consistent. Under that usage pattern reference indirection is strictly worse than having filtered or summarized the output in the first place, because it pays the reduction machinery’s overhead while delivering the reduction’s benefit almost never. There is also a consistency question that eager reduction does not raise. The referenced payload now lives outside the context as its own artifact with its own lifetime, and if the underlying data can change between the moment it was stored and the moment it is fetched, the agent can act on a copy that has gone stale. Indirection is the right strategy for large outputs that are probably unneeded and stable enough that a deferred read still returns the truth. It is the wrong strategy for outputs that are small, needed on most calls, or volatile enough that a stored copy cannot be trusted later.

The decision is a cascade, not a menu

Because the three strategies map onto distinct properties of the output, the choice among them is not a free selection from a menu. It is a cascade driven by two questions asked in order. The first question is whether the output needs to enter context at all right now. If the payload is large and the agent will probably not need most of it to finish the current task, the answer is to defer: store it, hand back an identifier, and let need pull it back only if it arises. That decision is made before any question of which fields to keep, because the cheapest field to reduce is the one you never brought into context. Only when the output does need to be present does the second question apply: can you enumerate in advance what to keep. A schema you own and version says filter: determinism costs nothing here, and there is no reason to buy an adaptability you will not use. A schema that shifts under you, or one you do not control, says summarize, because a static list has nothing to grip and the model call is what you pay to follow a moving shape.

Read as a cascade, the framework has a clear bias, and the bias is correct. Prefer the cheapest and most deterministic strategy the output’s shape allows, and escalate only when a specific property forces the escalation. Filtering is preferred over summarization not because it is more powerful but because determinism is worth more than adaptability whenever you can have it, and you give it up only when instability takes it off the table. Deferral is considered first not because indirection is the best general answer but because the largest saving available is to not pay at all. The strategies are also not mutually exclusive within a single system or even a single call. A workflow can filter the outputs whose schemas it owns, summarize the ones it does not, and defer the few payloads large enough to be worth an external store. Matching the strategy to the output means doing exactly that, one output at a time, rather than standardizing on one technique and forcing every tool through it regardless of whether its shape fits.

Overtrimming is the failure that trimming itself introduces

Every one of these strategies removes information from the agent’s view on the theory that the information was not needed, and every one of them can be wrong about that. Overtrimming is the failure mode trimming creates that did not exist before: the trim layer drops a field, and a later step turns out to need it. Now the agent has to recover the data it discarded, which means calling the tool again to retrieve what it already had and threw away. That recall is expensive in the obvious way, an extra round trip, and expensive in a subtler way, because a step that expected the field to be present has to be built to notice its absence and go get it. Overtrimming converts the saving trimming was supposed to deliver into a net loss on exactly the calls where the dropped field mattered.

The defense against overtrimming is not to trim less. It is to make what was dropped observable, so that a wrong reduction is a diagnosable event rather than a mystery. A trim layer that records what it discarded, on which call, and what it kept, turns the hardest failure to trace into the first thing to check. When a downstream step produces a wrong answer, the record of dropped fields is where the investigation starts, and the answer is often immediate: the field the step needed was removed upstream. That same record, read over time rather than per incident, is how you detect an allow list that has quietly gone stale. A workflow’s needs drift as it evolves, and a field the agent repeatedly reaches for but never finds in context is a signal that the reduction is now too aggressive for what the agent has become. Without that observability the reduction is a set of silent decisions whose correctness you can only infer from the agent’s degraded output, which is precisely the symptom that is hardest to attribute to a cause. The discipline is to log what you drop, for the same reason you would log any other place where the system throws information away on the assumption it will not be missed.

There is also the case where the correct amount of trimming is none. Trimming is a reduction of information under the assumption that the removed part is not needed, and when the output is already small, or the agent needs nearly all of it, that assumption does not hold and the machinery earns nothing. A filtering rule, a summarization call, or an external store each carries its own cost to build and maintain, and applying one to an output that was never a burden trades a real maintenance cost for an imaginary saving. Trimming is a response to a specific problem, an output large or noisy enough to hurt, and it is worth its own overhead only when that problem is actually present.

The output chooses the strategy

Reclaiming context from a tool’s output is not the act of shrinking a payload. It is a decision, made per output, about which of three fundamentally different strategies fits the shape of the data in front of you. Filter when you can enumerate what matters and the schema will hold still, and take the determinism and the zero cost as the reward for the stability. Summarize when the shape moves and a fixed list cannot follow it, and accept the model call and the loss of exactness as the price of adaptability, keeping it away from anything that has to survive precisely. Defer through a reference when the payload is large and probably unneeded, and let the fetch that rarely fires be the only time you pay. Escalate from the cheapest, most deterministic option only when a specific property of the output forces you off it, combine the strategies freely across the tools in a system, and instrument every drop so that a wrong reduction announces itself instead of hiding in a degraded answer. An agent that treats trimming as one technique will apply it where it does not fit and skip it where it does. An agent that reads the properties of each output and lets those properties choose the strategy reclaims the context it should and keeps the data it must, which is the whole of what trimming was ever for.