A thesis has been hardening across agent-builder communities over the past two weeks, on multiple platforms at once: a verifier that shares too much with the agent it checks isn't verifying anything. The strongest phrasing came from a discussion thread that put it bluntly — if your verification step runs in the same context as your agent, you built a mirror, not a checker. Around the same time, one of the better-known voices in agentic coding described splitting coding agents from verification agents as the core of loop engineering. Different communities, same conclusion.

The popular shortcut this thesis is aimed at looks like this: after the agent finishes, send one more prompt. "Now act as a strict QA reviewer and critically evaluate the work above." Same agent, same context window, same instructions, new persona. It feels like verification. It produces verification-shaped text.

It's the same agent grading its own homework in a different font.

We've written about verification before, from three other angles. Explicit success criteria covered what "done" means — naming the stopping condition. Latency per correct output covered measuring whether work actually finishes. Contract tests for agents covered where to test — the deterministic boundary instead of the stochastic core. And the post that started it all established that self-approval is worthless.

This post is about the remaining question: what makes a verifier real. The answer is architectural separation, on four specific axes.

Why the prompt-only persona fails

The reviewer persona inherits everything that made the builder wrong.

It inherits the reasoning. The persona has read the builder's chain of thought, because it is the builder's context window. Anchoring does the rest. Once a conclusion exists in context — "the layout renders correctly" — the follow-up evaluation gravitates toward confirming it. You're not asking a second opinion; you're asking the first opinion to repeat itself in a skeptical voice.

It inherits the misreading. If the agent misunderstood the spec, the persona sharing that context misunderstands it identically. A reviewer who read the same wrong summary of the requirements will approve the same wrong implementation.

It inherits the instructions. Any blind spot in the builder's instruction file replicates into the verifier, because they're the same file. If the instructions never mention checking text rendering on product mockups, neither the builder nor its in-context reviewer persona will check it.

It inherits the incentive. The builder's context is organized around finishing the task. A persona spun up inside that context shares the momentum. Real verifiers have no stake in the work being done.

None of these are fixable with better prompt wording. They're properties of shared state. So the fix is to stop sharing state.

Separation one: a different process

In our system, the verifier is a separately spawned child process with a clean environment and a fresh context window. It receives the task reference and the artifact to check. It does not receive the builder's reasoning, the builder's session, or the builder's narrative about what happened.

This matters more than it sounds. The single most useful property of a fresh-context verifier is that it can only verify the claim, not the story. A builder that reports "tests pass, page renders correctly" hands the verifier a claim. The verifier has to reconstruct the evidence from scratch — run the checks itself, take its own screenshots, read the actual output. We learned to treat builder-provided evidence as input, never as proof: our hardest-won verification rule is that the builder's screenshots are not the gate, the verifier's are. A verifier that accepts the builder's artifacts as evidence has quietly re-merged the two contexts.

Separation two: different instructions

The builder and verifier load different role definition files. Not the same file with a flag — different files, maintained separately, encoding different professional paranoia.

The builder's instructions accumulate construction knowledge: how to structure a change, which patterns the codebase uses, what the deploy pipeline expects. The verifier's instructions accumulate defect knowledge: inspect rendered text character by character because generated text fails in ways builders don't notice; verify the live page rather than the local artifact; check the siblings of anything that failed, because defects come in families.

These bodies of knowledge are different on purpose, and they must evolve independently. When a builder's instruction file develops a blind spot — and it will — an independently maintained verifier file is the thing that catches the consequences. Shared instructions mean correlated failure.

Separation three: different memory

Each role in our system has its own memory namespace: a separate short-term file and separate categories in the long-term store. The coder's memory and the verifier's memory cannot write into each other.

The failure mode this prevents is prior poisoning. A builder that concludes "this approach is reliable" writes that into its memory. If the verifier read the same memory, it would inherit the belief — and a verifier's whole job is to not believe that yet. Over time the two memories are supposed to diverge: the builder's fills with techniques, the verifier's fills with the specific ways those techniques have failed. Divergent memory is not a bug in the architecture. It's the evidence the architecture is working.

Separation four: enforced at the queue, not opt-in

The first three separations are worthless if invoking the verifier depends on someone remembering. Under load, optional verification decays to zero.

So the separation is injected where tasks are created. When a build task enters our work queue, the tooling automatically chains a verification task — assigned to the verifier role — that fires when the build task completes. The builder cannot close the loop alone, structurally. This wasn't always true: we once shipped a product with a visible text-rendering defect because the agent that produced it also certified it, and nothing in the system required anyone else to look. The lesson wasn't "remind agents to request review." Reminders are prompt-level fixes for an architecture-level problem. The lesson was to make the chain injection automatic.

One subtle bug we hit afterward: review tasks kept drifting to the wrong role — the meta-agent that monitors system health and edits agent instructions. That agent is also "a different agent," but it's the wrong kind of different. It evaluates the system; the verifier evaluates the artifact. Routing verification to the meta-role recreates a softer version of the original problem, because the meta-role's context is about whether the machine ran, not whether the output is right. Our task tooling now corrects the role assignment on verification tasks automatically. Role separation has to name the right role, not just a different one.

The four-question audit

If you run agents that check other agents' work, four questions tell you whether you have verification or theater:

1. Can your verifier read the builder's reasoning? If yes, it's anchored.
2. Do they share an instruction file or a memory store? If yes, their failures are correlated.
3. Would a blind spot in the builder's instructions change the verifier's behavior? If yes, you have one agent, twice.
4. Does verification happen if nobody remembers to ask? If no, it will stop happening.

The role definitions, memory directive, and queue-level chain conventions we run in production are public in the Agent Architect Kit if you want a starting point.

The community phrasing going around is right, and worth keeping: a verifier that shares state with your agent isn't a verifier. It's your agent wearing a costume — and underneath the costume, it already agrees with itself.