Agents That Verify Agents: How We Ship With a Lean Orchestrator
The agent that wrote the code is the worst possible judge of whether it works. So we stopped asking it.
TL;DR
- We ship AI-built platforms with a lean orchestrator that delegates each unit of work to a fresh-context subagent, then hands the result to a separate verifier that certifies "done" against checkable predicates — not the builder's own optimism. Underneath sit two more disciplines: idempotent, check-before-create provisioning and eval-first ML.
- This is how we get AI speed without AI slop: velocity from parallel agents, safety from a verifier that didn't write the code it's judging.
- The whole approach lives in a reusable, versioned build-system skill library — 13 deployable packages, 20 build-system skills — so the same discipline runs across every platform we build. (Not to be confused with the ~30 Claude skills that ship inside the Prompt Your Site product for buyers to keep — a different set.)
Why does "just use AI" produce code you can't trust?
Hand a single agent a big task and a full context window, and it will confidently declare victory — because it spent its effort convincing itself, not checking itself. Long-running agents drift: context fills with their own prior reasoning, and self-assessment becomes self-congratulation.
The cost lands in production. You get a codebase that demoed well and fails the first time reality touches it, and nobody can say which part was actually verified. For a buyer approving budget, that's the exact nightmare — paying for something that looks done and isn't.
How the orchestrator stays lean
The orchestrator's job is coordination, not construction. It holds the plan and the state, and it deliberately keeps its own context small so it never becomes the bottleneck or the drifting narrator.
Delegate to fresh-context subagents
Each meaningful unit of work goes to a subagent that starts clean — no inherited assumptions, no accumulated cruft. The subagent does the task and returns a distilled summary, not a transcript. The orchestrator absorbs the summary and moves on, so the expensive context is spent on work rather than on re-reading everything that came before.
Certify "done" with a separate verifier
This is the beat that matters most. When a subagent claims a task is complete, a separate verifier agent checks it — against explicit, checkable predicates rather than prose vibes. "Done" is a state something else confirms, not a state the builder asserts. A gate you can check beats a paragraph that says "looks good," every time.
Keep provisioning idempotent
Real builds touch real services — GitHub, Vercel, Stripe, Resend, Neon. Our provisioning scripts check before they create: if the Blob store or the Stripe product already exists, the script reuses it. That single rule makes the pipeline recoverable — a failure halfway through is a re-run, not a cleanup job and a pile of duplicates.
Where eval-first ML fits
When a build includes machine learning, the eval harness comes first — before any tuning. The eval defines what good output means and holds every subsequent change accountable to a number. Improvements get measured, not asserted. It's the same instinct as the verifier: don't trust the thing that has a motive to claim success; make it prove the claim against a standard you wrote down first.
We build the method into the tooling, not the meeting
Discipline that lives only in someone's head evaporates under deadline. So ours is encoded: gates with checkable predicates, deterministic apply-and-audit scripts that own their own marker-fenced regions, a self-maintaining memory architecture, and the orchestrator-plus-verifier pattern itself — all packaged as a versioned skill library we deploy into any repo via a manifest with per-file hashes.
That's the proof, and it's inspectable. We didn't invent a metric for this post; the library, the verifier pattern, and the idempotent provisioning scripts are the actual machinery behind the platforms we operate. If we can't point at it, we don't claim it.
What people get wrong about multi-agent systems
The mistake is thinking more agents means more magic. It doesn't — more agents without a verifier just means more confident wrong answers, faster. The value isn't the swarm; it's the separation of concerns: a builder that builds, a verifier that has no stake in the build passing, and gates written as predicates a machine can actually check. Take the verifier out and you've automated your way to unmaintainable code more efficiently.
Frequently Asked Questions
Why use a separate verifier agent instead of trusting the builder?
The agent that wrote the code is the worst judge of whether it works — it's primed to see success. A separate verifier with fresh context checks the change against explicit, checkable predicates, so "done" is certified by something that didn't just spend its effort convincing itself.
What makes provisioning idempotent, and why does it matter?
Our provisioning scripts check before they create — if a Vercel Blob store or Stripe product already exists, the script reuses it instead of making a duplicate. That means you can re-run setup safely after a failure, which is the difference between a recoverable pipeline and a fragile one.
What does eval-first ML mean in practice?
You write the evaluation harness before you tune the model. The eval defines what good output is and holds every change accountable to it, so improvements are measured rather than asserted — the same proof-over-pitch discipline we apply to the rest of the stack.
Want this discipline on your build?
We operate our own products this way before we ever run the method for a client. If you want AI speed with verifier-certified "done" instead of slop, start a conversation — we'll walk you through how we'd build yours.
About the author — William Rodriguez is the founder of Analytical Solutions and the architect of its agentic build system, the lean-orchestrator and verifier workflow described here. Learn more about us.