Swarms sound like the future, but most teams can’t debug them — here’s when peer-to-peer actually pays off — Swarms / P2P

A developer who built a six-agent customer support swarm using peer-to-peer handoffs found the system deadlocked in a forty-minute loop and produced contradictory answers with no errors or timeouts, concluding that decentralized multi-agent orchestration trades debugging ease for scalability. The account cites Sentry's observation that multi-agent failures live in agent interactions rather than any single agent's logs, and the TraceElephant benchmark, which found full observability raises step-level failure attribution from 16% to only 28-30%. The developer notes Anthropic's guidance to start with a single richer agent and add multi-agent only when a specific constraint justifies the roughly 15x token cost of multi-agent runs.

I spent a week watching a swarm of six agents burn through $400 in tokens, hand off a billing question to a refund specialist, get handed back, and loop for forty minutes without ever answering the customer. Every individual agent was working. The system was deadlocked. Nobody had thrown an error. Nobody had timed out. The trace just showed a beautiful, expensive circle. That's the moment I understood why swarms sound like the future and why most teams can't ship them. The swarm pattern is intoxicating on paper. No central supervisor. No bottleneck. Each agent owns a domain and decides for itself when to answer or hand off to a peer. OpenAI's Swarm library introduced the primitive in late 2024: agents transfer control to each other by specialization, and the "manager" disappears. LangGraph's swarm library, Microsoft's Agent Framework, and AWS Bedrock AgentCore all implement some version of peer-to-peer handoff. AWS's own documentation describes it as "dynamic and peer-to-peer, based on agent discoveries and needs" with "distributed" decision-making where agents make local choices about task planning and handoffs. I bought the pitch. I built a six-agent customer support swarm: triage, billing, refunds, technical, account, and escalation. Each agent had its own tools, its own prompt, its own domain knowledge. No supervisor meant no context saturation. No bottleneck meant horizontal scaling. The demo was flawless. Then I turned it loose on real traffic and discovered what the research already knew. The first failure was quiet. A customer asked about a refund. Triage handed to billing. Billing handed to refunds. Refunds handed back to billing because the refund policy check needed account status. Billing handed to account. Account handed back to refunds. Refunds handed to triage. No agent produced a wrong answer. No agent crashed. The system simply spun, and the customer waited. The second failure was louder but equally invisible. Two agents returned contradictory information about the same account. The synthesis step, which I'd naively built to "aggregate results," picked one arbitrarily. The final answer was wrong in a way that only made sense if you replayed the entire trace and read every tool output at every hop. This is the debugging problem that kills swarms. Sentry's engineering team put it perfectly: "The bug is in the interaction between them, and no single agent's logs will show it". Multi-agent traces are DAGs, not trees. Blame is distributed. The worst failures look fine because an agent returns a plausible-but-thin result, the next agent incorporates it without question, and by the time the output arrives, weak data has been confidently summarized through multiple layers. I went looking for tooling. What I found was a research literature that had already named my exact problem: failure attribution in multi-agent systems remains "underexplored and labor-intensive," with verbose system logs turning debugging into a bottleneck. A benchmark paper called TraceElephant found that full observability improves step-level attribution from 16% with output-only inspection to 28-30% with full traces. Even with perfect observability, you're catching fewer than a third of failures. That's the wall. Swarms give you distribution and resilience. They take away the single point of observation that made centralized systems debuggable. The ICML and survey literature is clear about the trade-offs. A 2026 survey of LLM-based multi-agent orchestration frameworks found that decentralized patterns trade low debugging ease for high scalability and fault tolerance . Anthropic's guidance is blunter: start with a single richer agent, add multi-agent only when you can name the specific constraint it relieves. Multi-agent runs measured at roughly 15x the tokens of a chat interaction, and moving from a single agent to a team typically adds another ~4x on top. SWARM+ is the clearest research validation that decentralized orchestration can scale if you build the right primitives. A fully decentralized workload management system, it scales coordination to 990 distributed agents with approximately 1-second per-job selection time at 110 agents. Under distributed failures, it maintains over 97% job completion with graceful degradation. Under correlated site outages—the worst case—completion drops to 95.6% , and mean selection time stays under 2.5 seconds. The system doesn't lose jobs when agents die. It autonomously reselects orphaned work through delegation monitoring, triggering additional consensus rounds to recover. That's the fault tolerance argument in numbers. But SWARM+ isn't an LLM agent swarm. It's a distributed systems protocol wearing an agent costume. The teams shipping LLM swarms to production are the ones who treat the pattern as a distributed systems problem, not a prompt engineering problem. Included Health built Dot, a healthcare navigation system on a federated multi-agent architecture using LangGraph. It's not a pure swarm—Dot runs through a main "supergraph" with sub-workflows handling urgent care, scheduling, and behavioral health—but the architecture is deeply peer-oriented. Different product teams own different graph sections. When a member moves between services, Deep Agents' filesystem lets the outgoing agent summarize the conversation and pass both the summary and a file path to the full history, so members don't repeat themselves across team boundaries. Human handoff is built into the graph through durable execution: when Dot reaches uncertainty, it pauses, routes to a human care advocate, and resumes with the context of what the human did. Dot launched with 75% higher chat engagement and over 99% high-risk situation detection . LangChain's agentic engineering report describes a pilot of 20+ debugging workflows where coordinated agent execution produced a 93% reduction in time-to-root-cause compared to historical baselines. Worker agents retrieve context that extends beyond source code, notify other agents, and trace agentic activity. The swarm isn't the product—it's the debugging infrastructure. The pattern that emerges from these deployments is consistent: swarms work when the topology is explicitly designed , not when agents are given a list of peers and told to figure it out. The failure mode I hit—the infinite handoff loop—is the primary one. The literature calls it handoff cycles, and the fix is structural, not prompt-based. A robust swarm detects handoff cycles a peer already in the trace , detects dead ends no peer fits , and escalates to a human when either happens or the hop budget runs out. The standard guidance recommends a chain depth limit of three to four handoffs before escalation. But cycle detection alone isn't enough. The deeper fix is observability that treats every handoff as a first-class span in a distributed trace. OpenTelemetry-based tooling like llmas-otel combines distributed tracing with fault injection, letting you target specific interaction points and inspect what each agent saw at each hop. SwarmTrace, a time-travel debugger for multi-agent pipelines, builds span trees where every agent action is an OTel graph node with replay from any step. The mental model shift is this: a swarm is a distributed system , and distributed systems need distributed tracing. Parent-child spans, state snapshots, checkpoint replay. The same primitives that made microservices debuggable. I'm not going to tell you swarms are the answer. The research is clear that most production systems blend patterns. A hierarchical backbone might use decentralized handoffs inside each team. A supervisor might hand off sub-problems to peer groups. The right combination depends on task structure, agent count, fault tolerance requirements, and cost budget. Use swarms when your problem is genuinely open-ended, when agents need to negotiate across domains, or when the topology of the work isn't known at design time. Use them when fault tolerance matters more than debuggability . Use them when you've built the tracing infrastructure to see what's happening at every hop. Don't use them because they're elegant. Don't use them because the demo looked good. And for the love of everything, don't use them without cycle detection and hop budgets. So here's my question: When your swarm deadlocks at hop seven, does your architecture show you the cycle—or do you find out when the token bill arrives? I'd love to hear where you've landed. Peer-to-peer handoffs, a supervisor you never fully escaped, or a hybrid that finally made sense and what finally made you change?