Learn about Agentforce SOMA(Single Org, Multi Agent) Orchestration

What is SOMA?

Single-Org Multi-Agent (SOMA) empowers multiple Agentforce agents to seamlessly collaborate within a single org. Instead of forcing users to manage conversations with different agents individually, SOMA provides one unified conversational touchpoint. Behind the scenes, a primary orchestrator agent intelligently coordinates and delegates tasks to specialized agents, ensuring each task is handled by the agent best equipped for it.

This feature is currently in Pilot, with a Beta planned for April, and an estimated GA of June '26. Further details will be shared as SOMA progresses.

Why use SOMA?

While hybrid reasoning gives us excellent cross-topic reasoning within a single agent (or across its internal nano-agents/topics), there is still an important nuance: the cognitive span of any one agent is limited.

Note: In practice, once an agent is responsible for more than ~8–10 well scoped topics/nano agents, it starts carrying too much concurrent intent. This increases reasoning load and leads to drift, confusion, or hallucination. Hybrid reasoning solves drop-off and provides deterministic control through the graph runtime, but it doesn’t remove the natural limits of how much parallel intent a single agent can reliably handle. A single agent even with hybrid reasoning cannot scale infinitely. Across all major LLM vendors, performance degrades when an agent is overloaded with unrelated domains (“topics” or “nano-agents”). Multi Agent Orchestration becomes essential when use cases introduce topic/nano agent overload, cross-org boundaries, or a concierge-style front door interaction model.

Whats the difference between SOMA, MOMA, A2A, and MCP?

The Big Picture

At a high level, these five concepts map to two dimensions:

Protocols (the "language" agents speak): MCP, A2A
Architectures (how agents are organized): SOMA, MOMA
Governance (the control plane): Agent Gateway

Think of SOMA and MOMA as where agents live, MCP and A2A as how they talk, and Agent Gateway as the gatekeeper that governs all of it.

MCP — Model Context Protocol

What it is: An open, vendor-neutral standard (originally created by Anthropic) that defines how AI agents connect to external tools, data sources, and APIs.
How it works: Follows a client-server model:

An MCP Server exposes tools, resources, and prompts
The Agentforce MCP Client connects to the server, and the LLM picks the right tool via natural language
Register an MCP server in Setup → all its tools auto-appear as invocable actions in Agent Builder

In Agentforce terms: MCP gives agents a standardized way to call external capabilities without custom code. It's often described as the "USB port for AI agents."
Status: MCP Client reached GA at TDX (April 2026). Agent Gateway MCP Governance reached GA in Spring '26 (Release 260).

A2A — Agent-to-Agent Protocol

What it is: An open protocol for agent-to-agent communication, enabling agents from different vendors or platforms to discover, invoke, and collaborate with each other. Salesforce was a founding member alongside Google, Microsoft, SAP, and AWS.
How it works: Agents publish Agent Cards (a machine-readable description of their capabilities). Other agents discover these cards, then communicate using LLM-native, unstructured dialogue over OAuth 2.0 and HTTP/JSON.
Two patterns:

Inbound (Client Agent): A 3rd-party agent (e.g., Microsoft Copilot Studio, Google agent) delegates a task to an Agentforce agent
Outbound (Server Agent): An Agentforce agent calls out to a 3rd-party agent

Real-world example: Moody's uses Microsoft Copilot Studio as the orchestrator, routing to Agentforce's Sales Recon agent as a specialty delegate.
Status: A2A Inbound Pilot launched March 2026. MOMA on A2A targeted for June 2026.

Agent Gateway

What it is: The native governance and control layer, within Agentforce Studio, for all agent interactions in Agentforce — both MCP and A2A. Often described as an "agentic drawbridge."
What it does:

MCP Server Registry: Unified registry for all MCP servers (MuleSoft, Heroku, external) with centralized visibility
Per-Agent Policy Enforcement: Industry-first granular, per-agent policy enforcement for MCP servers
Security Controls: JWT/OAuth auth, rate limiting, quota management, ABAC (attribute-based access control)
Schema Validation: Validates MCP and A2A message structures
Observability: Session-level traces logged to Data Cloud; policy outcomes visible in Agent Studio analytics
Rug-pull Detection: Blocks MCP servers that change tool descriptions after registration
Trust Layer Integration: Prompt injection scanning via Einstein Trust Layer

Zero-code administration: Policies are configured through UI — no custom code required.
Status: GA in Spring '26 (Release 260). A2A governance for SOMA interactions included in GA scope.

SOMA — Single-Org Multi-Agent

What it is: A multi-agent architecture where multiple Agentforce agents collaborate within the same Salesforce org.
How it works:

A Superagent (Parent Planner) owns the conversation with the end user
It delegates tasks to specialist/child agents based on topic or capability
All agents live in the same org — no cross-org trust complexity
Uses the Agent Graph model and GenAiPlannerDefinition to define parent-child relationships

Use case example: A student asks one agent about MBA programs, then transitions to parking questions — a single SOMA setup routes seamlessly between a WP Carey agent and a Parking agent, all in one session.
Key benefit: Users talk to one agent; behind the scenes, specialized agents handle domain-specific work — all within the same trust boundary.

MOMA — Multi-Org Multi-Agent

What it is: The natural evolution of SOMA — the same orchestration model, but extended across different Salesforce orgs (within the same Data Cloud DC1 trust boundary).
How it works:

A single Superagent in one org owns the conversation
It delegates to specialist agents in other orgs
Delivers one unified answer — no org-switching, no re-auth, no lost context
Agent relationships are explicitly defined; trust is enforced at both org and agent level
No agent can act outside its trust boundary or elevate privileges beyond the initiating user

Use case example: A large enterprise (e.g., CVS, ADP) running multiple Salesforce orgs can unify their agent experience without consolidating their entire data model.

In Short:

Start with SOMA when all your agents are in one org
Graduate to MOMA when you have multiple Salesforce orgs that need to collaborate
Use A2A to interoperate with agents on Google, Microsoft, or any A2A-compliant platform
Use MCP anytime an agent needs to call an external tool or API (regardless of SOMA/MOMA/A2A)
Agent Gateway governs all of the above