SAP clean core is often presented as an architecture discussion for S/4HANA programmes. Keep modifications low, use supported extension patterns, move custom code out of the core, and make future upgrades less painful. That is all true. But it misses the decision that now matters most to many DACH mid-market leaders: whether the organisation’s SAP landscape is dependable enough for AI-enabled work.
Before asking what SAP Joule, SAP Business AI, or an external enterprise agent can automate, ask a more basic question: can an automated system understand how work actually gets done in SAP without relying on undocumented exceptions, hidden tables, user memory, or fragile custom exits?
For many organisations, the answer is only partly.
That does not mean AI initiatives should wait for a perfect S/4HANA landscape. Perfection is an expensive excuse for inaction. It does mean that clean core needs to be treated as an AI-readiness discipline. The goal is not to eliminate every extension. The goal is to establish clear, reliable boundaries between standard processes, governed extensions, business rules, and agent actions.
An AI agent needs more than a working transaction
A human SAP user can work around an imperfect system. An experienced buyer knows that a purchase requisition with a particular combination of fields needs an additional spreadsheet check. A finance specialist knows which free-text note signals that an invoice should not be posted automatically. A customer service employee knows that a delivery block is sometimes technically correct but commercially irrelevant.
These workarounds are rarely visible in process diagrams. They are embedded in individual experience, email threads, side tables, custom reports, and informal handovers.
An AI agent has no such institutional intuition unless the organisation deliberately provides the context, rules, permissions, and tools required to act. It needs to know which data is authoritative, which action is permitted, what conditions require human approval, and how to recognise an exception. If a workflow depends on a custom field whose meaning varies by plant, a user exit that nobody owns, or a manually maintained table outside the governed process, the agent is operating on unstable ground.
Reliable automation depends on reliable contracts. In an SAP setting, those contracts include stable business objects, documented process states, explicit decision rules, controlled interfaces, and clear ownership. Clean core improves those conditions. It reduces the amount of hidden behaviour that an agent would otherwise need to infer.
This is why extension debt is not simply a technical debt issue. It is decision debt. Every undocumented enhancement raises the cost of determining whether an agent can act safely.
Extension debt creates false confidence in SAP AI programmes
There is a common pattern in early enterprise AI discussions. A team identifies a plausible workflow, demonstrates a conversational interface, connects it to a few data sources, and concludes that the process is ready for automation. The demonstration works because it follows the happy path.
Production work is different. A production-grade agent must handle incomplete master data, conflicting statuses, approval limits, blocked suppliers, changed delivery dates, duplicate records, and requests that are technically possible but commercially wrong. It must also leave a trace that a process owner, internal audit function, or IT team can understand.
Customisation makes this harder when it obscures process truth.
Consider a purchasing workflow. The apparent task may be to identify delayed purchase orders and draft supplier follow-ups. That is a relatively safe, assistive use case if the agent reads approved data, proposes communications, and leaves sending to a buyer. The risk changes when the same agent is expected to change order dates, release requisitions, or recommend substitutions. At that point, it must understand custom tolerance logic, approval routes, source-list rules, supplier constraints, and the consequences of each action downstream.
If those rules sit across custom code, spreadsheets, email conventions, and the knowledge of two long-serving employees, the agent is not the problem. The operating model is.
A conversational layer does not remove process complexity. It can make complexity easier to access, but it cannot make ambiguous logic safe. In fact, a convincing chat interface can conceal uncertainty until it triggers an action that should never have been automated.
Separate agent-safe workflows from workflows that need refactoring
The practical question is not whether a process is standard SAP or customised SAP. Both can support useful AI applications. The question is whether the workflow has a sufficiently clear action boundary.
An agent-safe workflow usually has a defined business object, trustworthy source data, identifiable process ownership, and an outcome that can be validated. It also has permissions that match the risk of the task. Reading a contract status and preparing a summary is different from changing payment terms. Drafting a response to a customer query is different from creating a credit memo. Reconciling a list of exceptions for a controller is different from posting accounting entries.
The safest starting point is often where AI helps people interpret, prioritise, prepare, or route work rather than execute irreversible changes. This is not a timid strategy. It is how organisations build operational evidence about data quality, exception rates, and user trust before widening an agent’s authority.
Refactoring should follow business risk, not architectural fashion. Some extensions deserve attention because they block a high-value workflow. Others can remain untouched because they support a stable, low-change process that no agent needs to access. Treating every custom object as a clean-core emergency creates an unnecessarily large programme. Treating none of them as relevant creates an AI roadmap built on wishful thinking.
A useful assessment distinguishes between extensions that can be exposed through a governed interface, extensions that need their rules documented and separated from presentation logic, and extensions that should remain outside the agent boundary entirely. The last category matters. Some decisions are too context-sensitive, too commercially consequential, or too weakly structured to delegate safely. Keeping them human-led is a design choice, not a failure of ambition.
Keep custom logic, but make its role explicit
“Clean core” is sometimes heard as “remove everything custom”. That is neither realistic nor desirable for many Mittelstand organisations. Custom processes can embody genuine competitive advantage: a specialised pricing model, an industry-specific fulfilment sequence, a distinctive quality process, or a carefully designed service workflow.
The problem is not custom logic by itself. The problem is custom logic that has no explicit interface, no accountable owner, no usable documentation, and no observable behaviour.
When an agent needs to participate in a customised process, it should not have to navigate the internal mechanics of a legacy enhancement. It should call a defined capability. For example, rather than allowing an agent to update multiple fields across several tables, provide an approved action that checks preconditions, applies the relevant rules, records the decision, and returns a clear result.
This approach creates a meaningful boundary. The agent handles interpretation and orchestration. The governed SAP capability enforces business logic. Human approval remains in place where risk or ambiguity demands it.
Do not give an agent broad access because it is easier than designing a proper action. Broad technical access may accelerate a prototype, but it makes accountability harder later. It also turns every undocumented dependency into a potential production incident. A narrow, well-defined action can feel slower to create, yet it is usually faster to test, secure, monitor, and improve.
Process observability is the missing layer
Most SAP AI projects focus first on model selection, assistant capabilities, or integration options. Those matter, but they are not where many deployments succeed or fail. The decisive layer is observability: the ability to see what the workflow did, which information it used, what rule or approval shaped the outcome, and where the process stalled.
For an enterprise AI workflow, a basic audit trail should distinguish between the agent’s recommendation, the data it retrieved, the tool or business action it invoked, and the human decision where one was required. Process owners need enough visibility to correct recurring failures. IT needs enough visibility to investigate access and integration issues. Business leaders need enough visibility to decide whether the workflow is producing useful outcomes rather than merely generating activity.
This is particularly important in SAP environments where the visible transaction is often only the final step in a longer chain of decisions. If an agent recommends expediting an order, a manager should be able to understand whether that recommendation arose from a genuine supply risk, a stale data point, a custom status interpretation, or an incomplete view of inventory.
Without this visibility, organisations tend to respond to AI errors in one of two unhelpful ways: they overreact and stop all automation, or they underreact because the output sounds plausible. Neither is governance.
Treat clean core as a prioritisation tool
The strongest AI roadmap does not begin with a platform catalogue. It begins with a process map that identifies where SAP data and decisions are dependable enough to support assistance or automation.
Start by selecting a limited set of workflows with material operational relevance and manageable action risk. Examine the real path, not only the documented process. Identify where custom code changes behaviour, where data is duplicated, where exceptions are decided manually, and where employees rely on information outside SAP. Then define the smallest useful AI role: retrieve, explain, recommend, draft, route, or execute.
That analysis will reveal whether the immediate constraint is extension debt, master-data quality, unclear process ownership, missing integration, or simply an overambitious automation goal. Each calls for a different intervention.
For a DACH mid-market business, this matters commercially. The value of AI rarely comes from a grand platform rollout. It comes from making a small number of important workflows faster, more consistent, and less dependent on scarce operational knowledge. Spending heavily on an agent layer before understanding the process boundary risks creating another pilot that impresses stakeholders but never earns production trust.
Clean core, viewed this way, is not an SAP housekeeping exercise. It is the work of making business operations legible to software that may soon be allowed to participate in them.
A Diagnostic identifies which SAP workflows are ready for AI assistance or automation, where extension debt creates unacceptable risk, and what needs to be refactored before an agent acts in production.
Context note: This article is based on implementation principles rather than external sources.