Execution-State Ledger

also known as Execution State Layer, Runtime Execution State, Derived Validity Index

Maintain an execution state outside the model that records what the run has observed, changed and attempted, and consult it before each step so stale observations are refused and still-valid results are reused.

Context

A long-horizon agent works in an environment it also modifies — a repository, a filesystem, a terminal, a live service. Every step appends an action and an observation to the trajectory, and after a few hundred steps that trajectory is the only account the model has of the situation it is acting in. Each entry was accurate at the moment it was taken, and the run's own later writes are what made some of them wrong. The harness controls both boundaries of a step: what is rendered into the prompt, and which command is allowed to execute.

Problem

A trajectory records what happened; nothing in it says which observations still describe the environment as it currently stands. Before every decision the model has to infer the current execution status from raw history, and that inference degrades as the history grows. When it falls short the agent acts on file contents that its own later edit superseded, or re-runs work whose result was still perfectly valid. Both failures are invisible at the step where they occur: the stale action succeeds, the redundant command returns the same answer, and the cost shows up as a wrong patch and a long, expensive run.

Forces

The trajectory is a faithful record of what happened, which is exactly why it cannot state what is currently true — every observation in it was correct when it was taken.
Leaving the current state to be inferred by the model costs nothing to build but is paid on every step and degrades with length; replacing the history with derived state raised Pass@1 from 56.2% to 64.2% on all 500 SWE-bench Verified instances while cutting total cost by 28.9%.
Maintaining the state in the runtime keeps it deterministic and adds no model calls, but the invalidation rules have to be written by hand for each kind of action and each kind of resource.
Dropping the raw trajectory from the prompt saves tokens and removes distractors, but it also removes the evidence the model would need to notice that the derived state itself is wrong.

When to use

The run is long enough that early observations stop describing the environment before the task finishes.
The agent's own actions mutate the resources its earlier observations described, such as a repository, a filesystem or a live service.
The same command is likely to be issued more than once because different steps happen to need the same result.
The harness can be modified to intercept proposed actions and to control what is rendered into the prompt.

When not to use

The run is short enough that the whole trajectory still describes the current situation.
Actions are read-only, so nothing the run does can supersede what it has already observed.
The environment changes for reasons the harness cannot observe, so a derived validity marking would be wrong more often than raw history is.
What is needed is an account of what happened rather than of what is true now, as in audit or post-hoc analysis.

Example

An agent is fixing a failing test in a large repository. Early in the run it reads a configuration file, forty steps later it edits that same file, and near the end it proposes a change based on the version it read at the start. A record of what the run has touched marks the first read as superseded, so the agent re-reads the file instead of writing over its own edit.

Diagram

flowchart TD A["Action executes"] --> B["Runtime updates execution state"] B --> C["State rendered into prompt instead of raw trajectory"] C --> D["Model proposes next command"] D --> E{"Recorded result still valid?"} E -- "yes" --> F["Return recorded result, skip execution"] E -- "no" --> G{"Premised on a superseded observation?"} G -- "yes" --> H["Block; re-observe the resource first"] G -- "no" --> A H --> A F --> C

Solution

Therefore:

The runtime keeps a structured record of the run's own execution alongside the trajectory: which resources have been observed and when, which have been modified since, and which commands have been attempted with what result. The record is maintained deterministically from the action stream, not written by the model, so it costs no extra model calls and can be inspected and tested like any other runtime component. It is then consulted at both boundaries of every step. On the way in, the prompt carries the current execution state — what is true now, what is still open — instead of the accumulated history. On the way out, each proposed command is checked against that state before it executes: a command whose recorded result is still valid is answered from the record rather than re-run, and a command premised on an observation that a later write has superseded is blocked so the agent re-observes first. The raw log can still be kept for audit; it simply stops being the thing the model reasons over.

What it gives you

An action premised on an observation the run itself invalidated is stopped before it executes instead of being discovered later through the damage it did.
Work whose recorded result is still valid is returned from the state rather than re-run, which is where the reported cost reduction of roughly 29% to 32% comes from.
The step's input carries a short statement of what is currently true instead of a record of everything that happened, so prompt size stops growing with the length of the run.
Because the runtime maintains the state deterministically and without additional model calls, the decision to block or reuse is reproducible and can be unit-tested.

What it costs you

The invalidation rules are hand-written and partial, so anything that changes the environment outside the harness's view leaves the state confidently wrong.
A stale entry marked valid is worse than no entry at all, because the reused result now carries the runtime's authority rather than being one more guess the model might question.
Replacing the trajectory with derived state removes the raw evidence a reader or the model would use to catch an error in the derivation itself.
The state schema has to be designed per environment; the measured gains come from harnesses built for repository and terminal work and do not transfer unchanged to other domains.

What this pattern forbids. The raw trajectory is no longer what the model reasons over, and no command may execute without being checked against the execution state first: an action premised on an observation the state marks superseded must be blocked until the resource is re-observed, and a command whose recorded result is still valid must not be re-executed.

And the patterns that stand alongside it, or against it —

complementsAppend-Only Thought Stream★— Make the agent's thought log append-only so the agent cannot rewrite its own history.
alternative-toContext Compaction★— When the context window nears its limit, replace the older conversation span with a model-written digest that preserves decisions, commitments, and active constraints while discarding noise, so the agent keeps running without losing the thread.
complementsStateless Reducer Agent★— Design the agent as a pure function (state, event) → newState; entire execution history is held in an external event log; enables pause / resume / replay / time-travel without bespoke checkpointing.
complementsMemo-As-Source Confusion✕— Anti-pattern: the agent cites its own past memos as ground truth instead of re-verifying them against the artifacts they describe, accumulating false confidence in stale summaries.
complementsTool Result Caching★★— Cache the result of expensive deterministic tool calls keyed by their arguments so repeat calls within a session return immediately.
complementsWorld-Model Graph Memory★— Memory store structured as a typed entity-relation graph used as the agent's authoritative world model for planning — not only for retrieval.
complementsAgent Resumption★★— Persist agent execution state so a long-running run survives restarts, deploys, or user disconnects.
complementsScratchpad★★— Give the agent a writable scratch space for intermediate notes that informs later turns but does not pollute the response.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance

Source: patterns/execution-state-ledger.md on GitHub · commit 804ea97 · view history
Added to catalog: 2026-09-09
Last updated: 2026-09-09
Contribute: open an issue or PR at github.com/agentpatternscatalog/patterns.