From Transaction Logs to Ledger Balances: Breaking Down Google's SKILL.state

An agent that has run 200 steps receives, in its step-200 prompt, a shelf record from step 3, an error from step 47, and a moment of hesitation from step 112. Most of this information is long obsolete, yet it still occupies space in the context. Google's new paper SKILL.state (arXiv 2608.26263) gives this disease a name: the trouble with context is not that it runs out, but that it gets poisoned — on a 200-step warehouse management task, standard ReAct accuracy falls from 0.84 at 100 steps to 0.74, while the prompt cumulatively consumes 2.6 million tokens.

The solution can be stated in one sentence: don't keep a transaction log; keep ledger balances.

Accounting solved this centuries ago. You don't need to reread every voucher to know your cash balance — you update the balance with each transaction and archive the vouchers for reference. SKILL.state ports this structure into agent runtime.

State, Patches, and Discarded Drafts

The traditional runtime is append-only: every step's observation, thought, and action is appended to the conversation history, the prompt grows linearly with step count, and cumulative cost grows quadratically. SKILL.state replaces this with an explicit, mutable execution state.

Each step's prompt contains only three things: the skill specification (the procedural manual that stays fixed for the entire task), the current state (a structured field table — for example, a CTF scenario has five fields: flags discovered, hypotheses tested, active files, working directory, command summary), and the latest observation.

The model reasons as usual. The paper is careful to stress that within-step chain-of-thought is fully preserved and unrestricted — deductive planning can be as long as it needs to be. But the output of reasoning is constrained to two things: a JSON patch (which keys to change, which to delete by setting null) and the next action. After the patch is validated and merged into the state, the reasoning trace is permanently discarded and never enters a subsequent prompt again.

The paper's soul sentence is worth quoting verbatim: project transient reasoning into persistent structured state, and let only the information needed for future execution survive the interaction.

The complexity accounting goes like this: append-only costs O(t) per step and O(T²) cumulatively; SKILL.state costs a constant per step and O(T) cumulatively. In numbers: on the same 200-step task, ReAct uses 2,608,755 tokens in total, SKILL.state 122,384 — one-nineteenth. Accuracy flips the other way: 0.74 versus 0.94. Even more telling is the shape of the curve: SKILL.state's per-step cost of 1,811 tokens is rock-solid from step 100 to step 200 (it was 1,905 at step 100 — it even dropped slightly). It is flat, not a line with a small slope.

Three Control Groups More Interesting Than the Main Experiment

Beyond the main table, three control experiments explain the "why" more clearly.

First: summarization memory is not the antidote; it is the disease slowed down. The Memory baseline (rolling 3-step window + periodic natural-language summaries) consumed 6.17 million tokens at 200 steps — more than double ReAct's 2.61 million. Every step writes new content into the summary, and the summary itself bloats; it merely turns down the speed of append-only one notch.

Second: being "stateful" is not enough — you need "state only." A LangGraph-style baseline stuffs both a structured state block and the full rolling history into the context, scoring 0.88 — better than ReAct, but a notch below 0.94. The state block is right; the history drowns it.

The third is the sharpest: the equal-budget control. All baselines were cut to the same ~1,800-character budget as SKILL.state and run again — sliding window 0.18 (critical early inventory allocations get squeezed out of the window), LLMLingua compression 0.22 (statistical entropy filtering deletes "seemingly redundant slot identifiers," and those identifiers are semantically life-or-death). SKILL.state scores 0.94 under the same budget. The conclusion in one sentence: the gain comes not from a shorter prompt, but from what is left in. Statistical compression destroys precise relational dependencies; structured state preserves exactly those.

"What Happens When History Is Lost?" — The Paper Answers Itself

"If history is truly discarded, what happens? What should be kept?" — the paper catches this question with two answers, one negative and one positive.

Negatively: losing history is not only not scary — it can save lives. In Experiment 3, the environment secretly changes behind the agent's back — an outsider moves goods on the shelves, then sends a correction alert. The history baseline hallucinates for 5 to 8 consecutive rounds: the stale facts piled up in the prompt overpower the contradictory new observation; the old record has authority, and the new observation can't out-argue it. SKILL.state needs zero recovery steps — the moment the correction alert arrives, the state updates immediately. History isn't just expensive; it fights with reality.

Positively, the Limitations section honestly lists three costs of discarding history. First, the schema must be written in advance: when the domain structure is unknown, there is no way to discover what the state should look like on the fly. Second, delayed relevance: the correct state update may depend on an early observation that "didn't look useful at the time" — it never made it into the state, and 50 steps later when it's needed, it's gone. Third, tasks whose goal is defined in the history itself: audits, debugging provenance, explaining past behavior — here history is the deliverable, not overhead.

Taken together, these three are precisely the exact shape of "what should be kept." And SKILL.state's real position hides in the architecture: this judgment should not be made implicitly by the model at every step via attention; it should be made explicitly by the engineer at the moment the schema is written. The judgment doesn't disappear — it changes location and moves earlier in time.

Validation at Runtime, Not in the Model

Small-model performance exposes the real bottleneck of this architecture. Gemma-4-31B scored 0.42 on 100-step tasks; after error classification: 68% were premature overwrites or deletions of state keys (missing existing fields when updating), 20% were schema type misunderstandings, 12% were JSON syntax — all structured-output compliance problems, not reasoning problems.

The paper's architectural response is a textbook design: schema ownership and validation live in the deterministic runtime, not the model. Malformed patches never enter persistent state; they trigger rollback and retry. The model can guess wrong; the ledger never gets dirty.

The approach also holds up on public benchmarks. On InterCode CTF, pass@1 is 54.2% versus ReAct's 43.2% — with "hypotheses tested" explicitly recorded in state, the model stops stepping in the same hole twice. On τ-Bench Airline, 32.4% versus 21.8%, with the baseline's prompt peaking above 11,000 tokens per step while SKILL.state stays constant at about 2,800. A noise experiment adds another cut: injecting 5 to 50 distractor events per step (telemetry, irrelevant git branch activity, rule rewrites), ReAct falls from 0.68 to 0.53 while SKILL.state never drops below 0.97 — distractions are filtered out at the patch-generation stage and never get a chance to enter subsequent prompts.

Closing

From "how much can it remember" to "what should be kept," one more question stands in between: who decides what to keep. SKILL.state's answer is a three-way division of labor — engineers write the schema, defining what counts as a field in the domain; the runtime validates patches, guarding the ledger against corruption; the model only proposes patches, doing what it is good at: guessing and reasoning.

The information that still stands after two hundred steps is not remembered. It is designed.