Role Collapse and Self-Approval: Why a Single AI Agent Always Praises Its Own Code
Why an AI agent that plays every role always praises its own code, and how an agent council separates roles and isolates context to resolve the conflict of interest.
In AI-assisted software development, a common trap is handing the whole process to one agent in one chat window: requirement analysis, DB design, coding, testing, and then approving its own work.
The result is usually a product that appears to work on the surface but hides latent bugs and architecture violations, while the same agent declares "no errors at all". The phenomenon comes from two structural failures: role collapse and self-approval.
What is role collapse?
Role collapse happens when a single LLM context has to carry several roles whose goals and standards of evaluation directly conflict.
In software, each role has its own idea of "correct". The architect cares about extensibility and invariants (schema-correct). The coder cares about the feature running (functionally correct). The UX designer cares about the user experience (UX-correct). The security specialist cares about vulnerabilities (security-correct).
Merged into one agent, an LLM tends to look for the lowest common denominator that satisfies the prompt, and every role's standard is pulled down. A stronger model does not fix this: knowing several standards is not the same as applying each one independently.
Self-approval and the forked-reviewer trap
Self-approval is the sycophancy tendency of LLMs at work: a model that just produced the source code tends to explain and defend its own decisions when asked to "review this code". This is a conflict of interest, not a skill gap, so more care does not remove it.
The forked-reviewer trap: many agent systems create a reviewer by forking a subagent from the main thread. A forked agent inherits the coder's reasoning history and wrong assumptions, so the review becomes a rubber stamp with no independence.
Context isolation in akiflow
The akiflow skill handles this trap with a boundary in Phase B (execution):
Independent reviewer: the adversarial reviewer is a plain subagent created from scratch, with no forked context, running on a strong model tier.
The only data sent to the reviewer is the diff and the item's closing criterion (closes when) from checklist.md, plus the RULE-agent-behavior.md floor. The reviewer never sees the chat history or the coder's self-justification, so its assessment is not steered by the coder's argument.
Three lessons for designing multi-role agent systems
1. Do not merge roles: each seat has its own filter and its own agent definition. A role that cannot return a verdict against the lead's conclusion is a rule loaded into whoever is already working, not a seat.
2. Do not allow self-approval: only the lead closes an item, and an item closes only after its challenger has taken a turn. Two agents agreeing is not yet a decision.
3. Every agreement needs a falsifier: an agreement that names no condition which would prove it wrong is manufactured consensus. Three earlier agents agreeing is not evidence.