Most "AI failures" are provisioning mistakes you pay for in tokens. Prove the work needs an agent before you issue the identity, and never run a swarm you can't justify as segregation of duties.
Someone stood up a social network this year that only agents could join. No humans allowed. Roughly 1.6 million agents registered, according to accounts making the rounds — and the vast majority were never dispatched to do anything at all. Capability with nothing to point it at.
That number gets passed around as a milestone. I read it as a diagnosis. The story we keep telling is that the swarm is the frontier: more minds mean more capability, so register the agents, build the teams, and let them coordinate. It is a seductive read. It is also the wrong one.
The failures I see in a regulated shop are not capability gaps. They are provisioning decisions — made before a single token is spent — to issue an agent, or a whole swarm, for work that never needed one. The token bill is just where you find out you got it wrong. And by the time the invoice arrives, the decision is months old.
Prove the task needs an agent before you issue the identity
Provisioning an agent is not a productivity choice. It is issuing a non-human principal, with all the weight that carries: an owner, a scope, a credential, a blast radius, and eventually an offboarding. It is the same joiner event I govern for every other machine identity, and machine identities already outnumber humans by something like 45 to 1, as high as 144 to 1 in the Cloud Security Alliance's May 2026 estimate. So the first question is never "how many agents." It is "does this work need one at all."
The 1.6 million registered-and-idle agents are what happens when you skip that question at scale. The register-first, find-a-purpose-later reflex does not produce capability. It produces an unenumerated fleet of principals holding credentials with no assignments — which, in my world, is not a milestone. It is a finding.
The gate I want in front of that reflex is a provisioning test, and there is a good one circulating in the AI-at-work writing that I have adopted wholesale, because it is a provisioning decision dressed as a productivity tip. Estimate four things about a task — its Size, its Independence, its Separation, and its Checkability — and it resolves to exactly one of four verdicts: nothing, a chat, one agent, or a team. The framing is not mine, but the discipline it enforces is exactly the one I want on every request. For most tasks the honest output is "nothing" or "a chat." Not a swarm.
Do not let cost talk you out of running it, because cost is not the gate. A widely shared account rebuilt a personal website with something like two dozen agents in an afternoon for about eight dollars; "fresh eyes on demand" now runs roughly a penny a look. A swarm is cheap to start — which is precisely why the discipline has to come from value, frequency, and checkability rather than from the invoice. The gate has to sit at the start, where the decision actually is.
Separation of interests is segregation of duties, not a performance trick
Here is the one durable reason to run more than one agent: to remove a conflict of interest. Not to add horsepower. Every honest example of a justified second agent turns out to be a control I already enforce on humans. An auditor who kept the books is not an auditor. The person who enters a payment cannot be the person who approves it. In a regulated fintech that is maker-checker and recusal, and I run it on people every day. The same test decides whether a task has earned a second mind: does the second agent remove a conflict the first one structurally cannot escape?
This is where the architecture from my control-plane post earns its keep. Agent proposes, judge disposes, tool executes is segregation of duties made mechanical — but only if the judge is an independent mind. A different model. A deterministic rule set. Something that does not share the proposing agent's context, incentives, or blind spots. A judge running on the same brain with the same prompt is not a second opinion. It is the same mind rubber-stamping itself, and you paid extra for the signature.
Which names the anti-pattern precisely. Two agents that share context, incentive, and blind spot are not a swarm. They are one mind you paid roughly fifteen times the tokens of a single chat to run — a multiple that traces to Anthropic's own write-up on its multi-agent research system. That write-up is the one everyone quotes for the headline that a multi-agent setup beat a solo frontier model by 90.2%; the part worth internalizing is the cost figure sitting right next to it. Adding non-independent agents buys you a shared failure mode and a bigger bill, not a second set of eyes.
So the test for a real swarm is a sentence, and you have to be able to write it: name the specific conflict of interest each additional agent removes. If you cannot name one, the Separation estimate says stop. You have a single-agent job wearing a team's token bill, and the defensible answer — the one I would put in front of an examiner — is one agent.
Token spend is a budget-cap control, not a "buy more thinking" lever
The load-bearing fact from that same Anthropic postmortem is the one that should reorganize how you budget for agents: token spend explained roughly 80% of the variance between good and bad runs, and identical tasks swung about 30x run-to-run. Sit with that. Spend is not a proxy for quality you can dial up. It is the dominant, largely uncontrolled variable in whether a run succeeds — which makes it a cap-it problem, not a turn-it-up lever.
More agents can buy negative return. An MIT and Google finding late in 2025 reported that multi-agent configurations in tool-heavy environments could perform worse than a single agent while burning two to six times the tokens for equivalent output. "Add a swarm" is not a safe default. It is a bet you can lose while paying more to lose it.
The counter-example people reach for actually proves the same point. Stanford's "Large Language Monkeys" work took a cheap model from 15.9% to 56% on a coding benchmark by sampling 250 attempts, beating a frontier model's 43% on a single try. The lesson is not "swarm harder." It is that repeated cheap attempts beat one expensive call only because a checker picks the winner. Strip out the checker and you have not multiplied intelligence — you have multiplied unverified guesses. That is minimum effective intelligence routing — a routing lever, not a license to spin up a team.
For the board, this collapses to one line: agent cost is a budget-cap item whose run-to-run variance dwarfs the savings from picking a cheaper model. So the real control is a per-run token cap, set before the identity is ever issued — the same discipline as a spend cap on a service account, enforced inline at the gateway, not a number you hope nobody blows through. The 30x variance is the reason a cap is a control plane and not a courtesy.
Checkability is the audit-defensibility gate
Here is the rule I will not bend: deploy an autonomous agent only where a cheap, deterministic checker can verify what it produced. A passing test. A reconciliation. A schema validation. An allowlist the egress destination is either on or not on. The Monkeys result only works because the benchmark ships a checker — you can afford 250 attempts precisely because a test tells you which one is right. No checker, no autonomy. Otherwise you are multiplying unverifiable claims at fifteen to thirty times the cost and calling the confidence a result.
This is the same gate I built into our audit-defensible pipeline: a deterministic check stands between the agent and the action, and the agent never certifies its own output. An examiner does not want the model's confidence score. They want to see the specific check that gated the action — the test that passed, the reconciliation that balanced, the row counts that matched. That check is the artifact. It is the control record I hand over, and it is the whole difference between a run I can defend and a run that merely sounds defensible.
And fluency is exactly what makes an unverified run look defensible, which is the more dangerous state to be in. Where the answer is genuinely unverifiable — a judgment call, an ambiguous risk decision, a tradeoff with no test that returns true or false — that is a human's job by design. Reserve it. Do not hand it to a swarm because the demo sounded certain. A polished multi-agent answer makes an unsettled question sound settled, and a settled-sounding overclaim is precisely what a tired reviewer waves into a control narrative at the end of a long day.
The metered-versus-subscription gap is shadow AI you have to surface
One more reported example, because it names a cost most of us cannot yet see. A single workflow — roughly 40 vendor contracts, invoices, and dashboards, wired together and run 134 times in a week — cleared 692 checked tasks and burned 107.56 million worker tokens. At metered API rates that week would have run something like a thousand to fifteen hundred dollars. Its actual cost was zero above the subscriptions already being paid. The gap between those two numbers is the entire point.
That gap is shadow-AI cost exposure, and it is my job to surface it before it is finance's surprise. The work rides flat-rate subscriptions today. The moment it moves to metered API, or simply scales past what a subscription tier absorbs, it becomes a four-figure-a-week line nobody budgeted — the FinOps twin of the unmetered service account. Unregistered agents are unmetered spend, and unmetered spend is a line item waiting to be discovered in a board meeting instead of forecast in one.
Which closes the loop back to the provisioning gate, because this is the cost side of joiner-mover-leaver. If an agent is not registered, its spend is invisible until finance finds it in the bill — the same way an ungoverned credential is invisible until it turns up in an incident. Surface the metered-equivalent cost of your subscription-hidden agent work now, on your own terms, so it lands on the books as a forecast rather than a shock.
What to do Monday
None of this is exotic, and you can start on Monday.
- Gate every agent request. Run Size, Independence, Separation, and Checkability in front of every provisioning decision, and default the verdict to "nothing" or "a chat" until the work earns more. Issuing an agent is issuing an identity — treat it like one.
- Make every swarm write its own justification. Require a one-sentence separation-of-interests statement for each additional agent: name the conflict of interest it removes. If you cannot, you are running one mind at roughly 15x, and the honest answer is one agent.
- Cap tokens before you issue the identity. Set a per-run cap inline at the gateway, not a hope in a policy doc. The 30x run-to-run variance is the reason a cap is a control plane, not a courtesy.
- No deterministic checker, no autonomy. Reserve the genuinely unverifiable for a named human, and make the check the artifact you show the auditor — the test that passed, not the model that felt sure.
- Surface the metered-equivalent spend. Put a dollar figure on subscription-hidden agent work now, so shadow-AI cost lands on your books before it lands in finance's.
Here is the whole thing as one rule you can hold in your head: prove you need the agent, then prove you need the second one. If you cannot do the second, you do not have a swarm. You have a chat and a token bill you have not read yet.
If you have put a provisioning gate in front of agent requests in a regulated environment, I want to know which of the four estimates kills the most bad ideas — and where a swarm you couldn't justify as segregation of duties still earned its keep anyway. Tell me in the comments.
