A compaction verifier hears only the loud failures. The quiet ones decide the task

Every long-running agent you operate has a moment where it throws away its own history. The context passes a budget, a second model writes a summary of everything older than the last turn, and the summary becomes the only record the agent has of what it already did. Coding harnesses do this. Browser agents do this. The OpenClaw compaction loop the paper adapts is the same loop most of us copied.

What nobody tells you at that moment is what the summary got wrong. You find out later, when the agent pays an invoice twice, re-runs a search it already ran, or files a report with a total that was right three compactions ago. The paper I rebuilt this week puts a number on the first two of those. Right after a compaction, the agent makes 0.108 more blocked calls per action and, a step later, starts repeating calls it has already made. The authors turn that observation into a verifier: restore the environment at the boundary, roll the frozen agent a few steps from the raw history and a few steps from the summary, and score the summary by the extra blocked or repeated calls it caused. Then they use the score to rewrite the compression prompt, and report a 5.7-point accuracy gain and a 7.8-point gain in the share of tasks solved twice in a row.

The verifier is cheap and it needs no labels, and I went in expecting to like it. I still do. What I did not expect was the size of the part it cannot hear. When I restricted my summariser to damage the verifier can observe, it closed 93% of the gap between an unverified summary and an oracle that chooses among the same candidates by finishing the task. When I restricted it to damage the verifier cannot observe, a dropped identifier or a misremembered amount, it closed 16%. The paper's conclusion names silent state corruption as a limitation in one sentence. In my testbed that sentence was most of the result.

By the end of this you should be able to say which of your own agent's compaction failures would make a noise the verifier can count, which would not, and what you have to put beside the verifier before you let it choose a summary on your behalf.

Three things this piece does not do. It does not reproduce the AppWorld numbers: there is no language model, no 4K context window and no API benchmark anywhere in my prototype. It does not evaluate the prompt-rewriting half of the method, because I had no prompt to rewrite. And it does not tell you whether an LLM compressor's mistakes split between the two channels the way my noise model's do, which is the one number I most want and do not have.

The short version

• The idea: judge a context summary where it happens, by what the frozen agent does next from the same state, rather than by whether the task eventually succeeded.
• Why it might work: the paper shows compaction produces an immediate, measurable rise in blocked and repeated actions, and a score built from that rise tracks summary quality without labels.
• What I tested: whether that score, used to pick the best of three summaries at every boundary, recovers the task success a lossy summariser throws away, on 120 synthetic invoice tasks with a scripted agent.
• What happened: at a 48-token budget it cut blocked calls by two thirds and moved accuracy from 42.7% to 44.6%. An end-of-task oracle choosing among the same three summaries reached 69.0%.
• Where it breaks: a dropped invoice id or a wrong amount never produces a blocked or repeated call, at any rollout length, so the score is a coin flip on exactly that damage.
• Decision: wait on the score as a selector or optimiser until a fact check sits beside it; adopt the paper's post-compaction burden metric and Pass² as monitoring today.

Start with the problem

Take a back-office agent settling invoices. It lists the open invoices for a client group, fetches each amount, pays each one, and files a report with the total and the count. Every one of those is a tool call, and every call comes back with an observation that goes into the context. Twelve invoices is 27 steps on the shortest path. At some point the context passes its budget and the harness does what Equation 1 in the paper describes: it keeps the most recent turn verbatim and replaces everything older with a summary.

What can the summary get wrong? Five things, in my task. It can lose an amount, lose the fact that an invoice was paid, lose the fact that the report was filed, lose an invoice id altogether, or remember an amount as a different number. Now watch what the agent does next under each one. Without the amount, it fetches it again. Without the paid marker, it pays again, and the environment refuses, because paying twice is an error. Without the filed marker, it files again and is refused. Those three leave a trace in the tool log that a script can count.

