SKILL.state: why current execution state should be small

Short answer

SKILL.state (arXiv:2608.26263, 'SKILL.state: Scalable Long-Horizon Agent Skills') separates a skill into four parts: an immutable skill spec (the procedure, fixed and reusable), a compact structured state (a small, schema-typed record of where execution stands), the latest observation (the most recent world reading), and a validated state patch (the only way state changes, checked against the schema before merging).

The useful half of the idea is operational: a skill whose current state is small and validated can be inspected, resumed, tested and handed to a small model without replaying history. The dangerous half is treating that small state as the record of what happened. Ernesta Labs' position: state is a projection over evidence. The evidence log - not the state object - is the truth; state is a cache you are allowed to rebuild. Status: STUDIED.

The failure mode: state is either nothing or everything

Agents today hold state at one of two extremes, and both break at long-horizon scale. The first extreme: no state. Every session starts from zero, so every skill the agent supposedly has - how to run this campaign, how to handle this customer type - must be re-explained, re-derived, or re-failed every time. The agent is a competent stranger forever.

The second extreme: everything is state. The full transcript, all tool outputs, every intermediate thought - hundreds of thousands of tokens of accumulated context carried on every call. This is the design most frameworks default into, and it fails in the ways our Agent Rot article documents: attention degrades as context grows, costs scale with history rather than with work, and one poisoned early observation keeps influencing every later decision because it never leaves the window.

Both extremes miss the thing a long-running agent actually needs: a small, structured answer to 'where does execution stand right now' - which step of which procedure, on which object, with what outstanding obligations - plus a full record of what happened that does not have to ride along in context. Conflating those two things is the root failure: teams use one artifact to be both the working snapshot and the historical record, so the snapshot gets bloated with history or the record gets trimmed for context reasons.

What the paper actually does

PRIMARY SOURCE RESULT: SKILL.state (arXiv:2608.26263, 'SKILL.state: Scalable Long-Horizon Agent Skills') addresses how to make agent skills reusable across long horizons. A skill is decomposed into four components: an immutable skill spec - the procedure itself, fixed and versioned, never mutated during execution; a compact structured state - a small, schema-typed record of the current execution position, deliberately bounded in size; the latest observation - the most recent reading of the world the skill acts on, kept separate from derived state; and a validated state patch - the only mechanism by which state changes, with each patch checked against the state schema before it merges.

PRIMARY SOURCE RESULT: Because current state is compact and schema-validated rather than a transcript, the authors report that a skill's execution can be resumed from its state without replaying history, inspected cheaply (the state answers 'where are we' without reading everything), and handed to a smaller model, since the small-model context needed to continue a skill is proportional to spec plus state plus latest observation, not to accumulated history.

PRIMARY SOURCE RESULT: The validated patch mechanism is the safety property the paper emphasizes: state transitions that do not type-check, or that violate the schema's invariants, are rejected at merge time. The agent does not get to write free-form text into structured fields and call it progress. This makes skill state, in the authors' framing, a first-class structured object with enforced integrity rather than an untyped bag the model scribbles into.

What they found, and what small state buys

The load-bearing finding is the separation itself. An immutable spec means a skill's procedure cannot drift mid-run - the agent can execute a skill badly, but it cannot quietly rewrite what 'done' means while executing it. A compact state means the context needed to act is proportional to the situation, not the past. A latest-observation slot means the world's current reading is always identifiable, so stale world-models have a defined place to be wrong and be replaced.

The validated patch is the part with the most transferable value. Free-form memory writes are how agent memory systems rot: the model writes a confident, vague, or fabricated summary, and every later step builds on it. Schema validation at merge time makes each write falsifiable against a structure - either the patch is a legal transition or it is not. That converts 'the agent remembers' from a claim into a typed, checkable operation.

The small-model implication is commercially significant and worth stating carefully: the authors report that skills become executable by smaller models when their context requirement is spec-plus-state rather than full history. This is not 'small models are as good as big models'. It is 'the floor a skill needs is lower when the skill carries structured state instead of its whole past'. For cost, for latency, and for fleet deployments where not every step can run on a frontier model, that floor matters.

Limitations, stated plainly

The paper evaluates skill execution in its own experimental setting, reported by its authors. We do not treat the small-model findings as a leaderboard claim across tasks and domains; we treat them as evidence for a structural argument.

The compact-state design has a hard boundary the paper is honest about but that adopters forget: compact state is a lossy summary of execution. Anything not represented in the schema is gone from the state's point of view. If a skill's state schema misses a dimension that later turns out to matter - a promise made mid-conversation, a customer's stated constraint - the state cannot know, and a system that consults only state will act on amnesia while feeling perfectly well-informed.

Schema maintenance is real, ongoing work. The validated patch mechanism is only as good as the invariants in the schema, and schemas that are too tight block legitimate transitions the authors did not anticipate, while schemas too loose pass garbage as structured garbage. The paper gives the mechanism; the domain-specific schema engineering is left to the adopter, and it is most of the actual effort.

