Multi-agent systems or workflow automation? Choosing the simplest thing that works

Multi-agent architectures, in which several specialised agents coordinate on a task, attract a great deal of attention. They can be the right answer. More often, a simpler design delivers the same result with fewer failure modes, lower cost and easier audit. This guide orders the options from simplest to most complex and explains when to move up a level.

Level 1: a single model call

Classifying an email, summarising a document or extracting fields can usually be done in one well-designed call with structured output. Add retrieval if the model needs your content. Many “agent” projects are this, and they should be built as this.

Level 2: a workflow with AI steps

When a task has several known steps, orchestrate them in code. Patterns include prompt chaining (one step’s output feeds the next), routing (classify, then send to a specialised path) and parallelisation (run independent checks at the same time). Each step can be tested in isolation, and the workflow is easy to explain to an auditor.

Level 3: a single agent

Move to an agent when the steps depend on what is discovered: an investigation where the next query depends on the last result, or a support case where the needed context varies widely. Keep the agent’s tools narrow and its stopping rules explicit.

Level 4: multiple agents

Consider multiple agents when sub-tasks need genuinely different tools, permissions or context that would overload a single agent, or when work can be parallelised across independent sub-problems. Expect new failure modes: agents misunderstanding each other, duplicated work, conflicting actions and harder debugging.

Let evaluation decide

Build the simplest version first and measure it on a realistic scenario set. Only add complexity when the measurements show a specific shortfall that the more complex pattern addresses. This keeps architecture decisions grounded in evidence rather than fashion.