The other two leave nothing. An agent that never knew invoice 1108 existed does not ask about it. An agent that remembers 450 as 460 pays 460, and the environment accepts the payment, because nothing about a wrong amount looks wrong to a payment tool. Then it files a report with the wrong total. No rejected call, no repeated call. The task fails, and the failure is recorded nowhere until the report is checked.

The paper is about the first kind, and it is precise about that. Its verifier counts "observable execution regressions", defined as actions the environment blocks and tool calls that repeat an earlier one. My whole contribution here is to ask how much of the damage is that kind, and the answer in my testbed is: less than half.

The figure's bottom half is the experiment. Everything above it is the paper, and the paper's part is worth understanding properly before I start poking at it.

How the method works

The authors call the method TRACE: Trajectory-Relative Agent Context ComprEssion.

1. Compaction is recurrent, so its damage compounds

The paper's first move is to insist that compaction is not a one-off edit. Once the context exceeds the budget, the compressed replacement becomes the input both to the agent's next decisions and to the next compaction (Equation 1, Section 2.2). A fact that survives one summary has to survive the next one too. On AppWorld's 147-task train-development split with MiniMax-M3 as both agent and compressor, that shows up as pass rate falling with budget and falling fastest on tasks with the longest full-context horizons (Figure 1 in the paper).

One detail from that sweep surprised me, because it contradicts what I would have told you a month ago. Summarising does not beat plain FIFO truncation until the budget gets severe. At 16K, 8K and 4K, dropping the oldest turns matches or slightly beats the summary; only at 2K does the summary win, 72.8% against 42.2% (Section 3.1). AppWorld lets the agent re-query application state, so a dropped observation is recoverable, and what FIFO preserves that a summary does not is the shape of the last few actions. Keep that in mind for later, because my prototype reproduced the ordering and I did not plan for it to.

2. The damage is behavioural, and it shows up immediately

Section 3 is the part of the paper I would send to a colleague even if the method did not exist. Three probes, all with the agent, environment and decision point held fixed.

At the last decision before termination, the summary-conditioned agent at 2K terminates in 44.6% of 10 sampled actions, with 37.3% in the required output form, against 77.2% and 68.1% for FIFO and 66.6% and 60.6% for the full history (Figure 2). The summary makes the agent keep working when it should stop. Across a summary's lifetime, the next-action distribution diverges from full-history behaviour by 0.149 when the recent raw turns are kept, 0.233 when they are compressed into the summary, and 0.289 when they are omitted (Figure 3). Compression keeps some of the effect of recent interactions and attenuates the rest. And in closed-loop continuation from 590 compaction boundaries, the summary produces 0.108 more blocked or error actions than the raw history at the first step, with repeated calls rising from 0.031 at step one to positive for the rest of a five-step horizon (Figure 4, 4,640 rollouts).

That last probe is the mechanism. Blocked first, then refetching: the agent loses its place, hits an error, and goes back to reconstruct what it had.

3. Turn the symptom into a score

Given that, the verifier almost writes itself. At a boundary, take the context before replacement and the context after replacing the older history with a candidate summary, keeping the most recent raw turn. Restore the environment state, roll the frozen agent K steps from each, and mark each action that was blocked or repeated. The burden of a continuation is the count of marked actions over those K steps (Equation 2). The summary's induced burden is the expected POST burden minus the expected PRE burden (Equation 3), and its score is the negative of that (Equation 4). PRE is rolled once per boundary and shared across candidates, so candidates differ only in their own continuation.

def _continuation_burden(self, context, env, agent, rng, boundary) -> int:
    sim = env.snapshot()                              # restore the state at the boundary
    seen = {c.signature for c in sim.calls}           # every call made before the boundary
    ctx = list(context)
    burden = 0
    for _ in range(self.horizon):                     # K in equation 2
        if sim.finished:
            break
        action = agent.act(ctx)
        obs = sim.step(action)
        if obs.error or action.signature in seen:     # blocked, or repeated: the union, once
            burden += 1
        seen.add(action.signature)
        ctx.append(obs)
    return burden

