When to build a multi-agent system, and when not to
If you are wondering when to use multi-agent systems, here is the answer we give clients who are sometimes disappointed to hear it: later than you think, and only when a single well-built agent has visibly hit its ceiling. Most business problems need one good agent with the right tools and context. The twelve-agent architecture diagram is usually a sign that someone enjoyed drawing it.
We build multi-agent systems in production, so this is not skepticism about the technology. It is the threshold question, and getting it right is worth a lot of money.
Start with one agent, seriously built
A single agent in 2026 can read your documents, call your APIs, run calculations, and follow a multi-step procedure. Give it retrieval over your knowledge base (the architecture we explained in RAG for people who run companies), a clear set of tools, and tight instructions, and it covers the majority of workflow automation use cases end to end.
The single agent is also easier to operate in every way that matters in production. One context to debug when an answer is wrong. One set of permissions to audit. One cost profile. When something misbehaves at 2am, your engineers trace one reasoning chain, not a conversation between five.
So the practical rule: exhaust the single agent first. Not "try it for an afternoon", but genuinely build it with evals and iterate. If it plateaus, you will know precisely where, and that failure point tells you what the second agent should do. Architecture decided by observed failure beats architecture decided by whiteboard.
The signals that one agent is no longer enough
Multi-agent earns its complexity in a few specific situations. The task is genuinely too long for one context: the agent must plan across many steps, gather material from several sources, compute, then verify, and stuffing all of that into one context degrades each part. The task has phases with conflicting instructions: the thoroughness you want during research is exactly what you do not want during final formatting. You need independent verification: a checker agent that validates the worker’s output against rules, with genuinely different instructions and no stake in the answer being accepted. Or parts of the work can run in parallel because they do not depend on each other, and latency matters.
Notice what is absent from that list: "the workflow has several steps". Steps are what single agents do all day. The trigger is conflict, scale, or independence between the parts.
What a real multi-agent system looks like
The production pattern is boring and effective. It is the shape we shipped at Pigment for financial analysis. A planner decomposes the user’s request. Retrieval agents fetch the relevant data. A calculation step runs the numbers with actual code, because language models should orchestrate computation, not perform it. A validation agent checks the result against constraints before anything reaches the user. Each agent has a narrow job, an explicit contract with the others, and its own evaluation.
Two properties make this work in production. Specialization with clear interfaces, so each piece can be tested and improved alone. And a verification step that is structurally independent from generation. What does not work is the org-chart fantasy: a manager agent supervising employee agents in open-ended conversation. Errors compound across chatty handoffs, and nobody, including the system, knows why the final answer came out wrong.
The costs the diagram does not show
Every agent you add multiplies the surface. Model spend rises fast, since agents pass context to each other and tokens are billed at every hop; the discipline from your AI bill at ten times the volume applies double here. Evaluation gets harder: you need evals per agent plus end-to-end, or you will not know which component to fix when quality drops, which is why we treat evals as the work that separates systems from demos. Permissions get harder too: each agent that touches your systems needs its own scoped access and audit trail, the design questions from giving an agent access without regretting it.
A useful heuristic from our projects: going from one agent to a well-designed multi-agent system multiplies engineering and operating effort by three to five, not by the count of boxes. The value has to clear that bar.
The decision in one question
Can you name the specific, observed failure of your single agent that a second agent would fix? If yes, you have an architecture decision. If no, you have a diagram.