Done Means Done: Why Status Tokens Beat Status Updates

Editor’s note (2026-06-14): Maestro has since moved to a Frontier-led model. The headline is now the Frontier Engine, a local multi-CLI fusion engine that fans a prompt across Opus 4.8, GPT-5.5, and Gemini 3.1 Pro and synthesizes one grounded answer; the discipline layer this piece describes is its proven foundation. The argument below stands as written; only the positioning around it has changed.

The first time an agent reported “complete” on a build that did not compile, I almost believed it. The dispatch had been clean: refactor a small module, run the type checker, return. The final message came back fluent and confident. “Done. Refactor applied; behavior preserved; tests look good.” The only reason I did not merge it is that I had a habit of running tsc --noEmit myself before accepting anything an agent had touched. Three type errors. Two of them in the file the agent had just rewritten. The third was a cascade from the first. The agent had not run the type checker. It had read enough of the codebase to know what a successful build sounded like, and it had produced a sentence that sounded like one. There was no lie in any narrow sense, and no truth in any useful sense either. The completion message was a mood, not a measurement.

That was the first time. It was not the last. Over the following months I logged the agent completion messages that turned out to be wrong, and the pattern was depressingly stable. Almost none of them were dramatic hallucinations. They were soft language. “Should be working.” “I believe this addresses the issue.” “Looks good on my read.” “Tests appear to pass.” Every one of those phrases was the agent telling me how it felt about its own output, and every one of them was the part I had to ignore to find out whether the output was actually correct. So the narrow claim in this post is that the prose completion message is broken as an interface, and replacing it with a four-token discipline (VERIFIED, UNVERIFIED, PENDING_REVIEW, FAIL) closes the largest single category of false-green I have seen in production. The wider claim is that this is the next stage after context engineering. Context engineering decided what the model sees on the way in. Status tokens decide what the model is allowed to claim on the way out.

Why status updates fail

“Done” has no fixed semantics. The agent saying “done” might mean: tests passed. It might mean: tests did not run because the runner is not configured. It might mean: tests passed because I deleted two assertions to get them to pass. It might mean: I did not test it, and the dispatch said “implement” so I treated verifying as optional. All four produce the same word at the end of the run, and the consumer (human reviewer, next agent, next iteration of a long-horizon loop) has no way to tell them apart without re-doing the work. Worse, “done” is the part that gets summarized and passed forward. Whatever subtle qualifier the model attached in the moment (“looks good, though I could not get the linter to run”) is exactly the detail that compacts away first. The verification claim has been laundered into a confidence statement.

The second failure mode is structural. The completion message is generated by the same model that did the work. Same context, same blind spots, same fluent style. A model that misread the dispatch and skipped a step will not flag the skip, because from the inside it is not aware of having skipped it. A model that watched the tests fail can still produce a “should be fine” close if the dispatch is ambiguous enough about what “fine” means. The completion message inherits every weakness of the run that produced it, and it presents those weaknesses in a form the downstream system cannot inspect.

The third failure mode is the most preventable. Humans want the completion message to be true. A long agent run is expensive; the operator has been waiting. A confident close produces a small dopamine release; an honest “I could not verify this” produces friction. The agent has no incentive to produce friction unless the protocol demands it, and free prose is not a protocol; it is a vibe. The operator and the agent then collaborate, gently and unconsciously, on a story in which the work is done. That story is wrong about 15 to 20 percent of the time in my data, and the 15 to 20 percent is the work that costs the most to clean up later. Prose completion is broken three ways: semantically undefined, blind to its own blind spots, biased toward the answer everyone wants. You cannot phrase your way out of “done” being ambiguous; the ambiguity is the word’s job.

The four tokens, with their exact semantics

The doctrine is short enough to write down completely. Every completion report carries exactly one status token, the final message begins with it, and the token is one of four. The precise wording is what gives the discipline its teeth.

VERIFIED means the relevant checks passed. This is a claim about evidence: the type checker ran, the linter ran, the tests ran where configured, and all of them returned clean. It is not a claim about correctness in the philosophical sense; it is a claim that the configured oracle was consulted and the oracle said yes. The point of grounding “done” in evidence rather than confidence is that the evidence is inspectable. I can read the log of what ran. I cannot read the log of how the agent felt about its work.

UNVERIFIED means a check could not run, and the agent must name the exact gap. This is the token that does the most work. The honest cases are common: no type checker is configured, the test runner errors on a missing dependency, the project has no linter. The correct token is UNVERIFIED, with a sentence naming which check did not run and why. The protocol is explicit: grep or read evidence does not upgrade UNVERIFIED to VERIFIED. The gap is the message.

PENDING_REVIEW means protected surfaces were touched and a human needs to look. The protected surfaces are named: instructions, tests, evals, CI. Those are the surfaces that grade the rest of the work. If the agent modifies them, the oracle has been changed, not the code under the oracle, and the change cannot self-certify. A test the agent rewrote and then ran is not a passing test in the relevant sense; it is a test whose author just graded their own paper. PENDING_REVIEW is the place to land an honest completion that says “I did the work, the work touched a grader, and no autonomous green token is appropriate here.”