Correctness check: test_verifier_prefers_the_note_without_visible_damage builds two summaries from the same history, strips every payment marker from one, and asserts the verifier scores it worse. test_verifier_cannot_see_a_misremembered_amount adds 100 to one amount in an otherwise clean summary and asserts the two scores are equal at K = 50. Both tests pass, and the second one is the article.

The paper then uses those scores offline. At 12 stratified training boundaries it samples three candidate summaries each, keeps the best and worst by score, hands the 12 pairs and the agent's system prompt to a frozen proposer, gets five rewritten compression templates back, and picks the one with the highest Pass² on the development split (Section 4.2, Equations 5 to 10). The proposer never sees a rollout, an error message or the score decomposition; it sees which summary was preferred and nothing else.

What the research actually shows

The strongest result

Two things to notice. The Pass² gain is larger than the accuracy gain, which is the paper's whole thesis in one column: the optimised prompt makes success repeatable more than it makes success likely. And the gap to uncompressed execution is still 8.6 accuracy points on average and 11.9 on hard tasks. The method narrows the hole compaction digs. It does not fill it.

I read that table three times. A compression template beating no compression on the same model is not something I expected to see, and the authors are careful about it: on medium tasks the transferred prompt beats uncompressed on every metric, including a 20.8-point Pass² gain, while on hard tasks it stays below. My read is that a good summary is doing some of what a good scratchpad does, concentrating state the agent would otherwise have to find in a long raw context. That reading is mine, and my guess is that it explains the medium-task gain better than the hard-task one. The paper offers the table as evidence of transfer and stops there, and with one target model it is right to stop there.

Does the mechanism earn the credit?

The paper's own probes make the behavioural diagnosis credible: the blocked-then-refetch pattern is measured on 590 boundaries with bootstrap intervals, and it is exactly the failure the verifier counts. What the paper does not have is an ablation of the method. There is no arm that optimises the prompt with a trajectory-level signal under the same proposer and selection procedure, so the comparison to ACON, which does use trajectory-level feedback, is confounded by everything else that differs between the two pipelines. Nor is there a version of TRACE with a different K, a different number of candidates, or the verifier replaced by a random preference.

Where the evidence is thin

The paper says "preliminary" in its abstract and "work in progress" on every page, and I think the right response is to take that at face value rather than to score it as a finished result. Two runs per condition, one benchmark, one optimising model, one transfer target. No seeds reported, no intervals on Table 1. The twelve training boundaries are stratified by error type, which is sensible, and also means the prompt was tuned on exactly the failures the verifier can see.

And then there is the sentence I keep coming back to, from the conclusion: the verifier "may not capture silent state corruption." The paper offers no estimate of how much corruption is silent. That is the gap a weekend prototype can get at, so I built one.

Why this paper earned the test

Five candidates on agent context management from the last four months, screened on claim support, baseline strength, causal evidence, production transfer, and testability. One person, one afternoon, and a field that publishes a compaction paper a week, so take the list as a judgement about which mechanism I could isolate, not a map of the area.

TRACE won on one property. Its central claim is that a boundary-local, closed-loop signal captures compaction damage, and that claim can be falsified by building a summariser whose damage you control and asking what fraction of it the signal sees.

Rebuilding the claim

Experimental setup

One task family, synthetic and written for this article: settle every open invoice for a client group and file a report with the total and the count. Three to twelve invoices per task, so the shortest correct trajectory is 9 to 27 steps against a cap of 50. 120 tasks, four runs each, which gives two disjoint run pairs for Pass² and Pass@2.

The environment has five tools and an execution-error contract. Paying an invoice that is already paid is a blocked call; so is filing twice. The environment is copyable, so a verifier can restore the exact state at a boundary and roll forward from it as many times as it likes.

The agent is a script. It reads everything it believes from its context and nothing else, re-reads an invoice it already knows 5% of the time to give the repeat detector something to detect, and works in a shuffled order per run. No language model anywhere.

