Multi-agent patterns: pipelines, parallel reviews and debate

Multi-agent patterns are the ways a piece of software work is divided between several AI agents with different roles. The common ones are a pipeline of roles in order, parallel perspectives that look at the same work from different angles and are then merged, debate, where agents propose and critique alternatives, an orchestrator that hands out subtasks, and generate-and-verify loops. Each trades cost and complexity for focus and independent checking. The pattern matters less than two things: whether checking agents see real evidence, and whether their loops are bounded.

This page expands the single-agent versus multi-agent section of How do AI agents fit into the software lifecycle?.

Why split work across agents at all

A single capable agent can plan, write and test a change by itself. Splitting the work has three main benefits:

• Focus. Each agent gets a narrow role and only the context it needs. A reviewer instructed only to look for security problems tends to look harder for them than a general agent asked to "also check security".
• Independence. One agent's output is checked by another that did not produce it and is not invested in defending it.
• Traceability. Each step produces its own record, so it is easier to see where a plan went wrong.

It also has costs. More model calls cost more. Every handoff between agents loses some context. And coordination itself can fail: agents can misread each other's output or repeat each other's work.

Pipeline

Agents run one after another, each with a fixed role: for example plan, build, review, test. Each step reads the task and everything the earlier steps wrote.

• Good for: most feature work and bug fixes, where the stages are well understood.
• Watch for: errors that propagate. A wrong plan produces a faithful implementation of the wrong thing. A review step that only reads the plan, not the code, cannot catch implementation mistakes.

Parallel perspectives

Several agents examine the same thing from different angles, such as correctness, security and test coverage, and a final step merges their findings into one result. The agents may actually run at the same time, or one after another; what defines the pattern is that each looks at the work independently.

• Good for: review and inspection, where different specialities notice different problems.
• Watch for: duplicate findings, and a merge step that drops valid concerns while summarising. If the perspectives run in sequence, later reviewers may anchor on earlier ones instead of looking independently.

Debate

Two or more agents propose different approaches to the same problem, a critic evaluates them, and a final step chooses or combines them.

• Good for: design decisions with real trade-offs, such as architecture choices, data models or migration strategies, where seeing alternatives side by side is the point.
• Watch for: proposals that differ only on the surface. Agents built on the same model may converge on the same idea in different words. Ask explicitly for different approaches, with stated trade-offs.

Orchestrator and workers

A coordinating agent breaks a large task into subtasks, assigns them to worker agents and combines the results. Unlike a pipeline, the steps are decided at run time.

• Good for: large, divisible tasks, such as changes across many modules, or research across many sources.
• Watch for: unpredictable cost and duration, since the orchestrator decides how much work to create, and subtasks that conflict when combined. This pattern needs the strictest limits on time, tokens and the number of workers.

Generate and verify

One agent produces something and another checks it, and the loop repeats until the check passes: write code, run tests, fix, run again.

• Good for: tasks with an objective check, such as making tests pass or satisfying a linter.
• Watch for: loops that never converge, and verifiers that can be satisfied the wrong way. If the check is "the tests pass", the cheapest route may be weakening the tests. Bound the number of rounds, and treat changes to the checks themselves as needing review.

Comparing the patterns

How multi-agent systems fail

The failure modes are mostly the same across patterns.

• Correlated errors. Agents that share a model and similar instructions share blind spots. Three reviewers that miss the same bug are not three times as safe as one.
• Checking summaries instead of evidence. A reviewer that reads the builder's description of a change, rather than the diff, is checking a claim. Pass real artefacts between agents: diffs, test output, error messages.
• Context loss at handoffs. Each agent sees only what it is given. Constraints mentioned early in the task can disappear by the fourth step.
• Agreement mistaken for correctness. Several agents reaching the same conclusion is not evidence that it is right, especially if they read each other's output.
• Cost multiplication. Each agent re-reads context. A workflow with many steps can cost many times a single-agent run.

The mitigations are the same too: different instructions for different roles, real evidence for every checking step, limits on rounds, time and spend, and a person approving the result.

Choosing a pattern

Start with the simplest arrangement that includes an independent check: a short pipeline whose last steps review the real change and run real tests. Add parallel perspectives when review quality matters more than cost, debate when the hard part is the decision rather than the code, and orchestration only for tasks that genuinely do not fit in one agent's context. Add an agent when it checks something the others do not.

How AI CodeOps does it

AI CodeOps sessions run one of 16 built-in workflows, each a fixed list of steps run by named agents. The default, Plan, Build, Review & Test, is a pipeline. Parallel Review has correctness, security and test-coverage reviews followed by a merge step. Swarm Inspection gives reviewer, security and tester slices to separate steps and merges them. Architecture Debate has two architects propose approaches, a critic review them and a final synthesis.

In every workflow the steps run one after another, and each sees what the earlier steps wrote. The parallel, debate and swarm labels describe how the work is divided, not timing. Nothing is decided by vote. After the steps, the change is written against a fresh copy of the repository, your tests run in a sandbox, and a separate findings pass reviews the actual diff. A person then approves. You cannot define your own workflows yet.

See Workflows for every built-in workflow and its steps, and Multi-agent reviews for how the review steps and the findings pass fit together.