The Autonomous Enterprise Has a Basis Problem

At SAP Sapphire 2026, Christian Klein stood in front of a 30,000-strong audience and described a future where agents run the business and people focus on what matters. The SAP Business AI Platform, the Autonomous Suite, more than 50 domain-specific Joule Assistants orchestrating over 200 specialized agents, Joule Work as the new front door to the entire suite. It was, by any measure, the most ambitious operating-model bet SAP has made since the move to HANA.

It was also a story told almost entirely from the business-process layer down. Finance closes itself. Procurement negotiates bids without a spreadsheet. Supply chain reroutes around a disruption before a planner has read the alert. Every demo lived in the application tier.

Here is the question nobody on stage answered, and the one every Basis and operations leader in the room should have been asking: when agents run the business, who runs the agents?

Because the autonomous enterprise does not float in the cloud on good intentions. It runs on kernels, databases, transports, certificates, network paths, and recovery procedures. It runs on the same SAP Basis layer that today still depends on a human being to apply a support package, approve a failover, or notice that a non-production refresh quietly broke three weeks of agent test data. We have spent 18 months automating the decisions a business makes. We have spent almost none automating the operations that keep those decisions possible.

That mismatch has a name, and recognizing it is the first step to closing it.

The Operational Autonomy Gap

The Operational Autonomy Gap is the widening distance between how autonomous your business processes have become and how autonomous the operations beneath them remain. The wider the gap, the more dangerous it is — because every increase in process autonomy raises the cost of an operational failure while leaving the speed of operational recovery exactly where it was.

Consider what changes when an agent, not a person, is the primary actor. A human running month-end close works at human pace; if the system is slow or a job hangs, they wait, escalate, and the close slips a day. An autonomous close agent works continuously, in parallel, across entities, at machine speed. When the platform underneath it degrades, the agent does not wait politely. It retries, it cascades, it makes decisions on stale or partial data, and it does so faster than any human can intervene. The blast radius of an operational incident scales with the autonomy of the workload sitting on top of it.

SAP itself has acknowledged the principle, if not the operational consequence. As the platform team framed it at Sapphire, lacking context is the number one reason enterprise AI projects fail to deliver value. I would extend that claim: lacking operational resilience is the number one reason they will fail to survive. Context tells an agent what to do. Resilient operations are what let it keep doing it when something breaks — and in a landscape of two hundred interacting agents, something always breaks.

Five Levels of Autonomous SAP Operations

We borrowed a useful idea from the automotive world without realizing it. Autonomous driving is described in levels precisely because “self-driving” is a spectrum, not a switch. SAP operations deserve the same honesty. Most organizations describe themselves as “automated” when they are nowhere near autonomous, and the imprecision hides exactly where the risk lives.

The point of the model is not to chase Level 5. It is to force an uncomfortable diagnosis. If your business processes are operating at the equivalent of Level 4 — agents executing end-to-end with minimal human input — and your Basis operations are honestly sitting at Level 1, you have not built an autonomous enterprise. You have built an autonomous front end bolted onto a manual back end, and you have moved your single point of failure from the application to the operations team.

Closing the gap means deliberately raising operational autonomy along five pillars.

Pillar 1 — Observability Before Autonomy

You cannot automate what you cannot see, and you certainly cannot let a system heal itself based on signals it does not collect. The foundation of autonomous operations is not AI. It is observability: unified, correlated telemetry across the kernel, the database, the integration layer, the infrastructure, and now the agents themselves.

This is where most modernization programs quietly stall. Teams stand up dashboards that show a hundred green lights and call it monitoring. Autonomous operations need something different — a system that understands relationships, not just metrics. A spike in HANA delta merge time, a creeping increase in enqueue lock waits, and a Joule agent suddenly retrying a posting are three signals that, correlated, predict a problem no single dashboard would catch. SAP’s own architecture leans on the Knowledge Graph to give agents a structured map of business relationships; operations needs the equivalent — a topology-aware model of how the technical landscape actually hangs together — before any self-healing logic can be trusted to act on it.

Pillar 2 — Self-Healing as the First Real Step

Conditional autonomy (Level 3) is where the practical value lives today, and it starts with the unglamorous work most Basis teams already know by heart: the recurring incidents that consume a third of the queue. A filesystem approaching capacity. A failed background job that needs a clean restart. A certificate nearing expiry. A work process pool exhausted by a runaway query.

These are bounded, well-understood, repeatable scenarios — exactly the kind that should never reach a human in 2026. The maturity step is to move them from alert-and-page to detect-decide-remediate-and-log, with the human reviewing what the system did rather than doing it. Done correctly, this is not risky; it is the opposite. A system that resolves the routine instantly frees your most experienced people for the genuinely novel failures where human judgment is irreplaceable. Done carelessly — without guardrails, audit, and a hard rollback path — it is how you turn a minor incident into an automated outage. The discipline is in the boundaries, not the ambition.