The compaction loop is Equation 1: when the context passes the budget, keep the latest turn verbatim and replace everything older. Budgets are 24, 48 and 96 tokens against raw trajectories that reach 105, roughly the compression ratios the paper runs at 2K to 8K. Four policies replace the older turns:

The summariser is where the damage comes from, and it is the part I would ask you to read most suspiciously. Every time a fact passes through it, it forgets or corrupts that fact at a fixed rate, independently. The mixed default is 10% for each of the three visible defects, a dropped amount, a dropped paid marker and a dropped filed marker, and 5% for each of the two silent ones, a dropped invoice id and a misremembered amount. Damage compounds across compactions because the next summary is written from the last one. Those rates are chosen, not measured, which is why the experiment that matters most is the one where I vary them.

git clone https://github.com/shravan1996/ship-the-paper-context-compaction
cd ship-the-paper-context-compaction
python3 -m unittest discover -s tests -t .   # 20 tests
python3 eval.py                              # 120 tasks, 4 runs, ~13 seconds, writes results.json

Python 3.14 on an arm64 Mac. No network, no model, no GPU, no third-party package. The run is deterministic given the seeds, and one of the tests asserts that, which I mention because it did not pass the first time. The summariser iterated over a Python set of paid invoices, and set order varies with the hash seed, so two runs of the same episode chose different candidates at the same boundary. One sorted() fixed it. A verifier that ranks three near-identical summaries is exactly the kind of code where a nondeterminism bug looks like a finding, and I would not trust any of the numbers below if that test were not in the suite.

What I expected

Three predictions, written before the run. The verifier would cut blocked and repeated calls substantially, because that is literally what it selects against. It would recover most of the task success the summary lost, I guessed two thirds of the gap to the oracle. And a longer rollout horizon would catch more, because silent damage would eventually turn into a wrong report, which the environment could reject.

The first held. On the second I was wrong by a wide margin. On the third I had assumed something the task design plainly contradicts, and seeing why is the most useful thing in the article.

What happened

Budget 48, 120 tasks, four runs each. Blocked and repeated are per run.

Four things in those numbers changed how I would use this, and only the first was on my list.

The horizon does not help, and it cannot. Why not just watch longer? My third prediction assumed a dropped invoice id would eventually show up as a blocked call, if you only watched long enough. It never does. The agent files a report with fewer invoices than exist, and the environment accepts the report, because a report is not a duplicate write. The only thing that could reject it is a check against ground truth, which the verifier does not have and the paper does not claim. Going from K = 5 to K = 50 costs 1.9× the rollout steps and buys 0.6 points, within noise. I expect the same holds for any environment whose tools accept a wrong value without complaint. The blind spot is the channel. Watching longer does not change which channel you are listening to.

Filtering the loud damage leaves the quiet damage. In the mixed run, the summaries the verifier chose carried slightly more silent defects than the ones it rejected, 0.88 against 0.81, and 61.1% of chosen summaries had at least one against 58.0% of rejected. The effect is small and I would not promise it reproduces. The direction is the one I would watch for in a real system: a selector that removes everything it can see leaves you with a population of summaries that are wrong in exactly the ways nothing downstream will flag. The oracle, which can see outcomes, went the other way: 0.50 silent defects chosen against 1.05 rejected.

Consistent failure looks like stability. FIFO's gap between Pass@2 and Pass² at budget 48 is 6.3 points; the summary's is 21.2. By the paper's framing that makes FIFO the more reliable policy, and it is, in the narrow sense that it fails the same way every time: it drops the invoice list, the agent never learns it is missing invoices, and it files a short report with zero blocked calls. At the loosest budget FIFO beat the summary outright, 90.8% against 85.4%, which is the paper's ordering at 4K and above and which I had not predicted. My summariser is lossy at a fixed rate however little it is compressing, which an LLM summarising a short context probably is not, so I read that as a fact about my testbed. But the Pass² lesson generalises: a low gap can mean stable success or stable failure, and the metric cannot tell you which.

