Multi-Agent Architecture Patterns: From Orchestrator to Blackboard

Why Single Agents Fail

Most agent projects fail not because of model defects but because a single agent must handle routing, planning, tool calling, memory management, and error recovery simultaneously. Context windows grow uncontrollably, instructions conflict, irrelevant history crowds the window, and one tool error can derail subsequent steps. The solution is to distribute work across multiple collaborating agents — a multi-agent system.

What Is a Multi-Agent System

A multi-agent system consists of a group of agents with distinct roles that coordinate via shared state or message passing and aggregate results. For example, a planner defines steps, a researcher gathers information, a writer drafts, and a reviewer checks. Each role has a clearer responsibility, shorter prompts, and can be tested, retried, or replaced independently.

Value of Multi-Agent Systems

Beyond relieving context-window pressure, splitting agents provides:

Parallelism : Independent branches run concurrently instead of queuing serially in one loop, yielding real time savings for research, retrieval, and batch processing.

Fault isolation and independent verification : An error in one agent or a bad tool result can be contained. An independent verifier can catch mistakes before they propagate downstream.

Permission boundaries : Read-only agents and agents that write databases or execute high-risk operations should not share the same identity. Separation enables least-privilege enforcement.

Testability and replaceability : Narrow-role agents with short prompts can be unit-tested, evaluated, and swapped individually. Monolithic agents make it impossible to know what breaks when one part changes.

Cost layering : Simple steps use cheap, fast models; complex reasoning uses expensive models. Splitting creates room for cost optimization; a single agent forces payment at the highest tier for all steps.

Common Architecture Patterns

1. Orchestrator-Workers (Centralized Scheduling)

A central orchestrator agent receives requests, decomposes tasks, and routes them to downstream worker agents. Workers do not communicate with each other; they report back to the orchestrator, which decides the next step.

Applicable scenarios : Starting point for most systems; need centralized control flow and global logging.

Main cost : The orchestrator easily becomes a performance bottleneck and single point of failure.

2. Sequential Pipeline (Fixed Pipeline)

Agents hand off in a fixed order; each downstream node directly consumes the output of the previous one (e.g., extract → validate → summarize).

Applicable scenarios : Highly deterministic, stable data-processing chains with clear step order.

Main cost : Rigid process; upstream step or output format changes force downstream adjustments.

3. Hierarchical (Tree Structure)

Top-level planner breaks a large goal into sub-goals assigned to mid-level lead agents, which coordinate their own bottom-level execution agents.

Applicable scenarios : Extremely large, complex goals requiring decomposition into multiple parallel squads.

Main cost : More layers increase task dispatch and aggregation overhead, token usage, and latency.

4. Network / Handoff (Peer-to-Peer Handoff)

No central hub; agents transfer control directly based on task needs (e.g., OpenAI Agents SDK Handoff: triage agent hands off to refund agent, which later hands off to support agent).

Applicable scenarios : Open-ended, conversational flows where the next step cannot be predicted in advance.

Main cost : Prone to infinite loops and unclear accountability; engineering must hard-code round limits and exit conditions.

5. Blackboard (Shared Blackboard)

Agents do not communicate directly but read/write a shared storage. Each agent monitors the blackboard, contributes when it sees a task it can handle, and stops when the goal is reached.

Applicable scenarios : Loosely coupled, multi-party asynchronous collaboration refining the same artifact.

Main cost : Must handle concurrent write conflicts and stale reads.

Always start with the simplest viable pattern (usually Orchestrator or Pipeline), add complexity only when hitting real bottlenecks; give every agent a hard responsibility boundary and termination condition; treat automated evaluation (Eval) as part of the architecture.

Message Passing in Multi-Agent Systems

Agents exchange information via shared state, point-to-point messages, or a combination.

Shared State

All agents read/write a single structured state object. LangGraph supports this approach.

Pros : Single source of truth, easy to inspect, audit, checkpoint, and resume; most natural when multiple agents co-author the same artifact.

Cons : Concurrent write conflicts and stale reads require locks, versioning, or a single writer. Passing full state to the model at every step increases token usage and latency as state grows. Unverified results may be treated as facts by downstream agents.

Point-to-Point Messages

Agent A sends a structured message to Agent B; B maintains its own local state. Conversational task handoff is the typical form; cross-system, cross-vendor task delegation standardization moves in this direction.

Pros : Loose coupling, good fault isolation, easy distributed deployment; clear ownership — receiver is responsible; only necessary information is sent, improving least-privilege and privacy boundaries.

Cons : No global view makes debugging and auditing harder; message ordering, loss, duplication, and loops must be handled manually; ambiguous protocols let models interpret the same message differently.

Hybrid Mode

Production systems rarely use a pure approach. Common recipe: central orchestrator manages main flow; events and messages handle triggers, delegation, logging, and monitoring; persistent shared state stores only structured results, not verbose logs.

In detail, three rules:

State holds only well-defined key fields; every update carries a version number.

Agents exchange concise summaries, not full state.

Global state is held by the orchestrator; each execution unit keeps its own independent context, communicates only via messages with the orchestrator, and independent monitoring and recovery mechanisms provide safety nets.

How to Choose

Match business scenario characteristics to recommended architecture and communication style:

Short, self-contained task, few tools → Single Agent; no communication needed; clean up prompt and context first.

Fixed steps, clear sequence → Single Agent / Fixed Pipeline; shared state (strongly structured fields).

Strong audit, need checkpoints and resume → Orchestrator; prefer shared state.

Multi-role collaboration refining same artifact → Orchestrator / Blackboard; shared state + single-writer restriction.

Conversational flow, next step unknown → Network (Handoff); prefer point-to-point messages.

Multiple independent subtasks needing parallel speedup → Orchestrator / Hierarchical; message dispatch down + results aggregated back to shared state.

Cross-service deployment, permissions must be physically isolated → Multi-Agent (Distributed); prefer point-to-point messages.

Asynchronous contributions, completion order uncertain → Blackboard; shared state + orchestrator decides termination.

Regardless of the choice, three red lines must be in the review checklist:

One field, one writer. Each critical field allows only one writer; other roles are read-only, preventing write conflicts at the source.

Pass summaries, not full state. Messages and state updates carry only fields the downstream truly needs. Controls cost and attention dilution.

Validate before writing to shared state. Any content entering shared state — and thus treated as fact by all — must pass a verification gate. Prevent one agent's hallucination from becoming the system's truth.

Summary

As model capabilities grow and context windows expand, the need to split agents merely to compensate for context limits is decreasing. Multi-agent systems still organize complex tasks, achieving parallelism, permission isolation, independent verification, and cost control through division of labor. The more a single agent can do, the more carefully we must judge whether splitting is worthwhile and how much real benefit it brings.

Multi-agent can improve task outcomes but may also increase token usage and system complexity. Unclear responsibilities, mutual waiting, error amplification, or no one owning the wrap-up are problems to consider after splitting. Factor these costs into selection: start with a single agent, get it working, then split only when a clear bottleneck appears.