/p/2026-08-05 · explainer
Paper explainer · 2608.00808 · Wang et al.

Your agent forgot
what it already did.

A long-horizon coding agent accumulates hundreds of actions, and nothing in that record marks which of them still describe the repository as it stands. So before every decision the model re-infers execution status from raw scrollback — and when that inference slips, it edits a file it read forty turns ago and never re-read, or re-runs work whose answer had not changed. Two baselines here re-read the same unchanged snippet 1,875 and 5,840 times over one benchmark run. Ledger keeps that state explicitly instead. Across all 500 tasks it lifts first-try success from 56.2% to 64.2% and 75.8% to 81.0%, while cutting cost 28.9% and 31.8% — with no extra model calls and no change to the agent.

01 · The problem

Nothing in the scrollback says what is still true

An agent's context is an append-only log: I ran this, I saw that. What it is not is a description of the repository. A file it read at turn 12 may have been rewritten at turn 30 by its own patch, and the only evidence of that is two entries sitting hundreds of lines apart in a transcript that also contains every failed command and every stack trace. The model has to notice the collision and draw the conclusion, silently, before every single action. Step through a trajectory and read what each side concludes.

Interactive · one trajectory, two readingstap a turn

      

Two failure shapes fall out of this, and the paper targets both. Stale action: the agent edits or reasons over content that has since changed underneath it. Redundant re-execution: the agent re-runs an inspection whose answer it already has, because confirming is cheaper than trusting the transcript. The second one is measurable and enormous — 1,875 and 5,840 re-reads of unchanged snippets across 500 tasks, for the two backbones tested.

02 · The mechanism

Two counters are enough to know what went stale

Ledger's whole trick is bookkeeping the agent could have done and did not. Every time the agent observes a file it records the path, the line range, and two numbers: a counter for that file and a global counter for the repository. Every modification advances the relevant counters. An observation is still current if its stored counters match the current ones, and potentially stale if they do not. That is the entire staleness test — no model call, no diffing, no heuristics. Drive it yourself: read some files, edit some files, and watch the index flip.

Interactive · drive the ledgerread a file, then edit it
Observation index

Note what is not stored: file contents, diffs, or summaries. The ledger holds only identifiers and integers, which is why it costs nothing to maintain and why it can never be wrong about its own claim. It does not say the file changed in a way that matters — it says an event occurred that could have invalidated what you saw, so treat the reading as expired.

03 · The method

One hook before the model, one before the shell

The state gets applied at two boundaries of every step. On the way in, the inform path renders the ledger into a compact plain-text view — a fixed task anchor, the files recently modified, and the observation index with each entry flagged current or potentially stale — and appends it to the end of the model input. On the way out, the govern path intercepts the command the model just proposed and rules on it before the shell sees it. Three verdicts, and only one of them actually runs something new.

Interactive · the govern pathtap a proposed command

      
what the shell actually executes
what the agent gets back

The asymmetry is deliberate and worth copying. Reuse only fires for inspection and search — commands that cannot change the repository, so returning a stored answer is safe by construction. A repeated test with no edit in between is not reused, because tests can be flaky or environment-dependent; it gets a nudge instead, running normally with a note attached that this looks redundant. The layer never silently withholds an execution it cannot prove is unnecessary.

04 · The proof

More tasks solved, on a smaller bill

This is the part that makes the paper worth your attention rather than your agreement. Same agent, same models, same 500 tasks — the layer is bolted on and nothing else changes. Both directions move at once, which is unusual: efficiency work normally costs you accuracy, and accuracy work normally costs you tokens. Here the agent solves more because it wastes less, since every avoided re-read is context it does not have to hold and re-read past.

Interactive · switch what the bars measure500 tasks · single run per configuration
0

First-try success, agent alone against agent plus ledgerpass@1, % of 500
050100%

The transfer result matters more than the headline. Ledger was built against one open scaffold, then attached unmodified to a different commercial agent — and still bought +3.4 points at 24.4% lower cost. That is evidence the problem lives in the trajectory format itself, not in one harness's quirks.

05 · In your stack

Which half should you build first? illustrative

If you are going to steal this, you will probably build one path before the other, so it is worth knowing what each buys alone. The ablation is genuinely surprising: on the weaker backbone either path alone captures essentially the whole gain, while on the stronger one governing does nearly all the work and informing adds little. Cost splits the opposite way. Step through the arms, then point the measured per-task costs at your own volume.

Interactive · inform, govern, or bothresolved instances of 500
0250500

Interactive · your volume at the paper's measured ratesper-task costs measured · the multiplication is illustrative
monthly spend, agent alone
monthly spend, with the ledger

The numbers

What the paper actually reports

What this does not show

In practice