The One Article That Unblocked My Multi-Agent Architecture

My team has been designing an agentic system recently. Building a single agent felt manageable, but the moment we tried to wire multiple agents together, the questions piled up fast: what orchestration structure? how do agents communicate? how do we handle memory across the system?

Most resources I found were either too abstract or too narrow. Then I came across Rohit Ghumare’s article on multi-agent systems, and it covered nearly everything I’d been stuck on. What follows is my breakdown of the key ideas, with notes from our own experience.

Why Multi-Agent at All

I spent all of last year failing at context management with a single agent. The problem is straightforward: a single agent’s context window fills up, and once it does, the agent starts forgetting earlier decisions. When one agent also tries to handle multiple domains simultaneously, its judgment degrades further.

Multi-agent architectures solve this by splitting concerns, but they introduce coordination overhead. Managing that overhead is the real challenge.

Three Orchestration Patterns

The most practical section of the article focuses on when to use each pattern, not on what sounds impressive.

Supervisor Pattern

A manager agent decomposes tasks, distributes them to workers, and synthesizes the results. This works best for tasks that split cleanly into subtasks, or when you need an audit trail. Three to eight workers is the sweet spot. The bottleneck risk is real: every decision routes through the supervisor, and if your decomposition logic is weak, the supervisor becomes the point of failure rather than the solution.

Swarm Pattern

No central manager. Agents communicate peer-to-peer and self-organize. This suits problems that require diverse perspectives or real-time responsiveness. The failure modes are significant: duplicate work, infinite loops, and suboptimal convergence are all common. Debugging is genuinely painful, and I’d only reach for this pattern after the simpler options have been exhausted.

Hierarchical Pattern

A recursive extension of the supervisor: a top-level coordinator delegates to mid-level managers, who delegate to workers. Right for systems with ten or more agents, or when strategy and execution need clear separation. Token costs spike with every coordination layer, so the cost model needs to be understood before committing to this structure.

From our experience, the supervisor pattern has been the most stable. The key is getting worker distribution and error handling right from the start.

How Agents Communicate

Orchestration defines the structure; communication defines how information actually flows.

Shared State puts all agents reading from and writing to a single state object. It is simple to implement and easy to debug. Most teams should start here. Message Passing uses an asynchronous event bus for loose coupling between agents. Handoff is explicit baton-passing with full context transfer, which works well for fixed-order pipelines.

The choice matters less than people think at small scale. Where it matters is when you hit your first race condition in shared state, or when message bus latency starts eating into your response time.

Memory Architecture for Multi-Agent Systems

The core memory problem: how do you share state without causing collisions?

Session-Based Memory has each agent work in an isolated local state. Changes merge into shared memory only when the session ends. An agent takes a snapshot at session start, works locally, and merges deltas at the end. This gives collision-free parallel processing at the cost of slightly stale reads.

Window Memory retains only the most recent N exchanges. When the window overflows, the oldest third gets compressed into summaries. This prevents unbounded state growth for long-running conversations.

Episodic Memory stores the collaboration history of specific agent combinations and uses it to inform future decisions. It records which agent combinations succeeded or failed on which task types, enabling choices like “this combination worked last time.” In practice, building reliable episodic memory is harder than it sounds. The signal-to-noise ratio in collaboration history can be poor, and you need enough runs before the patterns become meaningful.

Production Considerations

Token costs are the first surprise for most teams. A supervisor with four workers costs roughly 15K tokens per task: about 1K for decomposition, 12K across workers, 2K for synthesis. The same task with a single agent runs around 4K tokens. Coordination costs nearly four times more. Caching supervisor instructions, structuring worker outputs as data rather than prose, and invoking workers only when necessary are the main levers.

Latency compounds in serial execution. At two to five seconds per LLM call, four agents in series means twelve or more seconds. Running independent tasks in parallel brings that down to three or four seconds. Always parallelize where the data dependencies allow it.

Error propagation needs to be designed explicitly: timeouts at every layer, circuit breakers that stop calling an agent after repeated failures, graceful degradation so core functionality survives partial outages, and state isolation so a worker failure cannot corrupt shared state. If you can’t observe it, you can’t fix it. Monitoring is a day-one requirement, not an afterthought.

Anti-Patterns to Avoid

The four I’ve seen most often: linking agents that could run independently (over-orchestration), funneling everything through one agent that defeats the purpose of distribution (the god agent), deploying without token monitoring (surprise invoices are real), and assuming every agent will always be available (no fallback).

Where to Start

The article’s conclusion stuck with me:

Build one agent. Identify where it breaks. Add a second agent at that breaking point. Layer in a supervisor if needed. Repeat.

I started with an ambitious hierarchical design and ended up simplifying to a supervisor with three workers. The architecture I’m running now is less impressive on paper than what I originally planned, and it works reliably. That tradeoff was worth making.

Source: Building Effective Multi-Agent Systems