If you're building a team of AI agents, should they work in a line, critique each other, or split up and work at once?

This explores how to pick between three ways of organizing AI agents: handing work down a line, having one agent critique another, or sending pieces out to many agents at once. The three forms come from What organizational patterns work best for multi-agent coordination?, who compares them to how human teams work. Pipelines suit simple tasks with clear handoffs. Critique loops suit work where quality comes from repeated revision. Swarms led by a coordinator suit work that can run in parallel. The catch with swarms is that they assume the work splits cleanly into separate pieces, and that assumption is where most of the trouble starts.

The strongest warning about swarms comes from Why do parallel subagents produce conflicting design decisions?. Every action an agent takes rests on small assumptions it never writes down. When agents work in parallel, they can't see each other's assumptions, so they make choices that conflict. Yan's advice is to go back to one agent working through the task in order. Research on reasoning points the same way: When does sequential reasoning beat parallel voting? shows that when each step depends on the last one, working through steps in order beats running many short attempts in parallel and voting, by an exponential margin. So the first question to ask is whether the parts of the task really are independent. If later work depends on earlier results, splitting it up costs more than it saves.

The second question is whether you need multiple agents at all. When should teams choose workflows over agents? says to start with a single well-designed call or a fixed workflow, which is basically a pipeline. Move to agents only when you can't predict the path the task will take. On the other side, Do single agents always hit organizational limits? argues that some tasks really do outgrow one agent: ones that need different kinds of expertise, parallel execution, or a separate checker. A separate checker is exactly what a critique loop provides. There's also a benefit to critique that's easy to miss. Do critique models improve diversity during training itself? finds that step-by-step critique keeps a model's solutions varied instead of letting them narrow too early. So critique loops can protect the range of solutions an agent considers, not just catch its mistakes.

Organizational theory has studied this tradeoff for decades. How do coordination architectures trade off efficiency against resilience? summarizes Malone and Crowston's models. Centralized control, which is roughly what a swarm's coordinator provides, is cheap to coordinate but breaks when a key part fails. Decentralized setups survive failures but cost a lot to coordinate. Hierarchies sit in between and leave some capacity unused. No option wins on every dimension, so the choice depends on which failure you can least afford. Sharing information can also ease the main weakness of parallel work: Does sharing experience across agents beat isolated evolution? found that agents improved much more when they pooled their code changes and execution records than when each evolved alone.

One more option: you don't have to commit to a single structure. Can multi-agent teams swap roles, coordination, and algorithms independently? and the older Can separating structure and function improve multiagent organization design? both separate who does what from how the work is coordinated, so you can swap one without rebuilding the other. And Can LLMs automatically discover better team structures than humans? goes further, using a critique loop to redesign the team itself. It found chain, dual-leader, and changing structures that beat hand-designed ones. In practice, the best way to choose a structure may be to run a critique loop over a few candidates and let it find the right one.