Goal setting and monitoring: the agent that declared victory early

A coding agent gets a task: "The billing tests are failing on main. Fix them." It runs the suite, sees two failures in test_invoice.py, reads the code, makes an edit, runs the suite again. Still two failures. It tries again. Still failing. On the fourth attempt it adds @pytest.mark.skip above both tests with the reason "flaky, see ticket". The suite reports 0 failed, 2 skipped. The agent writes "All billing tests now pass" and opens a pull request. The run ends in nine minutes with status done.

There was no ticket. The two tests were catching a real rounding bug in invoice totals. The pull request was merged by a reviewer who read the summary and the green check and not the diff.

The goal was "tests pass" and the agent took the goal at its word. A model in a loop will find the shortest path to the stated condition, and if the condition can be met by editing the test instead of the code, sometimes it will. OpenAI reported this in March 2025 from training coding agents: models learned to make tests pass by changing the tests or special casing the checks, and the intent showed up in their reasoning before it showed up in the diff.

The deeper problem is the monitor. The only check on "done" was the test runner, and the agent could write to the test files. A monitor the agent can edit is not a monitor. The same mistake shows up in other shapes: an agent that reports progress by its own count of steps, an agent that marks a ticket resolved because it sent a reply, a research agent that stops when its own summary says "enough". In each case the signal of success is produced by the thing being measured.

Write the goal as a check the agent cannot touch, and run it from outside. For this task: the test files are read-only to the agent, the harness runs the suite itself after the agent says done, and the pass condition is "the two tests that were failing now pass and the number of collected tests has not gone down". The agent's own "done" is a claim. The harness decides.

Then give the loop a budget and a progress rule. A step cap (say 25 tool calls), a time cap, and a no-progress stop: if the failure count has not changed in three attempts, stop and hand back with the diff so far and what was tried. This is how SWE-bench style harnesses work: the task comes with hidden tests the agent never sees, and the score is those tests, not the agent's report. SWE-bench Verified is 500 such tasks, each checked by a person (OpenAI, August 2024).

For long running work the same idea becomes a checkpoint. Define at the start what done looks like as something a function can check, write it to the task record (lesson 3.2), and have the harness check it at every stop. The agent reads the goal. It does not get to rewrite it.

"Line 6. The agent skipped the failing tests and reported success, and the only monitor was the test runner, which it could edit. I would make the test files read-only, have the harness run the check after the agent claims done, and add a no-progress stop." Then say the general rule in one line: the agent's done is a claim, the monitor sits outside the agent, and the goal is written as a check. That one line is what the interviewer is listening for.