diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 39ec1cab6..fa702d218 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -12,6 +12,7 @@ *** xref:exp-services-connect-providers-to-add.adoc[] *** xref:exp-services-register-manually.adoc[] *** xref:exp-services-create-mcp-server.adoc[] + *** xref:exp-services-create-a2a-bridge.adoc[] *** xref:exp-instances-add.adoc[] *** xref:exp-services-view-details.adoc[] ** xref:exp-playground-overview.adoc[] diff --git a/modules/ROOT/pages/agent-fabric-overview.adoc b/modules/ROOT/pages/agent-fabric-overview.adoc index dba744905..8f244d1f5 100644 --- a/modules/ROOT/pages/agent-fabric-overview.adoc +++ b/modules/ROOT/pages/agent-fabric-overview.adoc @@ -78,6 +78,22 @@ Before agents can orchestrate across your enterprise, your existing systems need * When you need it: Use MCP Connector when you need to expose capabilities to agents that require custom logic, multi-system composition, orchestration with external MCP services, or transformation that configuration-based tools like MCP Bridge don’t cover. * Learn more: xref:mcp-connector::index.adoc[MCP Connector] +=== A2A Bridge + +* What it is: An A2A bridge is a gateway policy that presents an A2A-compliant facade in front of an existing non-A2A agent (the source agent), translating between the A2A protocol and the agent's native protocol without modifying the source agent. Agent Fabric derives an A2A card from the source agent, publishes it to your Portfolio, and deploys the bridge instance from a single wizard. + +* Role in Agent Fabric: Agent Fabric can only orchestrate A2A-compliant agents, but many enterprise agents—such as Salesforce Agentforce agents—aren't A2A-compliant on their own. A2A Bridge closes the gap between what your scanners can discover and what Agent Fabric can orchestrate, making non-A2A agents first-class participants in your agent network through configuration alone. + +* What you can do: +** Make a non-A2A source agent A2A-compliant without rebuilding it +** Customize the advertised A2A card and skills before publishing +** Deploy the bridge instance to a managed or self-managed Omni Gateway with inbound and upstream authentication +** Discover, govern, monitor, and orchestrate the bridged agent like any native A2A agent + +* When you need it: Use A2A Bridge when you have agents on platforms that aren't yet A2A-compliant (such as Agentforce) and you need Agent Fabric to orchestrate them now. Use A2A Connector instead when you need custom Mule application logic or want to bridge a platform that isn't natively supported. + +* Learn more: xref:exp-services-create-a2a-bridge.adoc[] + === A2A Connector * What it is: Use Anypoint Connector for A2A (A2A Connector) to add A2A protocol support to Mule applications so they can act as both A2A servers and A2A clients. You can also use A2A Connector to make agents built on other platforms A2A-compliant. diff --git a/modules/ROOT/pages/exp-glossary.adoc b/modules/ROOT/pages/exp-glossary.adoc index e6dd52476..0667a945a 100644 --- a/modules/ROOT/pages/exp-glossary.adoc +++ b/modules/ROOT/pages/exp-glossary.adoc @@ -3,6 +3,12 @@ The enhanced MuleSoft experience uses a consistent set of terms across governance, portfolio, instance management, and agentic experiences. Clear definitions help you apply the right concepts when registering assets, configuring strategies, and managing instances. +A2A bridge:: +A gateway policy that presents an A2A-compliant facade in front of a non-A2A _source agent_, translating between the A2A protocol and the agent's native protocol. Create an A2A bridge to make agents built on platforms such as Salesforce Agentforce discoverable, governable, and orchestratable by Agent Fabric. See xref:exp-services-create-a2a-bridge.adoc[]. + +A2A Bridge card:: +The A2A agent card that a bridge publishes. It's derived from the source agent's card plus any capabilities added by the bridge and any customizations you make. Bridge capabilities are set and locked by the platform so the card can't advertise a capability the bridge can't honor. + A2A endpoint:: An endpoint that exposes an agent's capabilities using the Agent-to-Agent (A2A) protocol. Point to an A2A endpoint during agent registration to fetch the agent card automatically. @@ -90,6 +96,9 @@ The native Slack assistant that connects to the MuleSoft Platform MCP Server to Semantic Service:: A service that applies context-aware matching to route LLM-driven requests to the most relevant tools and pathways. It's available at Basic scale (managed internal configuration) or Advanced scale (external embedding API and vector database). +Source agent:: +An existing agent, built on a platform that isn't natively A2A-compliant, that you make A2A-compliant by creating an _A2A bridge_ in front of it. The bridge derives its A2A card from the source agent without modifying the source agent. + Target:: The backend implementation that a gateway proxies traffic to after enforcing policies. Each instance defines a Target URL that points to the live service or runtime. diff --git a/modules/ROOT/pages/exp-services-create-a2a-bridge.adoc b/modules/ROOT/pages/exp-services-create-a2a-bridge.adoc new file mode 100644 index 000000000..c92a2c271 --- /dev/null +++ b/modules/ROOT/pages/exp-services-create-a2a-bridge.adoc @@ -0,0 +1,162 @@ += Creating an A2A Bridge +:keywords: a2a bridge, agent2agent, agentforce bridge, a2a compliant, agent fabric, non-a2a agent, omni gateway, source agent + +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. The bridge is a gateway policy that presents an A2A facade in front of a *source agent*, translating between A2A and the agent's native protocol 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-it-works]] +== 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 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-platforms]] +== Supported Source Platforms + +[cols="1,1,2a", options="header"] +|=== +| Source platform | Bridge availability | Notes + +| Salesforce Agentforce +| Available +| Bridge translates A2A to the Agentforce Einstein AI Agent v1 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 xref:exp-services-register-manually.adoc[]. + +| Other platforms +| Extensible +| Build a custom bridge policy with the Policy Development Kit (PDK), or use xref:a2a-connector::index.adoc[A2A Connector]. +|=== + +[[before-you-begin]] +== 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 xref:exp-home-start.adoc#permissions[Enhanced Experience 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-a2a-bridge]] +== Create an A2A Bridge + +You create a bridge from the source agent's detail page. + +. In *Portfolio*, open the *Agents* catalog and select the source agent you want to bridge. +. On the *Overview* tab, select *Configure A2A bridge & deploy first instance*. +. 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. +. Add custom skills or hide skills as needed. Each skill must have a unique ID. +. Click *Continue: Deploy instance*. +. 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. +-- +. 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. Select *None* to leave the endpoint unauthenticated. +. 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. +. Expand *Advanced* to review or adjust the generated policy configuration. +. 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 select *Customize card*. Editing the card creates a new bridge version that instances can adopt. + +[[update-instance]] +== 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, select *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. + +Select *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]] +== 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. + +* *Deployment* — Deploy A2A bridges to managed or self-managed Omni Gateway instances. +* *Transport* — Bridges expose a single A2A JSON-RPC interface. The derived card advertises this interface in its `supportedInterfaces`; other A2A transports aren't advertised. +* *Governance scope* — A bridge governs only traffic that flows through the Omni Gateway. Direct platform-to-platform traffic that bypasses the gateway isn't governed. + +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. +* *Session lifecycle* — The bridge creates and manages Agentforce sessions automatically. Sessions time out on the Agentforce side; you don't manage them directly. + +[[migration]] +== Migrate to Native A2A + +The A2A bridge is designed to be superseded. When a source platform adds native A2A support, disable the bridge policy 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 + +* xref:agent-fabric-overview.adoc[Agent Fabric Overview] +* xref:exp-services-create-mcp-server.adoc[Create MCP Servers] +* xref:exp-services-register-manually.adoc[Register a Service Manually] +* xref:exp-services-view-details.adoc[View Service Details] +* xref:a2a-connector::index.adoc[A2A Connector] diff --git a/modules/ROOT/pages/learning-map-agent-fabric.adoc b/modules/ROOT/pages/learning-map-agent-fabric.adoc index 6b5de33e8..e6a760bbb 100644 --- a/modules/ROOT/pages/learning-map-agent-fabric.adoc +++ b/modules/ROOT/pages/learning-map-agent-fabric.adoc @@ -40,6 +40,7 @@ Use Anypoint Exchange to discover agentic assets for reuse across your enterpris - xref:exchange::to-create-an-asset.adoc#create-agent[Create and Publish an Agent in Exchange] - xref:exp-services-create-mcp-server.adoc[Create an MCP Server] - https://videos.mulesoft.com/watch/Dn9QXJKDzTxSJPNgra9LoM[Watch a Video to Learn About MCP Bridge] +- xref:exp-services-create-a2a-bridge.adoc[Create an A2A Bridge for a Non-A2A Agent] - xref:exchange::to-create-an-asset.adoc#create-llm[Create and Publish an LLM in Exchange] | image::lm_build_1.png[""]