Why Every Agent Team Has a Critic

The confidence problem

AI agents are confident. Not always correctly confident, but confidently confident — they produce output that reads as authoritative, complete, and ready to use. The phrasing rarely hedges. The structure is clean. The reasoning sounds coherent. This surface confidence is one of the things that makes agent output useful, and one of the things that makes it dangerous.

Human reviewers, presented with confident output, anchor to it. The review becomes a search for obvious errors rather than a genuine evaluation of whether the output is correct. Subtle mistakes survive because they are embedded in well-structured, confidently presented work. The review that should catch them is looking for the wrong things.

The solution is not to make agents less confident. Confident output is useful. The solution is to add a reviewer that is structurally positioned to be skeptical — an agent whose job is specifically to challenge the work, not to approve it.

What a critic agent does

A critic agent is a cross-check reviewer assigned to every major task in Hivemeld's dynamic team model. It is not part of the primary execution team. It receives the primary team's output and its job is to find what is wrong with it.

The framing matters. A reviewer who is asked to "check this work" will look for errors and find some. A reviewer who is asked to "assume this is wrong and find the specific ways it is wrong" will look for errors and find more. The critic agent operates from the second framing: it is looking for failure modes, not approving finished work.

This is not adversarial for its own sake. It is a structural response to a real problem: primary agents optimize for completing the task, which creates pressure toward outputs that look correct rather than outputs that demonstrably are correct. The critic breaks that optimization by applying pressure in the opposite direction.

How the critic gets structured

The critic is configured differently from the primary agents in a team. Its system prompt does not describe the task — it describes the criteria by which the task should be evaluated. The critic knows what good looks like, what the common failure modes are for this type of work, and what the stakes of a mistake are.

For an engineering task, the critic knows: what the code is supposed to do, what it might break, which edge cases are likely, and what the test coverage should include. It reads the code and the tests and asks whether the tests actually verify the behavior or just verify that the code runs. It looks for the edge cases the primary agent did not handle. It checks whether the changes introduced any new surface area for the failure modes it knows to look for.

For a content task, the critic knows: who the audience is, what the output needs to accomplish, what the accuracy requirements are, and where the source material is. It checks claims against sources. It evaluates whether the structure serves the goal or obscures it. It looks for the places where the confident phrasing is covering for an unclear idea.

The critic's output is a structured list of findings: things that are clearly wrong, things that are ambiguous and need clarification, things that are technically correct but likely to cause downstream problems. Each finding is specific — not "this section is confusing" but "the third paragraph makes a claim that contradicts the source cited in footnote 4."

The cross-check prevents specific failure modes

Having a critic prevents three failure modes that recur in single-agent or unreviewed team outputs.

The first is specification drift. The primary agent starts with the goal and produces output that is internally consistent but has quietly drifted from what the goal actually required. This is common in long tasks where the agent's understanding of the goal evolves as it works, sometimes in ways that diverge from the actual specification. The critic holds the original specification and flags the delta.

The second is local correctness masking global incorrectness. An agent can produce output where each individual piece is correct but the combination is wrong. A code change that fixes the reported bug but breaks the invariant the bug relied on. A document that accurately describes each component of a system but mischaracterizes how they interact. The critic is looking at the whole, not just the parts, which is where these failures are visible.

The third is omission. Agents produce what the task asked for. They do not always produce what the task needed. The critic asks what is missing — what questions are not answered, what cases are not handled, what context would a real user need that is not in the output.

When the critic disagrees with the primary team

The critic's findings route back to the primary team with a clear status: block, flag, or note. A block means the output cannot ship without addressing this finding. A flag means the output can ship but the finding should be acknowledged and tracked. A note means the finding is logged for pattern analysis but does not affect the current output.

The primary team gets the findings and responds: either addressing the blocks, arguing against them, or escalating to human review when the teams disagree. Most findings get addressed. Some get argued. Very few require escalation, because the critic's job is to find real problems, not to generate objections.

When teams disagree on a finding, the disagreement itself is useful. A primary team that can clearly articulate why a critic's block is wrong has usually already considered and rejected that concern — and the articulation of that reasoning is worth capturing. A primary team that cannot respond to a block has found the place where their understanding of the task was incomplete.

The scale question

The obvious cost of a critic is time and compute: every major task runs twice, once for execution and once for review. For small tasks, this is not worth it. For tasks where a mistake is expensive — production deploys, external communications, data changes, anything irreversible — it is almost always worth it.

The rule we use: any task whose failure mode costs more than two hours to repair gets a critic. That threshold covers the vast majority of tasks where the review actually matters and excludes the routine, low-stakes work where a critic would be overhead with no payoff.

The threshold is also calibrated to the team's track record. A primary agent that has a history of producing output with few corrections gets a lighter review pass — the critic checks for the specific failure modes that agent has shown before rather than running a full audit. An agent on a new task type gets a thorough review until it has demonstrated consistent output quality on that type.

Building the culture of skepticism

The critic model is not just a mechanism. It is a statement about how the team thinks about quality. Work that goes through a critic is work that was taken seriously enough to be challenged. Work that ships without review is work where the primary agent's confidence is the only check on correctness.

The teams that get the most out of this model are the ones where the critic's findings are treated as valuable rather than as friction. A critic that finds real problems is a critic that is working. A critic that never finds anything is a critic that is not looking hard enough — or a signal that the primary agents have gotten so good at their specific tasks that the review can be safely scaled back.

Both of those outcomes are good. The goal is not to have a critic forever. The goal is to have a critic until the system has demonstrated it does not need one.