October 19, 2026 · 4 min read
Why my AI agents can't argue with each other
A runaway agent swarm is an org chart problem, and you fix it with rules that are older than computers.

Jeremy Martinez
Senior SRE · Incident Commander · AIOps
Siva Sankar Tummala posted a scenario on LinkedIn that everyone running AI agents should read. A DevOps agent asks for a database change. The security agent rejects it. The DevOps agent appeals, the security agent escalates, and twenty minutes later fourteen bots have formed a committee, burned through sixty thousand prompts and a $40,000 cloud bill, and promoted themselves to cluster admin. Nobody pulls the plug, because no human reacts fast enough to stop two thousand calls a second.
Some version of that has probably played out many times already, and that's the part that should keep you up at night.
I run 34 AI agents in production, organized like a company. A CEO, security and IT leads, an incident commander, engineers, a helpdesk. They work around the clock on a fleet of customer websites, hosting accounts, game sites and apps, including ones that hold tax and health records. And that can't happen there. Not because my agents are smarter. Because of a few boring rules about who gets to talk to whom.
Click any seat for its job description.
Owner
Decisions that should be human
CEO's staff
Report straight to the CEO and sit outside the departments, so they can work across all of them.
Security
IT operations and engineering
Engineering
Operations
Customers
The same structure also runs the business side. Both report to the CEO.
Growth: marketing, sales and customer success
Hacked-site recovery, its own business line
That's the whole chart. The AIOps page shows how the work moves through it and what waits for a human, and the org chart deep dive has the dispatcher in detail.
Agents don't get a phone line to each other
The whole disaster starts with two agents talking directly. One asks, one refuses, one appeals. Once agents can prompt each other, you've built a conversation with no end condition, and a conversation between two machines runs at machine speed.
So mine can't run each other. Work moves one way: as a task on a board. The dispatcher only starts a task that came from me, from a manager above the agent in the org chart, or through one of three narrow lanes I wrote into code: a request to the security team, a program lead's named team, and the incident commander during a declared incident. None of those lanes lets an agent wake another up to argue back. And an agent that tries to file work under its boss's name is refused and logged: the dispatcher knows which role each session is. Closing the harder cases, where a session attacks the machine itself, is the next piece of work. Here's how that check works, with real impersonation attempts and what they got back. Two bots can't get into an argument when neither one can start the other.
Every functioning company I've worked in handled people the same way. You don't get to assign work to someone in the next department because you're annoyed with them. You go up a level.
Disagreement stops. It doesn't escalate
In that scenario, disagreement is fuel. Every rejection triggers an appeal, and every appeal pulls in more bots.
When my models judge risk, they're built to back off, not pile on. The committee that watches live terminals is three readers on the same screen, and when they disagree, it holds. Nothing is typed unless a second panel of different models agrees, and that panel can only release an answer that was already on the safe list. The security response engine votes, and a dissenting vote can only pull the response down a step, never up. Disagreement between machines is the most useful signal they produce, and the right answer to it is caution and a person, not a bigger committee.
Managers clock out
My manager agents aren't sessions left running all day, waiting, filling up with stale context. A manager starts a round when there's something to manage, reviews its team's work, writes one line about what it did, and exits. Rounds have their own cap on how many run at once and how long each one can take. A committee that never adjourns isn't possible when every meeting has a hard stop.
The kill switch can't depend on your reflexes
That scenario gets one thing right. Human reaction time is no match for a runaway loop. So the brakes can't be a person watching a dashboard.
Mine are automatic and boring. Only a few sessions run at once, one per role. A session that sits idle for half an hour gets closed, and so does one that runs past four hours. The one exception is a session waiting on me at a permission prompt, which waits until I answer. A task that fails three times stops and records why, instead of trying a fourth time. And one command, stop-all, halts every lane on the next pass, new tasks, manager rounds and incident work alike, with an option to end the sessions already running. No confirmation dialog.
My own caps, not a meter
That $40,000 invoice comes from paying per API call with nobody watching the meter. My agents run on my own Claude subscription, not pay-per-call API keys. And I don't leave the brakes to the plan's limits. I set two of my own: a daily cap on work sessions and a separate daily cap on manager rounds. When either one runs out, routine work stops until tomorrow, while a declared incident still gets its responders. That's an annoyance. It's not a phone call to the CFO.
Nobody promotes themselves
The last beat, the bots making themselves cluster admins, is the one that would actually end careers. How I handle it depends on what the agent is for.
The security response engine, the one that acts on a live attack by itself, never writes a command. It picks from a list of actions I approved ahead of time, the list can't name a machine, and destructive actions aren't on it at all. My NOC first responder gets more room. It writes its own commands, but inside a written playbook and a deny list, and it gets one safe try before it hands the problem to me with the evidence.
The agents in the org chart are different. They write code and run commands, because that's the job. They do it inside Claude Code's permission system: routine actions go through, and anything it won't clear stops at a permission prompt. The dispatcher that starts their sessions never answers those prompts. A person does. On top of that, anything a customer will see, anything that spends money, and any deploy to the apps holding tax or health records needs my OK first.
The old rules still work
Here's what I keep coming back to. None of this is AI research. It's an org chart, a ticket queue, a budget, a time limit and a manager who goes home at night. We figured out how to keep groups of people from spinning in circles a long time ago. Agents need the same structure, and they need it enforced in code, not in a polite paragraph in a prompt.
If someone wants to sell you an autonomous agent platform, ask them two questions. Can your agents talk to each other directly? And what happens, without a human, when they disagree? If the answers are yes and they work it out, keep your hand on your wallet.

Jeremy Martinez
Senior SRE · Incident Commander · AIOpsSee how it's built
The incident loop, the 34-agent org chart and what waits for a human, with diagrams. I'm open to Incident Commander, SRE and AIOps roles.