An agent running a long procedure shouldn’t be rereading its own transcript at every step.

SKILL.state (Badhe, Tiwari, Chung, 2026) proposes a simple shift: at each execution step, the model receives only three inputs — the immutable skill specification, the current structured execution state, and the latest observation. After producing a validated state update, the reasoning trace is discarded. Only the updated state carries forward.

SKILL.state execution cycle At each step the model reads only the skill spec, the execution state, and the latest observation. After a validated state update, the reasoning trace is discarded and only the updated state survives. FIGURE 1 SKILL.STATE EXECUTION CYCLE Skill Spec immutable Execution State structured, persists Observation latest one only LLM reads only these three Reasoning Trace discarded each step State Patch validated by runtime Action one action Environment emits observations validated update, state survives next observation

How to read it: The three boxes on the left are the whole prompt at every step: the skill file, a small JSON working memory, and the latest event. The right column is what the model gives back: reasoning (dashed, thrown away once the patch validates), a state patch (ink blue, the path that persists, looping back into execution state), and one action (olive) that runs against the environment. Only the arrows that come back are the ones that last.

The result: a bounded prompt footprint and token cost that grows linearly with execution length, not quadratically. No stale observations, no obsolete reasoning, no reconstructing world state from accumulated text.

The constraint: this only works when the structured state is a sufficient statistic — everything the future needs must be projectable into it the moment it becomes known. Static schemas, no deferred relevance, output not being the trajectory itself.

When those conditions hold, discard the reasoning and keep the state.

SKILL.state: Scalable Long-Horizon Agent Skills (arXiv 2608.26263v2)