Agentforce A2A: which agent owns the dealer conversation?

Agentforce A2A, agent-to-agent calls between vendors, is now real enough that the architecture question shifts to ownership: which agent owns the dealer or service conversation? My answer is the agent of the system where the person logs in and the case lives. Dealers on a Salesforce portal talk to Agentforce, which reads SAP through APIs. Inside one org, multi-agent orchestration is generally available since Winter ’27. Across vendors, MuleSoft’s A2A Bridge works today with clear limits: synchronous only, no push notifications, task state in gateway memory. Native A2A in Agentforce was announced at Dreamforce 2026 without a status.

Why does every vendor now ship its own agent?

A machine builder with Salesforce, SAP and Microsoft 365 gets three agent pitches at once. Salesforce sells Agentforce for service, the dealer portal and sales. SAP’s head of AI described Joule as “an agent orchestrator working across enterprise workflows” in an April 2025 post1, in which SAP also calls itself a founding contributor to the A2A protocol. Microsoft documents how a Copilot Studio agent connects to another agent over A2A2 and can “delegate tasks to another agent, not just call APIs”. Each pitch puts its own agent at the front.

A dealer’s question ignores these boundaries. “Is the seal kit for machine 4711 in stock, and has my warranty claim for that machine been approved?” touches availability in SAP and the claim and asset in Salesforce. If every system’s agent wants to answer, the dealer gets three front doors or a chain of agents asking each other. Both are worse than one agent that owns the conversation and fetches what it needs.

A2A (Agent2Agent) is an open protocol through which agents from different vendors discover each other through an “agent card”, hand over tasks and return results. The difference to MCP matters for the design: MCP connects an agent to tools and data, A2A connects it to another agent that reasons on its own. What MCP means for IT is in MCP explained for IT leads.

What does agent-to-agent interoperability deliver today?

As of 27 October 2026, the status differs by path, and I would plan with the documented one only:

• Inside one Salesforce org: generally available. The Winter ’27 developer guide3 says “Multi-Agent Orchestration is generally available”. An orchestrator agent hands off to specialists in the same org, declared in Agent Script as connected_subagent.
• Agentforce as an A2A server through MuleSoft: available, with limits. The A2A Bridge4 runs as a policy chain on an Omni Gateway in front of the agent, translates A2A requests into Agent API calls and derives an agent card. Agentforce is listed as available, with streaming and human-in-the-loop. Salesforce had announced MuleSoft A2A support as generally available for July 2025 in the Agentforce 3 press release5.
• Native A2A in Agentforce: announced. The Dreamforce 2026 recap6 says Agentforce can “act as a specialized subagent in any A2A-compliant architecture” and promises to “orchestrate third-party agents from AWS, Azure, Google, and more”. That section names no status, and I have found no Salesforce documentation of a native A2A endpoint.
• SAP Joule: inbound only. SAP’s reference architecture for inbound A2A7, updated 26 October 2026, exposes Joule agents to third-party clients through Agent Gateway using A2A 0.3.0, with trust via SAP Cloud Identity Services. Its disclaimer says some components are not yet GA and bidirectional communication with third-party agents through Agent Gateway “is not yet supported”.
• Microsoft Copilot Studio: client side documented. The Copilot Studio page does not label the A2A feature as preview or GA. On MuleSoft’s bridge list, Copilot Studio as a source agent is “planned”, so a Copilot agent cannot yet be made A2A-callable through MuleSoft.

The limits of the A2A Bridge decide which tasks fit.

So cross-vendor A2A today fits a question that gets an answer within seconds. A warranty review that waits days for a technician’s report does not fit.

Which agent should own the dealer or service conversation?

The owner is the agent of the system where the person authenticates and where the result is recorded. These questions decide it:

1. Who knows the person? A dealer logged into an Experience Cloud portal is a contact on an account that carries the SAP sold-to number. Every visibility rule starts there.
2. Where does the result live? Cases, warranty claims and work orders sit in Salesforce, so the owner writes the outcome there.
3. Which channel? Portal chat, the service hotline and email-to-case are Salesforce channels. Teams is Microsoft’s.
4. Who takes over from the agent? The escalation queue of the service team runs in Salesforce Omni-Channel.

