We spent part of this week testing a build pattern that pairs every AI agent with a second agent whose only job is to refuse the first agent's work until it clears a bar. We are calling it the AI critic loop, and it changes how we structure every system we ship for clients this quarter.
The three-part structure behind it
The pattern itself is not complicated. It is a prompt built from three parts: a task, a build method, and a bar to hit. The task states what you want built. The build method tells the main agent to break that task into pieces, hand each piece to a separate sub-agent, and route that sub-agent's output to a paired critic agent before it counts as finished. The bar to hit is the stopping condition: the critic has to be satisfied, not just the builder.
That third part is the one most people skip. Most prompting still runs on a single pass: you ask, the model answers, you eyeball it, you ask again if it is wrong. The critic loop removes you from that middle step and puts a second model in your seat, one that is instructed to be hard to please.
Why splitting the builder from the judge works
This is not a new idea. Anthropic published research on this exact pattern back in 2024, describing what they call the evaluator-optimizer workflow: one model generates, a second model critiques against explicit criteria, and the loop repeats until the critique passes. Their finding was direct: a model grading its own homework tends to grade generously, and separating the roles produces measurably better output than a single model self-checking its own work. You can read the original writeup on Anthropic's building effective agents research page.
What has changed since then is not the idea, it is the tooling. Claude Code now ships native support for defining and orchestrating sub-agents directly inside a project, which means you no longer need custom orchestration code to run a builder and a critic against each other. You write the three-part prompt, and the main agent handles the fan-out and the handoff.
Beyond demos: what this looks like inside a 40-person company
The public demos of this pattern have mostly been visual: game levels, 3D walkthroughs, interactive worlds built from a single long-running prompt. Impressive, but not what most operators are shipping. The pattern is the same one we use when we build an AI Operations Agent for a client: break the build into pieces, assign each piece its own reviewer, and refuse to call it done until the reviewer signs off against a standard the client actually cares about, not a standard the builder invented for itself.
Concretely, here is what the loop looks like when we run it on an internal build:
- Task: state the deliverable in one sentence, including who it is for and what "done" means to them.
- Build method: split the deliverable into the smallest independent pieces, assign each to its own sub-agent, and pair every sub-agent with a critic that never touches the build code, only the output.
- Bar to hit: give the critic a reference to check against. A real client workflow, a real data set, a real screenshot. Not "make it good," an actual artifact to compare to.
That last piece is the one that makes or breaks the loop. Vague bars produce vague loops that stop early because the critic has nothing concrete to refuse. Specific bars, like a floor plan a 3D build has to match, or a client's actual lead intake spreadsheet an automation has to reconcile against, keep the loop running until the output is actually right.
Single pass versus the critic loop
| Dimension | Single-pass prompting | Builder-critic loop |
|---|---|---|
| Who judges the output | You, manually, each round | A dedicated critic agent, every round |
| Stopping condition | Whenever you run out of patience | Whenever the critic clears the bar you set |
| Your time cost | High, you review every draft | Low, you review the final pass only |
| Failure mode | Model marks its own work as good | Vague bar lets the critic pass weak work |
What we are changing this quarter
We are folding a critic sub-agent into every build that comes out of a luup assessment. When we scope a client's automation work now, the spec includes not just what the agent should do, but what a separate reviewing agent will check it against before it ships to the client. That review artifact, a real invoice, a real call transcript, a real lead form, becomes part of the deliverable, not an afterthought.
It also changes what "done" means operationally. Every system we build already runs unattended: clients get agents that work 24/7 instead of waiting on a team member's inbox. Layering a critic loop on top of that means the agent is not just running around the clock, it is checking its own output against a real standard before anything reaches a client's desk. Clients still own 100% of the code and files we build for them, the critic loop just changes how confident we are in what we hand over before we hand it over.
We are also using this to tighten the €999 assessment itself, which is credited to the build. Part of the assessment now includes writing the bar each future sub-agent will be checked against, so the client is not just getting a scoped plan, they are getting the actual reference artifacts the critic loop will use once the build starts.
Where to start if you want to try this yourself
If you run Claude Code already, the fastest way in is to rewrite your next non-trivial prompt into the three parts: task, build method, bar to hit. Give the critic something real to compare against, not an adjective. Read the model overview on Anthropic's models page if you are deciding which model to run as the critic versus the builder, since the two roles do not need to run on the same model or the same pricing tier. You can check current tiers on Anthropic's pricing page before you commit a critic loop to a model that is more expensive than the task needs.
The tradeoff worth knowing before you build this into a client workflow: a builder-critic loop is slower and more expensive per run than a single-pass prompt, because you are running two models in a loop instead of one call. For a one-off build that only ships once, that cost is trivial. For something you plan to run repeatedly inside an automation, decide upfront whether the critic runs every time or only during the build phase, otherwise you are paying for a critic on work a human already approved once.
For most operators, the first place to apply this is wherever you already suspect quality is inconsistent: a content pipeline, a lead qualification agent, a client reporting build. If you are not sure where the leak actually is, our revenue leak heatmap is a faster starting point than guessing. And if you want to see what a builder-critic build looks like once it ships to a real client, our case studies walk through the finished systems, not just the demos.
The gap between a system that looks finished and a system that has actually been checked against something real is where most AI pilots quietly fail. The critic loop is a cheap way to close that gap, and it is now easy enough to set up that there is no good reason to keep shipping single-pass output to clients. We write more of these breakdowns on the blog as we test them against real client builds.