Agent Interoperability in Salesforce: A2A, MCP, and Building Agents That Talk to Anything

For two years the AI agent market looked like a set of walled gardens. Salesforce agents talked to Salesforce, Microsoft agents talked to Microsoft, and connecting across them meant custom integration glue that broke every time a vendor shipped an update. That model is ending, and the signal is hard to ignore: in 2026 the Agent2Agent protocol moved under the Linux Foundation, which means agent-to-agent communication is being treated as shared infrastructure, not any one vendor's feature.

For Salesforce architects, this changes how you should design agents today. This post explains the two standards that matter (A2A and MCP), how Agentforce 3 and MuleSoft support them, and what to build now so your agents can participate in a multi-vendor ecosystem instead of becoming the integration debt of 2027.

Two Standards, Two Different Jobs

The interoperability conversation gets confusing because people use A2A and MCP interchangeably. They solve different problems, and you will likely use both.

Model Context Protocol (MCP) connects an agent to tools and data. It is the standard way for an agent to call an external capability, query a system, run a function, or retrieve a document, through a consistent interface instead of a bespoke integration per tool. Think of MCP as how an agent reaches outward to the things it needs.

Agent2Agent (A2A) connects an agent to other agents. It lets agents from different platforms discover each other, exchange tasks, and collaborate securely. Think of A2A as how agents talk to peers, including peers built on entirely different stacks.

A concrete example: a Salesforce service agent uses MCP to pull a shipment status from an external logistics system (agent-to-tool), then uses A2A to hand a refund authorization task to a finance agent running on a different platform (agent-to-agent). One workflow, both standards, no custom glue.

How Agentforce Supports Them

The important news for Salesforce teams is that you do not have to bolt these standards on. Agentforce 3 ships built-in support for both MCP and A2A. That native support is what turns interoperability from a research project into a configuration decision.

Three pieces of the Salesforce stack carry this:

Agentforce 3. Built-in MCP and A2A support, plus an enhanced Atlas architecture that Salesforce describes as lower latency, higher accuracy, and more resilient, with support for natively hosted LLMs such as Anthropic Claude. The interoperability standards sit on top of that foundation.

MuleSoft Agent Fabric. This is the orchestration and governance layer. It adds support for MCP and A2A and includes Agent Scanners that automatically discover agents and tools across major environments, including Salesforce Agentforce, Amazon Bedrock, Google Cloud's Vertex AI, and Microsoft Copilot Studio. Those scanners went generally available in January 2026. For an architect, automated discovery is the difference between knowing what agents exist in your estate and finding out the hard way.

AgentExchange. The marketplace now hosts MCP servers from more than 30 partners, including AWS, Google Cloud, and IBM. Rather than building every external connection yourself, you can adopt a published MCP server for a common system.

Verify in your org: Native A2A and MCP support depends on your Agentforce version and licensing, and the specific MuleSoft capabilities you have entitlement to. Confirm against the official Agent2Agent Protocol page and your MuleSoft entitlements before designing around them.

Why "Under the Linux Foundation" Is the Real Headline

It is easy to skim past the governance detail, but it is the most strategically important fact here. When a protocol like A2A is stewarded by a neutral open-source foundation rather than owned by a single vendor, three things follow.

First, no single company can quietly close it later to lock you in. The incentive that produced walled gardens is structurally weakened.

Second, competitors adopt it without fear. A protocol owned by Salesforce would make Microsoft hesitate to support it, and vice versa. A neutral protocol gets adopted across the board, which is what makes it actually useful.

Third, it signals durability. Vendors invest in standards they expect to last. Linux Foundation stewardship is a bet that A2A is infrastructure for the long term, which makes designing around it a safer architectural choice than betting on any proprietary interconnect.

This is why the open-standards move matters more than any single feature release. It changes the default assumption from "agents are locked to their platform" to "agents interoperate unless you choose otherwise."

What Architects Should Build Now

You do not need a multi-vendor deployment today to benefit. You need to design as if one is coming, because the cost of retrofitting interoperability is far higher than building for it. Practical guidance:

1. Describe agent capabilities cleanly. A2A relies on agents advertising what they can do. The clearer and more granular your agent's capability definitions, the more useful it is as a peer in cross-platform orchestration. Vague, monolithic agents do not compose well.
2. Prefer MCP servers over custom integrations. When you need an external tool or data source, check AgentExchange for a published MCP server before writing bespoke integration code. Standard connections survive vendor updates; custom glue does not.
3. Plan for discovery and governance. If you expect agents across Agentforce, Bedrock, Vertex AI, or Copilot Studio, MuleSoft Agent Fabric's scanners give you a single place to discover and govern them. Design your estate assuming you will need that visibility, not assuming you will track agents in a spreadsheet.
4. Keep humans and audit in the loop across boundaries. When a Salesforce agent hands a task to an external agent via A2A, your audit and escalation requirements do not disappear. Define where human approval is mandatory before tasks cross a platform boundary, not after.

The architects who win the next two years are the ones treating interoperability as a design constraint now, the same way they already treat security and data residency.

Who Should Care

Architects and platform engineers own this directly. Native A2A and MCP support means your design choices today determine whether your agents compose into a larger system or become isolated. Build for the multi-vendor case.

Senior developers should get familiar with MCP first. It is the standard you will touch most often, because most agent work involves connecting to tools and data, and adopting published MCP servers will save you the most integration time.

IT and program leaders should care about governance and discovery. As agents proliferate across platforms, the risk is not capability, it is losing track of what exists and who approved it. MuleSoft Agent Fabric's discovery is the control that addresses it.

The Bottom Line

Agent interoperability stopped being a future concern in 2026. A2A moved under the Linux Foundation, Agentforce 3 supports both A2A and MCP natively, MuleSoft Agent Fabric discovers and governs agents across Salesforce, Bedrock, Vertex AI, and Copilot Studio, and AgentExchange hosts MCP servers from 30+ partners. The walled-garden era is closing.

The practical takeaway is simple: design your Salesforce agents to be good citizens of a multi-vendor ecosystem now. Describe their capabilities cleanly, prefer standard MCP connections over custom glue, and plan for cross-platform discovery and governance. The standards are in place. The only question is whether your agents are built to use them.

To see how this fits the broader multi-agent architecture pattern inside Salesforce, read Designing Multi-Agent Systems in Agentforce.

---

Keep Reading

• Designing Multi-Agent Systems in Agentforce: Architecture Patterns for Enterprise
• How the Atlas Reasoning Engine Powers Agentforce
• OpenAI vs Claude vs Gemini for Salesforce: Which LLM Should Power Your CRM?

Protocol support, version capabilities, and partner counts are based on Salesforce and ecosystem reporting current as of June 2026 and depend on your Agentforce and MuleSoft licensing. Confirm specifics against official documentation before designing around them.