For a manufacturer this gives a clear split. Dealers and service customers talk to Agentforce, and SAP data comes in through an API action, as described in Agentforce and SAP: order status through MuleSoft. Sales reps who work in Teams and Outlook can have Copilot as their front door, with an Agentforce agent behind it for CRM questions. Clerks in credit management or billing work in SAP, and Joule is theirs.

I would write this down per audience, the same way an object has one owner. The owner should never be the vendor whose demo was best on the day.

A second agent is worth the hop only when it owns logic

A data read with one right answer belongs in an API or an MCP tool. An agent asking another agent for an order status is an API call with two language models in between, and each of them can misread the question. Delegate to another agent only when it owns judgement and rules you do not want to rebuild, for example an SAP-side process that already runs with SAP’s own checks.

Every hop raises four questions before go-live:

• As whom does the specialist run? The A2A Bridge authenticates to the Salesforce org with client ID and secret. In the documented client credentials setup8 with bypassUser set to true, the API uses the user associated with the agent, not the person who asked in Teams. That user’s sharing decides what the specialist can read. Gates belong in code on the receiving side, as in Agent Script: rules instead of the LLM.
• How long may it take? Within 120 seconds, or it fails.
• Who pays? Salesforce states that Agent API usage counts toward credit consumption, and the calling platform bills its own usage. One dealer question then runs on two meters.
• Where is the trace? A failure across two vendors means two logs and two support contracts. Cross-vendor cases belong in the test set described in testing Agentforce agents before go-live.

Worked example: dealer portal, Teams and a Joule agent

Assume a machine builder with 250 dealers, SAP S/4HANA, Microsoft 365 and an Agentforce agent on the dealer portal answering warranty and order questions. All numbers are assumptions. In one quarter three requests reach IT.

Sales wants the dealer agent in Teams. Area sales managers ask, for example, how many warranty claims a dealer has open. A Copilot Studio agent calls an Agentforce specialist through the MuleSoft A2A Bridge. The answer comes back in seconds, which fits the synchronous limits. One detail to check first: the bridge accepts JWT, Basic Authentication or Client ID enforcement, and Copilot Studio offers API key or OAuth 2.0, so both sides must agree on one scheme. Because the specialist runs as the agent user, I would restrict it to read-only questions every sales rep may see anyway, and keep claim details in Salesforce.

The SAP team proposes a Joule agent for credit checks. The portal agent would ask Joule whether a dealer may order despite a credit block. I would decline. A credit block is a yes or no in SAP, an API returns it deterministically, and the bidirectional Joule path is not yet supported.

Service wants an agent to run the warranty review. The review waits two to five days for the technician’s report. With no async tasks for Agentforce in the bridge and a 120-second timeout, this stays a Salesforce process with case, work order and approval, not an A2A task.

One of three requests goes through A2A. For a first year, I consider that ratio healthy.

Name one owner agent per audience

1. Name one owner agent per audience and channel: dealers, service customers, sales reps, back office.
2. List the questions that cross systems and mark each as a data read (API or MCP) or delegated judgement (agent).
3. Use multi-agent orchestration inside the org first. It is GA and keeps identity, logs and billing in one place.
4. Check identity, timeout, cost and logging for every cross-vendor hop before building it.
5. Pilot one read-only A2A hop if MuleSoft already runs in your company, and ask SAP and Microsoft for the GA status of their side in writing.

For the first point, a table with audience, channel, owner agent and the systems it queries is enough. Which integration pattern fits which system is part of Salesforce integration, and the masterclass chapter MCP and interfaces maps the protocols.

Sources8

1. 1April 2025 post (opens in a new tab)news.sap.com
2. 2connects to another agent over A2A (opens in a new tab)learn.microsoft.com
3. 3Winter ’27 developer guide (opens in a new tab)developer.salesforce.com
4. 4A2A Bridge (opens in a new tab)docs.mulesoft.com
5. 5Agentforce 3 press release (opens in a new tab)salesforce.com
6. 6Dreamforce 2026 recap (opens in a new tab)salesforce.com
7. 7reference architecture for inbound A2A (opens in a new tab)architecture.learning.sap.com
8. 8client credentials setup (opens in a new tab)developer.salesforce.com