Based on Badhe, Tiwari & Chung, SKILL.state: Scalable Long-Horizon Agent Skills, arXiv:2608.26263v1, August 26, 2026.
SKILL.statescalable long-horizon agent skills
TL;DR
Stop making the model reread its entire life.
Give it the skill, the current state, and the latest observation. Let it reason, propose a small state patch, take one action, then throw the working transcript away.
01
State is the memoryKeep only facts needed for the next decision in a structured object.
02
Reasoning is temporaryUse rich within-step reasoning, but don’t drag it into the next prompt.
03
Runtime owns truthValidate the proposed patch deterministically before applying it.
04
Prompt size stays boundedThe paper reports O(1) prompt footprint and O(T) cumulative tokens.
Paper abstract; Sections 3.1-3.3. Formula notation: P = procedural specification, Σ = structured execution state, O = latest observation.
The problem
Long horizons create a history tax.
In a conventional agent loop, observations, actions, tool outputs, and reasoning accumulate in the prompt. More context means more tokens, more stale facts, and more work separating now from then.
O(T)prompt length as turns accumulate
O(T²)cumulative token complexity
context growth
attention
drag
drag
t = 1 / initial observation
t = 12 / prior action + result
t = 50 / stale telemetry
t = 100 / obsolete reasoning
latest / what matters now?
Paper Sections 1 and 3.3. The paper describes historical observations and obsolete reasoning as remaining embedded after they cease to be relevant.
The core move
Turn every step into a state transition.
The SKILL.state loop
Observelatest Oₜ
→
Generatereason + patch + action
→
Validatereject malformed updates
Σₜ₊₁ = Σₜ ⊕ ΔΣₜthen execute aₜ
What the model receives
Pimmutable procedural specification
Σₜcurrent structured execution state
Oₜlatest environment observation
It does not receive previous observations, previous actions, or previous reasoning traces.
Paper Section 3 and Algorithm 1. The merge operator ⊕ is described as dictionary merge with null-deletion semantics.
A useful distinction
Reason richly. Remember selectively.
Intermediate reasoning ephemeral
Multi-step reasoning can remain intact while the model is deciding what to do.
Execution state persistent
Only the validated facts needed for future execution survive the step.
"active_item": "item_12",
"shelf": "shelf_42",
"status": "ready_to_ship"
"shelf": "shelf_42",
"status": "ready_to_ship"
State becomes the sufficient statistic for the next computation.
That is the bet. The limitations matter when the bet does not hold.Paper Sections 3.2 and 7. “Sufficient statistic” is the paper’s framing of when discarding history is lossless.
Schema authoring
Design the state once per domain.
The schema should capture what the agent must know to make the next correct move. It is not a diary of everything that happened.
The paper’s InterCode CTF example reuses one static five-field schema across 100 diverse challenges.
Example: software task state
discovered_flagslist
tested_hypotheseslist
active_fileslist
working_dirstring
cmd_summarystring
A good field prevents repeated work, preserves a dependency, or anchors the next action.
Paper Section 3.1. Example schema: discovered_flags, tested_hypotheses, active_files, working_dir, cmd_summary.
Why it scales
One prompt stays small.
The horizon can grow.
Illustrative prompt footprint
The paper’s asymptotic comparison, made tangible.
history runtime
11,931
SKILL.state
1,773
0larger prompt
history: O(T²) | SKILL.state: O(T) cumulative tokens
Paper Section 3.3 and Table 1, Warehouse Management using Gemini-3-Flash. Values shown: average prompt size at T = 10, 50, 200.
Worked example
Keep the fact. Drop the monologue.
Warehouse episode
Paper Appendix B.3, “Example Episode Trajectory”. The example uses item_12 on shelf_42 and a null state update after shipping.
Not just compression
Shorter is not enough.
Structure is the point.
| Runtime | What survives | Failure pressure |
|---|---|---|
| Prompt / ReAct | Full transcript | Growing context and stale facts |
| Memory | Summary + recent turns | Summary can blur exact relationships |
| Stateful | Structured state + full transcript | State still shares space with history |
| SKILL.state | Validated structured state | Bounded prompt; exact fields survive |
The paper’s budget-matched controls are important: at roughly 1,800 prompt tokens, sliding-window, summary-capped, and LLMLingua baselines still underperform structured state in the warehouse task.
Paper Sections 5.1 and 5.6, Table 5. The comparison is a plain-English synthesis of the evaluated runtime paradigms.
Evidence
Test the runtime, not just the model.
SKILL.state was evaluated across controlled sequential environments and public interactive benchmarks.
500Warehouse
Independent shelves. Store, ship, move, wait.
graphSoftware repo
Branches, commits, PRs, CI status, merges and rollbacks.
100InterCode CTF
Linux bash challenges spanning reverse engineering to exploitation.
τSierra τ-Bench
Retail and airline customer-service workflows with tools and policy.
Task successCorrect actions or final state
Average prompt sizeTokens per model invocation
Total token costCumulative burn across the horizon
Paper Section 4. Benchmarks and metrics as described by the authors.
Results
At T = 100, the gap is not subtle.
Warehouse accuracy T = 100
SKILL.state keeps accuracy high while holding average prompt size near 1,905 tokens.
Total tokens T = 100
Compared with Stateful, the paper reports a 16.2× reduction against 1,062,387 tokens at T = 100.
Paper Table 1, Warehouse Management with Gemini-3-Flash. Values are means; the paper reports ± sample standard deviation.
Robustness
Noise hurts history more than state.
Warehouse score T = 50
At high noise, the Prompt runtime falls to 0.53. SKILL.state stays at 0.98.
Recovery after drift external change
When the world changes outside the agent’s action loop:
Prompt
5-8 steps
5-8 steps
Memory
5-8 steps
5-8 steps
Stateful
5-8 steps
5-8 steps
SKILL.state
0 steps
0 steps
The paper reports zero recovery steps for SKILL.state in the tested drift scenarios.
Paper Tables 2 and 3, Warehouse Management. Noise is irrelevant telemetry; drift modifies the true world state outside the action loop.
The honest bit
State is powerful when the schema is right.
The paper’s strongest assumption is also its boundary: everything relevant to future action must be projected into state when it becomes known.
Don’t delete the past until you know what the future needs.
Implementation implication, inferred from the paper’s limitations.Reported open-weight failure taxonomy
Three boundary cases
- No fixed schema is known in advance.
- A past observation becomes relevant later, but was never committed.
- The trajectory itself is the output, as in auditing or provenance.
Paper Sections 5.7 and 7. Failure percentages are reported for Gemma-4-31B at T = 100. The final quote is an explicit inference, not a paper quote.
How to build it
A small runtime pattern, with serious guardrails.
Start with one domain and one agent. Make the state contract boring, explicit, and testable.
01
Define the domain stateList the minimum fields needed to choose the next valid action.
02
Separate immutable instructionsKeep the skill specification P stable across every step.
03
Make the model output a patchRequire state_patch plus one action. Use null to delete a key.
04
Validate before mergeCheck JSON, types, allowed keys, invariants, and action legality.
05
Merge deterministicallyApply ΔΣ to Σ with explicit dictionary merge semantics.
06
Execute outside the modelLet tools and environment enforce the actual world transition.
07
Evaluate the runtimeMeasure success, prompt size, total tokens, noise robustness, and recovery.
Implementation guide derived from Paper Sections 3, 4, 5, Appendix A, and Appendix B. It adds practical engineering detail as an interpretation.
Implementation contract
Make the boundary machine-checkable.
The model can propose a transition. The runtime decides whether it is valid.
Minimal response shape
{ "state_patch": { "inventory": { "shelf_42": null } }, "action": "Ship item_12 shelf_42" } // validate patch // merge state // execute action
Paper Appendix A.4 specifies exactly two JSON keys: state_patch and action; malformed updates are rejected by the runtime.
Implementation sequence
Build the loop. Then attack it.
A practical first milestone is not a clever prompt. It is a deterministic state transition loop with adversarial evaluation.
1. Golden episodes
Create seeded event sequences with ground-truth state and legal actions.
2. Failure injection
Add irrelevant telemetry, stale observations, malformed patches, and external drift.
3. Compare runtimes
Run full history, summary, stateful, and explicit-state variants at matched budgets.
Success criterion: the agent makes the next correct transition, the state remains valid, and cost stays bounded as the horizon grows.
Evaluation sequence derived from the paper’s SkillExecBench design, noise construction, state recovery tests, and budget-matched controls.
Takeaway
Persistent knowledge beats persistent transcript.
01Use conversation for computation, not as your only memory substrate.
02Make the execution state explicit, minimal, typed, and owned by the runtime.
03Keep history when the history itself is the product: audit, debugging, provenance, explanation.
04Evaluate the harness: scaling, noise, recovery, correctness, and cost.
Σ
current
world
current
world
Summary of the paper’s claims and limitations. Read the original for experimental details, prompts, seeds, and full tables.