FAIL means checks failed, and the response is to fix the defect, never to weaken the oracle. This should be the easiest token, because the agent has unambiguous output to report on. In practice, it is the one that gets quietly mutated most often. A failing test becomes, in the “fix”, a test that no longer asserts the failing condition. A type error becomes a type assertion that papers over the gap. If FAIL becomes VERIFIED after an agent edit, the diff had better be in the production code, not in the test or the type definition. Otherwise the oracle has been bribed and the green is a forgery.

Two operational rules sit on top of the tokens. First, no checker ran means the token is UNVERIFIED, never VERIFIED, no matter how careful the agent’s reading was. Second, the final message begins with the status token. No preamble, no separate wrap-up turn, no buried report. The token is the headline because the consumer is going to grep for the headline, and a discipline that lets the headline drift is no discipline at all. Four tokens, two operational rules. It fits on an index card.

How hooks enforce it

Writing the protocol down is not the same as enforcing it. An agent that has read the doctrine can still emit a fluent “looks good” close at the end of a long run, because the model’s habit is fluency and the protocol is one of many things in its context window. My first deployment relied on prompt-level reminders. They held about 80 percent of the time. The 20 percent failure rate was concentrated in the runs where the cost of a false VERIFIED was highest: the long, multi-step ones where the doctrine had drifted toward the middle of the window. Lost-in-the-middle does not care that the missing instruction is a verification instruction.

The fix is structural. I run two hooks at the harness level that inspect every completion before it leaves the agent boundary. The first is a subagent-guard hook: when a specialist subagent reports up, the guard checks that the report begins with a recognized status token. If it does not, the report is rejected back with a one-line instruction to re-emit, starting with one of the four tokens. The guard does not interpret the token; it only enforces the shape. The second is gate-telemetry. Every time an agent emits VERIFIED, the hook records which checks it claims to have run and appends that claim to an audit log. The log is not consulted on the happy path. It exists for the moment, days later, when someone asks why a particular change was merged without a passing test, and the log can show that VERIFIED was emitted with a list of checks that did not include the one that should have caught the regression. The audit log turns the token from a claim into a receipt.

Neither hook is sophisticated. The subagent-guard is a regex on the first line. The gate-telemetry is an append-only file. The point is not the technology; the point is that structural enforcement consistently beats prompt-level reminders for the same reason I argued in why I stopped using multi-agent frameworks: when the rule lives in code that you can read and the agent has to pass through, the rule holds. The gate-telemetry hook does not try to verify that the checks the agent claims to have run actually ran. That would be a different system, an oracle on top of the oracle. The hook only records the claim, so that the claim can be audited later. An agent that emits VERIFIED with a fabricated check list is committing a discoverable lie, not a clever evasion. Discoverable lies are the kind of thing a discipline can recover from. Plausible vibes are not.

The harness and the protected-surface rule

PENDING_REVIEW encodes a rule that took me too long to articulate: if the agent modifies the thing that grades the work, the work cannot self-certify, no matter how the checks come out. The instinct, before I had the rule, was to treat tests as code. The problem is that the test suite passing after the agent modified the tests does not tell you whether the code under the tests is correct; it tells you whether the modified tests still pass. Those are different claims. The first is what matters. The second is what the green light measures. When the two diverge, the light is wrong in the most expensive direction.

The same logic applies to evals (a loosened rubric is not improved capability, it is a lower bar), CI configuration (skipping a slow test or marking a flaky job non-blocking makes the build appear greener without touching the code), and instructions (editing the doctrine itself shifts what counts as a passing run). The principle: the green light is owned by the surface that grades the work, and the surface that grades the work must not be the surface under test. Any time the agent crosses that boundary, autonomous certification is not available. A human has to look. PENDING_REVIEW is the polite way of saying “I did the work, and the work mutated something I am not allowed to self-grade.” That sentence is the difference between a discipline that survives long-horizon autonomy and one that quietly corrodes.

What changes when status is a token, not a sentence

Three things improve, and I want to be specific about them because vague claims of “better reliability” are exactly the kind of soft language the doctrine is meant to replace.

Downstream consumers can decide what to trust without re-reading the run. When the token is a fixed string at the start of a fixed-shape report, the next agent, the orchestrator, the compaction step, the human reviewer, can all branch on it. VERIFIED means proceed. UNVERIFIED means stop and read the gap. PENDING_REVIEW means route to a human. FAIL means loop back. The whole question of “is the work actually done” collapses into a parseable signal. The signal does not become correct by being parseable, but the cases where it is incorrect become obvious instead of invisible. An honest UNVERIFIED is more useful than a confident “looks good” every time.

