Why We Don't Build AI Agent Armies (And Neither Should You)

The internet is currently obsessed with 15-agent AI workforces. Virtual CEOs delegating to virtual researchers delegating to virtual copywriters, all drawn up in a gorgeous orchestration diagram with thousands of likes underneath it. Here is my position, and I am not going to soften it: almost nobody should build a multi-agent system, and almost nobody should pay for one. The two-minute demo will not survive two weeks of your real operations.

The businesses actually making money with AI run boring, single-purpose systems that never break. The market does not pay for orchestration diagrams. It pays for the missed call that got a text back in thirty seconds, the estimate that went out the same afternoon, the invoice that got chased without anyone remembering to do it. Boring, reliable, profitable. Everything the agent-army demo is not.

The slot machine problem

Here is the fundamental issue with multi-agent systems: when you chain multiple probabilistic AI models together, agents calling agents calling agents, the failure modes do not add. They multiply.

Agent A hallucinates a detail. Agent B loses context during the handoff. Agent C formats the output wrong because it inherited garbage from the two agents before it. Agent D confidently executes on all of that bad data.

You have not built an intelligent system. You have built a slot machine. Put data in, pull the lever, hope for the best. Sometimes you get a perfect result. Sometimes you get nonsense. And the nonsense often looks just plausible enough that nobody catches it until a customer calls asking why their appointment got booked at a house you have never serviced.

The arithmetic is unforgiving. If each agent in a chain succeeds 95 percent of the time, which is generous, a four-agent chain lands around 81 percent, and a six-agent chain around 74 percent. Those are illustrative numbers, not benchmarks, but the direction is the whole point. Every additional agent is another pull of the lever, and reliability only moves one way.

The people building frontier agents agree with me

This is not a contrarian take from a guy in the home-services trenches. It is what the leading agent builders say themselves.

Cognition, the company behind the Devin coding agent, published a post bluntly titled Don't Build Multi-Agents. Their argument is that splitting work across agents fragments context and disperses decision-making: subagents cannot see each other's work, so they make conflicting assumptions, and as they put it, "conflicting decisions carry bad results." Their prescription is the opposite of an agent army. Keep the work in one place and share full context.

Anthropic reported the same pattern in Building Effective Agents: "the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns." Their explicit recommendation is "finding the simplest solution possible, and only increasing complexity when needed."

Read that again. The companies with the most incentive to sell you on agents are telling you to use fewer of them.

Anthropic's applied AI team made the same argument on stage, and it is worth twenty minutes of your time:

The committee meeting for a phone number

Here is a pattern I see constantly. A business needs something straightforward: read an incoming email, pull out the phone number, put it in the CRM. A plumbing office might get forty of these emails a day.

Instead of solving it directly, someone watches a YouTube tutorial and builds the "proper" architecture. A master planner agent receives the email and decides what to do. It delegates to a researcher agent that extracts the data. That passes to a reviewer agent that validates the output. Finally, an execution agent writes to the CRM.

Four AI models holding a committee meeting to find a phone number.

The API bill runs to hundreds of dollars a month. The success rate is whatever it feels like that day. And debugging is a nightmare, because when something goes wrong you are tracing a failure across four separate model calls, each with its own context window, its own system prompt, and its own creative interpretation of the job.

This is not engineering. This is complexity theater.

The boring alternative that actually prints money

One prompt. One model call. Deterministic code around it. A simple pipeline reads the email, extracts the phone number with a single well-crafted prompt, validates the format with plain code rather than another AI call, and writes it to the CRM.

Cost: pennies. Failure points: one. Debugging: trivial, because there is exactly one place things can go wrong, and it logs what it did.

Play that out for the plumbing office. Forty emails a day, every phone number landing in the right CRM field, every new lead texted back while the homeowner is still standing in front of the leaking water heater. Nobody thinks about the system at all, which is the highest compliment automation can earn. It runs at 2 AM on a Tuesday. It does not drift. It does not have a bad day.

Boring is a feature.

Harness engineering is the real skill

Most people building with AI have this backwards: the model is almost never the problem anymore. Claude, GPT, Gemini. The frontier models are plenty capable of reading an email, extracting a detail, or drafting a reply. The point of failure is the harness.

The harness is everything around the model: the code that routes data in and out, the output parsing, the error handling, the guardrails that stop the model from doing something creative with your customer database. Good harness engineering means simple, predictable, debuggable systems wrapped around one powerful model call.

Bad harness engineering is a Rube Goldberg machine where seven agents play telephone and you cannot tell which of fourteen places the failure lives in.

The best AI engineers I know spend most of their time on the harness and a fraction of it on prompts. The worst spend everything on elaborate orchestration and wonder why nothing works twice in a row.

How to spot complexity theater before you pay for it

You do not need to be technical to defend yourself against this stuff. You need five questions, asked in order, of anyone selling you an AI system.

• "What happens when it fails?" Not if. When. If the answer involves the system supervising itself, or another agent checking the first agent's work, you are being sold a slot machine with a second slot machine bolted on.
• "How many AI calls happen per run?" More calls means more cost, more latency, and more places for the output to go sideways. For most business tasks the right answer is one, maybe two.
• "Show me the logs from a failed run." A serious builder can pull up exactly what went in, what came out, and where it stopped. A demo artist changes the subject.
• "What do I own if we part ways?" If the workflows, the server, and the data do not stay with you, the impressive architecture is also a leash.
• "What does this cost per run at ten times my volume?" If they have to think about it, they have not run it at volume.

And one piece of fairness, because I want to be honest rather than just contrarian. There are narrow cases where multiple agents earn their keep, mostly read-only work like research, where parallel agents gather information and nothing they do writes to your systems. Notice what those cases have in common: when an agent is wrong, nothing breaks. The moment an agent can touch your CRM, your calendar, or your customer's phone, the tolerance for creative failure drops to zero. If the person pitching you a 15-agent system cannot explain precisely why your use case is the exception, it is not the exception.

What the market actually pays for

Nobody has ever paid an invoice because the architecture diagram was beautiful. Business owners pay for outcomes they can feel:

• The missed call that gets an instant text back, so the lead does not phone the next contractor in the search results. That is one workflow with one job. If a voice needs to answer, a voice agent does it, and it does only that.
• The web form lead that lands in the CRM, deduplicated and assigned, in under a minute.
• The review request that goes out the day the job closes.
• The reactivation email that quietly books jobs from a list of leads everyone had written off.

Every one of those is a single-purpose system. None of them requires an agent army. Together they are worth real money every month, and they keep being worth it because they keep working. Reliability is the product. The demo is just marketing.

And reliability is not luck. It is health checks, failed-job alerts, and structured logging built in from day one. I covered that checklist in the six systems every AI automation needs.

How we build at LeadsPass

We build single-purpose pipelines that do one thing perfectly. No agent armies. No orchestration layers. No committee meetings between virtual employees.

Our AI workflows run on n8n, which you can self-host on infrastructure you control, wired into the tools you already use. When we hand over a system, the client owns the whole stack, which matters for the same reason simplicity does: nobody can take it away, meter it, or break it with a pricing change. I made that side of the argument in renting vs. owning your automation.

Every pipeline follows the same principle: the fewest possible AI calls, the most possible deterministic code, and a system so simple that when something eventually breaks, you find it in minutes instead of days.

Build boring. Ship reliable. Let your competitors chase complexity. And if you would rather have one system that works than fifteen agents that demo well, tell us what you need.