A client asked me last month to build an Agentforce agent that could handle service requests, check order status from their ERP, pull account history, and draft follow-up emails. One agent. Four domains. About 30 topics.
It worked. Kind of. The agent got confused when a customer asked about an order and a billing question in the same conversation. It lost context halfway through, mixed up which topic it was on, and started hallucinating shipping statuses because it grabbed the wrong record.
So I broke it apart. One supervisor agent handling the conversation and routing. Three specialist agents doing the actual work. The problems went away. Here's how multi-agent orchestration works in Agentforce and what I've learned building it.
Why One Agent Isn't Enough
Single agents are fine for simple use cases. A service bot that answers FAQs, an SDR agent that qualifies leads, a case summarizer. One domain, one job, clean instructions.
The problem shows up when you start stacking responsibilities. Every topic you add to an agent makes the instructions longer and harder for the reasoning engine to follow. Think of it like giving one employee a 30-page job description covering four different roles. They'll handle the easy stuff but start making mistakes on anything that requires judgment.
Salesforce's Atlas Reasoning Engine is good, but it still has to parse all of your instructions and decide which ones apply to the current utterance. More topics means more room for misinterpretation. I've seen agents pick the wrong topic about 15% of the time once you get past 12-15 topics on a single agent. That number goes up fast as complexity increases.
Multi-agent architecture fixes this by splitting responsibilities. Each agent gets a narrow scope, clear instructions, and a small set of actions. A supervisor agent handles routing. You get better accuracy, easier debugging, and agents you can update independently without breaking everything else.
The Patterns That Matter
Salesforce published an enterprise agentic architecture guide recently that defines about a dozen patterns. Most of them are useful in theory. In practice, three patterns cover about 80% of what I build.
The Operator
This is the simplest multi-agent pattern. A front-door agent talks to the customer, figures out what they need, and hands off the conversation to the right specialist agent or human. It doesn't come back. The specialist takes over.
Use this when your specialists handle conversations end-to-end and don't need to collaborate. A service org where billing questions go to one team and technical issues go to another. The Operator figures out which one, transfers, done.
In Agentforce, you build this with the Service Agent's transfer capabilities. The Operator agent has topics focused purely on intent detection. Its actions are transfers to other agents or to human queues. No domain logic in the Operator itself.
The Orchestrator
This is the one I use most. The Orchestrator stays in the conversation the whole time. When the customer asks something, the Orchestrator passes the request to the appropriate specialist, gets the answer back, and delivers it. If the customer switches topics mid-conversation, the Orchestrator routes to a different specialist without dropping context.
The difference from the Operator: the Orchestrator stays as the single point of contact. The customer never talks directly to a specialist. The Orchestrator is managing a team behind the scenes.
In Agentforce, you implement this by giving the Orchestrator agent actions that invoke other agents. Each specialist agent is just a tool the Orchestrator can call. The Orchestrator's instructions tell it when to call which specialist and how to combine their responses.
This is the pattern I used for the client I mentioned at the top. The Orchestrator handles the conversation flow. The Order Status agent queries the ERP. The Account History agent pulls CRM data. The Billing agent handles payment questions. The Orchestrator calls whichever one it needs based on what the customer just said.
Domain SME
These are your specialist agents. Each one owns a business domain. Orders, billing, cases, claims, whatever your business needs. They have focused instructions for their domain and actions scoped to only the data and operations they need.
The main rule: a Domain SME should be fully self-contained for its area. It should be able to answer any question in its domain without needing to call another agent. If you find yourself having one specialist call another specialist, you either scoped them wrong or you need an Orchestrator in front.
How to Split Your Agents
This is the architecture decision that matters most, and there's no formula. But here's how I think about it.
Split by business domain, not by object. Don't create an "Account Agent" and a "Case Agent." Create agents around how the business actually thinks about work. A Returns agent that handles the full return process (which might touch Cases, Orders, and Inventory). A Billing agent that handles invoices, payments, and credits. Business domains, not data model objects.
Start with two agents, not ten. Take your monolithic agent, identify the two most distinct topic clusters, and split those into specialists with an Orchestrator in front. Get the routing working. Then split further if you need to. I've seen teams design elaborate eight-agent architectures on a whiteboard that never make it to production because the complexity is overwhelming. Start small. Add agents when you have a concrete reason.
Keep the Orchestrator thin. The Orchestrator's job is intent detection and routing. It should not have domain-specific logic. If you find yourself writing instructions like "when the customer asks about a return, check the order status first and then..." that logic belongs in the specialist, not the Orchestrator. The Orchestrator decides WHO handles the request. The specialist decides HOW.
Shared context matters. When the Orchestrator calls a specialist, it passes the conversation context. Design your specialist instructions assuming they'll receive context about a conversation already in progress. The specialist doesn't need to re-greet the customer or re-collect information the Orchestrator already gathered.
The Orchestration Archetypes
Salesforce defines four archetypes for how agents work together at a system level. In plain terms:
SOMA (Single Org, Multiple Agents) is the most common setup. All your agents live in one Salesforce org, share the same data, same security model, same governance. The Orchestrator routes to specialists within the same org. This is where you start and where most implementations stay.
MOMA (Multi Org, Multiple Agents) is for enterprises with multiple Salesforce orgs. A supervisor in one org can delegate to an agent in another org using the Agent-to-Agent (A2A) protocol. Each org keeps its own security and data boundaries. I've seen this in large enterprises with separate orgs for different business units or regions.
Multi-Vendor A2A extends this to agents outside Salesforce entirely. Your Agentforce Orchestrator can call agents built on other platforms like Google Vertex, LangGraph, or custom builds through A2A. MuleSoft acts as the bridge for systems that don't speak A2A natively. This is where things are heading, but it's early. Most implementations aren't here yet.
For most teams reading this: start with SOMA. One org, a supervisor, two or three specialists. Get that working before you think about cross-org or cross-vendor orchestration.
MCP and A2A: The Protocols
Two protocols make multi-agent orchestration work under the hood.
MCP (Model Context Protocol) connects agents to tools, data, and external systems. I wrote about MCP in a previous post. In the multi-agent context, MCP is how your specialist agents access external data. The Order Status agent uses MCP to call your ERP's API. The Knowledge agent uses MCP to search your Confluence instance. MCP gives agents hands to reach into systems outside Salesforce.
A2A (Agent-to-Agent) is the protocol for agent-to-agent communication. When your Orchestrator needs to delegate to a specialist in another org or on another platform, A2A handles the handshake. Identity, permissions, conversation context, task delegation. Think of MCP as "agent talks to system" and A2A as "agent talks to agent."
Both protocols are open standards now. The integration patterns you build today should work across platforms as adoption spreads. That's a bet worth making.
What Will Bite You
Topic collision. If two specialist agents have overlapping domains, the Orchestrator will sometimes route to the wrong one. Be explicit about boundaries. If your Order agent handles order status and your Returns agent handles return requests, make sure the instructions clearly define where "I want to return my order" goes. Test the edge cases. The Atlas engine is good at intent detection but it's not magic. Ambiguous routing instructions produce ambiguous results.
Context window pressure. Each agent in the chain consumes context. The Orchestrator's conversation history, plus the specialist's instructions, plus the retrieved data, plus the actions. It adds up. If your Orchestrator has been in a long conversation and calls a specialist with heavy instructions, you can hit context limits. Keep specialist instructions concise. Use action-based data retrieval instead of stuffing everything into instructions.
Testing is harder. A monolithic agent has one set of test cases. A multi-agent system has test cases for each specialist plus integration test cases for routing. The Agentforce Testing Center helps, but plan for a lot more test coverage than you'd need for a single agent. I typically build a routing test suite that sends 50+ utterances through the Orchestrator and validates which specialist received each one. Boring to set up. Saves you in production.
Latency stacking. Each agent hop adds latency. User talks to Orchestrator (reasoning step), Orchestrator calls specialist (another reasoning step), specialist calls external system via MCP (API call), response flows back up. For real-time chat, this is usually fine. We're talking seconds, not minutes. But if you chain three or four specialists together, the response time can feel sluggish. Monitor it. If a flow takes more than 8-10 seconds, users notice.
Observability gaps. When something goes wrong in a multi-agent system, you need to trace the full path: which specialist was called, what data was retrieved, what reasoning was applied. Out of the box, Agentforce gives you conversation logs. For production debugging, push execution data to Data Cloud (now Data 360) for analysis. Set up logging on your Orchestrator's routing decisions so you can audit which specialist handled which request and why.
Where to Start
If you have a monolithic Agentforce agent that's getting unwieldy, here's the move:
Pull up your topic list. Identify the two most distinct clusters. Topics that never need to reference each other. Those become your first two specialists. Build an Orchestrator with instructions that route based on intent. Keep the Orchestrator's actions simple: detect intent, call the right specialist, return the response.
Test with real customer utterances. Not the clean ones from your test plan. The messy ones from actual conversations. "Hey I need to check on my order and also I think I was overcharged last month." That's where routing logic gets real.
Get the two-specialist version working in a sandbox. Then evaluate whether you need more specialists or whether two is enough. For most orgs, three to five specialist agents covers the full scope of customer-facing work. If you're building more than that, you're probably splitting too fine.
Multi-agent orchestration isn't complicated as a concept. Same idea as microservices: break a monolith into focused components with clear interfaces. The real work is getting the boundaries right and testing the routing. Get that right and everything else follows.
If you want help designing a multi-agent architecture for your org, let's talk.