The cheap verifier was not cheap here. 85 rollout steps per run against 51 for the oracle. My tasks are at most 27 steps long, so running to the end is inexpensive, and the verifier pays for three samples of two continuations per candidate at every boundary. The paper's cost case is about 50-step tasks with a language model in the loop and a verifier run at twelve boundaries, once. Nothing in my prototype tests that, and I would expect the ratio to flip in the paper's setting. What I would not expect is for online selection at every boundary, which is how I used it, to be cheap anywhere.

What breaks outside the experiment

Your silent channel is wider than mine

My task has two silent defects and three visible ones. A real agent's summary carries user preferences, file paths, branch names, the reason a previous approach was abandoned, which of three similar records the user meant. Almost none of those produce an error when they are wrong; the agent proceeds, confidently, on the wrong one. The paper's AppWorld setting is friendlier than that, because application state can be re-queried and bad API calls are rejected by contract. If your tools accept whatever they are given, the verifier has less to hear. The control is to enumerate, before you deploy the score, which facts in your summary schema would be rejected if wrong and which would be accepted, and to count the second list.

A selector that removes the loud failures changes what survives

Any filter shapes the population it passes. Filter on visible burden and the summaries that remain are those whose damage is silent, which is what the mixed-regime selection numbers hint at. The warning sign is a falling blocked-and-repeated rate alongside a flat or rising wrong-output rate. The control is to track both, and to treat a divergence between them as a signal that the filter is working and the task is not.

Termination is a compaction failure too

The paper's Figure 2 is the finding I would least like to have in production: at 2K the summary-conditioned agent terminates correctly 37.3% of the time against 60.6% on full history. An agent that does not stop keeps calling tools, and in a system with side effects that is not a quality problem. The verifier catches some of it, because extra calls after completion are often repeats. The control is independent: refuse to let the agent finish without the terminal output form, and alarm when a run exceeds its full-context reference length by a margin.

The optimised prompt was tuned on the failures the verifier can see

The twelve training boundaries were chosen because they exhibited blocked actions, stratified by error type. The proposer then learned rules from summary pairs at those boundaries. I would expect the resulting template to be good at preserving whatever makes blocked calls go away and to have no particular pressure toward preserving identifiers the agent never acts on. The transferred template beating uncompressed execution on Kimi suggests the rules are general enough to help anyway. I would still regress any prompt change against a fact check before shipping it, because the optimiser's signal was not built to catch the regression I am most worried about.

Compact below the summary's own size and nothing saves you

At a 24-token budget my summary policy ran 10.6 compactions per episode against 2.0 at 48, and accuracy fell to 12.9% with the verifier at 14.2% and even the oracle at 35.4%. Every fact was passing through the summariser five times. No selector can pick a good summary out of three bad ones. The paper sees the same cliff between 4K and 2K. The control is a floor: never compact to a budget the summary schema itself cannot comfortably fit in, and alarm on compactions per task rather than on context size.

The production scorecard

The scores cover the verifier as a signal: the paired-continuation burden score, used either to select summaries online or to tune a compression prompt offline, plus the two diagnostics the paper builds it from. The prompt optimiser itself is scored only where the paper gives evidence.

A 3.1 average reads as a routine Wait, and the average is hiding how unequal the rows are. Three of them are 4 or 5 because the signal is free, label-less and easy to wire in. Two are 2 because of one fact: it is deaf to the failures I would most want it to hear. If you could score only one row, score Failure modes, and ask whether your summary schema carries facts whose corruption produces no error. Mine did. I expect yours does too.

A production shape I would test

