Your agent did not do anything

Your agent did not do anything

The output is excellent. It explains the bug, names the right files, describes a clean patch, and even predicts which tests should pass.

The repository is byte-for-byte unchanged.

This is an embarrassingly easy failure to ship because persuasive output looks like evidence of work. A chat surface shows the answer. A run record says “completed.” A summarizer turns the answer into “implemented retry handling.” By the time a human notices the empty diff, three layers of the system agree that the agent succeeded. They are all quoting the same prose.

The useful fix starts with four ordinary words: proposal, effect, observation, evidence.

A proposal is what the model asks to happen: apply this patch, run this command, update this record. An effect is the attempted or completed change in an environment. An observation is what the system can inspect afterward: a diff, an exit status, a file hash, test output, a database row. Evidence is the bounded judgment that named observations satisfy a named outcome rule.

The order matters. A proposal may be rejected by policy. An authorized tool call may fail before changing anything. A real change may occur while its response is lost. An observation may be partial. An evaluator may accept the desired file while missing an unrelated deletion. Collapsing all of that into a boolean called success gives model prose far more authority than it deserves.

Patchwork, the book's fictional pedagogical software-change agent, begins with one invariant: model output cannot mark an effect observed or an outcome verified. The model can propose a patch and explain its intent. The controller can record that proposal. Only the repository adapter can report whether a write was attempted and then expose repository observations. Only a bounded evaluator can compare the observed state with outcome and collateral predicates.

For a tiny task, that might mean:

• the model proposes adding a timeout branch to client.ts;
• policy permits writes only to client.ts and its test;
• the tool reports whether it wrote the file;
• a fresh diff shows the exact changed paths;
• the typecheck and targeted test report their own results;
• the evaluator accepts only if the required behavior changed and no forbidden path did.

If the model's final message says “all tests pass” while no test observation exists, the message changes no state label. If the write tool reports success but the fresh diff is empty, the effect remains unobserved or absent. If the test passes but the allowlist check finds a collateral edit, the outcome remains rejected. The prose can help diagnose the run; it cannot promote the run.

The OpenAI Agents SDK runner documentation↗ is a bounded current reference for one implementation's model/tool loop and stopping semantics. It does not establish this invariant or prove an outcome. The classic end-to-end arguments paper↗ is a candidate foundation for the narrower idea that some guarantees depend on information available at the endpoints. That does not mean intermediate checks are useless, and I am not claiming the paper describes model agents or Patchwork.

What this does not prove is that repository observations are complete evidence. Tests can encode the wrong requirement. A diff can miss generated or remote state. An evaluator can share the proposal's blind spot. The invariant only blocks one common category error: letting a description of work certify that the work occurred.

Where does your current system let prose change an effect, observation, or verification label without independent evidence?