This Blog is Part 2 of a Blog Series (4 Parts!). Click on the following to navigate back to the main menu of POV on How to Approach Custom Agents in the Enterprise – Blog Series.
POV 2: Agent to Agent Collaboration with SAP and non-SAP Agents
*A2A Interoperability Coming Soon in 2026
In some cases, you may want to leverage your non-SAP Agents with SAP agents. As discussed in POV 1, bringing SAP data outside of SAP will result in challenges in security, governance, and business context – compromising the agent’s responsibility, relevance, and reliability.
This is a great opportunity to combine the best of both worlds – SAP & non-SAP Agents through Agent-to-Agent collaboration.
How? The A2A open protocol, developed by Google, handles inter-agent communication allowing agents, regardless of their vendor, to communicate complex tasks. Many of you may have already heard of MCP (Model Context Protocol), however if you would like a refresh – check out this blog by Pramod. It is important to note that A2A does not replace MCP but rather works alongside it. Think of A2A as the communication handler between agents where one agent assigns a subtask to another and the MCP enables the agents with the right tooling to complete the task. Using A2A with MCP enables autonomous AI agents regardless of if they are SAP or non-SAP.
From SAP the key orchestrator of agent collaboration is Joule, as discussed in POV 1, where it orchestrates the sequencing of tasks and workflows using deep domain knowledge and business context. What does this mean in terms of what autonomous agent-to-agent collaboration can achieve between SAP and non-SAP?
Agents are Discoverable – AI Agents will have discoverable endpoints that will be captured in the SAP AI Agent catalog acting as an adapter between SAP and non-SAP agents. As per the diagram below there will be an auto-assigned ORD (capture agent metadata) to ensure the Agent is discoverable. Through this, Joule will know what the agents can do to ensure the right one is selected to complete a task. (see architecture diagram below)Delegate tasks/artifacts – There are 2 types of agents to facilitate A2A communication: a client agent and remote agents where the client agent sends the task (eg. prompt or system triggered) and the remote agent receives the task, matches the tools, and executes the task. A2A is designed to be task-oriented and with the combination with its discoverable endpoints and deep domain knowledge, business context, Joule will understand how to orchestrate internally and with external agents.Operate securely and interoperable across systems – As per the diagram below, all external agents will be routed through the Agent Catalog making them discoverable and preventing direct exposure of SAP Agents to external agents. In addition, Agents will have a secure tool layer (Tool catalogue) where agents will have access to tools within trust boundaries that respect security policies.Scale your enterprise – rather than operating agents in silos, you can now have a connected interoperable agentic ecosystem with distributed functionality/tasks making it easier to scale.
The above image shows A2A Architecture with SAP. For example, a customer service rep receives a billing inquiry in their email. The service rep initiates a dispute resolution process through Joule and engages with a Google Agent (e.g. BigQuery data Source) that retrieves the required data and shares it back to Joule – collaborating to generate insights and resolution recommendations. To see this lab preview A2A scenario in action, check out this github.
Therefore, you can leverage all your investments, SAP & non-SAP, to have a connected Agent ecosystem.
Next POV?
To check out Part 3 of the Blog Series click: POV 3 – Using Integration Suite as Your Governed MCP Server Platform.
Or click on the following to navigate back to the main menu of POV on How to Approach Custom Agents in the Enterprise – Blog Series.
Source: A2A Blog by Google
Source: SAP A2A Architecture
This Blog is Part 2 of a Blog Series (4 Parts!). Click on the following to navigate back to the main menu of POV on How to Approach Custom Agents in the Enterprise – Blog Series.POV 2: Agent to Agent Collaboration with SAP and non-SAP Agents *A2A Interoperability Coming Soon in 2026In some cases, you may want to leverage your non-SAP Agents with SAP agents. As discussed in POV 1, bringing SAP data outside of SAP will result in challenges in security, governance, and business context – compromising the agent’s responsibility, relevance, and reliability.This is a great opportunity to combine the best of both worlds – SAP & non-SAP Agents through Agent-to-Agent collaboration.How? The A2A open protocol, developed by Google, handles inter-agent communication allowing agents, regardless of their vendor, to communicate complex tasks. Many of you may have already heard of MCP (Model Context Protocol), however if you would like a refresh – check out this blog by Pramod. It is important to note that A2A does not replace MCP but rather works alongside it. Think of A2A as the communication handler between agents where one agent assigns a subtask to another and the MCP enables the agents with the right tooling to complete the task. Using A2A with MCP enables autonomous AI agents regardless of if they are SAP or non-SAP.From SAP the key orchestrator of agent collaboration is Joule, as discussed in POV 1, where it orchestrates the sequencing of tasks and workflows using deep domain knowledge and business context. What does this mean in terms of what autonomous agent-to-agent collaboration can achieve between SAP and non-SAP?Agents are Discoverable – AI Agents will have discoverable endpoints that will be captured in the SAP AI Agent catalog acting as an adapter between SAP and non-SAP agents. As per the diagram below there will be an auto-assigned ORD (capture agent metadata) to ensure the Agent is discoverable. Through this, Joule will know what the agents can do to ensure the right one is selected to complete a task. (see architecture diagram below)Delegate tasks/artifacts – There are 2 types of agents to facilitate A2A communication: a client agent and remote agents where the client agent sends the task (eg. prompt or system triggered) and the remote agent receives the task, matches the tools, and executes the task. A2A is designed to be task-oriented and with the combination with its discoverable endpoints and deep domain knowledge, business context, Joule will understand how to orchestrate internally and with external agents.Operate securely and interoperable across systems – As per the diagram below, all external agents will be routed through the Agent Catalog making them discoverable and preventing direct exposure of SAP Agents to external agents. In addition, Agents will have a secure tool layer (Tool catalogue) where agents will have access to tools within trust boundaries that respect security policies.Scale your enterprise – rather than operating agents in silos, you can now have a connected interoperable agentic ecosystem with distributed functionality/tasks making it easier to scale.The above image shows A2A Architecture with SAP. For example, a customer service rep receives a billing inquiry in their email. The service rep initiates a dispute resolution process through Joule and engages with a Google Agent (e.g. BigQuery data Source) that retrieves the required data and shares it back to Joule – collaborating to generate insights and resolution recommendations. To see this lab preview A2A scenario in action, check out this github.Therefore, you can leverage all your investments, SAP & non-SAP, to have a connected Agent ecosystem.Next POV?To check out Part 3 of the Blog Series click: POV 3 – Using Integration Suite as Your Governed MCP Server Platform.Or click on the following to navigate back to the main menu of POV on How to Approach Custom Agents in the Enterprise – Blog Series. Source: A2A Blog by GoogleSource: SAP A2A Architecture Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
