Where you prune
matters more than how.
Long-horizon research agents accumulate a lot of context they don't need. Most teams add a pruning step to manage that, then spend effort tuning the scoring rule. Researchers at Adobe Research ran the first comparison of three pipeline positions and found that WHERE the filter sits produces larger savings than which scoring method is used. Simple heuristics cut token usage by up to 73%. No method wins on all three metrics simultaneously.
First surfaced in Tandemly Briefing — 2026-08-09.
Pruning got tuned.
Nobody moved it.
Research agents that retrieve and synthesize across many documents spend a lot of tokens on material that doesn't change the answer. Pruning addresses that. But most of the published work on pruning asks the wrong question.
A long-horizon research agent works by retrieving documents across multiple sub-queries, accumulating context, and synthesizing an answer from that context. The context grows fast. By the time the agent reaches the synthesis step, it may be carrying far more tokens than the model can process cheaply, or more than actually influence the output.
The standard response is to add a pruning step: score each chunk by some relevance signal and drop the bottom fraction. Teams spend considerable effort on the scoring method. Is a simple TF-IDF overlap good enough, or does the agent need a learned model that estimates the marginal value of each document? Papers have compared these approaches on fixed task sets and reported which scoring rule produces better results.
The question almost nobody asked was whether the position of the pruning step matters independently of the scoring rule. Most pipelines do pruning post-retrieval (gather documents, then trim) or pre-synthesis (trim everything just before the final call). Those positions were rarely compared against each other, and almost never while holding the scoring rule constant. When position and scoring method vary together, you can't separate their contributions. The improvement might come from moving the filter, not from upgrading it.
Does where you prune matter, holding how you score constant? The researchers compared three pipeline positions against each other, using both lightweight heuristic criteria and a learned marginal-value model at each position, so the position effect and the scoring-method effect could be read independently.
Three positions.
Two pruning approaches.
The study is the first to hold the task pipeline fixed while varying pruning position, then cross it with two scoring approaches. That design is what separates the position effect from the method effect for the first time.
The researchers built a long-horizon research agent evaluation setup and defined three distinct points in the pipeline where pruning could be applied. At each position, they tested two pruning approaches: lightweight heuristic criteria (simple surface-relevance signals like coverage density) and a learned "marginal value model" trained to estimate each document's incremental contribution to the final answer given the rest of the context.
The three positions form a progression from early to late in the pipeline. Pre-retrieval pruning filters candidate sources before the agent retrieves from them. Post-retrieval pruning trims the returned documents before they accumulate further. Pre-synthesis pruning clears the accumulated context just before the final synthesis call.
The key design move is holding the task pipeline constant while varying these two factors independently. Earlier comparisons changed position and scoring method together, making results uninterpretable. This setup produces six conditions (three positions, two scoring approaches) that can be compared on three metrics: answer quality, token efficiency, and faithfulness to the source material.
Lightweight heuristics use surface signals: coverage density, lexical overlap with the query, basic relevance markers. No training required. The learned marginal value model estimates each document's incremental contribution to the answer given what the rest of the context already provides. It requires training on examples where the outcome of including or excluding each document is known.
The paper evaluates both at all three positions, generating six conditions. This is what lets the researchers separate "where to prune" from "how to score."
Position dominates.
No method wins everything.
Three results come out of the stage-aware comparison. Two support an immediate change in how most teams should configure their pipelines. One is an honest negative result that the cost-aware literature usually omits.
Pre-retrieval pruning cut end-to-end token usage by up to 73% with little degradation in answer quality. The mechanism is compounding: filtering before retrieval reduces what gets retrieved, which reduces what accumulates, which reduces what reaches synthesis. Pre-synthesis pruning only operates on the final stage; its savings don't compound.
Most pipelines do pruning post-retrieval or pre-synthesis by default. Moving the filter to pre-retrieval is a configuration change, not a system rebuild. The paper's result suggests it is also the highest-leverage change available before any scoring upgrade is considered.
The learned marginal value model was competitive with lightweight heuristics on some trade-offs, but it did not consistently outperform them across conditions. Simple surface signals produced up to 73% token reduction at matched or near-matched quality. The learned model requires training overhead; the heuristics require nothing beyond an existing relevance signal the pipeline likely already computes.
For teams weighing whether to invest in a trained pruning model, this result suggests starting with a well-placed heuristic first and measuring the gap before committing to the training overhead.
Quality, efficiency, and faithfulness do not move together under pruning. The configuration that maximizes token reduction is not the one that maximizes faithfulness to source material. No single position-plus-scoring combination dominates on all three. The authors present this as an honest negative result rather than eliding it.
The implication for practitioners: you need to decide which metric you are optimizing before picking a configuration. A pipeline tuned for efficiency may quietly degrade faithfulness. Reporting token reduction alone, without tracking the other two, gives an incomplete picture.
The study evaluates long-horizon research agents specifically. The position-dominance finding may generalize to other multi-stage retrieval pipelines, but the magnitude of savings would need to be measured in each case. The learned marginal value model's training overhead was not profiled in detail, so the cost-benefit comparison between approaches depends on pipeline scale and update frequency.
Move the filter.
Then measure three things.
The result is an immediate configuration change for most research-agent pipelines, plus a shift in how pruning comparisons should be run. Neither requires fine-tuning or new infrastructure to evaluate.
Where to go
from here.
The result is empirical, not prescriptive. Here is where to start applying it in a real pipeline.