Read it as one boundary. The context passes the budget, the summariser renders its candidates, and at this exact moment the raw history those candidates are about to replace is still in memory. Run the verifier here if you can restore state, and run the fact check here whether you can or not: every identifier, amount, path and marker in the chosen summary, looked up in the raw turns it summarises. A missing invoice id is a one-line set difference. A misremembered amount is a one-line comparison. The check is cheap for the same reason the verifier is, and unlike the verifier it hears the quiet channel. Once the summary has replaced the history, the check is impossible, so it runs before and never after.

The completion check and the budget floor sit on the agent loop and need nothing from the paper. The Pass² tracker sits on your evaluation job and is the paper's best idea about measurement: run every task twice and report the fraction solved both times, beside the fraction solved at all.

The decision at the bottom is what I would hold the line on. A new compression prompt ships when the verifier score and the fact check both improved on the development set. It holds when either moved the wrong way, and the case I am most worried about is the one where the verifier improved and the fact check got worse, because that is what a prompt tuned on visible failures might do.

From prototype to shadow traffic

1. 01

   Enumerate the silent channel

   Owner

   Applied science

   Artifact

   A two-column list of every fact your summary schema carries: facts whose corruption triggers a tool error or a repeat, and facts that would be accepted wrong

   Signal

   The second column exists and someone has counted it

2. 02

   Instrument the paper's diagnostics

   Owner

   Platform

   Artifact

   Blocked rate and repeat rate per action in the five steps after each compaction, and compactions per task, on the existing agent with no other change

   Signal

   A post-compaction spike like the paper's Figure 4 is visible or provably absent on your traffic

3. 03

   Freeze a replayable evaluation set

   Owner

   Applied science

   Artifact

   At least 100 tasks with restorable environment state, run twice each, reporting accuracy, Pass² and Pass@2

   Signal

   The Pass@2 minus Pass² gap is known for the current compressor

4. 04

   Add the fact check at the boundary

   Owner

   Platform

   Artifact

   A check that every identifier and number in the chosen summary appears in the raw history it replaced, logged per compaction

   Signal

   Silent defect rate per compaction, reported separately from the verifier score

5. 05

   Tune the prompt offline with both signals

   Owner

   Applied science

   Artifact

   A TRACE-style preference set from a dozen boundaries, candidate templates, and a decision record showing verifier score and fact-check rate before and after

   Signal

   Both improved on the development set, or the change is held

6. 06

   Shadow, then decide

   Owner

   Engineering leadership

   Artifact

   Four weeks of the new prompt in shadow against the incumbent on the same traffic, with a decision record naming the metric that made the call

   Signal

   Wrong-output rate did not rise while blocked and repeat rates fell

Ship gates

• Silent defect rate per compaction, measured by the fact check, is at or below the incumbent compressor's on the frozen set.
• Pass² on the frozen set improves by more than the run-to-run noise, measured over at least two disjoint run pairs.
• Post-compaction blocked and repeat rates fall, and the wrong-output rate does not rise, on the same runs.
• Compactions per task stay under a fixed ceiling, and no compaction runs below the budget floor.

Kill criteria

• The fact check finds a dropped identifier or altered number in more than 2% of chosen summaries in shadow.
• Blocked and repeat rates fall while the wrong-output rate rises for two consecutive weeks, which means the filter is selecting for silent damage.
• Runs exceed their full-context reference length by more than 50% after a compaction, or fail to produce the terminal output form.
• Any compaction on a workflow with irreversible side effects where the environment cannot be restored, because the verifier's rollouts would then execute real actions.

Human review policy: every compression-prompt change is reviewed by someone who has seen the verifier score and the fact-check rate side by side, before and after. Review of individual summaries is not required. Review becomes mandatory on any workflow where the fact check cannot be run, because on that workflow nothing is watching the silent channel.

My verdict

Wait for any workflow whose summaries carry identifiers or values the agent does not re-read. Ship the diagnostics now.

