Clean Core Is Not a Destination: Designing SAP Landscapes That AI Agents Can Actually Use

There is a comfortable version of SAP modernization doing the rounds right now. Move off ECC, adopt S/4HANA, push the Z-code out to BTP, tick the clean core box, then bolt on AI. It is tidy, it is fundable, and it quietly misses the point. Clean core is a hygiene standard, not an architecture. If you relocate a decade of undocumented custom logic from the ABAP stack to a side-by-side extension estate without redesigning the boundaries it sits on, you have not modernized anything — you have re-hosted your technical debt with better marketing. And the moment you point AI agents or a composable commerce front end at that landscape, the weakness becomes obvious.

The deadline is real, but it is the wrong forcing function

SAPinsider's 2025 benchmark research puts roughly a third of organizations as having completed their S/4HANA migration, with another large cohort intending to move before mainstream maintenance for ECC ends in 2027. That creates enormous schedule pressure, and schedule pressure produces lift-and-shift decisions. SAP itself formalized a clean core maturity model in 2025 — useful, because it forces teams to classify every extension by how upgrade-safe it is. But a compliance level tells you whether an extension will survive the next release. It tells you nothing about whether the capability it implements belongs there at all. Those are different questions, and only the second one compounds in value.

Composability is a boundary decision, not a technology purchase

The composable movement learned this the hard way. The MACH Alliance's 2025 global research reports very high adoption of MACH-style technologies and strong ROI claims, yet the failures in that community were rarely about microservices or headless APIs. They were about organizations decomposing along technical seams — a service per system, an API per table — instead of along business capability seams. The same trap is now open in SAP-centric estates, where BTP makes it trivially easy to create a hundred small extensions that collectively reproduce the monolith with more network hops.

A better test before you build anything side-by-side:

• Does this represent a capability or a workaround? Pricing logic that reflects a genuine commercial differentiator earns an extension. A fix for a report nobody reads does not.
• Who owns the contract? Every extension boundary should have a named business owner, a versioned interface, and a documented meaning for its key entities — not just a service endpoint.
• Can it be consumed without tribal knowledge? If understanding an API requires knowing which of four order statuses is the "real" one, it is not ready for agents.
• What happens on upgrade? Compliance level is table stakes; also plan how the interface evolves when SAP changes the standard object underneath.
• Is the event as important as the entity? Composable and agentic consumers need to react to change, not just query state.

Agents raise the cost of ambiguity

SAP's expansion of Joule agents across finance, procurement, supply chain, and service through 2025 changes the economics here. A human user compensates for a badly named field or an ambiguous status by asking a colleague. An agent does not — it acts on what the interface says, at machine speed, across thousands of transactions. Gartner's widely cited projection that a large majority of enterprise applications will embed task-specific agents within the next couple of years means the interfaces you design in this migration will be read far more often by software than by people. Semantic precision stops being documentation discipline and becomes an operational control. This is where our SAP practice spends most of its architecture effort: defining what an order, a customer, or an entitlement actually means before anything consumes it.

Sequence the programme around capabilities, not systems

Practically, that means resisting the urge to run modernization as a system-by-system inventory. Pick two or three capabilities where differentiation genuinely lives — quote-to-cash, service fulfilment, channel pricing — and modernize them end to end: clean the core beneath them, expose the interface deliberately, wire the composable front end, and only then let an agent operate inside them. Everything else moves to standard. It is slower to start and dramatically faster to extend, and it gives you a repeatable pattern instead of a one-off migration. We have seen the same sequencing work across enterprise programmes where the pressure to go fast was every bit as intense.

The organizations that will look smart in 2028 are not the ones that hit the deadline. They are the ones that arrived with a landscape whose boundaries mean something — where adding an agent, a channel, or an acquisition is a configuration exercise rather than another integration project. Clean core gets you upgrade-safe. Capability boundaries get you optionality, and optionality is the only durable return on a migration this expensive.