Multi-Agent Patterns: Hierarchical, Market, Swarm, Actor

Topology 1 — Hierarchical (boss + workers)

A hierarchical system has a boss agent that decomposes the task, delegates to worker agents, and reintegrates their outputs. Workers may themselves be bosses for sub-tasks.

When it fits: well-understood task decomposition; workers are specialized (researcher, writer, reviewer); auditability requires a single owner of the plan.

Coordination characteristics: synchronous handoffs are typical; the boss holds the plan and the context; workers return structured outputs.

Failure modes (Article 12): infinite delegation (boss sends work back to itself via a worker), deceptive delegation (worker reports done without executing), context-starvation (worker lacks the context it needs).

Mitigations: delegation-depth cap; completion-verification step on the boss; shared context channel for long-lived context.

Real-world examples:

• CrewAI role-based hierarchical pattern — public CrewAI docs and demos show the canonical boss + workers pattern (one “manager” and several “specialist” agents).
• Microsoft AutoGen GroupChat with a Manager agent — public AutoGen examples demonstrate the hierarchical variant.
• LangGraph supervisor-and-workers pattern — LangGraph’s supervisor pattern implements the same topology with explicit state-graph transitions.

Topology 2 — Market (bidding)

A market topology has a coordinator that posts a task and candidate agents that bid. The coordinator awards execution to the best-fitting bidder, then verifies and “pays” (in credit, reputation, or the next task).

When it fits: heterogeneous worker pool; the best worker depends on the task specifics; the coordinator does not have prior knowledge to delegate optimally.

Coordination characteristics: bid submissions carry declared capability, cost estimate, latency estimate; the coordinator applies a selection rule.

Failure modes: reputation gaming (an agent bids aggressively without capability); winner’s curse (the most optimistic bidder wins and underperforms); starvation of niche-capability agents with nothing to bid on.

Mitigations: track observed performance per agent and discount future bids by recent success rate; run a shadow evaluation on a fraction of tasks; reserve niche-capability agents for tasks that match their declared specialties.

Real-world examples:

• Contract-net protocol — the academic ancestor of market topologies (R.G. Smith, 1980); the pattern shows up in multi-agent reinforcement-learning papers.
• OpenAI Agents SDK routing pattern with capability metadata — the SDK supports routing that is effectively a market when candidate agents declare capabilities.
• LlamaIndex Agents ensemble routing — LlamaIndex ensembles act as bidders when the ensemble routes a query to the agent whose declared scope best matches.

Topology 3 — Swarm (peer-to-peer)

A swarm has peer agents with no central coordinator. Each agent observes shared state, takes local decisions, and broadcasts partial results. Global behavior emerges from local interactions.

When it fits: exploration tasks without a known decomposition; resilience to single-agent failure is primary; the problem has parallel, independent sub-goals.

Coordination characteristics: shared state store (blackboard); message broadcast rather than direct addressing; consensus or quorum rules for aggregation.

Failure modes: oscillation (agents react to each other indefinitely); groupthink (early agents bias later agents through the shared state); emergent harmful behavior that no single agent would produce.

Mitigations: anti-oscillation rules (hysteresis, cool-down); diversity injection (distinct prompts or models across peers); emergent-behavior monitoring (anomaly detection on the aggregate output).

Real-world examples:

• AutoGen GroupChat without manager — public AutoGen examples of pure peer-to-peer conversation illustrate swarm pros and cons.
• CrewAI peer-collaboration mode — CrewAI supports crew modes where agents interact peer-to-peer.
• Research-swarm public demos on arXiv exploration — a pattern where multiple agents propose readings and the swarm converges on relevant papers.

Topology 4 — Actor (message-passing)

An actor topology treats each agent as an actor — a unit of computation with a mailbox, processing messages sequentially, with failure isolation and supervisor trees (Erlang/Akka tradition). Messages are asynchronous; state is local to the actor.

When it fits: long-running agents with state; high concurrency with failure isolation; asynchronous events (webhooks, alerts) drive the agent.

Coordination characteristics: each agent processes one message at a time; messages are queued; supervisors restart failed actors.

Failure modes: message-ordering assumptions violated (the sender assumed FIFO, the implementation is not); slow actor queue buildup (backpressure absent); supervisor cascade failure (supervisors fail simultaneously).

Mitigations: explicit message-ordering semantics documented; backpressure with bounded queues; supervisor-tree design with heterogeneous restart policies.

Real-world examples:

• Kafka-based actor model for asynchronous agents — public reference architectures use Kafka topics as the mailbox substrate; agents consume from their topic.
• Semantic Kernel plugin-driven handler pattern — agents written as plugins triggered by events realize an actor pattern over SK.
• LangGraph with async state-graph plus queue triggers — LangGraph supports async transitions; combined with a queue, it implements actor-like behavior.

Topology selection matrix