Who writes the agent's tests: three ways to define what's correct

When you build an agent, the question that really matters isn't how to describe the solution—it's who decides whether a solution is correct. In the write-test-fix loop that decision was made by tests you wrote by hand: you defined, up front, what counted as done. But writing the tests by hand is only one of the ways to give an agent that criterion, and it's the one that scales worst. This is the conceptual leap of the series: an agent's real input isn't the description of the task, but the definition of how a correct solution is recognized—what I called the evaluator in the minimal-loop post. This post walks through the three levels of that input, from tests by hand to the repo's suite, and the principle that ties them together.

TL;DR

• An agent's real input isn't describing the solution, but defining how a correct one is recognized. That piece—the tests, a check, another model—is what the series calls the evaluator, and an agent doesn't optimize for doing the right thing: it optimizes for passing it.
• There are three levels depending on who writes the evaluator: you by hand (spec + tests), the agent from examples you give it, or the repo's existing suite. The higher the level, the less work per task and the less control over the criterion.
• The higher the level, the higher what you have to review climbs. At level 2 you review the tests the agent wrote itself, not just its code: an agent that defines its own criterion can set itself a lax one and go green without being right.

The evaluator is the agent's real input

In the previous post I called the piece that decides whether the model's output is correct the evaluator. In the write-test-fix loop that evaluator was the tests: a process that returns green or red. It's easy to read it as an implementation detail—"you need some tests to stop the loop"—and move on. But the evaluator isn't a detail: it's what you're really giving the agent.

Look at it from the loop. The model proposes an output, the evaluator judges it, and depending on that judgment the cycle stops or tries again. The model supplies the judgment about what to do; the evaluator supplies the judgment about whether it came out right. Remove the evaluator and you don't have an agent: you have a model that writes once and nobody checks whether it got it right.

That piece is exactly what a chat doesn't have, and putting them side by side is the fastest way to see why the evaluator is the input that matters:

CHAT                         AGENT

prompt                       prompt  (goal)
   │                            │
   ▼                            ▼
 model                        model ──► output
   │                            │
   ▼                            ▼
response                     evaluator ──► correct?
                                  │
                             no ──┘──► another turn
                                  │
                            yes ──► deliver

In a chat, the model's output is the final answer. In an agent, that same output passes through the evaluator first, and it's that verdict—not how many times you call the model—that turns the cycle into an agent. Everything the series built up to here—the loop, the sandbox that turns the output into a reliable observation—exists to run an evaluator you supplied.

From there comes the consequence worth keeping in mind from the start, because it explains a lot of agent behavior that looks strange until you have it in your head:

An agent doesn't optimize for doing the right thing. It optimizes for passing the evaluator you gave it. If the evaluator is lax, "correct" comes to mean "whatever the evaluator lets through."

And from there the principle that orders the post: your job when building an agent isn't to describe the solution, but to define how a correct solution is recognized. That definition is the evaluator, and it's the input that really matters. It sounds abstract until you ground it in a concrete question: who writes that evaluator? In the minimal-loop post you wrote it yourself, by hand, as three tests. But that's not the only option, and depending on who writes it, how much work it costs you to define the criterion—and how much control you have over it—changes. That's what separates the three levels.

---

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/who-writes-the-tests-agent-evaluator.