Finally, the paper does not address where the authoritative history lives. That is not a flaw in its mechanism - it is a scope boundary - but it is exactly the gap through which adopters fall: they implement compact state, point everything at it, and quietly lose the record. The paper's own framing treats state as the skill's working object; it does not license treating it as the system of record.

Why builders should care

The costs teams actually pay for agent state are context-window cost, attention degradation, and un-debuggable runs - and all three come from history riding along with action. Small structured state is the direct countermeasure: you act on a bounded snapshot, and history stays where it belongs, in a log you consult on demand.

The validated patch answers a question every operator eventually asks with dread: 'what exactly did the agent write to its memory, and can it be wrong?' With untyped memory writes, the answer is free-form text that can be wrong in ways nobody can check. With schema-validated patches, the answer is a typed transition that either conforms or is rejected - and rejection is logged evidence about your agent's behavior.

The small-model floor is the quiet commercial argument. Most agent workloads have a few steps that need frontier reasoning and many steps that do not. A skill architecture where a small model can execute a step from spec-plus-state lets you put the right price of compute on each step, instead of paying frontier rates for every step because every step carries the whole conversation.

Ernesta Labs interpretation

LABS INTERPRETATION: We read SKILL.state as the correct operational half of a two-part story, and we refuse the half it does not claim. Small, validated, current state is what execution should consult - it is cheap, inspectable, resumable, and it keeps context proportional to the situation. But small state is a projection, deliberately lossy, built from history for convenience. State is a projection over evidence: the append-only evidence log is the record of what happened; the state object is a cache of where execution stands, and any conflict between the two is resolved in favor of the log, always. The moment a team lets a 200-byte state summary override, or worse replace, a durable record, they have built a system that forgets on purpose and then trusts its own forgetting.

This distinction maps onto the one from our verification work: a claim is not evidence. Compact state is a bundle of claims about history, typed and validated for structure, but claims. Validation checks that a patch is a legal transition, not that it is a true one. Truth lives in the log; legality lives in the schema; builders need both and must never confuse them.

What we would implement

LABS RECOMMENDATION: Implement the four-part split, with the evidence log as a fifth, non-negotiable component. (1) Immutable, versioned skill specs - procedures never mutate during execution. (2) Compact, schema-typed current state per skill, with an explicit size bound. (3) A dedicated latest-observation slot so current world readings are distinguishable from derived conclusions. (4) Validated state patches as the sole write path into state - every patch type-checked and invariant-checked at merge, with rejections logged. (5) An append-only evidence log that remains the system of record, from which state is derivable and against which state can always be audited - plus a rebuild procedure that regenerates state from the log, run in CI, so 'state is a projection' stays an enforced property and not a slogan.

We would also adopt the small-model implication pragmatically: with state bounded, route state-execution steps to cheaper models where a schema-validated patch is the output contract. The validation layer catches what a smaller model gets structurally wrong, and the evidence log catches everything else.

What we would not implement

We would not implement compact state as the system of record, and we would not build any feature whose audit story ends at the state object - no 'what happened last week' question should ever be answered by replaying a summary that was compressed for context reasons. We would not let the model write to state through any path other than a validated patch - one escape hatch and the integrity property is gone. We would not let schema validation launder truth: a patch that conforms is not thereby true, and no amount of type-checking certifies that the observation it encodes actually happened. And we would not freeze skill specs so aggressively that they cannot be versioned - specs evolve between runs, deliberately and with records, even though they never mutate during one.

Practical test: what does your agent act on, and what does it remember?

Run this audit on your system today. Step one: find the object your agent consults before acting - the thing that answers 'where am I'. Measure it: how many tokens is it, and how much of that is history versus current position? If the answer is 'the whole conversation', your agent's action cost scales with its past, and the test has already found your first problem. Step two: find the record of what actually happened last week - the log, database or transcript - and verify it exists independently of the action-context object. If your agent's context is the only record, then every context trim is an unrecorded deletion of your own history, and you should fix that before anything else.

Step three, the harder one: take the ten most recent writes into your agent's memory or state and ask, for each, what checked it before it merged. If the answer is 'nothing - the model wrote free-form text and it stuck', you have unvalidated state: each write is a claim nobody verified, structuring every later decision. The minimal fix is exactly the paper's mechanism - one schema, one validation function, one rejection log - applied to your single most-used state write. You do not need the full architecture to get most of the integrity benefit; you need one schema that a write either conforms to or gets rejected by.

What remains unknown

• How lossy compact state gets in practice - which dimensions of execution history turn out to matter later and were not represented in the schema; the paper's evaluations cannot enumerate them for your domain.
• Whether the small-model execution findings generalize across task families and models; the paper reports its own setting, and we treat the small-model floor as a structural argument, not a benchmark.
• How the ongoing cost of schema maintenance compares with the integrity benefit as skill libraries grow into dozens of interlocking skills.
• How to arbitrate when a validated patch conflicts with the evidence log - the projection should lose by construction, but the paper does not specify reconciliation, and adopters must design it themselves.

Primary sources

• SKILL.state (arXiv:2608.26263)