Here is a pattern you have almost certainly built, or are about to. One model does the work. A second model checks it. A drafting agent writes the summary, a critic agent reviews it. A generator proposes the SQL, a judge validates it. You wire the output of the first into the input of the second, and the tension in your shoulders eases, because now there is a review step. Two sets of eyes. Defense in depth.
It even looks like advice I gave you. In an earlier post on AI and teams, I argued that “does anyone see any problems?” is not a review process, and that structured review, where a specific reviewer is assigned a specific thing to check, beats a vague glance every time. So you built exactly that. A reviewer with a job.
Except your reviewer is a language model. And in You Can’t Regex Your Way Out of a Good Argument, the first post in this pair, I spent two thousand words on a single uncomfortable property of language models: they can be argued out of a stated position by nothing more than a confident counter-argument [1], and none of your security tooling stops it, because there is no payload to catch.
You did not add a reviewer. You added a reviewer that can be talked out of its review. Then you stamped its output “checked.”
This Is the Pipeline Version of the Last Post #
That first post assumed a human in the loop. You, in the chair, asking a model to evaluate your work, with at least a fighting chance of noticing when it folded. That was the reassuring case. You were the detection layer.
Take yourself out of the chair. Put one model in charge of reviewing another, or in charge of reviewing the documents another retrieved, and the detection layer is gone. The flip still happens. Nobody is watching it happen.
That is this post.
Two Ways the Review Fails, and They Are Not the Same #
Be precise here, because there are two failures wearing the same coat, and they need different defenses.
The first is passive deference. No attacker. No adversarial anything. The critic model is simply agreeable by construction, the way I have described before: trained on human approval [2], leaning toward the answer that pleases. Hand it an upstream agent’s output and ask “is this correct,” and its default lean is toward yes. It rubber-stamps. This is sycophancy with the target rotated ninety degrees, no longer aimed at a human user but at the previous link in the chain. It needs no hostile input. It is the resting state.
The second is active persuasion. This is the change-of-opinion attack from the first post, arriving inside a pipeline. Something in the loop makes a confident case, the reviewer updates toward it, and the verdict reverses. This one needs adversarial or simply wrong content somewhere in the flow.
Passive deference is common and quiet. It is what most LLM-as-judge setups actually suffer, every day, with no villain involved. Active persuasion is rarer and sharper. Do not merge them. The first is a property of the reviewer you chose. The second is a property of what the reviewer is allowed to read.
And the reviewer you chose matters more than you might think. When researchers measured how easily different models could be argued into compliance, the gap between model families was large, and they traced part of it back to how the models were trained: the ones trained with AI feedback rather than raw human approval held their ground noticeably better [5]. The lean toward agreement is not a fixed constant. It varies with the training signal, which means “which model do I trust to review” is a real engineering decision, not a coin flip. More uncomfortably, the same research found the more capable models were sometimes the easier ones to persuade, because they were better at understanding the argument being made. Do not assume the smartest reviewer is the most stubborn one.
Which brings us to the part nobody draws on the architecture diagram.
The Attacker Is Usually a Document #
When people imagine the active version, they picture a hostile agent infiltrating the pipeline. Hold that thought for one paragraph, because the real attacker is more boring and far more likely.
It is a document.
In my post on the instruction and data boundary, I argued that every document in your RAG knowledge base is a potential injection vector, because the model cannot separate the content it retrieves from the instructions it follows [3]. The change-of-opinion attack does not even need that boundary to break. It needs something weaker. It needs a passage that argues a case.
Your reviewing model reads from the same untrusted corpus as everything else. A fluent, confident, wrong passage gets retrieved into its context. To the model, that passage is not data sitting inertly beside the question. It is a voice in the room, making an argument, and the model was trained to find arguments compelling. The verdict moves. No agent was compromised. No instruction was injected. A wrong document got into the retrieval set, which, as I wrote in January, happens constantly and is already something we treat as unsolved.
The worst corner, briefly, because I promised it. Yes, a genuinely hostile or compromised agent in a multi-agent system can do this on purpose and repeatedly, tuning its argument until the critic caves. That is real, and if you run autonomous agents with privileged access you should think hard about it. But it is the rare, severe end. The common end is a bad blog post in your vector store.
Plan-Then-Execute Locks the Wrong Thing #
Here I have to correct an impression I may have left you with.
In my second post on non-determinism, I praised the plan-then-execute pattern: lock the agent’s plan, and injected content can change execution details but cannot add unauthorized tool calls. It is genuinely good, and it does limit prompt injection’s blast radius.
It does nothing for this.
A critic agent’s output is not a tool call. It is a judgment. “Approved” or “rejected.” Plan-then-execute locks which tools may fire. It does not, and cannot, lock the verdict, because the verdict is the thing you wanted the model to produce freely in the first place. The payload here is the conclusion. And the conclusion is exactly what every reproducibility and isolation pattern you built leaves free to vary. You constrained the container. The poison is in the contents.
The Laundering Problem #
This is the part that should keep you up.
A wrong answer is a wrong answer. You can catch a wrong answer. People stay skeptical of raw machine output. They double-check it. They bring their own judgment to it.
A wrong answer wearing a “reviewed by a second model” badge is worse than a wrong answer, because the badge is precisely the thing that switches the human scrutiny off. Earlier in this series, I called a sycophantic model’s approval an echo, not a second opinion. In a pipeline, the echo gets a reviewer’s badge pinned to it, and the badge does real work. It tells the next human down the line that this has already been checked, so they need not look hard.
You did not add a safeguard. You added a reason for everyone downstream to stop paying attention.
Notice the pattern? The review step did not merely fail to catch the error. It suppressed the thing that would have.
What I Am Not Saying #
Let me be honest about the limits, the way I tried to be in the first post.
I am not saying multi-agent review is worthless, or that everyone’s pipelines are broken. Mature designs already distrust free-form critique. They use majority voting across several reviewers, fixed rubrics the model fills in rather than free judgment, deterministic checks for anything with a right answer, and human gates on the decisions that matter [4]. Those defenses work. If you have built them, much of this post is a risk you have already priced in.
What I am warning about is the naive version. The single critic agent handed a free-form “does this look right.” It is the version that is easiest to build, the version that demos beautifully, and the version that quietly sneaks into systems that started simple and grew. That is the one to find and redesign before it matters.
Designing the Pipeline So It Cannot Be Talked Down #
The fix is architectural, the same as everything else in this series. Design the workflow, not the model.
Do not build a single-critic chokepoint. One reviewing agent is a single point of epistemic failure, and now you know it is a point that can be argued down by one paragraph. Use several, or use voting, or do not route the whole judgment through one model that can have its mind changed.
Send the right questions to code. In the non-determinism post I said it plainly: do not make the model pretend to be a computer when you have an actual computer. If part of what the critic checks has a deterministic answer, schema validity, a numeric threshold, a business rule, then check it with code that cannot be flattered. Reserve the language model for the genuinely judgment-shaped questions, and do not trust it to hold even those.
Ground the verdict. A review anchored to a cited source is harder to flip than a free-floating opinion, and easier for a human to audit when it does flip.
And put the human gate where the asymmetry is worst. In the teams post I argued that the real predictor of overtrust is domain expertise asymmetry, the gap between what the reviewer can verify and what it is trusted to know. The same logic applies to your agents. Put the human checkpoint exactly where the reviewing model is least equipped to catch its own reversal, not where it is most convenient to add one.
The Thing You Removed #
Across this pair, the shape is simple. The first post showed you an attack with no payload your filters can catch. This one showed you what happens when you build a pipeline out of the models that attack works on, and then put one of them in charge of catching it.
We see what we want to see, I keep writing. So, it turns out, do the models we trained on us.
The reviewer you replaced, the senior colleague who would tell you to your face that you were wrong and not move an inch when you pushed back, had one property none of this has. They could not be argued out of it by a confident sentence. That was never a bug in the old process. It was the entire point of it.
Where does a model hold a judgment in your pipeline, rather than just produce one? If you are running LLM-as-judge or critic agents in production, I would like to know what you have done to keep the reviewer from caving, and where it has caved anyway. Reach out on LinkedIn or BlueSky.
References #
[1] Hernández-Espinosa, A., Abrahão, F.S., Witkowski, O., & Zenil, H. (2025). Neurodivergent Influenceability as a Contingent Solution to the AI Alignment Problem. arXiv:2505.02581. https://arxiv.org/abs/2505.02581
[2] Cheng, M., Lee, C., Khadpe, P., Yu, S., Han, D., & Jurafsky, D. (2025). Sycophantic AI Decreases Prosocial Intentions and Promotes Dependence. arXiv:2510.01395. https://arxiv.org/abs/2510.01395
[3] Greshake, K., et al. (2023). Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. arXiv:2302.12173. https://arxiv.org/abs/2302.12173
[4] Abdelnabi, S., et al. (2025). LLMail-Inject: A Dataset from a Realistic Adaptive Prompt Injection Challenge. arXiv:2506.09956. https://arxiv.org/abs/2506.09956
[5] Zeng, Y., Lin, H., Zhang, J., Yang, D., Jia, R., & Shi, W. (2024). How Johnny Can Persuade LLMs to Jailbreak Them: Rethinking Persuasion to Challenge AI Safety by Humanizing LLMs. arXiv:2401.06373. https://arxiv.org/abs/2401.06373
Photo by Suvan Chowdhury: https://www.pexels.com/photo/close-up-photo-of-minion-miniature-toy-1606655/