The demo version hides the risk
There's a pattern playing out across every AI demo right now. Someone shows a swarm of agents: planner, builder, reviewer, triage. They coordinate in real time, spin up tasks in parallel, and ship code or content or research faster than any human team could. The demo is genuinely impressive. The comments say things like "this changed everything."
Then someone in the audience asks: "What happens when one of them goes off the rails?"
The host moves on quickly.
The received wisdom is that agent swarms are a productivity unlock. More agents running in parallel means more output. Add a reviewer agent and you get quality control built in. Add a planner and you get strategic coordination. The math seems obvious: N agents doing N things simultaneously equals N times the speed.
This is roughly correct and almost entirely useless as a way to think about running agents in a real business.
Here's what the demos don't show. An agent loop without a clear definition of done will keep going until it hits a cost cap, a rate limit, or a timeout. Whichever comes first. That's not an edge case. It's the default.
The self-evolving swarm that "iterated through 219 generations" someone posted on Reddit recently? The top comment was: "This is also just an ad wrapped in a nice story." The second most upvoted reply described getting 500 server errors.
Meanwhile, someone on r/clawdbot wrote: "If your agent has ever reset your session at 4am, burned your tokens in a retry loop, or eaten 3GB of RAM, you're not using it wrong." That post landed because it's funny and because it's true for a lot of operators right now.
There's a more uncomfortable version of this problem. Another Reddit thread asked a sharper question: most AI agent frameworks measure how far the human gets out of the way. None measure what keeps the system honest when they do. That's the actual gap. Not raw speed. Not parallelism. Accountability without a human in the room.
The real failure mode
At Foundry Works, we've been running agent systems in production long enough to know the failure mode isn't bad models. Models are good. The failure mode is vague goals meeting unconstrained autonomy.
When you tell an agent swarm to "make this better" without defining what better looks like, with no output path, no turn budget, no review checkpoint, you're not delegating work. You're releasing entropy.
The patterns that actually work look boring compared to the demos. A planner agent that produces a list of tasks with acceptance criteria, not a vague strategy. A builder agent with a defined write scope: these files, this folder, nothing else. A reviewer agent with a rubric, not just "check the quality." A hard turn budget that pauses the loop and surfaces work for human review before continuing. A rollback plan that takes thirty seconds to execute.
None of this is exciting content. It won't trend on LinkedIn. But it's the difference between an agent system that saves your team ten hours a week and one that creates a problem nobody can find the source of.
The questions to ask before adding more agents
The implication for your business is practical. If you're building with AI agents right now, or evaluating whether to, the questions to ask aren't about the model or the framework. They're operational.
What is the acceptance criterion for this task being done? Which files or systems is the agent allowed to touch? How many turns before it surfaces for review? What does rollback look like? Who gets the output and who checks it?
Answer those before you add more agents. The bottleneck in most AI agent projects isn't compute or intelligence. It's the absence of a definition of done.
Agent swarms aren't the problem. Autonomous loops without a finishing condition are.