Every agentic architecture diagram I get sent has the same tell. Somewhere around the third revision, the boxes multiply. A planner agent, a researcher agent, a critic agent, an orchestrator to manage the critic, a memory agent, a tool router, a supervisor sitting on top of all of it. By the time it reaches my desk it looks less like a system and more like an org chart for a company nobody would want to run.
I understand the instinct. "Agentic" has quietly come to mean "many agents," and many agents feels like more capability. But after a couple of years building production agentic platforms for claims, sourcing, and investigations, the environments where being wrong has a cost that lands on a real person, I've come around to the opposite view. The number of agents in your architecture is not a measure of how advanced it is. It's a measure of how much control you've decided to give up. And most teams are giving up far more than the problem in front of them ever asked for.
Every agent is a decision you stopped controlling
The seduction of the multi-agent diagram is that every box looks busy. What the diagram hides is what each box actually adds. Another nondeterministic hop where the output isn't guaranteed. Another stack of tokens on the invoice. Another surface that can be prompt-injected. Another handoff where the audit trail gets a little thinner. A five-agent system isn't five times as capable as a one-agent system. It's five times as many places where the thing can quietly do something you didn't intend, multiplied by however often they call each other.
We wrote a while back about the blast radius of a helpful agent, how far the damage travels when an agent carrying your credentials gets compromised. Agent count is the multiplier on that blast radius. We also wrote about the bill nobody modeled, how consumption patterns rather than token prices are what actually drive AI sticker shock. Agent count is one of the loudest consumption patterns there is. A supervisor agent that re-reads every other agent's output before deciding what to do next looks elegant on a slide and reads like a ransom note on the invoice.
Pragmatic means minimizing decisions, not maximizing agents
The goal of a good agentic architecture isn't to have the model do as much as possible. It's to have the model decide as little as it has to, and to make the few decisions it does own completely legible after the fact.
So when we design on Neura-Cortex, we don't open by asking how many agents we need. We ask a narrower question: which steps in this workflow genuinely require judgment, and which ones only feel like they do because nobody has bothered to write them down as rules yet? Most enterprise workflows, once you actually map them, turn out to be mostly deterministic. A supplier's certification is either expired or it isn't; that's a date comparison, not a reasoning task. A claim either has the required attachments or it doesn't; that's a checklist. A policy either covers the procedure or it doesn't, and the genuinely ambiguous cases are a small, identifiable set you can name in advance.
The pragmatic move is to run the deterministic majority as ordinary, testable, cheap code, and to reserve real agency for the slice that actually needs it. That isn't a compromise on ambition. It's the difference between a system you can put in front of an auditor and a system you cross your fingers over.
Where multiplicity earns its keep
None of this makes me anti-agent. There are workloads where more than one agent is exactly right: work that is genuinely parallel and separable, work that has to be governed differently because it touches different data under different permissions, work where a narrow specialist is easier to test than one sprawling generalist prompt.
Take Clairant, our claims platform. Its pipeline runs intake, policy lookup, prior-authorization cross-reference, and a recommendation, and that is plainly more than one agent. But it's a bounded pipeline with defined handoffs, not a swarm negotiating with itself. Each specialist has a narrow remit you can test in isolation, a clear input and output, and its own governance envelope. Adding a step there earns its place because the step is separable, individually auditable, and cheaper to reason about than one giant do-everything prompt. The distinction was never one-agent-good, many-agents-bad. It's bounded-and-legible versus open-ended-and-emergent.
The pattern I push back on hardest is the one where agents talk until they agree. The debate loops and reflection spirals. The autonomous negotiation that treats compute as free and treats correctness as something that will emerge on its own if you just let the conversation run long enough. In a demo it produces an impressive transcript. In production, over a healthcare or government workload, it produces a bill you never modeled and a decision path you can't reconstruct when someone shows up asking you to.
The test we actually use
Before an agent goes into one of our architectures, it has to answer a short list of questions. What decision does this agent own that a deterministic rule couldn't make just as well? If it fails silently, who notices, and how quickly? Can we test it on its own, or only as part of the whole choir? What does it cost per run at ten times today's volume, and does that number survive contact with a real invoice? And when it acts, does the audit log come out the other side able to explain why?
An agent that can't answer those doesn't get added. Not because autonomy is dangerous in the abstract, but because an agent you can't account for is a liability you've dressed up as a feature.
A multi-agent system nobody can explain is not more intelligent than a simple one everybody can. It's just a more expensive place to be wrong.
Why the substrate lets us stay small
The reason we can afford to right-size is that the hard parts don't live inside the agents. Guardrails, identity, routing, human-in-the-loop checkpoints, and the audit log all live in Neura-Cortex, underneath. That changes the economics of adding an agent. When the expensive machinery is built once and shared, we're never reaching for another agent just to get governance, or memory, or a tool connection, because those already exist below the waterline.
That removes the excuse teams lean on most when they justify agent sprawl: "we needed another agent to handle X." Usually you didn't. You needed X handled, and the substrate was already handling it. Take that excuse away and the agent count stops drifting upward on its own.
Open your current agentic design and count the agents. Then, for each one, ask what decision it owns that a plain rule couldn't make, and whether you could explain its last action to an auditor without opening a debugger. The agents that survive that question are your architecture. The rest are cost, risk, and latency wearing the costume of sophistication, and removing them is often the most advanced thing you can do to the system.
The most impressive agentic architecture I reviewed this year had two agents. It ran a regulated workflow end to end, came in under budget, and could account for every decision it made. Nobody is going to put it on a conference slide, because it doesn't look like the future. It just works, and the people who own it sleep at night. That, and not the box count, is what pragmatic actually looks like.
MTekLabs designs, deploys, and governs production-grade agentic AI platforms for government and commercial enterprises. Our solutions are built human-in-the-decision-loop where it matters and auditable by design. Explore them at mteklabs.com.
How many agents is your architecture actually carrying?
We would be glad to walk through where your design is paying for autonomy it doesn't need, and where a smaller, more legible agentic system would move the same numbers for less risk and less spend.