There’s a new number people are putting on their LinkedIn profiles, and it’s supposed to impress you. I manage 30 AI agents. I manage 60. I built 16 specialists and then a Conductor to manage them. Business Insider called it bot bragging — AI status signalling for the post-ChatGPT professional class. The subtext, as the BI piece put it, is always the same: “I’m not being replaced by AI. I’m the boss of it.”
It’s the new 100% code coverage.
We’ve done this before
Every era of software engineering picks a number that feels like proof of quality and stops being one the moment it becomes the target. Lines of code. Story points. Microservice count. Test coverage percentage. Each one starts as a useful signal, gets weaponised into a KPI, and ends up hiding the exact problem it was supposed to measure.
I wrote about this a while back in the hidden cost of coverage. Chasing 100% doesn’t get you better tests — it gets you more tests, most of which exist to satisfy the number. The interesting question was never “how much of the code is covered” but “are the risks that actually matter covered.”
Agent count is on exactly the same trajectory. Sixty agents don’t tell me you built something sophisticated. They tell me you didn’t stop to ask which of them needed to exist.
The presentation that started this
I sat through a presentation recently on a system built around sixty agents backed by more than a hundred and fifty skills and deterministic scripts. Impressive on the slide. Less impressive when you asked how it was built.
Each night the swarm was let loose on a batch of work. In the morning the team reviewed the output, found the things it got wrong, tweaked the agents and the surrounding code, and ran it again the next evening. Autonomous overnight, human-corrected in the morning. As a principle, that’s a beautiful loop. In practice, without deliberate guardrails, every lesson costs you a full overnight token run plus a morning of engineer time — and you only ever learn what went wrong after you’ve already paid to find out.
That “expensive” bit matters more than it seems. When the token bill is somebody else’s problem — a generous enterprise budget, a research allowance, a client footing the infrastructure line — the pressure to think carefully about what an agent is quietly disappears. Design discipline is downstream of feeling the cost of your design decisions. Take the cost signal away, and sixty agents doesn’t feel like sixty agents. It feels like progress.
Agent is not a synonym for skill
Here’s the technical core of it: most of those sixty agents should have been skills.
An agent is a decision boundary. It holds context, reasons about a problem, chooses what to do next. A skill is knowledge scoped to a named task — a SKILL.md that an agent loads on demand when the work matches. You spin up a new agent when you need isolated reasoning about a distinct problem. You author a new skill when you need to teach an existing agent a task it doesn’t yet know how to do well. Those are different acts of design, and conflating them is how you get to sixty.
I’ve written about the distinction in more detail in skills, instructions, and scripts. The short version: a well-designed system has a small number of agents with clear ownership, each backed by a rich library of skills they can load when the task calls for them. What you’re seeing in the bot-bragging posts is the opposite — one agent per skill, each dressed up with a name and a backstory, most of them essentially cron jobs with a language model attached.
Which is fine, if that’s what you meant to build. But don’t call it sixty specialists. Call it sixty scheduled tasks and be honest about the sophistication.
Context isolation is a scalpel
The defence I hear for the many-agents pattern is context isolation. Each agent gets its own scoped context, which prevents pollution and hallucination bleed between concerns. That’s a real benefit — I’m not going to pretend otherwise.
But isolation has a cost, and the cost scales with the number of boundaries you draw. Every new agent means re-injecting the context it needs to do its job. If the same background information has to be reconstructed across sixty agents in a single workflow, you’re paying to rebuild a coherent worldview that a single well-scoped agent already held. That’s before you count the orchestration overhead of routing between them.
I put actual numbers on the context side of this in the 4-tier context architecture — the same rules apply here. Loading context you don’t need isn’t just wasteful — it dilutes attention and pushes you toward larger models to compensate for noise you created yourself. Multiply that per-session cost by sixty agents and you can see where it lands.
Isolation is a scalpel. Use it where reasoning genuinely needs to stay clean — a security-sensitive path, a creative task that shouldn’t be contaminated by execution details, a long-running planner that must not be nudged by short-term context. Using it everywhere is like putting every function in its own microservice because you read that microservices scale. The pattern is real. The application is wrong.
The maintenance tax of agent sprawl
Enterprise IT teams have started calling this pattern agent sprawl — the unmanaged proliferation of AI agents across an organisation, each with its own prompts, skills, tools, and quirks. And the other thing about sixty agents is that someone has to maintain every one of them.
Skills drift. Instructions rot. The model underneath gets upgraded and starts interpreting your prompts differently. Prompts that worked in one release start producing subtly wrong output in the next. Every agent in your system is a surface where this can happen, and the surface area is linear with the count.
This is why I’ve argued for drift detection with human-in-the-loop escalation as a baseline, not a nice-to-have. If your system doesn’t tell you when its own assumptions have shifted, you find out from a customer. Sixty undifferentiated agents without that machinery isn’t an architecture — it’s a maintenance debt with a headcount.
The nightly-run-morning-review loop I described earlier is a symptom of the same problem. Without drift detection, a pattern registry, and author agents that referee the output before it lands, the only feedback signal is “the humans didn’t like what came out this morning.” That’s a slow, expensive, and lossy way to run a system.
What’s really being sold
Strip away the technical arguments, and bot bragging is about identity.
AI is coming for white-collar work. Nobody knows how fast or how thoroughly, but everyone knows something is happening. Standing up in that uncertainty and saying “I manage 30 agents” is armour. It repositions you from potential victim to obvious operator. You’re not the one being automated — you’re the one running the automation.
I get the impulse. But armour isn’t architecture. The professionals who’ll matter in five years aren’t the ones with the biggest agent count on their LinkedIn banner. They’ll be the ones whose systems still work when the token budget stops being unlimited, when the model provider deprecates the version they built against, when the drift catches up.
For the record — we built a 15-agent framework and I’ve written about why specialists beat generalists at that scale. Fifteen isn’t a magic ceiling. It’s the point where adding another agent stopped buying us clearer reasoning and started buying us more context to re-inject and more surface to maintain. Your number will be different. But it should be a number you can defend by pointing at decision boundaries, not one you picked because it looked good on a slide.
Sixty agents isn’t a flex. It’s a question the presenter hasn’t answered yet.