The verifier is a good idea and I would like to have it. It measures a real effect at the moment the effect happens, with no labels, and in my prototype it did exactly what it promises: two thirds of blocked calls gone, half the repeats gone, a clean preference for summaries with less of the damage it can see. The paper's behavioural probes are the best description of compaction failure I have read, and the Pass² framing is one I have already started using.

What stops me is the part the verifier is built not to hear. I assumed silent corruption was a corner case the authors had flagged for completeness. In my testbed it was the main event, which surprised me more than any number in the paper did, and nothing about rollout length, candidate count or sample count changes that, because the damage never produces an event the environment can reject. Where the paper and my prototype disagree on emphasis, I trust the paper on how well the score works on AppWorld and the prototype on what the score can and cannot observe, because those are the questions each one measured. Neither of us knows how an LLM compressor's errors split between the channels, and that number decides everything.

The narrow path I would take today is the reference architecture above: the verifier offline, tuning the prompt, with a fact check beside it that has veto power. What I would not do is let the score choose summaries online, where my prototype found it more expensive than an oracle and barely better than no selection. And I would not let a falling blocked-call rate stand in for task success on any dashboard, because the two came apart by 24 points in the run where it mattered.

I would change this verdict if:

1. Someone measures the visible-to-silent split of a real LLM compressor's defects on a real agent and finds silent damage under a fifth of the total. Then the verifier is most of the answer and the fact check is a backstop.
2. The prompt optimiser is shown to reduce silent corruption as a side effect, by a fact check run before and after on the paper's own AppWorld boundaries. The proposer reads the summaries, so it might.
3. A boundary-local signal is found that hears the silent channel, such as a short continuation scored against the raw history's outputs rather than its errors. Then the paper's framework carries it with no change to the loop.

What to remember

The number I most want is the one nobody has published: take a real agent's real compaction summaries, diff every entity and number in them against the raw history, and count how many of the defects would have made a noise. If you have that log, or a harness that could produce it in an afternoon, I would like to compare notes, because my 60/40 split is a parameter I typed in and the whole verdict leans on it.

Acknowledgements

This article builds on Toward Reliable Context Compression for Long-Horizon Agents: An Empirical Study of Execution Instability by Guanghui Min, Liang Wu, Mayank Darbari, Chen Chen, and Liangjie Hong. The compaction loop, the execution-burden metric, the paired-continuation verifier and the Pass² framing are theirs, and their code is at nokia-applied-research/Trace. Errors in my reading of them are mine.

The prototype is an original implementation. It does not use the authors' code, models, tasks or data, and it reproduces none of their results. It is Python standard library only, under MIT. The invoice tasks are synthetic and were written for this article.

References

Primary research

• Toward Reliable Context Compression for Long-Horizon Agents: An Empirical Study of Execution Instability. Guanghui Min, Liang Wu, Mayank Darbari, Chen Chen, Liangjie Hong, 2026 (arXiv:2608.06503, submitted 6 August 2026). TRACE is Trajectory-Relative Agent Context ComprEssion

Supporting and contrary evidence

• ACON: Optimizing Context Compression for Long-horizon LLM Agents. Minki Kang et al., ICML 2026. The trajectory-level prompt optimiser TRACE is built against
• ACM: Agentic Context Management for Long Horizon Tasks. Xiaochuan Li et al., 26 July 2026. Lossless context management by offloading to queryable memory
• Addressable Recall Compaction for Long Context-Window Control in AI Agents. Thang Dang et al., 27 July 2026. Replacing old observations with addressable citations
• LLM Agents Are Latent Context Managers: Eliciting Self-Managed Context via State Proprioception. Binyan Xu, Haitao Li, Kehuan Zhang, 29 June 2026. A training-free dashboard the agent reads to decide what to archive
• AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents. Harsh Trivedi et al., ACL 2024. The benchmark and the execution-error contract the verifier counts against

Prototype

• Source, setup, tests, and evaluation
• Exact tested commit

Sources last checked: 2026-08-23

A verifier tells you about the failures it was built to hear. Before you trust it, write down the ones it was not.