Most teams asking for a multi-agent system don't need one. They need one good agent with the right tools. The orchestration layer everyone talks about is a tax, and you pay it whether or not you needed the complexity.
This is the part vendors skip. So let me name the actual decision.
What a multi-agent system actually is
A single agent is one model in a loop with tools. It reads a request, calls a function, reads the result, repeats. That covers more than people expect.
A multi-agent system splits work across agents that hand off to each other. A planner agent routes to a research agent. A research agent hands to a writer agent. Each has its own prompt, its own tools, sometimes its own model.
The pitch sounds clean. The reality adds three failure modes you didn't have before.
The three new failure modes
First, handoff loss. Every agent boundary is a place where context drops. Agent A knows something. Agent B never gets told. The output is confidently wrong, and the bug is invisible in any single log.
Second, cost multiplication. Each agent re-reads context to do its job. A five-agent chain can burn five times the tokens of one agent doing the same task. You feel this on the bill, not in the demo.
Third, debugging surface. When a single agent fails, you read one trace. When a fleet fails, you read five traces and guess which handoff dropped the ball. Mean time to fix goes up, not down.
None of these are hypothetical. They show up the first week in production.
When one agent is enough
Most business problems are a single task with clear inputs and outputs. Answer the support ticket. Pull the data, summarize it. Classify the document, route it.
A support agent we built answers in 12 minutes, down from 4 hours. That is one agent with access to the docs and the ticket system. No fleet. No orchestrator. It works because the job is bounded and the tools are right.
If you can write the task as one sentence with one clear output, you want one agent. Add tools, not agents. Give it search, give it a database, give it the ability to file a ticket. Capability comes from tools far more than from headcount.
When you actually need more than one
Multi-agent earns its cost when the work has genuinely separate domains that don't share context well. Think a coding agent and a security-review agent. You want the reviewer to see the code fresh, without the author's assumptions baked in. The separation is the point.
It also earns its cost when tasks run in parallel and don't depend on each other. Five documents, five independent extractions, no shared state. Fan out, collect, done. That is a real win.
The test is simple. Do the agents need to share a working memory to be correct? If yes, you are fighting handoff loss for no reason. Keep it one agent. If the work is truly independent or truly adversarial, split it.
How we'd scope it for you
We start with one agent every time. We build the smallest thing that solves the task and we measure it in production. If a second agent is justified by the work, we add it then, with a reason you can read.
Our OpenClaw Installation gets a working agent into your stack. A RAG Chatbot handles the bounded question-answering case, where one agent over your docs is almost always the right call. Both are fixed-price. You can see the bands on our pricing page. Fixed price every time, you own the code, we exit.
We are a 2-person team that shipped 10 production products in 7 months. That pace is only possible because we don't build orchestration nobody needs. The ex-AWS Federal background means we have watched plenty of distributed systems fail in ways that look a lot like a badly split agent fleet. The lessons transfer.
The short version
Default to one agent. Earn the second one. Split work only when domains are separate or tasks are parallel, never just because the architecture diagram looks more serious with boxes in it.
If you are weighing a fleet against a single agent and want a straight answer, book a call. Thirty minutes, free, and we'll tell you which one your problem actually is.