Compaction stops silently upgrading the report. In a long agent run, the model summarizes its own earlier work to make room for new context. A summary of “I finished step four; the tests appeared to pass” compresses, three steps later, into “step four: complete.” The qualifier was the entire signal. It is gone, and the next decision is made on a hallucinated success. With a token, the compression rule is different: tokens survive intact because the protocol treats them as load-bearing. I covered the underlying mechanic in prompt engineering is dead: once you treat the context window as engineered rather than typed, what gets preserved across compaction is a policy decision. The token is a policy decision.

The audit trail becomes searchable. How often did the agent emit VERIFIED on this workflow last month? Which gap did UNVERIFIED name? Did any FAIL flip to VERIFIED without a corresponding production-code diff? Each query is a one-line grep against the audit log; each was a multi-hour reading exercise against prose completions. The token does not make the agent more honest in any single run. It makes the dishonesty across many runs visible. The system is a little slower at the surface (some confident closes now become UNVERIFIED with a named gap) and much faster end-to-end, because the runs that used to ship false green get caught at the boundary. Same shape as the automation paradox: a small front-loaded discipline tax that pays back as silent failures become visible ones.

The limit, and the part I am still wrong about

There are things the four-token discipline does not solve, and naming them is part of the honesty it is supposed to demand. The biggest limit: VERIFIED is only as strong as the oracle behind it. A permissive type checker, tests that do not exercise the path the agent touched, or a linter that ignores the most error-prone patterns all leave VERIFIED inheriting that weakness. The token proves the configured checks passed; it does not prove correctness. A system that treats VERIFIED as a guarantee rather than a receipt is misusing it. Second, the discipline only holds per run. Long-running autonomous loops can produce cumulative drift across many runs, each emitting a clean VERIFIED while the aggregate moves in a direction nobody wanted. Third, the specific four tokens encode my workload. Teams in different domains might need finer-grained categories, or a fifth I have not named.

The part I am still wrong about is whether structural enforcement scales. The hooks I described work because my agent population is small and the workspace is one I own. A larger system with many operators and overlapping protocols would need more than a regex on the first line. I suspect the answer is closer to a policy proxy than to a hook, the same shape Govyn takes for tool calls, but applied to completion semantics. The next generation of orchestration treats agent boundaries as policy surfaces, and the completion boundary is one of them. Until that exists, the four-token discipline is the strongest control I have.

How we run autonomous loops now

Most agent work in my setup is a loop now, not a single dispatch. A task arrives, an orchestrator runs it across many iterations, and the failures that matter happen between iterations rather than inside any one of them. Running that unattended took a handful of rules I learned the expensive way. The loop self-paces its own cadence; I do not wake it on a fixed timer, because a fixed wake wastes the prompt cache and burns tokens. State does not live in the context window, which gets compacted or reset out from under the run. It lives in one durable checkpoint artifact the loop reads first on every resume, and that file is the real memory. Termination is not the loop’s call. A separate verifier grades the success condition in a fresh context the working loop cannot influence, so the run that did the work never gets to declare itself finished. Every loop starts with a dual termination contract: a checkable success condition and a hard iteration or time cap, because a loop with no cap does not crash when it stalls, it just keeps running. And loops never spawn loops; one orchestrator loop, bounded specialist work inside it. The reason any of this is safe to leave running overnight is the token discipline underneath. Each iteration reports in one of the four tokens, so drift and false-green surface at the iteration boundary instead of compounding silently across twenty. This is the discipline layer under the Maestro setup the note at the top references.

Loop engineering: what comes after context engineering

Prompt engineering was about what the model does. Context engineering was about what the model sees on its way in. The frontier now is loop engineering: how an autonomous run sustains itself across many iterations without a human in the seat. Each stage pushed the hard part further down the pipeline, away from clever wording and toward structural discipline. A loop has a problem the single call never did. To make progress, iteration twenty has to trust what iterations one through nineteen reported about themselves, and no operator is standing by to catch the one that quietly went wrong. That trust is only possible if each iteration emitted something that means one fixed thing. A prose “looks good” cannot carry it; the qualifier compacts away and the loop builds on a success that was never there. A token can. This is why the four-token discipline is the enabling primitive for loop engineering rather than a reporting nicety: it is the smallest unit of trust that survives a context compaction, which is exactly the boundary a loop keeps crossing.

That is what the four-token system is actually doing. It is not a verification system. It is a transport for verification, a fixed-shape claim that can be inspected and grounded later. Without it, “the work is done” dissolves into prose the moment it leaves an iteration, and the next iteration builds on a mood. With it, the claim is durable enough to audit, to compose with the next iteration’s report, to survive the moment three days later when someone wonders why a green build shipped a regression. The answer is in the log because the discipline forced the answer into a shape the log could keep. If you are building loops that have to keep going for longer than one run, and you are still treating completion as a prose problem, the upgrade is small and the payoff is large. Pick four tokens that fit your workload. Anchor each to evidence the consumer can inspect. Enforce them structurally, not in the prompt. Then read your own gate-telemetry log a month later and notice how many runs you would have shipped on a “looks good” were actually UNVERIFIED with a gap nobody named. That number is the false-green rate your old protocol was hiding from you.