Execution-State Ledger

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.

Solution

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.

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.