The Maker and the Checker
Vishal Sachar
Co-Founder & CEO of CLRT
The single most important structural decision in any agentic system is also the most overlooked. You must separate the agent that does the work from the agent that checks it. A model grading its own output is the most generous marker in the world, and you cannot build anything you trust on top of it.
The reason is simple and human. The same reasoning that produced an answer is the reasoning least able to see what is wrong with it. An AI that just wrote a piece of code, or a financial summary, or a client email, has effectively talked itself into believing it is correct. Ask it to review its own work and it will mostly confirm its own conclusion. Ask a second agent, with different instructions and sometimes a different underlying model, and the second one catches what the first one could not see.
This is why serious systems are built as a maker and a checker. One agent explores and produces. A separate one verifies the result against the actual requirements, the tests, the rules, the spec. The split is what lets the system run without a person watching every step, because the verification you trust is the only thing that makes "it is done" mean something more than "it claims to be done."
It costs more. A checker is a second pass, more time and more compute, so you spend it where a second opinion is genuinely worth paying for: the high-stakes output, the irreversible action, the work going straight to a client. You do not check everything. You check what matters.
The principle reaches well beyond software. Any process where the same person produces and approves their own work has the same blind spot. The maker and checker split is just good governance, applied to machines.
Never let the agent that did the work be the only one that decides it is good.
A deeper dive
There is a real cognitive reason self-review fails, and it is not laziness. A model generates an answer by following a particular chain of reasoning, and when you ask the same model to review that answer, it tends to re-walk the same chain and arrive at the same place, confirming rather than testing. Effective verification breaks that symmetry deliberately. You give the checker different instructions ("find what fails these requirements" rather than "is this good"), often a different model, and ideally only the requirements and the output rather than the original reasoning, so it cannot simply inherit the maker's assumptions. This is exactly the principle behind goal-driven agent loops, where a separate, fresh evaluation decides whether the stopping condition is truly met, rather than letting the worker declare its own victory. The cost is a second pass, so the engineering judgment is allocation: spend verification on the irreversible and the high-stakes, accept lighter checks on the cheap and reversible.
Key terms
- Maker
- The agent that explores and produces the work.
- Checker
- A separate agent that verifies the result against the actual requirements.
Work with CLRT
Shipping AI into anything that matters? Every agent CLRT builds carries verification by design, because in production "it claims to be done" is not good enough. Let us show you what that looks like.
Vishal Sachar
Vishal Sachar is the Co-Founder and CEO of CLRT, where he helps UAE businesses make sense of applied agentic AI and put it to work. He writes on agentic systems, AI governance, and the economics of automation. Reach him at vishal@clrtstudio.com or on LinkedIn.
