Why multi-agent architectures
Single-agent systems work well for bounded tasks, but enterprise applications quickly exceed what one model, one toolset, or one context window can handle reliably. Multi-agent architectures let you specialize, parallelize, and isolate failure domains while composing coherent workflows.
The decision to move from single to multiple agents is not about sophistication—it is about managing complexity, specialization, and scale at production grade. A single agent trying to do everything often becomes unmaintainable: its prompt balloons, its tool list grows contradictory, and its failure modes become opaque.
Single-agent vs Multi-agent tradeoffs
| Dimension | Single agent | Multi-agent |
|---|---|---|
| Scope | Best for focused tasks with clear success criteria | Handles complex, multi-step workflows with distinct phases |
| Specialization | Generalist; prompt engineering must balance competing priorities | Specialist agents with focused prompts, tools, and guardrails |
| Fault isolation | One agent failure can compromise the entire task | Failures contained per agent; orchestrator can retry or route around |
| Scaling | Scaled vertically (larger models, longer contexts) | Scaled horizontally (parallel agents, distributed execution) |
| Complexity | Simpler orchestration, easier to reason about end-to-end | Requires orchestration, communication patterns, and shared context |
Enterprise Agentic Architecture and Design Patterns
Salesforce Architect guide presenting a pattern-based methodology for agentic solutions. Covers the rationale for multi-agent architectures, the Router, Fan-out/Fan-in, Sequential, and Collaborative patterns, and the SOMA/MOMA/Multi-Vendor orchestration archetypes.
Read the Salesforce design patterns guideSwarm vs. Hierarchical data flows
The choice between a Swarm (Joint Collaboration) and a Hierarchical (Manager-led) structure depends on how you want context and state to flow between participants.
Context Flow Comparison
Loading diagram...
Orchestration Tradeoffs
| Aspect | Swarm (Joint) | Hierarchical (Magentic) |
|---|---|---|
| State Management | Global: One shared history thread | Local: Private ledgers for each sub-task |
| Token Usage | High: History grows exponentially | Optimized: Context is pruned for specialists |
| Adaptability | Emergent: Agents self-organize | Directed: Manager dictates next steps |
Concurrent and Group Collaboration
Beyond linear chains, multi-agent systems often employ concurrent processing or shared roundtable collaboration to solve problems requiring multiple expert perspectives or high-throughput analysis.
Scatter-Gather (Concurrent Analysis) Pattern
Loading diagram...
Group Chat (Roundtable) Orchestration
In the Group Chat pattern (common in Microsoft AutoGen), multiple agents share a single conversation thread. A specialized "Chat Manager" or "Moderator" uses a model to decide which agent should speak next based on the task progress. This allows for emergent collaboration but requires strict token management and "Speaker Selection" logic to prevent infinite loops.
For long-running, distributed agentic workflows, enterprises often adopt the Saga Pattern from microservices. This involves breaking the agentic workflow into a series of local transactions managed by a state machine (e.g., AWS Step Functions). Each step has a corresponding "Compensating Action" to undo the effect if a downstream agent fails, ensuring system-wide consistency across diverse backend systems.
Router/Dispatcher pattern
The Router pattern is the simplest multi-agent architecture: a classifier agent receives incoming requests, infers intent or category, and delegates to a specialist agent optimized for that type of task. It is the multi-agent equivalent of a switch statement or dispatch table.
Routers excel when requests naturally partition into distinct categories—customer support vs billing vs technical inquiries, or code generation vs documentation vs testing. The router does not need deep domain expertise; it needs enough context to classify correctly and route to the right specialist.
Router/Dispatcher pattern flow
Loading diagram...
When to use the Router pattern
| Use case | Example | Key consideration |
|---|---|---|
| Intent-based routing | Customer support triage: billing vs technical vs account requests | Router accuracy directly affects user experience |
| Modality-specific handling | Code generation vs documentation vs test generation | Specialist agents can have different tools and prompts |
| Domain separation | Legal contracts vs marketing copy vs technical docs | Clear boundaries reduce prompt interference |
| Cost-aware routing | Simple queries to small models, complex tasks to large models | Router needs cost signals or heuristics |
Router bottleneck risk
The router becomes a single point of failure. If classification accuracy is low, requests misroute and users see confusing errors. Classification logic should be logged, evaluated, and potentially upgraded to a small ensemble or few-shot model.
Fan-out/Fan-in pattern
Fan-out/fan-in orchestrates parallel execution: a dispatcher sends the same or related requests to multiple specialist agents simultaneously, then aggregates their results into a coherent response. This pattern is useful when you need multiple perspectives, redundant analysis, or parallel processing of independent subtasks.
Unlike the router, which delegates to exactly one agent, fan-out invokes multiple agents in parallel. The aggregator must resolve conflicts, merge insights, and produce a unified output. This introduces complexity in result synthesis but can improve reliability through redundancy and speed through parallelism.
Fan-out/Fan-in pattern flow
Loading diagram...
Error handling in fan-out requires explicit policies. If one agent fails or times out, should the orchestrator proceed with partial results? Should it retry that agent? Should it fail the entire request? These decisions depend on the criticality of each parallel task and the redundancy built into the system.
Fan-out use cases
Redundant validation (multiple reviewers cross-checking), multi-modal analysis (text + image + code together), ensemble predictions (voting or averaging), and parallel decomposition (breaking complex tasks into independent subtasks).
Sequential chaining and collaborative delegation
Sequential chains execute agents in a fixed pipeline, where each agent receives the output of the previous one and contributes to the final result. Collaborative delegation is more dynamic: agents negotiate handoffs, request additional work, or iterate based on evolving context. The difference is between a rigid assembly line and a flexible team collaboration.
Sequential chaining example
Loading diagram...
Sequential vs Collaborative delegation
| Aspect | Sequential chaining | Collaborative delegation |
|---|---|---|
| Control flow | Fixed pipeline, predetermined order | Dynamic, agents negotiate next steps |
| Flexibility | Predictable but rigid | Adaptable to changing context |
| Complexity | Simple orchestration, easy to debug | Requires negotiation protocols and conflict resolution |
| Use case | Assembly-line workflows with clear stages | Problem-solving where requirements evolve |
Shared context management is critical in both patterns. Each agent needs access to the conversation history, intermediate results, and relevant state. Without a shared context bus, agents either duplicate work or miss important context established earlier. Context can be passed explicitly (as messages) or implicitly (through shared memory or a blackboard pattern).
Sequential chain pitfalls
Long chains are fragile: if any agent fails or produces poor output, downstream agents amplify the error. Consider introducing checkpointing, validation steps, or rollback mechanisms to recover from intermediate failures.
Agent communication patterns
Multi-agent systems need ways for agents to share information, coordinate actions, and negotiate handoffs. The communication pattern you choose affects latency, reliability, and scalability. The main approaches are shared memory, message passing, event-driven communication, and blackboard systems.
Communication pattern comparison
| Pattern | How it works | Pros | Cons |
|---|---|---|---|
| Shared memory | Agents read/write to a common context store | Fast, simple, immediate visibility | Requires concurrency control, risk of race conditions |
| Message passing | Agents send messages directly to each other | Explicit communication, easier to reason about | Overhead grows with agent count, coupling concerns |
| Event-driven | Agents publish events, subscribers react | Loose coupling, scalable to many agents | Event schema management, eventual consistency |
| Blackboard | Shared workspace where agents contribute partial solutions | Collaborative problem-solving, emergent behavior | Hard to predict convergence, requires arbitration |
Communication overhead grows quadratically with agent count in fully connected topologies. For n agents, there are O(n²) potential communication channels. This is why most production systems use centralized orchestrators, hierarchical topologies, or message buses rather than peer-to-peer communication.
Choosing a communication pattern
Shared memory works well for tightly coupled agents with simple coordination needs. Message passing is better for explicit handoffs and clear ownership. Event-driven scales best for large, dynamic systems. Blackboard is useful for collaborative problem-solving where the solution emerges incrementally.
Orchestration topologies and archetypes
The structural relationship between agents—the orchestration topology—defines how context flows and how autonomy is shared across the swarm.
- Star (Hub-and-Spoke): A central router or triage agent receives all requests and dispatches them to specialists. Ideal for service desks where intent must be classified before action.
- Mesh (Fully Connected): Agents communicate peer-to-peer without a central authority. This emergent behavior (Group Chat) allows for high flexibility but is harder to audit and control.
- Hierarchical (Supervisor): A recursive structure where a Manager Agent oversees worker agents, who may in turn manage their own sub-agents. Best for high-compliance environments.
Common multi-agent topologies
Loading diagram...
1. SOMA (Single Org, Multiple Agents): Multiple agents collaborate within one organizational boundary using shared governance and data. A Supervisor agent acts as a single front door, routing requests to Specialist agents. For external functionality, agents use the Agentforce MCP Client with MuleSoft acting as an MCP-wrapper for non-MCP-enabled APIs.
2. MOMA (Multi Org, Multiple Agents): Agents collaborate across multiple organizational boundaries, requiring secure coordination. A Supervisor in one org delegates to an agent in another via the standardized Agent-to-Agent (A2A) protocol. This handshake ensures org-level trust, user identity flow, and shared conversation context.
3. Multi-Vendor A2A (Salesforce-led): A Supervisor agent coordinates work across native agents and agents from other vendors (e.g., Google Vertex, LangGraph) via A2A protocols. For systems not A2A-capable, MuleSoft exposes a lightweight agent facade.
4. Multi-Vendor A2A (MuleSoft-led): When orchestration is initiated from a non-Salesforce entry point, MuleSoft Conductor acts as a neutral external orchestrator for reasoning and routing, using A2A to call vendor agents including Agentforce.
The Model of Models pattern leverages multiple expert agents to generate a broad swath of perspectives, then extracts the consensus. Unlike the Judge & Jury pattern, this pattern embraces multiple points of view to enhance richness—also called the Panel of Experts pattern. This is closely related to the Swarm pattern, where a large number of agents collaboratively explore a problem space and arrive at a solution.
The Project Manager pattern is a complex long-running pattern that oversees multi-step projects. It coordinates activities, tracks completion, notifies users, and represents project status to stakeholders. It takes an input template/outline of a project—including tasks, roles, and dependencies—then instantiates cases and assigns them.
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.