--- schema_version: "1" id: 2ea48a9f274a44cf256589d7d190edb2f56a5ea29e53fc4d147419549eb57c41 title: Make an Agent A2A-Compliant collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/general/exp-services-create-a2a-bridge.md canonical_url: https://docs.mulesoft.com/general/exp-services-create-a2a-bridge source_site: docs.mulesoft.com content_type: documentation content_hash: a1c80c1141571a7f091edb8d769afbe1bf610986db5bac500ede9de43c5432c4 description: MuleSoft Documentation Site latest: true --- --- product: Getting Started keywords: a2a bridge, agent2agent, agentforce bridge, a2a compliant, agent fabric, non-a2a agent, omni gateway, source agent --- # Make an Agent A2A-Compliant > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Create an A2A bridge to make a non-A2A agent A2A-compliant so that Agent Fabric can discover, govern, and orchestrate it alongside native A2A agents. Agent Fabric orchestrates agents using the Agent2Agent (A2A) protocol, but many enterprise agents—such as Salesforce Agentforce agents—aren’t A2A-compliant on their own. An A2A bridge closes this gap. A bridge is a chain of policies—inbound authentication plus the bridge policies—that runs on an Omni Gateway instance and presents an A2A-compliant facade in front of a **source agent**. More than a protocol translator, the bridge is an A2A-compliant protocol server: it translates between A2A and the source agent’s native protocol, manages the task lifecycle, and serves A2A task management methods so downstream consumers see a fully A2A-compliant agent. No changes to the source agent are required. When you create an A2A bridge, Agent Fabric derives an A2A agent card from the source agent, publishes it to your **Portfolio**, and deploys the first bridge instance—in a single wizard. During creation, you define: - **A2A card** The advertised name, description, and skills the bridge exposes to other agents for discovery and routing. Capabilities are set and validated by the platform. - **Deployment** The environment, Omni Gateway, base path, and consumer endpoint where the bridge instance runs. - **Inbound authentication** How A2A clients authenticate to the bridge. - **Upstream authentication** How the bridge authenticates to the source agent. ## How an A2A Bridge Works A source agent is an existing agent, built on a platform that isn’t natively A2A-compliant, that you want to bring into your agent network. The bridge sits between A2A clients and the source agent as an A2A-compliant protocol server and handles: - **Protocol translation** — Converts A2A requests into the source platform’s native API calls and maps native responses back to A2A task states. - **Identity and task mapping** — Maps the source platform’s session or conversation identifiers to A2A `contextId` and `taskId` values. - **Task lifecycle and state** — Tracks task state so A2A operations such as `GetTask`, `ListTasks`, and `CancelTask` return correct results. - **A2A card derivation** — Generates an A2A v1 agent card that accurately reflects the capabilities the bridge can honor. The bridge card is derived from the source agent’s card, plus any capabilities added by the bridge and any customizations you make. The card advertises the bridge’s A2A endpoint as a JSON-RPC interface in its `supportedInterfaces` and locks platform-set capabilities such as streaming and the human-in-the-loop extension. Because the bridge is always A2A-compliant, A2A clients consume a bridged agent with no custom logic. If the source platform later adds native A2A support, you can disable the bridge and clients continue to work without changes. ## Supported Source Platforms
Source platformBridge availabilityNotes

Salesforce Agentforce

Available

Bridge translates A2A to the Agentforce Agent API. Supports streaming and human-in-the-loop.

Microsoft Copilot Studio

Planned

Roadmap. Copilot’s activity-based Direct Line API requires heuristic task-lifecycle handling.

Amazon Bedrock AgentCore, Google Vertex AI

Not required

These platforms are natively A2A-compliant. Register them directly rather than bridging. See Register Services Manually.

Other platforms

Extensible

Build a custom bridge policy with the Policy Development Kit (PDK), or use A2A Connector.

