PrymeIntelligence

Agent governance·Article

Why one agent should not approve another agent's work

One AI agent should not approve another agent's work. Agents built on the same model and sources share blind spots, so their agreement proves very little.

Two agents on similar models, reading the same sources and configured by the same team, tend to make the same mistakes. When one approves the other's work, their agreement is closer to the first opinion repeated. A checking agent can help sort and flag work. The approval itself needs an independent party, which for now means a person.

Why does a second agent feel like a control?

Because it copies the shape of one. In a human process, a preparer drafts and a checker approves, and the value comes from two people with different knowledge, attention and incentives looking at the same item. Putting a second agent in the checker's seat produces the same diagram: two boxes, two steps, an approval at the end.

It is also cheap and fast. A checking agent never tires, never falls behind and can review every item rather than a sample. For teams struggling to staff approval queues, that is very attractive.

Why does agreement between agents prove so little?

Independence is what makes a second check valuable, and two agents are rarely independent.

Shared models. If both agents run on the same model, or on models trained on similar data, they share the same tendencies: the same misreadings, the same confident errors on the same kinds of input. A mistake that looks plausible to one will usually look plausible to the other.

Shared sources. If both read the same policy library, product terms and customer record, an error in those sources passes through both. The checker confirms the preparer's work against the same wrong fact.

Shared configuration. If the same team wrote both agents' instructions, their assumptions about the process are built into both. The checker looks for the problems its authors thought of, which are the problems the preparer was also built to avoid.

Shared exposure to manipulation. If the preparer was misled by an instruction hidden in a document, the checker reading the same document may be misled the same way.

The result is that errors are correlated. Two agents agreeing does not halve the chance of a mistake; it may barely change it. And because the approval looks independent, people downstream relax.

What can a checking agent usefully do?

Plenty, as long as it is not the approver. Its value lies in narrowing and focusing the work a person has to do.

A checking agent may It should not
Compare a draft against stated rules and flag mismatches Release the draft
Check that every fact cited has a source, and mark weak sources Decide that a weak source is good enough
Sort held items by risk so people see the important ones first Clear low-risk items from the queue on its own
Summarise what changed in a case since the last action Treat its summary as approval
Detect patterns across many items that a person would miss Overrule a person's decision

Used this way, the checker makes human review faster and better targeted. Our piece on whether one AI agent can check another's work for compliance explores the boundary in more detail, especially for second-line monitoring.

What should approve an agent's work instead?

For actions that need approval, a named person with the time, information and authority to refuse. For routine actions an agent has proven it can handle, no approver at all: the action is checked against the agent's bounds when it acts, and allowed if it passes.

That second option is often the better answer to the pressure that leads teams to use checking agents. If the volume of held items is too high for people, the question is whether those items need holding. Where evidence shows the agent handles a type of work reliably, it can be allowed to execute that work within bounds, and human review can concentrate on what remains. Our guide on designing the hold-and-approve step for an AI agent covers how to decide what to hold.

The same logic applies at a larger scale. Deciding that an agent is fit for production is an approval, and it should not rest on another agent's assessment either. Our playbook on approving a new AI agent for production sets out who should sign.

Could two very different agents be independent enough?

In principle, more independent: different models, different sources, different teams. In practice, true independence is hard to achieve and harder to prove. Models increasingly share training data and techniques. Sources in a business tend to come from the same systems of record. And the people configuring both agents work in the same organisation, with the same view of the process.

Even with real differences, the checker is still a system acting on behalf of the business, with no accountability of its own. When its approval turns out to be wrong, someone still has to answer. It is cleaner for that someone to have made the decision.

What does the uneventful case teach here?

Most of an agent's work is routine and correct. A checking agent will agree with almost all of it, and that agreement will be right. That steady stream of correct agreement is what builds trust in the arrangement, and that trust is exactly what makes the rare correlated failure so damaging when it arrives. As we put it in the uneventful case is the common one, controls are designed for the case that is not uneventful, and agent-on-agent approval is weakest precisely there.

What is the trade-off?

Keeping people as approvers means paying for review time and accepting that queues will sometimes be slower than a machine could clear them. It also means designing review so people are not overwhelmed, which usually means holding less and proving more.

Using an agent as approver saves that cost and replaces it with a hidden one: a control that will fail at the same moment as the thing it controls. Look at any process where an agent's output is released on another agent's approval, and change the second agent's role from approving to flagging, with a named person deciding. The broader framework for who decides what is in our guide to agent governance as a bound, not a model.

Where Pryme fits

In Pryme, a held action waits for a named person. Agents can coordinate other agents through an orchestrator, but each agent's action is checked against its own bounds and no agent can approve a held item. A checking agent can sort, summarise and flag work for a reviewer; the verdict and the approval are filed against the named person who made it.

Questions people ask

Is it acceptable for an agent to approve very low-value items?

If the items are low enough in value and risk that no approval is needed, let the preparing agent act within that limit and drop the approval step. Approval by a second agent adds the appearance of a control without the substance.

What about using a different model provider for the checker?

It reduces some shared tendencies but not shared sources, shared configuration or shared exposure to the same inputs. It can make a checker more useful as a flagging tool. It does not make it an independent approver.

Can a checking agent reduce how many items a person reviews?

Yes, by sorting and highlighting, so people spend their time on the items most likely to be wrong. It should not remove items from the queue without a person seeing them, unless the preparing agent was already allowed to act on that work alone.

Decide what your agents may do. Prove it. Enforce it.

Pryme Intelligence certifies each agent on your own cases, checks every action against five bounds at the moment it happens, and files every verdict.