Pillar 3 — Autonomous Resilience: The DR Reckoning

This is the pillar I care most about, because it is the one the autonomous-enterprise narrative most conveniently ignores.

Disaster recovery has been, for thirty years, a fundamentally manual and fundamentally unproven discipline. We document an RTO. We write a runbook. We test it once a year, in a controlled window, with the right people watching — and then we assume that the failover we rehearsed under ideal conditions will behave identically during a real incident, on a Tuesday, with half the team on PTO and an agent fleet hammering the database. That assumption has always been optimistic. In an autonomous landscape, it is negligent.

Autonomous resilience inverts the model. Instead of validating recovery once a year, you validate it continuously — automated failover rehearsals against isolated copies, machine-verified that the database is consistent, the application starts clean, and the recovery point is real. Instead of discovering at 2 a.m. that a configuration drift broke your standby, you detect the drift the hour it happens. Instead of an RTO that is a hopeful number in a document, you have an RTO that has been measured, last week, by the system itself.

When 200 agents depend on a platform being available, “we think we can recover in four hours” is no longer an answer. Resilience has to become a property the system proves about itself, not a promise the operations team makes about it.

Pillar 4 — The Data Integrity Imperative Nobody Budgeted For

Here is the trap, and it is a compliance trap with teeth.

Autonomous agents are not built and validated in production. They are designed, trained on patterns, tested, and regression-checked against non-production systems. And non-production systems, across the overwhelming majority of SAP landscapes, contain full, unmasked copies of production data — real customer records, real financial detail, real personally identifiable information, refreshed from production precisely so the test environment is “realistic.”

Now point an agent-development program at those systems. You are no longer just exposing PII to a wider set of developers and testers. You are potentially feeding it into model context, embedding it in agent test artifacts, and propagating it across environments that were never assessed for that use. Under GDPR and every regulation that has followed its logic, that is not a theoretical risk. It is processing personal data for a purpose it was never collected for, in systems that were never authorized for it.

The autonomous enterprise raises the stakes of a problem the industry has under-invested in for years: non-production data is production data wearing a different hostname. Anonymization and masking stop being a compliance checkbox and become a precondition for safely developing agents at all. If you cannot give your agent program realistic, structurally intact, de-identified data to work against, you are choosing between two bad outcomes — slow, unrealistic testing, or fast development on a regulatory time bomb. Resolving that tension is foundational infrastructure for autonomy, not an afterthought to it.

Pillar 5 — Governance and the New Basis Operating Model

SAP’s answer to control is the AI Agent Hub — a single command center to discover, manage, and govern every agent, SAP and non-SAP, with the runtime sandboxed and guardrailed. That solves governance for the business agents. It says nothing about who governs the operational autonomy you are building underneath them, and that responsibility is going to land squarely on Basis and operations.

The role is changing in front of us. The most valuable operations professional in an autonomous landscape is no longer the fastest firefighter. It is the person who designs the guardrails, defines what the system is allowed to do without asking, decides where the human-in-the-loop checkpoint sits, and audits what the autonomous layer actually did. We are becoming, to borrow the industry’s emerging term, AI generalists for the infrastructure — orchestrators and governors rather than operators. That is a more strategic role, and a more demanding one, and the teams that lean into it will be the ones still standing when the org chart is redrawn around agents.

What to Do Before the Next Board Mandate

The autonomous enterprise is not waiting for operations to catch up, so the work is to close the gap deliberately rather than discover it during an incident. Three moves matter now. First, diagnose honestly — place your business-process autonomy and your operational autonomy on the same five-level scale and measure the distance between them; that distance is your risk. Second, invest in the unglamorous foundation — observability, self-healing for bounded scenarios, continuously validated recovery, and masked non-production data are the load-bearing walls, and none of them are optional. Third, claim the governance role before it is assigned to you — define the guardrails for operational autonomy now, while you still can shape them, rather than inheriting someone else’s.

Agents running the business is genuinely transformative, and I am not arguing against it. I am arguing that the transformation is only as resilient as the operations beneath it — and that the Basis discipline, far from being made obsolete by the autonomous enterprise, has just become the thing it quietly depends on most.

The agents will run the business. The question is whether anyone will be running the platform they run on. That part, still, is up to us.

Puneet Khatri is Head of Services at Libelle Americas, where he leads client delivery across SAP Basis modernization, disaster recovery, and data anonymization. He is a published author with SAP PRESS (Rheinwerk) and the Disaster Recovery Journal, and has served as a judge for the Stevie and Globee business awards. ORCID: