Concept card

Agent Communication in SAP — MCP vs A2A, Hop by Hop

As of 2026-10-10

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Agent Communication in SAP?

"A2A via MCP" is a category error: MCP connects an agent to tools and data, A2A connects an agent to another agent. This card gives the hop-by-hop rule for SAP architectures — which protocol on which link, and why most Joule designs use both. Protocol detail lives in C164 (MCP) and C163 (A2A).

Why this card was recentred

An earlier version of this card described "agent-to-agent communication via MCP". That framing mixed two different protocols. The Model Context Protocol (MCP) is a client-server protocol: a host application's client calls tools, reads resources and uses prompts exposed by a server. The Agent2Agent protocol (A2A) is a peer protocol: one agent delegates a task to another, opaque agent and follows that task through a lifecycle. You can wrap an agent behind an MCP tool, and SAP designs sometimes do, but then the calling side sees a function, not a partner — no task states, no negotiation, no asynchronous hand-back. The distinction decides security design, audit trail and failure handling, so it is worth getting exactly right.

Why it matters

MCP and A2A answer different questions — tools versus peers — and the choice changes the security model, the audit trail and how long-running work is handled.
SAP's own pro-code pattern (CAP @cap-js/agents) uses MCP inward for tools and A2A outward for other agents: the clearest reference design for the boundary.
Joule's bi-directional A2A was announced for general availability in Q4 2026, so architecture diagrams drawn now must label every agent hop correctly.

Key points

MCP = agent ↔ tools/resources/prompts (client-server); A2A = agent ↔ agent (peers with task lifecycle). "A2A via MCP" conflates the two.
A2A tasks carry states (submitted, working, input-required, auth-required, completed, failed, canceled, rejected); MCP tool calls return results, with long-running work in an optional Tasks extension.
Discovery differs: MCP server/discover on a known endpoint vs A2A Agent Card at /.well-known/agent-card.json.
Hop rule: human→agent = UI; agent→SAP data/action = MCP; agent→foreign agent = A2A.
CAP @cap-js/agents generates MCP tools from CDS entities/actions and serves the agent over A2A; @agent.hitl maps to the A2A input-required state.
Wrapping an agent as an MCP tool is acceptable only for short, synchronous, function-like work.
Both asset types belong in SAP AI Agent Hub; both fall under SAP API Policy §2.2.2 when SAP APIs are reached agentically.

Terms used on this page

MCP (Model Context Protocol): Client-server protocol through which an AI host calls tools, reads resources and uses prompts exposed by a server; spec revision 2026-07-28.
A2A (Agent2Agent protocol): Peer protocol under the Linux Foundation for one agent to discover and delegate tasks to another agent; version 1.0 is the first stable specification.
Agent Card: JSON metadata document describing an A2A agent's identity, skills, endpoint and authentication; can be signed for authenticity.
Task (A2A): Unit of delegated work with a lifecycle of states, followed by polling, streaming or push notifications.
Hop labelling: Design practice of marking each link in an agent architecture as UI, MCP or A2A before choosing security controls.
@agent.hitl: CAP annotation that forces human approval before an agent executes an action, surfaced as the A2A input-required state.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.