## Before You Begin Before getting started, make sure you have: - An Anypoint Platform account. - A source agent registered in your **Portfolio** that isn’t already A2A-compliant. - One of these Exchange permissions: - Exchange: Exchange Contributor - Exchange: Exchange Administrator - Exchange: Exchange Creator - This API Manager permission on the target environment: - API Manager: Manage APIs Configuration For more information, see [Enhanced Experience Permissions](https://docs.mulesoft.com/general/exp-home-start#permissions). - A managed or self-managed Omni Gateway in the target environment. - Credentials for the source agent’s platform, such as the Salesforce org URL, OAuth token URL, client ID, and client secret for an Agentforce source agent. ## Create an A2A Bridge You create a bridge from the source agent’s detail page. 1. In **Portfolio**, open the **Agents** catalog and select the source agent you want to bridge. 2. On the **Overview** tab, select **Configure A2A Bridge & Deploy First Instance**. 3. In **Customize Card**, review and edit the **Skills** on the A2A card the bridge will publish. Skills describe what the agent can do so other agents can discover and route to it. 4. Add custom skills or hide skills as needed. Each skill must have a unique ID. 5. Click **Continue: Deploy Instance**. 6. In **Deploy Instance**, configure where and how the first bridge instance runs: - **Environment** — Select the target environment. - **Omni Gateway** — Select the managed or self-managed gateway that hosts the bridge. - **Instance URL** — Enter the path segment for the bridge’s A2A endpoint. Agent Fabric checks for route conflicts against existing instances on the gateway. - **Consumer Endpoint** — Optionally override the gateway ingress URL used to build the instance URL. 7. Configure **Inbound Authentication** to control how A2A clients authenticate to the bridge. Select a method such as **JWT Validation**, **Basic Authentication**, or **Client ID Enforcement**, then provide the required values. 8. Configure **Upstream Authentication** to control how the bridge authenticates to the source agent. For an Agentforce source agent, provide the **Salesforce Org URL**, **Token URL**, **Grant Type**, **Client ID**, and **Client Secret**. Source-derived values such as the tenant endpoint are read-only. 9. Expand **Advanced** to review or adjust the generated policy configuration. 10. Complete the wizard. Finishing publishes the A2A card and deploys the bridge instance together. After the bridge is created, the derived A2A agent card is published to the **Agents** catalog in your **Portfolio**, where it can be discovered, governed, monitored, and orchestrated like any other A2A agent. On the bridged agent’s **Overview** tab, Agent Fabric shows two cards side by side: - **A2A Bridge card** — The advertised name, description, version, protocol, capabilities, and skills the bridge publishes to other agents. Capabilities such as streaming, push notifications, state transition history, and extensions are set by the platform and locked to prevent the bridge from advertising a capability it can’t honor. Skills are flagged as **Custom** when you added them or **Hidden** when you excluded them from discovery. - **Source card** — The name, description, and metadata of the underlying non-A2A source agent that the bridge card is derived from. To scale a bridge across environments or gateways, deploy additional instances from the **Instances** tab using **Create A2A Bridge Instance**. To change the advertised card content—skills, advertised name, and description—open the agent’s **Overview** tab and click **Customize Card**. Editing the card creates a new bridge version that instances can adopt. ## Update an A2A Bridge Instance Each bridge instance is pinned to a specific bridge version. The instance’s **Overview** tab shows a **Deployment** section with: - **Serving A2A Bridge Version** — The bridge version this instance runs. The version fixes the instance’s advertised card (skills, name, and description) along with its authentication and advanced settings. If a newer version exists, Agent Fabric shows that a newer A2A bridge version is available. - **Consumer Endpoint** — The URL where the instance receives A2A requests. - **Discovery URL** — The well-known A2A agent card endpoint (`.well-known/agent-card.json`) that callers fetch to discover the agent. To change an instance’s configuration, click **Update Instance** to open the **Update A2A Instance** dialog, then adjust any of these: - **Inbound Authentication** — How other agents authenticate when they call this instance. - **Upstream Authentication** — How the instance’s bridge authenticates to the source agent. Leave a masked secret unchanged to keep the stored value, or enter a new value to rotate it. - **Advanced** — The generated policy configuration, such as the request timeout. - **Version** — If a newer bridge version is available, adopt it to update the instance’s advertised card and settings to that version. Click **Save Changes** to redeploy the instance with the updated configuration. Updating an instance doesn’t republish the bridge card; edit card content from the agent’s **Overview** tab with **Customize Card**. ## Known Limitations A2A bridge behavior is constrained by what the source platform’s API supports. Review the limitations for your source platform before you rely on a bridge in production. - **Transport** — Bridges expose a single A2A JSON-RPC interface. The derived card advertises this interface in its `supportedInterfaces`; other A2A transports aren’t advertised. - **Task state durability** — Task lifecycle state is held in gateway memory and doesn’t survive an Omni Gateway restart. After a restart, A2A operations such as `GetTask` and `ListTasks` can’t return state for tasks created before the restart. Agentforce source agents have these additional limitations, which the derived agent card reflects: - **No asynchronous tasks** — Agentforce responds synchronously. Long-running tasks that exceed the gateway timeout fail. Use Agentforce agents for real-time, low-latency tasks, and orchestrate long-running work through a broker. - **No task subscription** — A2A resubscription isn’t available. Streaming must be consumed on a single in-band connection. - **No push notifications** — The Agentforce API doesn’t support push notifications. - **Limited input-required support** — Not all Agentforce agent types support the A2A `input-required` state, so some bridged agents can’t pause a task to request additional input for human-in-the-loop interactions. - **Session lifecycle** — The bridge creates and manages Agentforce sessions automatically. Sessions time out on the Agentforce side; you don’t manage them directly. ## Migrate to Native A2A The A2A bridge is designed to be superseded. When a source platform adds native A2A support, disable the bridge and point consumers at the platform’s native A2A endpoint. Because clients already consume the agent through the A2A protocol, no client changes are required. ## See Also - [Agent Fabric Overview](https://docs.mulesoft.com/general/agent-fabric-overview) - [Create MCP Servers with MCP Bridge](https://docs.mulesoft.com/general/exp-services-create-mcp-server) - [Register Services Manually](https://docs.mulesoft.com/general/exp-services-register-manually) - [Viewing Service Details in the Portfolio](https://docs.mulesoft.com/general/exp-services-view-details) - [A2A Connector 2.0](https://docs.mulesoft.com/a2a-connector/latest/)