The verifier problem: why your agent keeps thinking it's done

I want to explain why Missions in Cortex work the way they do, because the design decision at the center of them is not obvious until you have watched enough agents fail.

When we started building Cortex three and a half years ago, the goal was straightforward: instrument the full path from signal to deployed change. A customer reports a bug, an internal conversation identifies an opportunity, a telemetry alert fires — all of these are signals, and they have always been converted into software by humans absorbing them, prioritizing them, planning around them, building from the plans, and validating the results. We wanted to see how much of that loop could flow without a human needing to intervene at each step.

We learned something early that took a while to articulate clearly. The agents were not failing at generation. They were failing at judgment — specifically, the judgment that says: this is done, and here is how I know.

The generator is the cheap part

Here is the thing about a generative agent: once you have a good harness, the model will produce output endlessly and cheaply. Give it a task, and it will write code, check its work, refine, and keep going. The cost per iteration has collapsed. The speed has become remarkable.

What that means is the bottleneck has moved. It is not the generating. It is the verifying.

And there is a specific failure mode that only becomes visible when you run enough agents on enough tasks: a model that produces the output and grades its own output will drift toward telling you it is done. Not because it is being dishonest — agents are, in my experience, genuinely good-faith systems trying to solve the problem they were given. The issue is subtler. As an agent gets closer to the edge of what it can confidently verify, it gets more likely to rationalize its way to a passing grade. Anthropic’s own interpretability research has surfaced something in this space — representations that look like the agent becoming more likely to take shortcuts as it approaches a failing goal. I think about that finding a lot when I think about the verifier problem.

A spec-driven workflow that says “here is what I want, write some tests at the bottom” is not an answer to this. The agent writes tests. The tests pass. The tests were written by the same agent that wrote the code, so they test the behavior the code has, not necessarily the behavior you wanted. You end up with a green checkmark that means “the agent’s implementation of the feature satisfies the agent’s tests of the feature.” That is not nothing, but it is not proof.

What a Mission actually is

A Mission is our attempt to formalize the verifier into a first-class object, defined before generation starts and kept separate from it.

Concretely, a Mission is a structured data object — not a prose spec, not a ticket with some acceptance criteria at the bottom. It enumerates every hypothesis the software should satisfy. Can a user complete sign-up in under four clicks? Does this payment flow handle a timeout without double-charging? Does this API return the right shape when the upstream service is down? Is this test coverage threshold met? Does this endpoint reject an unauthenticated request?

Each hypothesis comes with a second declaration: how will we know this is true? And the discipline we enforce is that this declaration cannot be “the agent will check.” The verifier has to be something external to the generation loop — a unit test, an end-to-end test, a computer-control session in a real browser, a type check, a lint rule, a coverage metric.

Where deterministic verification is not possible — where the outcome is genuinely about judgment (“does this code review comment actually improve the code?”) — we use an LLM-as-judge, separately scoped with fresh context, explicitly separated from the agent that produced the work. The wall of context between creator and verifier is not an accident. It is the whole point.

The agent cannot finish until every verification passes. Not “mostly passes.” Every one. The result is that the loop is not closed by the agent’s confidence — it is closed by external confirmation. That distinction sounds subtle. In practice it is the difference between work that ships with evidence and work that ships on faith.

The architecture underneath

The structure that makes this work has three parts: an orchestrator, workers, and a validator.

The orchestrator defines the Mission — it takes the goal, decomposes it into principal units of work, and defines the skills each worker will use. Workers then pick up a task with clear instructions and a blank context. They do not know what the other workers have done. This isolation is deliberate: it means any attempt to game the verification — any drift toward rationalizing a pass — only survives within a single run, not across the whole Mission.

When a worker finishes, the validator comes in. The validator is also operating with fresh context. It does not inherit the working state of the agent that built the thing it is verifying. It sees the task definition, the success criteria, and the result — and it answers: did this pass, or not?

Where something fails, the loop does not stop. It repairs and re-validates. The Mission does not complete until the whole structure resolves — all hypotheses confirmed, or explicitly escalated to a human because they cannot be machine-verified.

What this costs, and why it is worth it

I will not pretend Missions are cheap. On a large task — migrating a substantial legacy codebase, building a new product surface from a complete spec — the cost can run from a few hundred dollars to over a thousand. The orchestrator, the parallel workers, the validation passes, the repair loops: every one costs inference.

The right comparison is not “this versus a one-shot prompt.” The right comparison is “this versus a contractor engagement” — where you are getting a quoted scope, defined deliverables, and evidence that the work meets the spec. When you frame it that way, the economics look different. We are working toward being able to insure the outcome: here is the cost, here is what you will get, and we stand behind it. That is a technology problem we are actively solving.

But the more common waste I see is not expensive Missions at all. It is ten thousand employees using AI tools with no routing discipline, no cost controls, and no sense of when a task needs a frontier model and when a cheaper one is fine. That gap — wasted spend on the wrong tool for the task — is orders of magnitude larger than Mission costs for most enterprises.

Agents succeed when they have non-human feedback

There is a more general principle underneath all of this, and it shapes how we think about the Agent Readiness Assessment too.

Agents succeed when they can receive feedback from something other than a human, consistently and reliably. That is the whole game. The more of your codebase is instrumented with deterministic feedback — tests that pass or fail, lint rules that fire, coverage thresholds that hold, dev environments that spin up cleanly, logging formats that enforce themselves — the better agents perform in it. Not marginally better. Substantially better.

When we look at a codebase and say it is not ready for agent-assisted delivery, we almost always mean one thing: there is not enough machine-checkable structure for an agent to know whether its work is correct. It has to ask a human at every step, which means it is not an agent — it is an autocomplete with extra steps.

The Mission is the formal expression of that principle at the task level. Define the outcome. Define how you will verify it. Let the agent work. Do not let it stop until the verification passes.

That is the whole design.

“The agent cannot finish until every verification passes. Not ‘mostly passes.’ Every one. The loop is closed by external confirmation — not the agent’s confidence.”