Multi-Agent Systems, Explained Without Hype

The single-prompt trap

Most “AI features” you’ve seen are a single prompt doing too many things at once. Read this email, score the lead, write a reply, schedule a meeting, update the CRM. The prompt gets longer, the model gets confused, and the outputs get worse.

Multi-agent systems split the work the way you’d split it across a team.

The three patterns we use

1. Pipeline (sequential)

One agent does step A, hands off to the next. Researcher, then writer, then editor, then publisher. Each agent has one job and one prompt. The handoff is a structured object, not a paragraph.

Good for: content pipelines, document generation, research reports.

2. Orchestrator + workers (hub-and-spoke)

One orchestrator reads the goal and decides which specialist to call. The specialists don’t talk to each other; they only report back. Customer support agents usually look like this, one router, several skilled responders.

Good for: support, triage, lead routing.

3. Peer collaboration (swarm)

Multiple agents work in parallel and reconcile. A planner, a researcher, and a critic all argue about the best move, and a coordinator picks the winner. This is overkill for most business workflows, we use it for novel research tasks where the answer isn’t obvious.

Good for: research, planning, strategy.

The non-obvious advice

The hard part of multi-agent systems isn’t the agents, it’s the contracts between them. What does the researcher hand to the writer? In what shape? What happens if a field is missing? The teams that succeed treat agent hand-offs like API design.

What we’d build for you

We start with one agent. Always. If the work splits cleanly into roles, we split it. If not, we don’t. The agent count is an output of the design, not an input.