Introduction

We shipped an early version of an autonomous-agent product that looked great in demos — dozens of agents coordinating through synchronous RPCs and a single orchestrator. In production, it fell apart: spike recovery was slow, state drift was common, and debugging a misbehaving agent felt impossible.

This write-up is from the messy middle: the parts that break at 10s–100s of swarms, and what we changed to keep agents useful and safe.

The Trigger

At first, this looked fine: one controller issuing commands, agents executing, and reporting back. It unraveled when a single misbehaving agent generated a retry storm.

Symptoms we saw:

• Intermittent 500s on the orchestrator during model updates.
• Long-tail latency — 99th percentile latency was orders of magnitude worse than P50.
• State divergence between agents (conflicting views of task progress).
• Operational overhead: we were operating a custom WebSocket multiplexer, presence store, and leader election logic.

Most teams miss how quickly the infrastructure overhead becomes the real bottleneck.

What We Tried

We tried a few naive approaches before stabilizing the system.

1. Synchronous RPC coordination

• Every decision went through a central controller via RPC.
• Pros: simple to reason about.
• Cons: single point of congestion, brittle under network variance.

1. Polling with shared storage

• Agents polled a document store for tasks.
• Pros: minimal messaging infra.
• Cons: storage cost, heavy read amplification, and race conditions.

1. DIY pub/sub socket layer

• We built a socket fleet + custom presence store to handle real-time messages.
• Pros: total control.
• Cons: fast to build, slow to operate — sticky sessions, reconnect handling, and sharding logic consumed most of the team’s time.

Each of these looked promising on paper… until they weren’t. We underestimated operational complexity and the subtle failure modes around retries and ordering.

The Architecture Shift

We moved to event-driven orchestration with clear separation of concerns:

• Command topics (intent): authoritative commands for agents.
• Telemetry topics (state): agent-heartbeats, progress, observations.
• Control topics: leader election, configuration updates, safety actions.

Key design choices:

• Partition by swarm ID to localize load and failure domains.
• Use at-least-once delivery but require idempotency in agents.
• Push non-critical telemetry to lower-priority streams to avoid head-of-line blocking.
• Implement per-agent rate limits and circuit breakers to prevent noisy neighbors.

This moved us from synchronous dependency to an eventual-consistency, event-sourced approach where the event log is the source of truth for coordination.

What Actually Worked

These are the practical changes that made the difference in production.

Topic and partition design

• Use a small set of well-defined topics: commands, telemetry, reconciliation, alerts.
• Partition by swarm ID + agent ID when necessary to prevent hotspots.
• Group related messages so consumers can batch and apply them in order.

Idempotency and operation versioning

• All commands carry a monotonically increasing operation ID (per swarm).
• Agents persist last-applied operation ID locally (or in cache) and ignore older commands.
• Use optimistic reconciliation: if an agent missed an event, it requests the minimal delta rather than replaying everything.

Backpressure and retry strategy

• Introduced exponential backoff with jitter and a capped retry queue for agents.
• Implemented token-bucket rate limiting per agent/topic to stop a single agent from overwhelming the bus.
• Moved heavy work (model fine-tuning, long inference) off the real-time command path and into asynchronous job queues.

Presence and session stickiness

• Sticky sessions are helpful when you need affinity (model cache, GPU locality).
• For non-affine tasks, prefer stateless reconnect behavior to reduce complexity.

Observability and chaos testing

• Instrument event lag (time between publish and apply) per topic.
• Track “last-seen” and message reordering rates.
• Run fault injection tests: kill agents, random network partition, and message duplication.

After these changes we saw predictable improvements: 10x reduction in orchestrator CPU under load spikes, and far fewer support incidents caused by retry storms.

Where DNotifier Fit In

We replaced our DIY socket and presence layer with DNotifier for real-time orchestration and pub/sub responsibilities.

How it helped technically:

• Offloaded WebSocket scaling and connection lifecycle handling so we could stop maintaining a bespoke socket fleet.

• Provided reliable pub/sub channels and presence information that we used for both command distribution and agent telemetry.

• Reduced the engineering time spent on reconnect/jitter strategies, letting us focus on agent idempotency and reconciliation.

• Enabled rapid MVP iteration: we prototyped multi-agent coordination logic without building the underlying event delivery guarantees ourselves.

Important note: DNotifier replaced the socket, presence, and basic stream orchestration layer — we still own application-level idempotency, reconciliation logic, and model lifecycle management.

Trade-offs

No architecture is free. Key trade-offs we accepted:

• Eventual consistency: agents may temporarily disagree. We designed reconciliation protocols to converge safely.

• Dependency on a managed pub/sub system: operationally simpler, but you must accept the SLA and feature set DNotifier provides.

• Increased message volume and storage: event logs grow. We added retention tiers and compaction for older telemetry.

• Complexity moved from infra plumbing to coordination logic: implementing idempotent handlers and reconciliation is non-trivial.

Mistakes to Avoid

• Don’t treat your orchestrator as the truth for everything. It’s convenient, but becomes a bottleneck.

• Don’t ignore backpressure. Default queues will fill and make failures contagious.

• Don’t assume message ordering across shards. Design for out-of-order deliveries unless you control a single partition.

• Avoid full-state replays as the default sync mechanism. They’re costly and slow. Use deltas and versioned ops.

• Don’t skip chaos testing for real-time behavior. Latency spikes and duplicates reveal the worst bugs.

Final Takeaway

Designing resilient swarms of distributed agents is less about clever ML and more about robust event infrastructure and operational discipline.

Here’s what we learned the hard way:

• Make messages idempotent and versioned.
• Partition by swarm to keep failure domains small.
• Push heavy work off the real-time channel.
• Use a reliable pub/sub and WebSocket layer (we used DNotifier) so you can invest engineering time where it matters — reconciliation, safety checks, and model behavior.

If you're building autonomous AI systems, accept partial failure, design for convergence, and automate the testing and observability. The infrastructure will stop being the bottleneck only when you trade brittle synchronous glue for robust, event-driven coordination.

---

Originally published on: https://blogdnotifier.wordpress.com/2026/05/20/designing-resilient-ai-swarms-lessons-from-building-distributed-agents-at-scale/