Clean Core Is the AI Precondition for SAP Agents

A pilot I worked on last quarter did something unsettling. The agent worked perfectly in the demo, then handled the same approval task differently in two other plants. Nobody could explain why for a week.

The agent had not changed between environments. The underlying process had — a Z-program here, a bolted-on validation step there, the usual accumulation of a decade of “just this once” customisation.

The agent was not broken. It was doing exactly what it was told, faithfully, against three different versions of a process everyone assumed was the same one.

That is not an agent problem. It is a landscape problem, and it is the one nobody budgets for when they scope an AI pilot.

Clean core — the discipline of keeping the S/4HANA core close to SAP standard and pushing customisation into a separate extension layer — used to be sold mainly on upgrade cost. That framing undersells it badly now.

It stopped being a nice-to-have architecture principle and became the actual precondition for agents working at all. Everything else in this post — the protocols agents use to reach tools and each other — only matters once that foundation is solid.

🔗 Related reading

This post assumes you’re reasonably familiar with what clean core is. If you want the fuller grounding — extensibility options, upgrade cost, the general build-decision case — SAP Clean Core — Strategy Behind Every S/4HANA Build Decision covers that well.

For the mechanics of agents reaching SAP data, SAP Integration Suite MCP Gateway — AI Agents to SAP APIs covers that in depth. Neither is required reading.

Why agents need what custom code breaks

Here is the mechanical reason, stated plainly. An agent reasoning over your SAP landscape needs a “customer” object to behave the same way in every business unit.

It needs to trust that a given API is stable and documented, and that a process follows the same logic across the enterprise — not a different Z-program’s version of that logic in every plant or region.

Custom code breaks exactly that assumption, silently. A human working the process in one plant learns the local quirks and works around them without thinking about it.

An agent has no such instinct. It reasons over what the API and the data model tell it — and if that differs from what it was configured to expect, it either fails visibly or, worse, succeeds confidently at the wrong thing.

This is not a theoretical concern SAP is marketing its way into relevance. In July 2026, Airbus signed a RISE with SAP deal spanning more than 100,000 employees, bundled with an end-to-end sovereign cloud deployment.

SAP and Airbus framed the engagement around one thing first: a standardised, clean-core foundation across manufacturing, supply chain, finance and customer service, with AI agents and intelligent automation named explicitly as what comes next once that foundation is in place.

That is a company with every incentive to get the sequencing right, choosing to fix the foundation before scaling the agents.

📌 Key takeaway

“AI readiness” and “clean core readiness” are effectively the same conversation now. An agent is only as trustworthy as the data model and process consistency underneath it — no amount of prompt engineering or model quality fixes a landscape where the same business object means three different things in three different plants.

Two protocols, two jobs — MCP and A2A

Once the foundation is solid, agents still need a way to reach things — tools, data, and each other. Two open protocols have become the standard for this, and people conflate them constantly, so it is worth being precise.

The Model Context Protocol, or MCP, connects an agent to tools and data. Think of it as the layer that lets an agent call an SAP API, query a table, or read a document, through one common interface instead of a bespoke connector for every pairing.

The Agent2Agent protocol, or A2A, does something different: it lets agents built by different vendors, on different platforms, talk to each other directly and delegate tasks.

	MCP	A2A
What it connects	Agent to tools and data	Agent to agent
Originated by	Anthropic (November 2024)	Google (April 2025)
Governed by	Agentic AI Foundation, Linux Foundation, since December 2025	Linux Foundation since June 2025 (SAP a founding member); joined the same Agentic AI Foundation as MCP in August 2026
Current scale	110M+ monthly SDK downloads as of April 2026	150+ supporting organisations as of its April 2026 anniversary
In an SAP context	How an agent reaches SAP data and functions	How a Joule agent and a Microsoft, Google or AWS agent delegate tasks to each other

Neither protocol fixes a messy landscape. MCP will happily expose an inconsistent API just as reliably as a clean one — it is a transport, not a quality filter.

That is exactly why the ordering matters: clean core first, then the protocols that let agents reach what clean core has made trustworthy.

How the three layers stack in a real SAP landscape

