All field notes

Published field note · Research note

· 5 min read

Progress is not state until the environment verifies it

An executor may propose that work is complete, but only independent observation of the environment should advance durable task state.

A repository agent reports that a database migration is complete. It says the new column exists, the backfill ran, and the application now reads the new shape. Its task ledger—a durable record of work status—changes migration from pending to done.

A read-only check against the database finds the schema unchanged.

Evidence boundary between an executor claim and durable stateFour boxes run left to right: executor claim, observation, evaluator, and durable state. A dashed evidence boundary separates the executor's claim from observation of the environment. A crossed miniature path explicitly rejects a direct claim-to-state write. A second branch shows the evaluator keeping the requirement pending when the evidence does not satisfy the criterion.CONTROLLED STATE TRANSITION01EXECUTOR CLAIMpropose complete02OBSERVATIONread environment03EVALUATORtest criterion04 / CRITERION METDURABLE STATEmanager writesEVIDENCE BOUNDARYCLAIMSTATECRITERION NOT METKEEP REQUIREMENT PENDING
A completion claim can only reach durable state through observation and evaluation; an unmet criterion or insufficient evidence keeps the requirement pending.

Nothing exotic happened. The executor—the component allowed to attempt the environment change—generated a valid migration file but never applied it. The dangerous part was not the failed action; it was letting the same component that attempted the work promote its own summary into durable task state. Every later decision now starts from a false premise.

I want a harder boundary: self-reported completion may propose a state update, but it cannot authorize one. Durable progress should advance only through an independent observation of the environment. “Independent” here is about authority and evidence paths, not necessarily a different model vendor. The executor may point an auditor toward a table, file, window, or log. It may not decide that the resulting observation proves completion.

LongHorizon-Harness v1 implements a concrete version of this separation. The paper maintains explicit task state outside task execution and advances it through a Manage-Execute-Audit loop. A manager selects a bounded subtask from current state. A fresh, budget-bounded executor is the only role allowed to intentionally modify the environment. A separate auditor—a component that checks the result without authority to change it—starts without the executor's raw trajectory, or sequence of model calls, actions, and observations; receives read-only tools; and inspects the resulting environment before the manager updates the persistent state. Executor claims do not directly mark records complete.

The paper also describes a lightweight AgentAdapter that lets those roles use interchangeable model and harness backends without rewriting their native loops. Here a harness is the runtime around a model that supplies context and routes actions. That detail matters architecturally: the evidence boundary is wrapped around execution rather than assumed to live inside one particular coding or computer-use agent.

Those are source-reported properties of a version-one preprint evaluated on web-interaction (WeaveBench), terminal-work (Terminal-Bench 2.1), and desktop-computer-use (OSWorld 2.0) setups. I am deliberately not turning its benchmark improvements into a general reliability claim. The tasks, graders, role budgets, backends, and environments are specific, the paper is new, and independent replication may change how much weight its performance results deserve.

The broader controller rule is my synthesis. A task record should distinguish at least three statements:

  • the executor claims an effect occurred;
  • an observer found environment evidence of an effect;
  • an evaluator judged that evidence sufficient for a named requirement.

The auditor owns the read. The evaluator owns the predicate judgment: whether the observation satisfies the requirement. The manager owns the durable state write. One process may implement the evaluator and manager, but executor prose still cannot substitute for observation.

For the migration, the execution report might truthfully say “created 20260830_add_status.sql.” The auditor then queries schema metadata and reports that orders.status is absent. The manager can retain the migration file as an artifact and the missing column as a verified fact while leaving the requirement pending. That is still progress, just not the progress the executor claimed.

Anthropic's first-party evaluation guidance gives a bounded production vocabulary for the same category boundary: a transcript is the record of the trial, while the outcome is the final state in the environment. Its flight example asks whether a reservation exists in the database, not whether the agent said it booked one. This supports the outcome-versus-transcript distinction; it does not validate LongHorizon-Harness or prescribe Manage-Execute-Audit as the only architecture.

There is a fair countercase. In purely discursive work—a design critique, an explanation, a negotiation draft—the artifact may be the environment state. There may be no database row or executable test that can settle quality. Independent human or model judgment is still needed, and disagreement may remain legitimate. The rule survives, but “environment verification” becomes inspection of the actual artifact under an explicit rubric, not a pretense that every outcome is mechanically decidable.

What this does not prove: LongHorizon-Harness v1 does not prove that read-only auditors are correct, independent in their errors, or sufficient for every task. An auditor can miss hidden state, accept an incomplete criterion, or share the executor's blind spots. The opening migration scenario is fictional and illustrative. The narrower claim is that an executor's completion statement and a durable fact about the world require different authority.

Where in your agent system can an executor's sentence still flip durable state to done without a fresh observation of the thing it was supposed to change?

Open question

What I'm testing

Where can an executor in your system mark durable work complete without a fresh observation of the environment it was meant to change?

Evidence boundary

Sources and boundaries

A linked source supports only its named role below. This note connects and tests ideas; the note itself is not evidence.

  • frontier preprint
    LongHorizon-Harness v1

    Reports one Manage-Execute-Audit architecture and results in its named benchmark setups; it does not establish that read-only auditors are universally correct or sufficient.

  • production report
    Demystifying evals for AI agents

    Provides first-party terminology separating a trial transcript from its environment outcome; it is not independent validation of Manage-Execute-Audit.

Back to all field notes