How to Stop AI Agents From Hallucinating: The Verifier Approach

The failure mode is familiar to anyone who has used a research agent: it returns a clean, confident, well-formatted answer, and somewhere inside it is simply wrong. A fabricated citation. A reasoning step that doesn’t follow. A source no one should have trusted. The output looks more reliable than it is, which is exactly what makes it dangerous.

Simon Du — Reasoning Chief Scientist at Apodex and an ML theorist whose convergence proofs the field cites — argues that the usual fixes for this don’t address the real problem. Apodex builds verification-centric deep-research agents, and Du’s central claim is that accuracy comes from an architectural decision most teams skip: a second model whose entire job is to doubt the first.

Why prompts and bigger models don’t fix it

The two default responses to hallucination are to write a better prompt or reach for a larger model. Du’s point is that by mid-2026, the multi-agent system itself is no longer the differentiator.

“This is now super normal in the mid of 2026,” he says of multi-agent setups. “Maybe it’s novel half a year ago, but now I think every company has a version of it.” If everyone has the same machinery, the same machinery isn’t what makes one system more trustworthy than another.

What he says actually moves the needle is an explicit, separate verification agent. “What differentiate from us is we also have agent to do verification.” Not a prompt that asks the model to double-check itself — a distinct agent, pointed at a different job.

What the verifier actually checks

The verification agent is, mechanically, the same underlying model. The difference is its inputs and its task. The reasoning agent sees the search results and proposes a claim. The verifier sees more — the reasoning process and the final claim — and judges whether the chain holds.

Du describes three kinds of checks the verifier runs:

• Source reliability. “Generally speaking, the information from Wikipedia is like someone at least check it, so it’s more reliable than a random post from Reddit.” The verifier judges whether a source should be trusted at all.
• Reasoning validity. It checks “whether the reasoning from the source to a claim is correct or not” — judging another agent’s reasoning process, not just its conclusion.
• Executable verification. “If it’s about some coding cost, you can actually write some tests to verify the program you write is correct.” For code, the verifier can write a test and run it.

The key structural point: “We have an explicit sub verification agent to do verification.” It sits outside the reasoning it audits, which is what lets it disagree. A model asked to check its own work tends to rationalize whatever it already produced; a separate verifier, fed a different slice of context, has no answer of its own to defend. That independence is the whole reason the check is worth running at all.

The sync-meeting analogy that makes it click

The most useful reframe Du offers is organizational. The verifier isn’t only a correctness filter — it’s the coordinator that keeps a large agent team aligned.

“Those verification agents basically acting as organizer of an alignment meeting in a company,” he says. “It gathers all the information and then it will verify which one is correct, and maybe discard those wrong ones, and then it will reassign the task for the next step.”

He pushes the analogy directly: “Just like how you organize a company, you know, while you have weekly meeting, because you need to sync all the information from this week’s output. We also have some similar based like this verification agent will verify all the information and then reassign some tasks.”

So verification does double duty. It throws out wrong answers, and it decides what the team works on next. In a system that can run up to 150 agents on one task, that sync function is what stops the whole thing from drifting into noise.

The practical takeaway

If your agent has to be right about things that cost money when they’re wrong, Du’s argument is worth sitting with: hallucination is partly an org-chart problem. The fix isn’t a smarter generator — it’s a separate referee with different inputs, free to disagree, that gates the answer before it ships and reassigns work when something fails the check.

FAQ

How do you stop an AI agent from hallucinating?

Add a separate verification agent that audits the reasoning before any answer ships. According to Simon Du of Apodex, a dedicated verifier — with different inputs from the reasoning agent — checks whether sources are reliable, whether the reasoning follows, and for code can write and run tests. That structural separation matters more than prompt tweaks.

Why isn’t a better prompt enough to fix hallucination?

A prompt asking a model to check itself keeps the check inside the same reasoning process that produced the error. Du’s approach uses a structurally separate verification agent that sees the full evidence chain and final claim, so it can catch flawed reasoning a self-check would miss.

What is a verification agent in a multi-agent system?

It’s an agent whose only job is to audit other agents’ output. It judges source reliability (a vetted Wikipedia page versus a random Reddit post), checks whether reasoning from source to claim is valid, and for code can write tests to verify correctness — then discards wrong answers before they reach the final report.

Does a bigger model hallucinate less?

Not reliably. Du argues that by 2026 every serious team already has capable multi-agent systems, so scale isn’t the differentiator. What measurably improves accuracy is adding an explicit verification agent that audits evidence — an architectural choice, not a question of model size.

Can a verifier check code, not just text?

Yes. For coding tasks, Apodex’s verification agent can write tests and run them to confirm a program is correct, rather than just reading the reasoning. This executable check is one of three verification types Du describes, alongside source-reliability and reasoning-validity checks.

How does verification keep a large agent team aligned?

The verifier acts like the organizer of a weekly sync meeting. It gathers every sub-agent’s output, discards wrong answers, and reassigns the next round of tasks. In a system running up to 150 agents on one problem, this gather-and-reassign role is what prevents errors from compounding.

Is the verifier a different model from the reasoner?

It’s typically the same underlying model used as a judge (“LLM as a judge”), but with different inputs and a different job. The reasoning agent sees search results; the verifier sees the reasoning process and the final claim, so it has enough context to evaluate whether the whole chain is correct.

Why does separating the verifier from the reasoner matter?

Because a model checking its own work tends to defend its own reasoning. A verifier that sits outside the reasoning, with broader inputs, is free to disagree and reject the claim. That independence is what makes the check meaningful rather than a rubber stamp.

What’s the difference between LLM-as-a-judge and a verification agent?

LLM-as-a-judge is the technique — using a model to evaluate another model’s output. A verification agent is that technique deployed as a standing role in the system: it audits sources, reasoning, and code across every step, discards bad answers, and reassigns work, rather than scoring a single output in isolation.