The Architect’s Guide to Agentforce Interoperability

Authored By: The Agentforce Product Team (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

Read on to learn more about defining your approach to interoperability.
Then download Part 2 as your reference guide while building. 

Before designing multi-agent systems, it’s important to understand how a single agent operates. An Agentforce agent is composed of Subagents (formerly called Topics), modular building blocks scoped to specific domains, each with defined Actions (e.g., Flow, Apex, Prompts).

Every Agentforce agent runs its own LLM reasoning loop, orchestrating how tasks are delegated across Subagents and how responses are formed until the goal is achieved. The Agentforce Reasoning Engine extends this loop with Agent Script-based determinism, adding explicit transitions and sequencing across Subagents, ensuring predictable and controllable behavior instead of relying solely on LLM decisions. This combination of LLM reasoning and deterministic scripting is what enables business workflows. A single agent can handle a lot, but as complexity grows, it hits these walls:

• Data boundary limits: Data, workflows, and permissions living in different Salesforce orgs or systems cannot be accessed. This is an architectural wall a single-agent design cannot cross.
• Context overload: The LLM reasoning engine’s context is filled with instructions, action outputs, and conversation history until it starts ignoring core rules or conflating topics.
• Domain specialization collapse: An agent trying to be an expert in everything applies the wrong logic to invoke specific Subagents. The larger the instruction block, the worse the precision.

Decision Framework: Use single agents when your business process is relatively straightforward, operates within a single domain, and requires a unified set of data access across its Subagents.

SOMA (Single-Org, Multi-Agent) orchestration enables multiple specialized Agentforce agents to work together seamlessly within a single Salesforce org. Instead of forcing users to manage conversations with different agents individually, SOMA provides one unified conversational front door agent. Behind the scenes, a “Superagent” or “Orchestrator” agent intelligently coordinates and delegates tasks to specialized agents, ensuring each task is handled by the agent best equipped for it.

Decision Framework: Use SOMA when your customers want a unified “front door” experience for specialized agents operating within a single Salesforce (org) environment.

• Pros: Simplifies the user experience by providing one conversational entry point for multiple specialized agents.
• Cons: Limited to the data and workflows available within a single Salesforce organization.

MOMA (Multi-Org Multi-Agent) orchestration, as the logical evolution of the single-org (SOMA) model, allows multiple Salesforce organizations to provide a unified agent experience without the need for complex data consolidation. This architecture is built on a philosophy of intentional delegation instead of an open network and enforces an intentional one level deep constraint (Agent A>Agent B, not Agent A->B->C) to prevent unpredictable chaining. Security is maintained through user identity-aware execution and operating within a Data 360 One (DC1) trust boundary.

Decision Framework: Use MOMA when your native Agentforce network needs to securely delegate tasks across different Salesforce orgs without consolidating data models.

• Pros: Delivers a unified agent experience across complex enterprise landscapes while maintaining strict data residency.
• Cons: Mapping user identity across multiple orgs and sharing context across orgs can be challenging.

The Model Context Protocol (MCP) Client allows Agentforce admins to register external MCP servers so builders can integrate remote tools, resources, and actions inside Agentforce in a standardized way. This allows Agentforce to consume external capabilities through a tool contract rather than through bespoke point-to-point integrations.

Decision Framework: Use MCP Client when Agentforce should remain the primary orchestrator and simply needs access to external capabilities as tools. For example, pulling data from an external system, invoking a workflow, searching a knowledge source, or taking action through a third-party platform.

Use the MCP Client when Agentforce should consume an external capability as a tool.

• Pros: Turns external services into secure, governable tools for Agentforce without custom code; includes safety features like semantic integrity checks (anti-rug pull) and risk scoring to prevent tool poisoning. It keeps the reasoning loop centered in Agentforce while expanding what Agentforce can do.
• Cons: The abstraction is intentionally tool-centric. If the remote capability is better modeled as a specialist agent that should own part of the reasoning or workflow, forcing it into MCP can be unnatural. Also, because the schema is defined by the external server, contract changes can cause the integration to fail until refreshed or re-registered.

Agentforce A2A Outbound is the native way for Agentforce agents to collaborate directly with a third party agent. To enable this, admins must first register the external agent by detailing its specific skills, capabilities, and transport protocols. Once registered and connected to an Agentforce agent, it becomes available at runtime for secure, cross-platform task delegation.

Decision Framework: Use Agentforce A2A when your native Agentforce network needs to securely interact with external vendor agents, such as Google or Box. Note: Here one agent needs to delegate work to another agent that owns part of the reasoning, planning, or execution.

• Pros: Because it’s built directly into Agentforce, you don’t need to purchase external orchestration tools to manage these multi-agent workflows. It enables a “unified brand” AI ecosystem to users and uses pre-built expertise from external platforms.
• Cons: Trusting third-party agents and ensuring data privacy across systems can be a challenge. It requires manual registration of the third-party agent’s capabilities and matching authentication standards.

Use this simple rule: The key distinction isn’t whether AI exists on both sides. The key distinction is how the remote capability is modeled:

• If it is modeled as a tool, use MCP
• If it is modeled as a collaborating agent, use A2A

A2A Inbound allows external third-party agents to natively call upon the specialized skills and data of an Agentforce agent. This setup treats Agentforce as a high-value “expert” that can be summoned by outside systems to perform Salesforce-specific actions. By exposing Agentforce capabilities via a secure API endpoint, external platforms can delegate tasks to Salesforce without the user ever leaving their third-party application.

Decision Framework: Use Inbound A2A when your primary AI interface lives in a third-party system (like a custom portal or external bot) but needs to execute complex workflows inside Salesforce.

• Pros: Powers external applications with real-time Salesforce data and automation without duplicating logic.
• Cons: Requires the external system to handle the orchestration and “handoff” logic to ensure a smooth user experience.

Salesforce’s Hosted MCP Server allows Agentforce capabilities to be exposed to external hosts, such as third-party agents, copilots, and LLM platforms through a standardized MCP interface. This lets external platforms invoke Agentforce as a tool provider while Agentforce continues to encapsulate enterprise actions, business logic, and orchestration behind the scenes for complex and specialized tasks.

Decision Framework: Use Agentforce Agents as an MCP Server when an external platform should consume Agentforce as a tool provider. This is especially useful in two scenarios:

• Enterprise agent interoperability: When a third-party enterprise agent, such as Microsoft Copilot, needs to invoke an Agentforce agent because Agentforce contains the enterprise actions needed to complete the task.
• External LLM / channel distribution: When you want branded Agentforce capabilities to be accessible inside external conversational surfaces such as ChatGPT, Gemini, or similar hosts.

In this model, the external platform remains the primary host experience, while Agentforce is intentionally exposed through MCP as a tool endpoint. Even if Agentforce is agentic internally, the interoperability pattern is still MCP because the external relationship is tool invocation rather than peer-agent delegation.

• Pros: Makes it easy to use powerful and specialized Agentforce agents built for your business based on Salesforce data (Billing, Support, etc.) reusable outside Salesforce through a standardized protocol; allows external assistants and enterprise agents to use Agentforce’s orchestration and business actions without rebuilding them; supports both enterprise interoperability and external channel distribution.
• Cons: The external host owns the primary user experience and reasoning loop, so Agentforce has less control over how and when it is invoked. Enterprise scenarios also require strong handling for authentication, authorization, identity propagation, and context passing.

The overview above is just the start, helping you identify which orchestration pattern fits your use case. Continue reading to see how to design and ship it.

Here’s what you’ll learn when you download Part 2: The Multi-Agent Orchestration Reference Guide for Architects:

• Decompose complex processes into agents that stay accountable. Three strategies — by domain expertise, by workflow stage, or by capability — turn one bloated agent into a set of specialists that each do one job well.
• Match your architecture to one of five orchestration patterns. Supervised Mode and Handoff Mode are generally available today. Parallel Execution, Event-Driven Background Agents, and Plan and Present are on the roadmap.
• Choose between LLM-driven and deterministic routing. The Reasoning Engine flexes to open-ended requests. Agent Script gives you deterministic control when a workflow needs a guaranteed sequence. Most multi-agent designs use both.
• Avoid the seven most common anti-patterns. Mesh orchestration, overlapping Subagents, and too many delegation layers are the fastest ways to erode governance and observability at scale.
• Design for what’s supported today. Agent Script’s current constraints (sticky handoff, nested delegation, the seven-connected-subagent limit) shape which patterns you can ship now versus which to plan for next quarter.