Maker-Checker for AI Agents: Does a Forty-Year-Old Control Still Hold?

Can a maker-checker control survive when the maker is an AI agent? Yes, but only if the agent stays on the proposal side and a separate checker controls the act. The older formulation is stricter than the loose version used in many AI meetings: for each transaction, completion requires at least two individuals. That does not mean every agent action needs a person; it means the approval boundary must not collapse into the same thing that proposed the action.

The maker checker AI agent role

Maker-checker began as a control over completion, not as a writing style for reviews. Wikipedia’s definition is blunt.

"The principle of maker and checker means that, for each transaction , there must be at least two individuals necessary for its completion."

— Maker-checker - Wikipedia, 18 September 2007

That quote does not say “one system drafts and another system comments”. It says completion requires separation. In a bank payment, one person may prepare the release and another may authorise it. In an expense process, one person may submit the claim and another may approve it. In an AI workflow, the agent can assemble the payment, draft the customer response, or prepare the record change. The hard part is the next step.

Veto’s glossary states the AI version directly: “Applied to AI agents, the agent is the maker and a human (or an independent system) is the checker.” That is the cleanest mapping. The agent originates. The checker authorises. If the same agent proposes a payment and then marks its own proposal as acceptable, the old control has not survived; it has merely been renamed.

This is where the phrase “maker checker AI agent” becomes dangerous. It can mean a useful authorisation control. It can also mean an agent that generates work and another agent that scores it. Those are not the same thing. A second agent may improve a draft policy memo, but that does not make it a proper checker for releasing a supplier payment.

The old control was not built on a belief that the maker is honest. Veto puts the point more strongly by describing maker-checker as one of the oldest controls in finance and saying that it works because it does not depend on either party being honest or correct. That is the reason independence matters. A checker who is merely downstream of the same failure is not a checker in the control sense.

The practical test is plain. Ask whether the checker can stop the action, not merely criticise the output. If the agent drafts a refund email and the checker suggests better wording, that is review. If the agent attempts to issue the refund and the checker must approve before money moves, that is closer to maker-checker. For more on responsibility when an agent acts, see Who Is Responsible for AI Decisions?.

The two meanings of maker checker AI

The phrase “maker checker AI” now carries two meanings. One comes from control language. The other comes from agent design patterns. They overlap in vocabulary, but they do not have the same purpose.

The agentic design pattern version is about iterative quality. One workshop page defines it as “a specialized two-agent loop for iterative quality refinement”. Another says one agent produces output and another evaluates it, looping until quality criteria are met. A related exercise describes the same pattern as two agents alternating on a shared conversation thread until quality criteria are met.

That pattern can be valuable. It can catch a weak summary, improve an answer, or reject a draft that fails a rubric. It is still not automatically a control over a consequential act. The checker in that pattern may be judging usefulness, not authority. It may have no mandate to stop a payment release, a deleted record, or a changed credit limit.

Bizagi frames the human-verification version differently.

"AI works best as a "maker," with humans as the "checker", combining speed with expert validation to ensure accuracy and trust."

— The AI Maker-Checker Paradigm: The Importance of Human Verification, 30 June 2026

That statement supports a modest claim. It supports AI producing something and a human validating it. It does not, by itself, prove that the validation is timely, authorised, recorded, or tied to the exact action that followed. A compliance officer should care about that gap.

Take a legal-case summary. If AI creates the summary and a subject matter expert checks it before it becomes official, Bizagi describes that as the maker-checker paradigm. That is a review workflow. It may be enough for some documents. It is not the same as a runtime stop on an agent attempting to change a customer record.

The distinction matters because reviewers often inherit the same label for different controls. A human-in-the-loop step can mean a person glancing at output. It can also mean a required approval before execution. Only the second meaning carries the older control’s discipline. The label alone proves nothing.

A second AI agent can still be a checker, but only under harder conditions. Veto’s glossary says the checker can be “a second agent with a different identity, a different policy, and ideally a different model.” Even that is not a complete answer. Different identity and policy may reduce common failure. They do not make the approval human. They do not decide whether a regulator, an auditor, or an internal risk owner will accept the evidence later.

Maker checker automation

Maker checker automation is the attempt to make the control executable. It routes the proposal. It decides whether the action can proceed. It records the outcome. Done badly, it turns a control into theatre. Done well, it makes the approval point hard to bypass.

Bizagi says process automation can ensure the maker-checker paradigm when using AI agents, and also says process automation gives a structured and systematic approach to implementing the model. That is a fair automation claim. A workflow can make sure the proposed act reaches a queue, gets a decision, and moves only after the decision. The objection is also fair: a queue is not a control if everything enters it, nobody can triage it, and approval becomes a click made under pressure.

