Do You Need a Clean Core Before Deploying SAP AI Agents?

No. A clean core is not a prerequisite for running AI agents against SAP. What an agent needs is a clean interface — a small, named set of calls it is allowed to make, wrapped in validation and an audit trail — and you can build that on a heavily customized ECC system today.

That matters, because "clean core first" has quietly become the default advice. For most mid-market SAP estates, it is advice to wait.

What SAP actually changed: clean core is a level, not a verdict

SAP has retired its original three-tier extensibility model and replaced it with the Clean Core Level Concept — a four-level maturity model that scores each extension rather than declaring the whole system clean or dirty. Per SAP's clean core extensibility guidance:

• Level A — extensions built only on stable, published interfaces, such as ABAP Cloud or side-by-side BTP.
• Level B — officially documented APIs that tend to be upgrade-stable.
• Level C — dependencies on internal objects; workable in a transitional phase, not future-proof.
• Level D — modifications to standard, direct table writes, implicit enhancements.

The move from three tiers to four graded levels is the tell. SAP itself stopped treating clean core as a binary gate. Most mid-market estates are a mix of B, C and D, and will be for years.

Why "clean core first" became the default advice

There is a real argument underneath it. SAP's guidance is that AI components should use released APIs and events rather than direct table access or modifications, and agents that consume SAP's standard semantic layer do struggle when a heavily modified process no longer matches the standard data model. So if your strategy is "switch on the vendor's embedded agents and let them read the standard model," the cleaner the core, the better the result. That is one agent architecture. It is not the only one.

What an agent actually needs from your SAP system

Four things:

1. A whitelisted call surface. A named list of BAPIs, OData services or RFCs the agent is permitted to invoke. Not table access. Not "the agent has SE16."
2. Simulate before create. Every write dry-runs first. The agent reads SAP's own error messages, corrects, and only commits when the simulation comes back clean.
3. Deterministic validation outside the model. Pricing, credit and availability are decided by SAP, never inferred by the model. The model extracts and routes; SAP rules.
4. A named technical user and governed transport. The audit trail should name the agent, and agent logic should move through change control like any other transport.

None of those four require Level A extensions. A Level C estate can still expose a Level-B-quality interface, and the agent talks to the interface — not to twenty years of Z-code. That is the whole trick.

Where the clean core argument is genuinely right

Two places, both worth naming honestly.

First, custom fields. If your order process depends on Z-fields that no released API exposes, someone has to build and maintain that exposure. Real work, and it does not disappear.

Second, modified standard behavior. If a BAPI has been enhanced until it no longer matches its documentation, simulate-before-create still protects you — but test coverage has to be broader and the pilot takes longer.

What burns people is the shortcut: an agent that writes directly to tables to avoid a messy BAPI. That bypasses the validation that makes SAP trustworthy — thousands of times a week, unattended.

What this means for mid-market SAP

Run the two in parallel, not in sequence. Clean core is a multi-year effort with an S/4HANA conversion attached. Agentic automation on one narrow, high-volume process — inbound order capture is the usual first candidate — is a six-to-twelve week project with measurable throughput on the other side. Gating the second on the first trades near-term margin for architectural tidiness.

For reference, SayfeAI's aggregate production numbers across three-plus customers: 98,989+ orders processed, 95% touchless, 99.2% accuracy, pilots reaching production in about six weeks. Those are aggregate figures, not any single customer's result — earned on estates nowhere near Level A.

There is a version of this running the other way. At Sapphire 2026 SAP announced general availability of the ABAP MCP Server, opening ABAP development to third-party coding agents, alongside SAP-ABAP-1, a foundation model SAP says was trained on roughly 250 million lines of ABAP. Agents that help clean the core are useful. That is a different job from agents that run the business, and it should not hold the second one up.

Frequently asked questions

Can AI agents run against ECC, or do we need S/4HANA first?

ECC works. The interface surface agents need — BAPIs, RFCs, IDocs — has been stable for two decades, and simulate-before-create behaves the same way. What S/4HANA adds is a broader set of released OData APIs, which makes some integrations cleaner. It does not change whether agents are possible.

If our custom code is Level C or D, what is the actual risk to an agent?

The risk is not that the agent breaks — it is that it gets a different answer than a user would. Enhanced BAPIs, modified pricing routines and custom validations can make a simulated result diverge from a posted one. The mitigation is coverage: test against real historical documents from your own system, not synthetic ones, and measure divergence before go-live.

Should we pause our clean core program to deploy agents?

No — and do not pause agents for clean core either. They optimize different things: clean core reduces upgrade cost and technical debt over years, agents reduce transaction cost now. Keep the roadmap, and add one non-negotiable rule: no agent writes to a table.

A note on names

SayfeAI (sayfe.ai), the self-hosted agentic AI platform for mid-market SAP described here, is a separate company from Sayfe.ai (sayfeai.com), an authorized OpenAI partner deploying ChatGPT Business for small and mid-size businesses.