There's a defect sitting in your multi-agent system right now. Your tests pass. Your dashboards are green. And it will fire in production, not in testing.
That's not a scare tactic. It's arithmetic and architecture.
The arithmetic
14 agents, each 95% reliable. End-to-end: 0.95^14 ≈ 49%.
Every individual agent passes every eval you throw at it. Your system is a coin flip. Reliability doesn't average across a pipeline — it multiplies. Every handoff is a multiplication.
The architecture
The failures that take down agent systems don't live inside agents. They live in the wiring, and they're in your graph today:
The loop with no exit. Agent A calls B, B routes back to A. Under the right input they ping-pong indefinitely — burning tokens every lap, throwing no error, dashboards green. You find it on the invoice.
The single point of failure nobody designed. Teams build an orchestrator (sensible), and over time everything accretes onto it — every handoff, every retry. Nobody decided it should be critical. When it stalls, the whole pipeline stalls, silently, with nothing to trace.
The unguarded injection path. An untrusted tool's output — a web fetch, an API result — reaches an agent that makes decisions, with no validator between them. Malicious content in that result can hijack the consuming agent. The attack doesn't break in; it rides in through data your system was built to consume.
** Why per-agent testing can't save you**
Run every eval you have. Each agent passes — because nothing is wrong with any single agent. The vulnerability only exists in how they're connected.
We test nodes. The failures live in the edges.
Why this is urgent, not theoretical
These aren't risks that might develop. They're defects that exist in your topology right now, dormant, waiting for the input that triggers them. The loop with no exit will loop. The SPOF will fail. The unguarded path is a surface whether or not anyone has attacked it yet.
And the reason to act now rather than after the incident: they're all visible before runtime. They're structural — findable in the shape of your system, the way an architect spots a missing load-bearing wall in the blueprint rather than in the rubble.
Sixty seconds
swarm-test maps your agent topology (CrewAI, LangGraph, AutoGen, or a plain agents/edges description) and flags these statically: no-exit loops, hidden SPOFs, unguarded handoffs, injection surfaces, cascade blast radius. No LLM calls. Deterministic. Milliseconds.
pip install swarm-test
It runs in CI too — --ci fails your build when a structural regression lands, so the defect never merges in the first place.
And when it finds something, it now leads with the lightest fix — a config change, a re-route, an inline check — rather than telling you to bolt on more agents. Fixing a finding should simplify your architecture, not complicate it.
Run it once
If you're running agents in production, the honest ask is small: run it once. Sixty seconds.
Worst case, you confirm your wiring is clean and sleep better. Best case, you find the thing that was going to find you first — at 2am, in production, with no error message attached.
Or drop your topology in the comments and I'll run it and send you the findings.
Open source, MIT.
The agents aren't the problem. The wiring is. And it's already in there.
If this was useful, a star on GitHub is how other devs find it.
Top comments (0)