Some agent-control products describe this as a stop before the tool call. MakerChecker says it blocks unauthorised tool calls, sends consequential actions to a named person for approval, and records exactly what happened. Its developer docs also describe approval gates where a high-risk step waits for human sign-off. Those are stronger words than “review after output”. They put the check before the act.

There is a limit. A vendor saying it records what happened is not the same as your organisation proving that the recorded event is complete enough for a dispute. You still need to know what was proposed, who or what checked it, what rule applied, what decision was made, and what action followed. If the record cannot answer those questions in sequence, the control may exist operationally but fail evidentially.

MakerChecker’s docs describe checks over whether the agent is active, whether the skill is granted to its role, whether acting would break segregation of duties, whether it is within limits, and what risk tier applies. That is the right kind of question set for automation. It treats the agent’s proposed act as something to be tested, not as something to be trusted because the agent produced it.

Automation also needs scoping. Volopay’s expense workflow page says users can select which transactions to run maker-checker on. That matters because an organisation that routes every tiny step through approval will train people to approve blindly. An organisation that routes only the wrong steps will discover the gap after the disputed action. The design question is not whether to add a checker everywhere. It is which actions need a separate authorisation event before completion.

The useful boundary is reversibility. MakerChecker says it is a server agents call before they do anything they cannot take back. That phrase maps well to the compliance problem. A draft can be revised. A deleted record, a funds transfer, or an external filing may not be so forgiving. The more final the act, the less convincing a later review becomes.

What this means if you have to produce evidence

The evidence problem starts after the action. The agent proposed a payment release. The checker approved it. The payment went out. A month later, someone disputes it. At that point, the control either left a usable record or it did not.

MakerChecker’s public page says it provides explicit permissions, human approval for consequential actions, and tamper-evident records. That combination is the right target, but the words should be read carefully. “Tamper-evident” means alteration should show. It does not mean alteration is impossible. It also does not guarantee that the underlying approval was good.

The record has to bind the proposal to the decision and the decision to the action. A log that says “approved” without showing what was approved is weak. A chat transcript that shows a human saying “yes” without tying it to the action is weak. A dashboard export that can be rewritten without detection is weak. Evidence is not the same as observability.

The older maker-checker control assumed that separate human actors created friction. AI agents remove some friction. That is useful for operations and hazardous for controls. If the agent can prepare, approve, and execute before anyone sees the consequence, the organisation has speed but not separation.

This is why maker-checker should be described as a runtime authorisation control, not merely as a review pattern. The relevant moment is before the payment is released, before the account status is changed, before the record is deleted. A later report may help incident response. It does not make the original act authorised.

For financial-services teams, the distinction is not academic; the topic page for financial services groups related pieces where agent action, approval and evidence meet. For teams dealing with clinical or other sensitive review workflows, High-Risk AI Output Review covers the review side, while AI Decision Review Workflow deals with structured oversight. Those pages are adjacent to maker-checker, but they should not be used to blur the difference between reviewing output and authorising execution.

Practical steps for applying maker-checker

1. Name the maker. Decide whether the maker is a person, an AI agent, or another system. If the agent originates the action, say so. Do not hide it behind the name of the application that hosted it.
2. Name the checker. The checker must be separate from the maker. Veto’s glossary says a human or an independent system can occupy that checker role.
3. Define the acts that need checking. Do not make the category “important things”. Write the list as actions: release payment, delete record, approve refund, change limit, send external notice.
4. Put the check before completion. MakerChecker’s docs describe approval gates where a high-risk step waits for human sign-off. A post-action review is not the same control.
5. Scope the queue. Expense-workflow material says transactions can be selected for maker-checker. That selection must be defensible, because routing too much and routing too little both break the control in different ways.
6. Record the proposal, the decision and the action. MakerChecker says it checks each call and records it. That is the minimum shape of useful evidence: what was attempted, what decision was made, and what happened next.
7. Do not overclaim agent-to-agent review. A two-agent loop can refine quality, but the workshop definition is about one agent producing output and another evaluating it until quality criteria are met. That does not automatically authorise execution.

The narrow position is simple: an agent may propose, but a separate permission step should decide before the act touches money, customers or records; for one implementation shape, see GREENLIGHT, or request the product demonstration.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Human-in-the-Loop — related posts on human review and approval boundaries.
• Financial Services — related posts on controls where money, records and approval meet.
• Who Is Responsible for AI Decisions? — why responsibility does not disappear when an agent acts.
• High-Risk AI Output Review — a closer look at review workflows for sensitive outputs.