SAP Agentic AI Explained: Joule Studio, MCP, A2A and the AI Agent Hub

In 30 seconds

What it is Controlled agent actions, with a trail.

You use it when You are about to design or review an SAP extension or AI use case that touches Agent Platforms, A2A, MCP and APIs.

Next in this section SAP Business Data Cloud Zero-Copy: Share SAP Data With Databricks and Snowflake, No Pipelines →

Define the bounded task → Expose narrow tools → Validate every call → Keep the evidence → Controlled agent actions, with a trail. A learning overview, not a screenshot of a live system.

Advanced · 10 min read · Part 16 of 17 in SAP AI Components Explained

Agents can call tools and hand work to other agents. The scary part is that they act. Here is how SAP keeps a lock on every door, and keeps the key.

SAP agentic AI is the focus of this post. An agent is an application that uses a model to decide its next step and then takes it, by calling a tool or handing a task to another agent. Two open standards make that plumbing interoperable: MCP (Model Context Protocol) for agent-to-tool, and A2A (Agent2Agent) for agent-to-agent. SAP is building support for both: Joule Studio to build agents, Agent Gateway as an A2A interface, AI Agent Hub to govern agents, models and MCP servers, and MCP access to SAP and non-SAP APIs. Several pieces are new, and some are not yet generally available.

By the end you will be able to say in one sentence what Agent Platforms, A2A, MCP and APIs does, draw how data moves through it, and use the design-review line that stops most mistakes: Protocol support is not business authority.

Agent Platforms, A2A, MCP and APIs in one sentence

Agents talk to tools through MCP and to each other through A2A. Every door still has a lock, and the lock is yours.


Its job	Let an agent use tools and delegate tasks without ever holding unrestricted authority.
You need	An agent runtime (Joule Studio, or your own on BTP), an MCP server exposing a few narrow tools, and a policy layer that validates every call.
Layer	Assistants and agents
Design check	Protocol support is not business authority.

The everyday picture

A dispatch office with specialist desks. The dispatcher (agent) can ask the finance desk (a tool) for a figure, or hand a task to another office (another agent). Each desk checks the dispatcher’s badge before answering.

Why Agent Platforms, A2A, MCP and APIs exists

The useful thing about agents, that they act, is the dangerous thing about them. The model is persuadable; a tool result can contain instructions; a broad tool is a loaded weapon. The safe pattern is the same one every good back office uses: narrow desks, badge checks at each one, and a logbook.

How Agent Platforms, A2A, MCP and APIs works, in four steps

Define the bounded task. One case, one outcome, a list of allowed tools. Write it down.
Expose narrow tools. An MCP server offers ‘read case’ and ‘propose’, never ‘post’.
Validate every call. Your backend checks the tool name, the arguments and the user’s rights before running it.
Keep the evidence. Every call, result and human decision goes to the audit log.

You write down the bounded task: one case type, one allowed outcome, a short list of tools. An MCP server exposes those tools, read-case and propose, never post. The agent runtime, Joule Studio or your own code on BTP, asks the model which tool to call next. Before anything runs, your policy layer checks the tool name, the arguments and whether this user may do this for this case; a failed check is a stop, not a retry. Every call, result and human decision goes to the audit log, and anything that would change business data is handed to a human approval, for example in SAP Build Process Automation. A2A adds the ability to delegate a task to another agent, SAP’s or a partner’s, with its reply treated as data to validate, not as instructions to follow.

Where it sits in the SAP landscape

The agent proposes; the policy layer decides. Narrow tools, no ‘post’.

A worked example, with numbers

The clarification agent runs in Joule Studio with two MCP tools: get_case and propose_assignment, an MCP server wrapping existing OData APIs; there is deliberately no post tool. For PAY-0042 the model asks to call get_case(‘PAY-0042’); the policy layer checks that this agent, for this user context, may read this case, allows it, and logs it. The model then calls propose_assignment with account INV-7781; the policy layer validates the arguments, the proposal goes to the approval workflow from post 10, and a person posts it. Later a partner’s field-service agent asks, over A2A, for the payment status of a related order; the reply is treated as data and validated, never followed as an instruction. Every call and decision is in the audit log.

How the data flows

The check that actually matters

Protocol support is not business authority. A tool being discoverable over MCP, or an agent being reachable over A2A, says nothing about whether this user, for this case, may use it. That decision belongs to your policy layer and ultimately to S/4HANA’s authorization. Give every agent its own service identity (SAP positions Cloud Identity Services for agent identity), a spend limit and a time limit, and assume anything a tool returns could be trying to talk the model into something.

Protocol support is not business authority. A tool being reachable over MCP says nothing about whether this user, for this case, may call it. Your policy layer decides.

MCP vs A2A

Question	Option A	Option B
Connects	An agent to tools and resources	An agent to another agent
Typical call	‘read case’, ‘propose’	‘handle this task’, task status
You need first	MCP, for most first projects	A2A, when agents must collaborate
Trust rule	Validate every tool result as data	Validate every agent reply as data

