What actually breaks in a multi-agent AI coding swarm
A developer building an AI coding swarm expected model capability to be the hard part. It wasn’t. The failures came from the surrounding system: empty responses, exhausted token budgets, context window overflows, and compaction errors that left the workflow with no valid path forward.
The four failure modes
The developer documented four distinct problems, each occurring at a different layer of the stack.
- Token budget exhaustion: A critic agent returned no final content because the model consumed its entire output-token allocation on internal reasoning, leaving nothing for the actual answer. Retrying with a larger budget exposed the problem but didn’t address the underlying design question of how much budget each task type actually requires.
- Context window overflow: One request contained approximately 12,669 tokens against a configured context limit of 8,192. The request couldn’t be processed. In a multi-agent workflow, context accumulates fast: project instructions, prior messages, file contents, tool outputs, and results from upstream agents all compete for the same finite space.
- Compaction failure: When the system tried to compress a long conversation to continue working, it hit a point where reduction wasn’t possible without losing the most recent exchange or checkpoint. Retrying the same compaction wasn’t a recovery strategy. The workflow needed a different next step entirely.
- HTTP 415 error: A local inference server rejected a request before the model could do anything, because the client sent an unsupported media type. This is an integration problem, not a model problem, and it requires different diagnostics than the other three.
The five principles they settled on
After working through these failures, the developer landed on a set of practical changes to how they design multi-agent workflows.
- Each stage needs a clear contract. An agent should know what it is expected to produce, and the orchestrator should know what qualifies as success. An empty message should never silently count as a completed code review.
- Classify failures before retrying. A temporary service error, an invalid request, a context overflow, and an exhausted output budget are not interchangeable. Some warrant a retry, some require a modified request, and some should stop the workflow immediately.
- Assemble context deliberately. Instead of passing entire conversation history between agents, carry forward the task objective, verified findings, unresolved questions, and necessary file references. Drop the accumulated noise.
- Make recovery explicit. A failed stage should leave enough information for the orchestrator to decide whether to continue, restart a bounded section, or terminate without pretending the task succeeded.
- Verify results independently. For coding tasks, that means inspecting actual changes, running tests, checking command exit codes, or confirming expected files exist. A confident summary from an agent is not proof the change works.
The broader takeaway: adding more agents doesn’t increase reliability. Every handoff is an opportunity for information to be lost or misinterpreted. The developer concluded they’d rather have two agents that reliably complete clearly defined tasks than six agents passing large context payloads between each other without a dependable verification step.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