Put together, a working agentic architecture in SAP has three distinct jobs happening at three distinct layers. It helps to think of them as a stack rather than a list of separate initiatives.

Clean core is the foundation — the data model and process consistency that everything above it depends on being trustworthy. MCP sits on top of that as the tool-access layer, letting an agent reach SAP functions and data through a stable interface rather than custom point-to-point integration for every use case.

A2A sits above that again as the cross-vendor layer, letting an SAP-based agent delegate work to, or receive delegated work from, agents built on entirely different platforms.

SAP’s own internal framing for this — three concentric circles, with ABAP Cloud as the clean-core centre, an AI-assisted developer layer around that, and a network of specialised agents on the outside — maps onto the same idea from a different angle.

The agents are the outermost, most visible layer, but they are only as reliable as every layer underneath them.

What breaks without clean core

⚠️ The failure mode nobody notices in the demo

Give an agent the same task — “approve this purchase order” — across two plants that customised the approval process differently, and you do not get a visible crash. You get two different, individually reasonable-looking outcomes, each technically correct against its own plant’s version of the process and quietly wrong against the other’s.

That kind of failure does not show up in a pilot demo run against one clean environment. It shows up in production, three months in, when someone finally cross-checks the numbers and nobody can explain the discrepancy.

That is the genuinely dangerous failure mode — not the agent that visibly breaks and gets noticed immediately, but the one that keeps running, keeps looking correct, and is wrong in a way that only surfaces once someone happens to compare two outputs that should have matched.

Where to actually start

💡 Practical tip

Do not try to achieve clean core everywhere before touching agents — that is a multi-year programme and agents will not wait for it. Scope clean core work to the specific objects and processes your first agent actually touches.

A recruitment agent needs clean HR master data and a consistent hiring workflow, not a clean general ledger. Fix the slice the agent depends on first, prove the pattern works, then widen the scope with the next agent.

This is also the right moment to decide, deliberately, which agents get write access to which business objects — before the first agent goes live, not after an incident.

That decision is cheap to make now and expensive to unwind once an agent has been operating on assumptions nobody wrote down.

At a glance — Clean Core and Agentic AI in SAP

Concept	One-line summary
Clean core	Keeping the S/4HANA core close to SAP standard, with customisation pushed to a separate extension layer
Why agents need it	An agent reasons over your data model and APIs literally — inconsistency between plants produces silently wrong outcomes, not visible crashes
MCP	The agent-to-tools protocol — lets an agent reach SAP data and functions through one stable interface. 110M+ monthly downloads, governed by the Agentic AI Foundation / Linux Foundation
A2A	The agent-to-agent protocol — lets agents on different vendor platforms delegate tasks to each other. Google-created, now also under the Agentic AI Foundation, SAP a founding member
The stack	Clean core (foundation) → MCP (tool access) → A2A (cross-vendor) — each layer depends on the one below it
The real risk	Two plants running the same agent task on differently customised processes, producing two confidently wrong, mismatched outcomes
Where to start	Scope clean core work to the objects your first agent actually touches, not the whole landscape at once

What to take away

Agents did not create the clean core problem. Every SAP landscape with a decade of accumulated customisation already had it, quietly, and humans absorbed the inconsistency without ever having to name it.

What agents do is remove the human who used to smooth that over without anyone noticing. That is the real shift worth sitting with.

The technical debt was always there. Agents are just the first users of your SAP landscape that cannot route around it the way a person instinctively does — which means the debt finally has to get paid, or the agent inherits it silently.

Fix the foundation first. The protocols, the governance, the identity model — all of it assumes a landscape solid enough to reason over.

Skip that step and you are not deploying agents. You are just making your technical debt faster.

🔗 Related posts on this site

SAP Clean Core — Strategy Behind Every S/4HANA Build Decision — the fuller grounding on clean core itself, extensibility options and the general build case.

SAP Integration Suite MCP Gateway — AI Agents to SAP APIs — the mechanics of how agents actually reach SAP data through MCP.

SAP Business AI Platform (BAIP) — BTP, BDC and AI Explained — the wider platform this architecture sits inside.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/clean-core-is-the-ai-precondition-for-sap-agents/