What Agent Platforms, A2A, MCP and APIs does, and what it does not

It does

MCP: a standard way for an agent to discover and call tools and read resources.
A2A: a standard way for agents to hand tasks to each other, with identity and task state.
SAP: Joule Studio to build agents, Agent Gateway to expose them over A2A, AI Agent Hub to govern SAP and non-SAP agents, and governed MCP exposure of APIs (for example through MCP Gateway in SAP Integration Suite).

It does not

Make a tool safe. A narrow tool with validation is safe; a broad one is not.
Replace APIs. MCP and A2A sit on top of your APIs and identity.
Decide anything. The model proposes; code and people decide.

Three real situations

Payment clarification agent. The agent’s only tools are read-case and propose. A clerk approves; the posting happens in S/4HANA through the normal process.

Service coordination. A Joule agent hands a field-service task to a partner’s agent over A2A; the partner’s reply is treated as data and validated before anything is scheduled.

Agent-to-agent research. A research agent gathers evidence from two systems through MCP tools and returns a summary with references, never a decision.

In practice: what teams get wrong

SAP’s agent platform has three layers. Build: Joule Studio, SAP’s low-code and pro-code environment for skills and agents (the Agent Builder was announced as generally available; SAP pages show differing dates and a promotional period, so check the current terms). Expose and connect: Agent Gateway offers an A2A interface so external agents can talk to agents on SAP technology, and MCP Gateway in SAP Integration Suite offers customer-managed, governed MCP exposure for SAP and non-SAP APIs. As of mid-October 2026 SAP’s reference architecture still lists bidirectional communication with third-party agents through Agent Gateway as not yet supported, with a fuller release expected. Govern: the AI Agent Hub (SAP AI Agent Hub by SAP LeanIX, also sold standalone) is a vendor-agnostic place to discover and govern agents, LLMs and MCP servers. MCP is agent-to-tool; A2A is agent-to-agent. None of this removes the need for a policy layer that checks every call against the user’s rights before it runs, or for a human approval on anything that changes business data.

From the field. I have seen an agent given a broad ‘update’ tool ‘to save building three narrow ones’. The model found a way to use it the designers never intended, and only the audit log revealed it.

Other gotchas worth a line:

Instructions can hide in tool results; treat everything returned as data, never as commands.
Limit duration, retries and spend per task.
Use a service identity per agent, scoped to its tools.
SAP’s agent platform (Joule Studio, Agent Gateway, AI Agent Hub) is new and moving, and some capabilities are not yet generally available; check the current SAP documentation.

Terms you will hear

Term	Plain meaning
Agent	An app that uses a model to choose and take the next step.
MCP	Model Context Protocol: standard agent-to-tool calls.
A2A	Agent2Agent: standard agent-to-agent delegation.
Joule Studio	SAP’s builder for skills and agents, in SAP Build.
Agent Gateway	SAP’s A2A interface for agents.
AI Agent Hub	Governance for SAP and non-SAP agents, LLMs and MCP servers.
Policy layer	Your check on every call before it runs.

Quick self-check

In one sentence, what is Agent Platforms, A2A, MCP and APIs’s job?
Which decision does it not make, and who makes it instead?
What is the one thing you would verify before calling it production-ready?

Show the answers

Let an agent use tools and delegate tasks without ever holding unrestricted authority.
Make a tool safe. A narrow tool with validation is safe; a broad one is not.
Instructions can hide in tool results; treat everything returned as data, never as commands.

Key takeaways

Agents talk to tools through MCP and to each other through A2A. Every door still has a lock, and the lock is yours.
Protocol support is not business authority.
MCP: a standard way for an agent to discover and call tools and read resources.
Make a tool safe. A narrow tool with validation is safe; a broad one is not.
SAP’s agent platform (Joule Studio, Agent Gateway, AI Agent Hub) is new and moving, and some capabilities are not yet generally available; check the current SAP documentation.

FAQs

MCP or A2A, which do I need?

MCP for an agent calling tools; A2A for agents calling agents. Most first projects need only MCP.

Can an agent post to S/4HANA?

It should propose, and a process with a human approver should post, through the same API and authorization a person would use.

Keep going in the series

Previous: Joule and Joule for Consultants Next: Zero-Copy Data Platforms

Full map: SAP AI Components Explained — 17 posts from platform to agents.

Sources and research notes

Research checked on 21 October 2026. Product names, plans, models and regional availability change fast; the starting reference for this component is Model Context Protocol specification. Examples use a fictional utility company and fictional cases (amounts, IDs, names); no customer landscape is described.

Recap

Agent Platforms, A2A, MCP and APIs: let an agent use tools and delegate tasks without ever holding unrestricted authority. The result is controlled agent actions, with a trail. The one thing to remember: protocol support is not business authority.

Found this useful? The next post, Zero-Copy Data Platforms, builds on it. Share it with the SAP colleague who keeps asking what all these components actually do.