MuleSoft's A2A bridge: Agentforce agents join multi-agent workflows
MuleSoft now lets Agentforce agents take part in A2A workflows without code changes. What the bridge does, why it matters and what to ask before relying on it.
A week after launching Agent Fabric at Dreamforce, MuleSoft has shipped one of the pieces that makes the idea practical. On 23 September it announced an A2A bridge that lets existing Salesforce Agentforce agents take part in multi-agent workflows built on the Agent2Agent protocol, without rewriting them.
It is a small announcement on the surface. Underneath, it says a lot about where integration platforms are heading: from connecting systems to connecting agents.
What MuleSoft launched
A2A (Agent2Agent) is an open protocol for agents to discover each other, hand over tasks and report back. Google launched it in April 2025, and it has been a Linux Foundation project since June 2025. In April 2026 the foundation reported more than 150 supporting organisations, a stable 1.0 specification and support in Microsoft’s, AWS’s and Google’s agent platforms.
The problem is that most agents running in companies today were not built for A2A. Agentforce agents speak Salesforce’s own Agentforce API. MuleSoft’s answer is a bridge that runs as a policy in Omni Gateway. According to MuleSoft, it:
- translates between A2A and the Agentforce API,
- generates an A2A Agent Card that describes what each agent can actually do,
- maps identifiers and handles the A2A task lifecycle, so the Agentforce agent behaves like a full A2A participant,
- handles authentication, including OAuth 2.0 on behalf of the user.
The same policies apply to bridged agents and native A2A agents: authentication, PII detection, schema validation, rate limiting, audit logging and end-to-end tracing. Setup is done through the Agent Fabric interface. MuleSoft says a similar bridge for Microsoft Copilot Studio is on the way.
Why it matters
Most large organisations will end up with agents on several platforms: Salesforce, Microsoft, ServiceNow, cloud providers and their own code. Those agents need to work together, and every direct, custom connection between two agents is a new integration to build, secure and maintain.
That is a familiar problem. It is the point-to-point integration problem from twenty years ago, with agents instead of applications. The answer then was a common layer with standard protocols, central policies and one place to see what happens. The A2A bridge is MuleSoft applying the same pattern to agents: A2A as the common protocol, Omni Gateway as the enforcement point, Agent Fabric as the place to see it all.
There is also a quieter point. A bridge that makes agents look standard from the outside lowers the cost of not consolidating on one agent platform. That suits MuleSoft, whose business is sitting between systems from many vendors.
How it compares
A2A and MCP are often mentioned together, but they solve different problems. MCP connects an agent to tools and data. A2A connects agents to other agents. Integration platforms are now adding both.
MuleSoft is early with a bridge for a specific agent platform, but it will not be alone. The big cloud providers already support A2A natively, and the other iPaaS vendors are building agent registries and gateways that could take the same step. The difference will be in the details: which agent platforms are covered, how identity is carried from agent to agent, and how well the bridge reflects what the underlying agent can really do.
What to ask before relying on it
If you run Agentforce and are planning multi-agent workflows, a few questions are worth asking:
- Identity: When one agent asks another to act, whose permissions apply? Check how the on-behalf-of flow works end to end.
- Accuracy of Agent Cards: A generated Agent Card is only as good as the agent behind it. Test that the capabilities it advertises are the ones the agent can deliver.
- Tracing across platforms: Can you follow one request through every agent involved, including those outside Salesforce?
- Failure handling: What happens when an agent in the chain times out or gives a poor answer? A2A defines task states, but the business logic for retries and fallbacks is still yours.
- Lock-in: The protocol is open, but the bridge and the policies live in MuleSoft. That can be a good trade, as long as it is a conscious one.
A2A is still young in production. MuleSoft’s bridge is a sign that the integration layer for agents is taking shape, and that the platforms that already sit between your systems want to be the ones that sit between your agents too. This builds on MuleSoft’s Agent Fabric launch at Dreamforce.
Sources
This post was written with AI assistance and reviewed by the editor before publishing.