All true, and all beside the point.

The controls were strong because they weren’t optional. Nobody chose to route changes through the transport system; there was no other way to move a change. The discipline wasn’t enforced by a policy anyone wrote. It was a property of the platform.

That’s a subsidy. An expensive organizational capability, delivered free, invisibly, by the software.

There were two of them.

The first subsidy: discipline lived in the software

For about thirty years there were two ways to change what a production SAP system did to a business document.

The transport. And the system open — firefighter ID, time-boxed, logged, approved in advance and reviewed after.

What mattered more than the controls was the ceremony. Nobody opened production casually. You knew you were doing it, your team knew, and someone was going to read the log.

That ceremony wasn’t designed by your organization. It came with the platform, and it did the essential work before any control did: it made the change visible as a change, which is the precondition for governing one at all.

More than that, the transport enforced the separation of authority from judgment. The person who wrote the code was structurally not the person who approved it into production. That wasn’t culture. It was the system refusing.

Run Business AI seriously and a third path opens, and it has no ceremony whatsoever.

Prompt templates and their versions. Model bindings and version pins. The grounding corpus an agent reasons against. Tool permissions, destinations, runtime bindings, the agent’s own identity and what it may touch.

Every one of those can change what happens to a purchase requisition. None of them feels like a change.

Editing a prompt feels like configuration. Reloading a grounding set feels like data maintenance. Repointing a model version feels like an administrative task somebody does on a Tuesday. Nobody checks out a firefighter ID to edit a prompt. Nobody’s pulse moves.

The second subsidy: the guard door was architectural

The other thing SAP gave you free was a narrow interface.

For thirty years, reaching into SAP meant RFC, IDoc, later OData — a small, enumerated, hard-to-extend set of doors. That mattered organizationally more than technically.

Your enterprise has had two development cultures for two decades. The SAP team: ABAP, configuration, functional consultants, transport discipline. And everyone else — .NET, React, Power Platform, full-stack — who moved to Git a decade ago and never looked back.

They coexisted because the terms of contact were set on the SAP side. The two teams met constantly — integration design, API definition, interface specs. Connectors existed. Power Platform could reach SAP and some organizations tried it.

But the SAP team didn’t build the doors — SAP did. What the SAP team held was admission. They knew where the interfaces were. They granted the access. And nothing anyone built reached production unless an SAP person moved a transport.

That last one was the binding constraint. A platform developer could build whatever they wanted and point it wherever they wanted. It didn’t matter. Without a transport, it never arrived.

Which means the second subsidy was enforced by the first. Exposing an interface was itself a transported object. These weren’t parallel gifts — one was the mechanism for the other, and that’s why they’re being withdrawn together rather than by coincidence.

The two cultures rarely admired each other. Each looked negligent from the other side, because the consequence that justified the other’s discipline wasn’t visible from where they stood — external audit and restatement risk on one side, rollback and an apology on the other.

Contempt is a poor basis for a control boundary. Neither side audits a group it has already dismissed.

Agent-to-agent protocols and MCP exist specifically to remove the narrowness. Any capable agent can discover and call an exposed capability without a hand-built integration. So the guard at the door isn’t being bypassed — the door is being replaced by something that has no frame, and the exposure decision moves off the SAP team’s desk.

What SAP has actually built, because most commentary gets this wrong

It would be easy to write this section as a list of things the vendor hasn’t done. That would be inaccurate, and out of date by about a quarter.

Joule Studio reached general availability in May 2026 with Git-based deployment giving versioning and rollback out of the box. Its architecture documentation states that logging, audit logging and telemetry are provided by the runtime, and that operational controls are structural features rather than afterthoughts.

The SAP AI Agent Hub is a vendor-agnostic registry that inventories agents, models and MCP servers regardless of who built them, governs the lifecycle from proposed through to decommissioned, and surfaces verification status inside Joule Studio and Integration Suite. It adds identity and access control on SAP Cloud Identity Services, session-level observability through Cloud ALM, agent mining through Signavio, and org chart mapping through SuccessFactors. Cloud ALM ships bundled with every RISE and GROW subscription at no additional cost.

That is a serious governance architecture, shipping quickly.

Now look at the calendar. Everything material lands in Q3 and Q4 2026 — the managed Joule Studio a business user can reach through a browser, the Agent Hub, agent identity, session observability, and the inference tracing an auditor would actually ask for. Design-time access is free through the end of 2026 and post-promotion pricing hasn’t been published.

Everything arrives at once, this quarter and next.

And there’s one more piece. SAP’s autonomous migration tooling now performs system analysis, custom code remediation, configuration work and test generation on its own. That is not a tool that assists with change. It is a tool that makes change, across landscape boundaries, at a pace no human change manager reviews in real time.

Agents aren’t only downstream consumers of change any more. Some of them are change actors.

The organization hasn’t changed shape in thirty years

Here is the thing nobody says out loud.

The technology under SAP has churned continuously. Netweaver came and went. The Java stack came and went. HANA arrived and rewrote the database assumptions. The product has been renamed repeatedly. Through every one of those, the shape of the organization running SAP stayed identical: Basis, security, functional, development, with a centre of excellence bolted on for coordination.

Thirty years of relentless technology change that never once required a structural reorganization. That’s a remarkable run, and the reasonable inference is that this change won’t require one either.

That inference has been correct every previous time.

It isn’t this time, and the reason is the two subsidies. Every prior technology change left both intact. The transport still moved everything. The interface was still narrow. The organization didn’t have to change shape because the platform kept doing the coordination for it.

Which is also why the muscle doesn’t exist. Not because SAP teams are inflexible — because they were never asked. You don’t build a capability for a job the software was already doing.

Christian Klein put it plainly at Sapphire: “Moving to the Autonomous Enterprise requires serious change management. Adoption of AI goes hand-in-hand with business process change and end user enablement.”

He’s right. It’s worth being precise about what that turns out to mean.

The inventory lives in LeanIX. The observability lives in Cloud ALM. Conformance measurement lives in Signavio. Org mapping lives in SuccessFactors. Agent identity lives in Cloud Identity Services. The build surface lives in Joule Studio.

Six products, most of them owned in most enterprises by different functions with different budget lines and no shared governance forum. The tooling is real and it works. Assembling it into a control environment is an organizational problem — and assembly is precisely what the subsidies used to make unnecessary.

The tooling gap is closing this quarter. The tooling was never the part that took a decade.

“My tools still work. Why now?”

You’re right, and it deserves a straight answer rather than a manufactured deadline. Solution Manager runs to end of mainstream maintenance in December 2027, with extended maintenance carrying ChaRM further for those who hold it. Nothing breaks tomorrow.

But ChaRM was installable in weeks. What took ten years was the roles, the change advisory board, the approval paths, the retrofit discipline, the SoD matrix, and the accumulated instinct in a handful of people for when to ask a question.

Waiting for the tooling to be finished means starting the ten-year part a decade late.

This week

The first useful move is definitional, and it’s free.

Your change process almost certainly defines a change as something captured in a transport request, or something requiring a system open. Both definitions are now too narrow, and the gap between them is where the third path sits.

If this object changed overnight and nobody was told, could a business document post differently tomorrow?

If yes, it’s a change. It belongs inside your control envelope — whatever moves it, whoever owns the tooling, and whether or not a transport request will ever exist for it.

That test catches the prompt, the grounding corpus, the model version pin and the tool permission set. It excludes a great deal people currently escalate unnecessarily. And it’s short enough to survive a steering committee, which matters more than elegance.

Then the harder question: for each thing the test catches, who approves it — and are they allowed to be the person who wrote it?

If the answer involves three products and two departments, you’ve found the actual work.

There’s a role in there that doesn’t exist on anyone’s org chart. Somebody has to own the boundary between agents and applications — what’s exposed, to whom, with what authority, evidenced how. It isn’t Basis. It isn’t security. It isn’t the platform team. It’s the seam between them, which is exactly why it has no owner today.

What I’m not saying

I’m not saying the vendor is behind. On the evidence, SAP is moving faster on agent governance than most of its customers are moving on agent adoption, which is an unusual position for a platform vendor to be in.

I’m also not saying you need to buy something. A category of vendor is forming around this gap and their analysis is often accurate. But their conclusion — that you need a new change management platform — is a commercial position, and it’s the wrong shape for the problem. What was withdrawn wasn’t a tool. It was an organizational capability the tool used to supply, and no product replaces that.

Two structural subsidies underwrote SAP change governance for thirty years. Both are being withdrawn in the same quarter. What replaces them is a set of capable products that only becomes a control environment once somebody assembles them.

Assembly is the one thing the subsidies always did for you.

For about a decade that was accurate, and it was useful. It meant the deployment decision was an operating-model decision — who runs the infrastructure, who patches, who holds the SLA — and not a capability decision. The software was the software. Where it ran was a separate question with separate economics.

That sentence expired in October 2025, and I don’t think enough people noticed.

Shared foundation, separate scope

The 2025 release shipped on 8 October 2025. Same ABAP Platform underneath both editions. Same release date. Same seven-year maintenance window running to December 2032.

Shared foundation, in other words. But not shared scope.

SAP’s own release documentation states the position plainly: AI capabilities and intelligent agents are available exclusively in SAP S/4HANA Cloud Private Edition — now branded SAP Cloud ERP Private — while on-premise SAP S/4HANA 2025 receives core functional enhancements.[1]

One more scope note, because leaving it out would be its own kind of misleading. There’s a third deployment model — public edition, now branded SAP Cloud ERP — and it isn’t part of this comparison at all. It runs on a separate, multi-tenant codebase with its own continuous release cadence, outside the numbered 2025/2027 releases this piece is about. It’s also not behind: public edition has had Joule since November 2024, nearly a year ahead of private edition’s embedded layer, and continues to pick up new agents on its own schedule. If you’re on public edition, this specific split isn’t your split — but the pattern underneath it is the same one: deployment model, not capability demand, decides when and whether you get the agent layer.

The on-premise edition is not being abandoned. It gets real improvements — finance, asset management, service, sales, the ABAP development experience. These aren’t consolation prizes. If your 2027 target state is a well-run, current, functionally complete ERP, on-premise 2025 delivers it.

What it does not get, as part of the release, is the agent layer.

What the line actually separates

Both editions can reach AI. That’s the part people get wrong in the other direction — they hear “no AI on premise,” and that isn’t true either.

The supported on-premise pattern is real and it works. S/4HANA exposes OData. A BTP application reads it with principal propagation, calls the orchestration service, and returns a result. For plenty of use cases that is entirely sufficient.

But look at what you have once it’s built. A capability sitting next to the system. Someone has to leave the transaction, ask it a question, read the answer, come back, and act. Three steps where the process had one — and a decision point that lives outside the audit trail of the thing it changed.

On the other side of the line, the agent isn’t a separate application you built. It’s licensed as part of the product and embedded in the same screen — the user never leaves the transaction to consult it.

That is the difference, and it is not a feature-count difference.

One edition lets you build AI your people can consult. The other licenses AI that’s already embedded where the work happens.

Anyone who’s run a rollout has watched this pattern before, wearing different clothes. Enable Now content is supposed to track the system as it changes. Six months after go-live, how much of what shifted during hypercare actually made it back into the training material? Test automation is supposed to keep testing the system — how many of those scripts still run, and how many died the slow death updating them always does once something else is on fire? Neither tool failed. Staying current was a separate decision every time, and separate decisions are the first thing hypercare kills.

That’s the general shape of it: adoption is a function of how many decisions a capability costs, not of the capability itself. Put an agent beside the transaction and it costs one every time — open it, ask it, act on the answer, same as opening Enable Now instead of just working. Put it inside the transaction and it costs nothing. There’s no separate decision to lose to hypercare, because there’s nothing to open.

The price isn’t money

Every capability gap in SAP’s history has had a price on it. License the add-on. Buy the module. Build it on the platform. Pay a partner to close it. That is what a gap normally is — a purchase you haven’t made yet.

This one has a price too. It just isn’t denominated in money.

At Sapphire in May 2026, SAP reversed a years-long position and announced that Joule assistants and agents would be extended to ECC and on-premise S/4HANA. That was real news, and anyone still describing the boundary as absolute is working from a 2025 picture.

Then read the conditions. Access requires beginning the migration through RISE with SAP and committing the majority of the landscape to SAP Cloud ERP. SAP’s own product documentation for ABAP AI on on-premise releases — 2025, 2023, 2022 and 2021 — says availability is subject to the special RISE contract conditions announced at Sapphire, and tells you to verify entitlement and contract status with your account executive before planning adoption.[2] SAP’s leadership has framed the whole arrangement as an interim bridge rather than a long-term commitment to on-premise AI.

So it is purchasable. There’s still no SKU. What there is instead is a qualification.

That distinction matters more than it sounds. A SKU can be scoped. You can pilot it on one plant, buy a limited quantity, expand if it works, walk away if it doesn’t. A qualification can’t be scoped, because the thing being priced isn’t the capability — it’s your estate. There is no line item for AI on three plants. There is a commitment about where the majority of your systems will live, and the capability arrives as a consequence of it.

The only currency that buys the agent layer is deployment model. That was true as an architecture observation in October 2025. Since Sapphire it’s true as a contract term.

That is an unusual sentence to be writing about an ERP in 2026, and it is why the pre-2025 sentence has to come out of your architecture document. It didn’t merely become inaccurate. It became a sentence that hides a decision.

The honest counter-argument

The strongest objection to all of this is that the boundary is already moving. Sapphire proved the line isn’t fixed. Cloud-first is what every vendor does with AI — the infrastructure, the metering and the model access all live there — and it doesn’t follow that on-premise is being deliberately starved. If SAP extended AI to on-premise once, under pressure from an installed base that isn’t migrating fast enough, it can extend it again on better terms.

That’s a fair reading and I’d hold it loosely rather than dismiss it.

But notice what actually moved. The capability crossed the line; the dependency didn’t. The extension is conditioned on landscape commitment, delivered side by side rather than inside the transaction, and described by SAP as a bridge. The boundary didn’t dissolve. It got a toll booth, and the toll is denominated in exactly the currency this piece is about.

That’s a weaker form of “the gap is closing” than it first appears. Plan for the dependency holding. Be pleased if it loosens.

What this changes

Deployment model now determines feature availability, not just operating responsibility. That’s a different conversation with a different set of people in the room.

For an architect, any decision that rested on the old sentence needs re-examining. Not necessarily reversing — re-examining.

For a CFO, the comparison is no longer hosting cost against hosting cost. It’s hosting cost against hosting cost plus a capability set available on one side only, on terms that price your estate rather than the feature — and whose 2027 pricing isn’t published on either side yet, which makes the comparison harder rather than easier.

For a program, the deployment decision may already be made. If any capability in your 2027 target architecture depends on the agent being inside the transaction, you don’t have a deployment choice. You have a deployment consequence to accept.

Here’s how you find out which one you are. List the AI-dependent capabilities in your 2027 target architecture. For each one, ask a single question: does the value depend on the AI being in the transaction — or only on it being available to the person doing the transaction?

If everything on your list is the second kind, you have no problem here. Build it on BTP, keep the deployment decision where it belongs — sovereignty, control, cost structure — and ignore the rest of this. That’s a legitimate outcome, and more organizations should reach it deliberately rather than by default.

If anything on your list is the first kind, the decision is already made. What remains is when you say so out loud.

Twenty minutes. A list and one column. Better you run it than a steering committee — because the version that surfaces in a steering committee arrives as a budget request, and this was never a budget question.

Search your architecture documents for the sentence, or any variant of it. If it’s in there, it’s describing a product that stopped existing in October 2025. The point isn’t to make you move. It’s that where you run should be a decision you made, rather than an assumption you inherited from a document written in 2023.

If you hold an on-premise SAP maintenance agreement, you have a perpetual licence to Solution Manager. SAP says so directly: customers with on-premise maintenance agreements retain the perpetual licence and can continue using Solution Manager after the end of mainstream or extended maintenance.

So 2027 is a support date. Corrections stop. Your right to run the software doesn’t.

It gets better than most people realise. If you take the optional extended maintenance for Business Suite 7 — the one that costs two percentage points on your maintenance basis and runs to the end of 2030 — you receive extended maintenance for Solution Manager 7.2 at no additional cost. Not a separate purchase. Included.

And the extended maintenance scope isn’t a token subset. Per SAP Note 3255311 it covers requirements management, project management, process management, test suite, change control management, IT service management and landscape management.

Change control management. ChaRM is in scope, to 2030, at no extra cost.

I’ve seen this described repeatedly as paid extended maintenance for selected functions. That framing is wrong in both halves, and it’s worth knowing which one you’re actually looking at before you build a plan around it.

The second date

Now change one variable.

Solution Manager usage rights are included in on-premise maintenance agreements. S/4HANA Cloud — including private edition — comes with its own cloud maintenance agreement.

RISE includes Cloud ALM. It does not include Solution Manager. If you move fully to RISE and retain no separate on-premise maintenance agreement, you have no Solution Manager usage right at all.

Not at end of maintenance. At the end of your on-premise agreement.

That’s a different kind of event, and the difference is the whole point of this piece.

An on-premise customer has a support problem. A RISE customer with no remaining on-premise agreement has an entitlement problem — and its date sits in their contract, not on SAP’s maintenance roadmap.

Exactly when that lands is a contractual question, not a roadmap one. It depends on when your on-premise maintenance agreement terminates — which is why the first action below is to confirm it in writing rather than assume it.

For an organisation converting during 2026, that clock may already have started, before the one everyone is planning around.

What travels with it

For organisations that built change governance on ChaRM — transport control, approval workflow, the release calendar, the audit trail internal audit has been shown for a decade — this isn’t a tool swap.

It’s the rebuild of the control framework that SOX evidence, release governance and segregation-of-duties testing currently rest on.

Test Suite goes the same way. So do process documentation and monitoring. Focused Build and Focused Insights are included in Solution Manager’s usage rights and follow the same maintenance conditions, so they travel with it too.

One precision point, because overstating this is the fastest way to lose an argument with someone who has read their own paperwork. RISE supplements have historically granted narrow web self-service rights inside Solution Manager Enterprise Edition — raising support tickets, checking status, confirming them, and change approvals directly related to those.

Supplement wording changes between versions. Check yours rather than taking mine. But whatever the current text says, understand what that entitlement is: a support interface. It is not ChaRM, and it will not carry a release process.

Three remedies, and what each actually costs

The first is to keep an on-premise maintenance agreement. If you retain any SAP product under on-premise maintenance, the Solution Manager entitlement survives — along with the perpetual licence and, if you’ve taken it, extended maintenance to 2030. For organisations moving only part of the estate, this is often already true and needs confirming rather than solving. It’s also the remedy most likely to disappear quietly, because as the remaining on-premise footprint retires, the entitlement retires with it. That’s a dependency with its own expiry date, and I’ve not yet seen an organisation tracking it.

The second is to subscribe to Solution Manager, private cloud edition. This is a real offering from SAP Enterprise Cloud Services, created specifically to give cloud-only customers access and usage rights to a Solution Manager 7.2 system in the private cloud. Worth knowing what you’re buying before anyone quotes it: it comes in two versions, and only the full stack carries what you’d recognise as Solution Manager. SAP is also explicit that it arrives unconfigured — basic configuration and process customising are yours to do or yours to pay for, on top of the subscription. So the cost isn’t the subscription. It’s the right tier, plus rebuilding your configuration in a new system, while running everything else. And the 2027 maintenance date still sits underneath it. This is a bridge, not a destination.

The third is to move to Cloud ALM. That’s SAP’s stated direction, entitlement is included with cloud subscriptions and Enterprise Support, and free usage runs to a baseline that covers almost every customer. It’s also, by SAP’s own account, not at parity — SAP says directly there is no feature parity between the two platforms. Whether Cloud ALM covers your ChaRM configuration is a scoping exercise, and it’s the one I’d run first, because the answer determines which of the three remedies you’re actually choosing between.

The shape of what’s being asked

You move your change governance — the control framework that produces your audit evidence — onto a new platform, on a deadline, while simultaneously running a conversion, a release upgrade and an integration rebuild. Same people, same twelve months.

And if you’re going to RISE, the clock on the thing you’re leaving may already be running.

That’s not an argument against Cloud ALM. Cloud ALM is where this is going, the entitlement is included, and it’s increasingly where agent observability lands too — which matters more every quarter.

It’s an argument against discovering the sequencing in month nine.

Why it’s missing from the business case

Because it isn’t a cost. It’s an entitlement change, and entitlement changes don’t generate a line item.

The RISE business case has a subscription figure, a migration figure, an infrastructure figure and a change-management figure. It rarely has a line for rebuilding change governance — because nobody costed it. The tool was always just there, included in an agreement that had been renewing since before most of the current team joined.

So start by establishing which clock you’re on. Confirm in writing whether you retain a Solution Manager usage right under your current agreement structure, and when that agreement actually terminates — that date, not a roadmap date, is the one that governs you. If the answer is yes via an on-premise agreement, find out what happens to it when the remaining on-premise footprint retires. Check whether you already hold extended maintenance for Business Suite 7, because if you do you have ChaRM to 2030 at no additional cost and considerably more room than you may think. Then scope Cloud ALM against your actual ChaRM configuration — not against Cloud ALM’s feature list, but against your approval workflow, your transport control, your release calendar, and whatever your external auditor has been shown for the last five years. The gap between those two lists is the real scope of the transition, and it’s a number you can produce in a fortnight.

This is one of five separate SAP clocks stopping in the same December, and the other four compete for the same people — which is next week’s problem.

Things that were always there don’t get costed. They get discovered.

It will tell you what the change does. The scope, the objects touched, the fields affected. It is precise, it is complete, and it is almost certainly accurate.

It will not tell you that somebody in the room said this wouldn’t hold up.

That isn’t a flaw in how your specs are written. It’s what a document is. Every artifact your organization keeps was composed after the decision was made, and each one records the outcome as though it were the only option on the table. The alternatives aren’t suppressed. They’re just not what the document is for.

Call it the winner’s account.

What gets deleted

Most objections raised in a design meeting are preference. Two people want to load the dishwasher differently. Either approach works, the dishes come out clean, and the argument is a tax on everybody’s afternoon. Nothing is lost when that objection disappears from the record, because there was nothing in it.

Then there’s the other kind. Occasionally somebody understands a downstream consequence the people deciding genuinely cannot see. Not because those people are careless — because it isn’t visible from where they’re standing. The design assumes master data discipline the organization doesn’t actually have. Or process consistency across sites that was never true.

Those two objections sound exactly the same when they’re raised. Same tone, same confidence, same I’ve seen this before. Which is precisely why the second one gets talked past — at the moment it’s spoken, it’s indistinguishable from the first.

The record deletes them both, equally, without knowing which was which.

And it isn’t the big decisions this happens to. Those have paper — a business case, a steering committee, somebody’s signature. Ask why the company moved a product line to make-to-order and you’ll get an answer, because the whole organization knew why at the time.

It’s the decisions one level down. The rule inside the design. The tolerance. The threshold that’s fifteen and not ten. The scoping call that put something in two plants and not the third. Individually too small to justify a document. Collectively, they determine how the process actually behaves.

Why nobody kept it

The obvious explanation is negligence, and the obvious explanation is wrong.

Think about what keeping it would have required. At the moment an objection is raised, nobody knows which kind it is — that’s the whole problem. So you can’t keep the important ones. You’d have to keep all of them, indexed and searchable, held for a decade against the possibility that one turns out to matter.

The technology was never the obstacle. Search engines have been indexing and ranking unstructured text since the nineties, and doing it well. What you couldn’t do was have one. That capability was the entire product of a company — you used theirs, or you did without.

And indexing a haystack to find a needle you can’t yet describe is not a business case anybody funds. So every organization made the same call: keep the decision, discard the discussion. Every one of them was right to. At those prices, the winner’s account was the rational record.

What changed isn’t the capability. It’s what it costs and how long it takes — and the second one matters more than it sounds.

A capability you can’t reach inside the decision window isn’t a capability you have. An answer that takes eighteen months is not available to a question being settled this week. That’s the sense in which this wasn’t possible: not that the techniques didn’t exist, but that nothing they produced could arrive while it still mattered.

Retrieval over unstructured text, by meaning rather than keyword, has gone from a program budget and a quarter to a rounding error and a few minutes. Which removes the binding constraint — you no longer have to know in advance what’s worth keeping. Every previous attempt at this failed in the same place: somebody had to decide, at the moment of capture, what would matter later. And the objection that matters is precisely the one nobody flagged, because if anyone had known it mattered they’d have acted on it at the time.

The other half arrived without anyone deciding anything. Your meetings are being transcribed. Not because it was planned — because it became free and nobody turned it off. Most organizations now generate more hours of recorded discussion in a month than in the previous decade.

And a transcript has a property nothing else in your estate has. It was produced during the decision rather than after it. What’s in there is the thinking process — how the group weighed it, what got set aside, which option somebody argued for hard and lost. Both kinds of objection are in there, still unsorted, which is exactly right, because nobody could sort them at the time either.

What it’s costing you now

This stopped being a philosophical problem about six months ago.

Point AI at a process and ask where the waste is. It’ll tell you. A mandatory field nobody needs, where everyone types whatever gets them past it. A step that exists twice. A rule that applies to one plant and nowhere else. A tolerance tighter than anything downstream requires.

The analysis is right, and it’s cheap now. That work used to be a consulting engagement. It’s an afternoon.

Then somebody has to decide what to remove, and that’s where it stops.

Because each of those was decided by a person, in a room, for a reason — and four years on, the reason is gone and the rule is still there. What happened in between is the part nobody notices. The rule didn’t fail. It degraded: right most of the time, quietly wrong at the edges, in exactly the circumstances the objection was about. Nobody raised a defect, because nothing was obviously broken. Somebody built a workaround and after a while stopped mentioning it.

Longer still and it isn’t a workaround. It’s just how the process works. There’s nobody to blame, because there’s nothing left to blame.

So you’re holding a list of inefficiencies and you can’t tell which ones are load-bearing. And the two mistakes aren’t the same size. Leaving it costs a little, forever — and that cost was absorbed years ago. Taking it out might cost a lot, on one specific Tuesday, and everyone will know who did it.

Nobody takes that trade without information. So it stays. And so does the next one, and the forty after that.

The finding got cheap. The risk didn’t.

And your content strategy won’t catch it

There’s a version of this that people think they’ve already solved.

It comes up when you stand up a data platform, or scope an AI project, or replace a document system. Somebody has to decide what gets pulled in, indexed, and governed, and what stays where it is, reachable through an API when someone needs it. Important gets materialized. Everything else stays connected.

It’s a sound model, and someone on your team will build that list well. Contracts, specifications, policies, the documentation that took years to assemble. Every one of them produced on purpose, with a title and an owner and a version.

The list will be right, and the thing you actually need won’t be on it.

Because it isn’t content. It’s what people said on the way to producing the content — a passage in the middle of a conversation about something else. It won’t come up in the scoping session. Nobody will argue for excluding it. It isn’t on the list because it was never a candidate.

Your platform will hold everything your organization decided. It just won’t hold why.

The questions nobody asked

Everything above assumes somebody objected. Often nobody did.

The room didn’t have the person who’d seen it go wrong before. Or they were two levels down and not invited. Or they were in a different function and it never occurred to anyone that this touched them. The decision was made carefully, by capable people, and the thing that mattered went unmentioned because nobody in the room knew to mention it.

There’s no erasure there. There was nothing to erase.

Which sounds like the harder problem, and in one meeting it is. Across two hundred, it isn’t — because the same questions turn out to be missing over and over. The one about who reads this downstream. The one about what happens at period close. The one about whether the data will actually arrive that way. They’re not exotic. They’re just not on anybody’s list, because no list exists.

And this is where something genuinely did change, rather than getting cheaper.

Every previous approach required knowing what you were looking for before you started. Define the schema, write the rules, pick the terms to index. The system could only surface what somebody had already thought to specify — which is precisely useless against a blind spot, because a blind spot is by definition the thing nobody specified.

You can’t index an absence. There’s no keyword for nobody asked what happens at period close. Finding it means reading a discussion, knowing what discussions like it usually contain, and noticing what this one is missing. That isn’t retrieval at any price. It’s new.

And it works off the same record. What a room did discuss is what tells you what it didn’t.

Which makes the thing worth building toward something other than an archive. Not a store of what was said — a working set of the questions this organization has learned it needs to ask, assembled from the ones it kept failing to ask.

Your senior people already carry a version of that list. They built it the way everyone builds it: something went wrong, and they never forgot to check again. It took them twenty years, and it leaves when they do.

Where to start

Ask what your transcripts are being used for. If the answer is summaries and action items, you’re extracting the part you already had — somebody was capturing that before, and now it happens by itself. Useful, and not the valuable part.

Then ask your team which workaround they’d most like to be rid of. They’ll have an answer immediately; people carry these. Ask why the underlying rule works that way, and who argued against it at the time.

You probably can’t recover that one. But the rules nobody will be able to explain in 2030 are being decided in your design meetings this quarter, and that part is still in front of you.

The reasoning that would explain the one you’re stuck with happened in a room, four years ago.

Your organization did the thinking once. It just didn’t keep it.

I asked what the field was for. He said that was it — just add the field. It was on the list he’d been given. So I asked what data would go into it, and what would consume the data once it was there. He didn’t know. Neither, it turned out, did the person who’d asked for it.

The change was correct. It would have transported cleanly and broken nothing.

It didn’t go, and not because he’d done anything wrong.

I’ve thought about that exchange a lot this year, because the thing that stopped it working is about to stop working generally.

What approval actually is

Here is what I do as a final approver, roughly in this order.

I want a clear description of the change and the process area it sits in. Then the scope — which company codes, which sales organizations, which divisions. I’m establishing boundaries, because most of what goes wrong later turns out to have been sitting just outside the boundary somebody drew.

Then the change itself and what it does. I have enough exposure to follow it and to ask questions. Where I’m not sure, I ask for an explanation.

Then testing, which is where the real risk lives. Not whether they tested — everyone tests. What was the scope and breadth. What was actually executed. Did anyone test for failure, or only the happy path. What are the variables. What is downstream.

Then the administrative tail, which is unglamorous and is where cutovers die. Transport status. Fields complete. Back-out plan. Impacts of moving — do we need to restart integrations, update a certificate, open the system to finish the job. Anything external.

And then organizational change. Which documents need updating, which training material, how this gets communicated, to whom.

Read that list again and notice what isn’t in it.

I never claim to read the code.

Every step is a question addressed to somebody who can be asked a follow-up. The gate isn’t an inspection of the artifact. It’s an interrogation of the account — and what it establishes is not whether the change is technically correct, but whether anybody thought about it.

That distinction sat harmlessly in the background for as long as the only way to sound like you’d thought about something was to have thought about it.

The side door

Most of the conversation about AI in enterprise systems is about agents acting autonomously. Posting documents. Executing transactions. Deciding.

That isn’t where we are, and framing the risk that way misses what’s already happening.

The thing that’s already happening is smaller and much harder to see. The person still does the work. They use AI to explain it.

Sometimes that’s a genuine gain. Someone understands more than they otherwise would have, because they asked good questions of a good tool and followed the answers. I’ve seen people come out of that exchange sharper than they went in.

Sometimes it’s a thin understanding papered over with fluent, well-structured, entirely plausible answers.

From the approver’s chair, those two are identical.

Because the gate was never measuring understanding directly. It measured whether somebody could explain — and until very recently, you couldn’t explain a change you didn’t understand. Explanation was a reliable proxy, so nobody had to think about the difference.

That correlation is what broke. Not the process. Not the workflow. The thing underneath both of them that everybody was relying on without naming it.

The questions that still work are the ones about the decision rather than the change. What did you consider and reject? Who did you have to talk to? Why this option and not the other one? The change sits in the system and anything can describe it.

The reasoning only exists if it happened.

Point it at the artifact

There’s an obvious response to all this, and it’s the wrong one: put AI on the approval itself. Score the change, recommend approve or reject, move the queue faster.

Wrong layer. And it’s the layer most of the tooling conversation is aimed at.

Go back to my list and sort it differently. Not into hard and easy — into what’s about the artifact and what’s about the decision.

Establishing the org footprint is about the artefact. Reading a test plan to work out whether failure paths were covered is about the artifact. Tracing outward from changed objects to find what consumes them is about the artifact. Transport status, field completeness, back-out plan, integration restarts, certificates — all artifact, and most of it deterministic.

Nearly the entire list is artifact.

It requires no seniority. It takes time. It’s the reason approvals sit in queues, and it’s the first thing that quietly stops happening when a date is close.

Research is everything about the artifact. Judgment is everything about the decision.

That line is the whole design. Everything on the artifact side can be assembled, cross-checked, and put in front of an approver as a brief — under two conditions, without which it makes things worse rather than better.

Every conclusion carries its evidence, traceable to the object, the configuration entry, the test result. My own gate depends on being able to say I’m not sure, explain that. A brief that can’t be interrogated has replaced a consultant I could question with a summary I can’t, which is a downgrade wearing efficiency’s clothes.

Concerns are ranked, not listed. A brief flagging forty items teaches the reader to skim it, which is a slower and more expensive version of rubber-stamping.

One item on that list deserves correcting, because most people place it wrongly and I did too. The downstream trace — what else touches this, what breaks quietly — feels like the part that needs an experienced human. It isn’t. A person can only check what they thought to check, and under delivery pressure they think to check less. That’s precisely the step a machine does better, and precisely the step most often skipped.

What doesn’t automate

Every organization has three or four people who make the difference at this gate.

Individual contributor, then manager, then back to hands-on. SME in one area, generalist across five. SAP, and everything hanging off it — the integrations, the reporting layer, the third-party systems nobody has a current diagram for.

What you’re paying them for isn’t SAP knowledge. You can hire that.

It’s three things at once. They know how a business like this one operates. They know how systems behave, and how they tend to behave together. And they know what’s actually sitting in your environment right now.

The first two travel. The third doesn’t.

You see it in a lot of places — in estimates, in what they push back on, in who they tell you to go and talk to. It’s sharpest in the questions they ask before a change goes.

Not does the field work. Anyone can check that. Something closer to: this new field is going on the sales order — which reports pick it up, which integrations have to change, and what happens when it hits the data lake?

Now notice what’s already in the system by the time that question gets asked.

The spec. The config. The test evidence. All documented, all still there in five years.

The question is the only thing the review adds. And it’s the only thing nobody keeps.

Which is backwards, when you look at it. The answer applied to one change. The questions apply to every field anyone adds from here on.

Where the learning goes

So there are two things happening at the same gate, and they pull in opposite directions.

On one side, the account arriving at your desk is getting more fluent and less reliable as a signal, because the tool that produces good explanations produces good-sounding explanations too, and you can’t tell them apart by reading.

On the other, the work that takes the time — the artifact side, the research, the cross-checking — is exactly the work that can now be assembled before anybody senior looks at it.

Those aren’t in tension. They’re the same shift arriving from two directions, and the response to both is the same.

Move the machine to the artifact. Keep the human on the decision. And then capture the questions, because the questions are the part that doesn’t survive anything — not documentation, not handover, not the end of a contract.

The research part of a review is the same in every company. Scope, boundaries, downstream, test coverage. None of it changes when the name on the building changes.

The questions are the part that doesn’t travel. Yours come from what this organisation has already lived through, and from people who won’t be here forever.

Capture enough of them and the review starts asking about the reporting layer before anybody senior walks in.

That part nobody can sell you. It only exists where it was earned.

The SAP AI Signal · signal.cogniteer.io

SAP Access Control 12.0, Process Control 12.0 and Risk Management 12.0 all reach end of mainstream maintenance on 31 December 2027. Extended maintenance runs to 2030. After that, customer-specific maintenance only.

That much isn’t in dispute.

The scope is wider than three products

Seven products convert into the successor release. The three above, plus audit management, business integrity screening, and the UI masking and logging components.

Most organisations are tracking one of the seven — usually access control, because that’s the one with an audit finding attached to it. The other six move on the same schedule.

The prerequisite

This is the part that changes the shape of the decision.

The successor release requires SAP S/4HANA 2025, or SAP S/4HANA Foundation at that release level.

Your control platform is downstream of your ERP decision. Not adjacent to it. Downstream.

So it’s a sequence, not a set of choices

ECC, then S/4HANA 2025 or the Foundation, then the new GRC release. Two legs. One deadline. In that order.

That distinction matters because most organisations are treating these as parallel workstreams. The ERP programme has an owner, a budget, a steering committee. The GRC platform has a different owner, usually in risk or internal audit, with its own budget and its own committee. Both are tracking 2027. Neither has the dependency on their plan.

Working the calendar backward

Take the second leg first. It’s the one people underestimate.

A GRC migration — scoping, configuration, ruleset rework, testing, user acceptance, cutover — is commonly estimated at twelve to eighteen months. Treat that as an estimate rather than a fact, but it’s the right order of magnitude for anyone who has done one.

Now the first leg. An ECC to S/4HANA move is measured in years, and it has to be complete — not started, not in wave two — before the GRC leg can begin.

Work backward from December 2027 and the decision date sits well inside 2026. For most organisations that means this year, not next.

What the frozen path costs

The obvious response is extended maintenance. Take the three years, sequence calmly, land it by 2030.

That’s legitimate and a lot of organisations will do it. But it should be bought with a clear view of what it contains.

A release in extended maintenance keeps running. What stops is everything behind it: security patches, legal and regulatory updates, support for new modules. And by definition, new capability — a frozen release receives corrections, not features.

Which means anything that ships in a future release ships somewhere you aren’t. Including agent governance. Agent identity, registries, runtime controls, evidence trails — all of that is future-release work, arriving in versions after the one you froze, during precisely the period when agents show up in your estate.

Extended maintenance buys time. It doesn’t buy capability. Those are different purchases and the business case usually only prices the first one.

On cost: SAP publishes an extended-maintenance premium of two percentage points on the maintenance basis for its Business Suite 7 core applications. Whether the same figure applies to the GRC products specifically is worth confirming with your account team rather than assuming — it isn’t stated in the same place.

What this piece is not about

Three things deliberately left out, because each one deserves its own treatment and none of them changes the sequencing argument.

Third-party support is a real option used at scale, and it changes the ERP question. It doesn’t remove the control-platform question.

If you’re running S/4HANA public cloud, most of this doesn’t apply to you in the same form.

And SAP Cloud Identity Access Governance is a different path with no S/4 prerequisite. It’s also, by independent assessment, narrower than access control on segregation-of-duties depth and emergency access. That’s a comparison worth doing properly, and this isn’t it.

The honest caveat

The end-of-maintenance dates are firm. The successor’s availability is planned, and those plans have already moved once.

That cuts both ways. It argues against rushing to a release that isn’t stable. It also argues against assuming the deadline moves because the successor did. SAP extended ECC once and a lot of people read that as a pattern. It might be. Plan as though it isn’t.

Where to start

Not with a migration plan. With two questions.

Which leg are you on — and is it actually complete, or complete for the entities that matter?

And who owns the sequence? Not the ERP programme. Not the GRC platform. The dependency between them.

If the answer to the second question is a shrug, that’s the finding. It’s also the cheapest thing on this page to fix.

The identity platform confirms the agent is authorized to act on that account. The audit log captures which agent made the change, and when. Every control fires correctly. Every dashboard stays green.

Nobody can answer the only question that matters: should those terms have changed, on that customer, at that point in the order lifecycle?

That question doesn’t live in the identity platform. It doesn’t live in the audit log. It lives in the credit policy, the customer’s payment history, the order’s current state, and a threshold that exists in somebody’s head and in a slide deck from 2023.

Permission is not legitimacy

We spent two decades building controls that answer one question. Was this permitted? Roles, authorizations, segregation of duties, approval hierarchies. That machinery is good, and it was built for a world where the thing taking the action was a person who already knew the business.

Agents need a second question nobody built for. Was this correct?

Those are different questions. They live in different systems, and no product on the market merges them — though several will tell you otherwise.

An agent can be fully authorized and still do the wrong thing. When it does, nothing in your stack raises its hand, because from the stack’s point of view nothing went wrong.

Question 1 — Who authorized it?

This part is genuinely being solved, and solved well. Worth saying plainly, because most writing on agent governance is unrelentingly grim and this half isn’t.

Agent identity is consolidating the way single sign-on consolidated. Agents get their own identities, scoped permissions, an owner of record, and a revocation path. The identity layer is estate-agnostic by nature — it doesn’t need to know what a delivery document is — so it federates cleanly across systems, and the vendors doing it are converging fast.

If your organization runs Microsoft 365, you already have the substrate for this whether anyone deliberated about it or not. If you’re heterogeneous enough to have brought in a dedicated identity provider, you likely have a stronger version.

Your CISO is already on this one. Let them run it.

Question 2 — Where can it actually be stopped?

Here the received wisdom is wrong.

Most buyers assume governability is a property of the agent — that you control the agents you bought from your vendor, and the foreign ones are the problem.

Microsoft documents the actual mechanism candidly in its own guidance: calls that don’t reach the identity platform can’t be evaluated by its access policies, carry no risk signal to calculate, and can’t tie an audit record to a specific user. An agent endpoint that doesn’t require authentication is a reachable, ungoverned surface — regardless of who built the agent behind it.

That runs both directions, and both directions matter. A third-party agent onboarded properly and routed through a governed path is controlled. Your own vendor’s agent, reaching a resource through a static API key, is not.

Governability follows the route, not the logo.

So when a vendor tells you they govern all your agents, they’re answering a narrower question than the one you asked. They govern what crosses their path. That’s real, and it’s worth having, and it isn’t the same as knowing your business.

For a real estate the consequence is this: one consequential action touches three or four systems, and the ones that can stop it are frequently not the one that can judge it. A workflow platform mediates the request and can block it — it owns the route. The identity platform can revoke the agent’s access — it owns the credential. But the transaction lands in your ERP, and only the ERP knows the order’s current state, the credit segment, the exception in play.

Question 3 — What determines it was valid?

Nobody has a clean answer for this one, and it’s where your exposure lives.

Validity isn’t a property of the agent, the credential, or the route. It’s a property of the situation: this customer, this order, this point in the lifecycle, this operating mode, this exception. Answering it takes the process state, the transactional rules, and specific knowledge of which deviations from the standard path are legitimate.

Some of that lives in your application. Some lives in a policy document. A great deal lives in the head of a process owner who has no console, no admin rights, and no ability to stop anything.

The person who knows whether the action was legitimate is usually not the person who can prevent it.

Why grounding doesn’t answer question 3

The instinctive fix is to make the AI understand your business — ground it in your own documents, your history, your transactions. Reasonable instinct. It’s also where a specific kind of trouble starts.

Your transactional history records what happened. It doesn’t record what should have happened.

It doesn’t capture what alternatives were available and rejected, why an exception was approved, which rule was waived, or which outcomes were tolerated because it was quarter-end and the shipment had to move. A completed transaction proves something occurred. It proves nothing about whether it was correct.

Stacked on that is the long tail. A few paths carry most of the volume. Then there’s a tail of rare variants — some entirely legitimate, like the consignment arrangement that bills on consumption; some workarounds for problems nobody fixed; some the scar tissue of a master-data error that’s been quietly generating exceptions for two years.

In the transactional record, all three look identical. A legitimate-looking path with a document at the end.

Ground an agent on that and you don’t get a system that understands your business. You get one fluent in your history, including the parts you’d never have approved.

Your history is not your policy.

Grounding can teach an agent how your company has behaved. Something else has to tell it which of that behavior was right — the explicit, machine-readable statement of what must be true before an action commits. That layer is the one almost nobody has built.

The platform vendors have seen it coming. Both major process-intelligence players are building a governed layer designed to hold exactly this kind of business knowledge: rules, constraints, guardrails for agents. Some of it is shipping, some is in beta, some is on the roadmap for later this year. Read the documentation closely and you’ll notice something else. They’re building the container and asking you to fill it.

That’s the honest state of the market. The artifact is being standardized. The authoring is still yours.

The test: trace one action

Don’t start with a vendor evaluation. Start with one action.

Pick something consequential an agent could plausibly do. Change payment terms. Release a blocked order. Confirm a production order. Then trace it:

• Who created or sponsors this agent? A named human, not a team.

• On whose behalf does it act? Its own identity, or someone’s delegated authority?

• What authorizes the action? Identity plus policy — and is there a path that bypasses both?

• Where can it actually be stopped? Name the enforcement point. If you can’t, that’s the answer.

• What determines the action was valid? A rule, a state check, a process model — or a person who would just know?

• What records the reasoning and the result? And can you join those records afterward?

• Who owns the exception when it goes wrong? By name.

The reason to run this now rather than later: it works before you deploy. It doesn’t require agent sprawl. Most organizations don’t have it yet — roughly one in six has an agent in production, while about two in five enterprise applications are expected to ship with one embedded by the end of this year.

The gap between those two numbers is the window you’re in.

The clock isn’t the vendor roadmap

If this reads like an architecture problem you can schedule for next year, one detail deserves your attention.

The control frameworks are moving. Internal control expectations are now being written to reach directly into AI system architecture — model lineage, deployment approvals, decision logs, dependency mappings treated as production-readiness artifacts rather than documentation assembled afterward. And the retention clocks are already running: six months for high-risk systems under the EU AI Act, and in US financial services a six-year default under FINRA’s books-and-records rule, with SEC periods running three to six years depending on the record class.

When the control framework moves, external audit follows. The requirement arrives on somebody else’s schedule, and it doesn’t wait for a vendor category to exist.

You may be asked to reconstruct an agent’s decision before anyone has sold you a way to do it.

What would change my mind

One claim here is load-bearing and unproven: that no platform currently validates an autonomous agent’s action against live transaction state, across multiple systems, before it commits.

Neutral platforms already do far more cross-system process work than most buyers realize — reconstructing business objects across different applications, detecting deviations from an intended process, triggering remediation. That’s real, and more mature than the skeptics allow.

What I couldn’t find in any public production case is the pre-commit version: an agent proposes an action, the action is judged against current state across systems, and it’s allowed, escalated, or blocked before anything is written.

If that exists in a named production customer, this analysis narrows considerably, and I’d want to know. Until then, treat “we govern your agents” and “we can tell you an action was wrong” as the same claim at your own risk.

Where to start

Not with a control tower.

Trace one action. Find out where it can be stopped, and what decides whether it should be. The gap between those two answers is the thing to fix first — and it will be more specific, more fixable, and considerably cheaper than whatever is currently in your evaluation pipeline.

There is a market ready to sell you exactly that. It is large, it is growing fast, and it is full of genuinely good technology. And most of the companies that buy into it never get to production.

That failure rate isn’t a knock on the tools. It’s a signal — and once you understand what it’s signaling, you understand the whole context layer problem better than most of the people selling into it. So this piece is about the build-your-own path: who’s selling it, why it stalls, and the one distinction the entire category depends on you not noticing.

The market you’re about to walk into

If you go looking to build your own context layer — your own knowledge graph, your own semantic backbone for AI — you’ll find a mature and crowded field waiting for you. There are graph databases that have run in production for a decade. There are semantic-layer tools that define your metrics once and serve them everywhere. There are ontology platforms with deep academic pedigree, RDF engines, entity-resolution systems, and a new wave of “build your graph faster” accelerators that promise to turn your existing tables into a graph with a few clicks. The analysts size this market in the billions and climbing at north of 20% a year. It is not vaporware. Some of these are excellent, serious pieces of engineering.

And here is the number that should give you pause before you sign anything: by most industry estimates, fewer than one in six of these projects makes it past the pilot stage. The rest stall — not on the technology, but on something the technology was never going to solve for them. The buyer guides, written by the vendors themselves, are surprisingly honest about where the bodies are: projects die on ontology design, on entity resolution, and on a slow realization that arrives six to nine months in. Teams discover they’ve started accumulating — the vendors’ own words — “custom validation layers and semantic constraint logic that grows faster than the core application.”

Read that phrase again, because it’s the whole story hiding in plain sight. The tool gave them a graph. Then they had to hand-build, on top of it, an ever-growing pile of logic that checks whether the thing in the graph is right. And that pile grew faster than everything else, because the tool didn’t provide it and was never going to. They didn’t buy a context layer. They bought an empty engine and slowly discovered they’d signed up to build the hard part themselves.

To see why, you have to see the distinction the market is built on blurring.

Two things both called “knowledge graph”

The words “knowledge graph” get stretched across two things that are not the same, and the gap between them is where your project lives or dies.

The first is a generalized knowledge graph. It’s an engine for representing any entities and any relationships. It knows how to store the fact that A relates to B, how to let you query the connection, how to infer that if A contains B and B contains C then A contains C. What it does not know is anything about your business. It arrives empty. “Customer,” “order,” “delivery,” “billing block,” and every rule connecting them is something you have to pour in yourself. The engine is domain-agnostic by design — that’s its selling point, and it’s exactly why it’s crowded and increasingly cheap. A general graph engine is a commodity, and the market knows it, which is why every vendor is racing to add “AI-assisted” graph-building to make the pouring-in feel faster.

The second is a domain-specific knowledge graph. This is one where the domain’s real entities, relationships, and rules are already encoded — where the graph doesn’t just know that an order relates to a delivery, but knows what a correct order-to-delivery-to-billing sequence looks like, and therefore what a broken one looks like. It knows that a delivery with no invoice behind it might be a revenue leak or might be a perfectly legitimate consignment that bills later — and it knows which questions to ask to tell them apart. The rules aren’t poured in by the buyer. They’re native, because someone who understands the domain built them in.

Here’s the move the market makes: it sells you the first and lets you believe you’re getting the second. The demo shows a graph answering business questions beautifully — because the demo was hand-built by experts who poured in exactly the right domain knowledge for exactly those questions. Then you buy the engine, point it at your data, and discover it’s empty. The “AI-assisted graph builder” extracts your tables and their relationships — it reads your schema and infers that this table joins to that one — and calls the result a knowledge graph. But it has only extracted structure. It has learned what your data is. It has learned nothing about whether your work is right, because that isn’t in the schema to extract.

Why the domain graph can’t be extracted — only encoded

This is the hinge, so let me be precise about it.

Everything the generalized tools can automate is a form of extraction. They read what already exists — your tables, your columns, your foreign keys, your query history — and they structure it. Modern ones do this well; they’ll auto-generate an ontology from your database and save you weeks of documentation. But extraction has a hard ceiling: it can only surface what’s already written down somewhere. And the thing that decides whether your work came out right is, definitionally, not written down. It’s the difference between what your system recorded and what your business intended — and intent doesn’t live in the schema. A delivery record doesn’t carry a field that says “this one’s a legitimate consignment, that one’s a leak.” That judgment lives in the process, in the exceptions your business has run for years, in the heads of the people who know which is which. No amount of reading the tables extracts a rule that was never in the tables.

Which means the domain graph — the one that would actually catch the problem your AI is about to miss — cannot be generated. It has to be authored, by someone who carries the domain rules that were never written down and can encode them. That’s not a limitation the next release of the tool fixes. It’s a category boundary. Extraction and authorship are different acts. The entire generalized-graph market is an extraction market, priced and built for a problem — “structure my existing data” — that is genuinely being commoditized. The thing you actually needed sits on the other side of a line the tools can’t cross, because it was never a tooling problem. It was a knowledge problem wearing a tooling costume.

This is why the projects stall at exactly the six-to-nine-month mark. That’s how long it takes to build the graph, point it at production, and discover that the graph doesn’t know which exceptions are real — and to start hand-writing the “validation logic that grows faster than the application.” That growing pile is the domain graph they didn’t buy, being built by hand, by people who are learning the domain rules the hard way because no tool handed them over.

What this means for an SAP customer specifically

If you run SAP, this distinction is not academic, and it cuts sharper for you than for most.

Your ERP is the most domain-specific system you own. Decades of your business’s actual operating logic are encoded in how your order-to-cash, procure-to-pay, and record-to-report processes actually run — including every legitimate exception that looks like an error and every quiet error that looks fine. A generalized graph tool pointed at your SAP data will extract the structure beautifully: it will learn your tables, map your relationships, auto-document your fields. And it will know nothing about whether a given transaction did the right thing, because that knowledge was never a table. It’s the operating reality on top of the tables.

And yes — this is the moment to talk about the graph you were just handed. At Sapphire this spring, SAP put a knowledge graph at the core of its new platform: 452,000 tables, 7.3 million fields, by SAP’s own count — fifty years of ERP engineering made machine-readable. It is the largest structural extraction ever shipped, and it’s genuinely useful. Now run it through the same test. It encodes what SAP’s tables mean — SAP’s meaning of SAP. It does not, and cannot, encode whether your transaction did the right thing, because your operating reality was never in those tables either. SAP’s CEO says customers store their most mission-critical domain know-how in SAP. What’s stored is the record of what you did. What was never stored is whether it was right.

One more wrinkle before you point any tool at those tables: as of this spring, SAP’s API policy gates what autonomous tooling may extract at all — third-party AI extractors now need an endorsed pathway. So even the extraction half of this market has an access question hanging over it. That’s a different essay.

So when a vendor — or an internal team, or a systems integrator — proposes to “build you a knowledge graph for your SAP data so your agents have context,” the question that separates a production system from a stalled pilot is simple: are you extracting my structure, or encoding my rules? If the answer involves pointing an AI-powered tool at your tables and generating a graph, you’re getting the first, and you’ll meet the wall at month six. If the answer involves someone who actually understands how your specific processes run — in project mode, in steady-state run, in cutover, in hypercare, at quarter-close — sitting down and encoding what correct looks like across all of those, you’re getting the second. Those are different projects with different price tags and, more importantly, different outcomes. Most of what’s being sold is the first, dressed up to look like the second.

The one line to carry out of this

The build-your-own-context-layer market is real, and for the problem it actually solves — extracting structure from your existing data — it’s mature and worth buying. But that was never the problem that breaks your AI after go-live. The problem that breaks your AI is the layer that knows whether your work came out right, and that layer can’t be extracted from anything, because it was never written down. It has to be authored by someone who carries the domain.

That’s why the largest technology companies keep shipping the first at ever more heroic scale and calling it the second, why the graph-tool market can’t sell it to you no matter how good the demo looks, and why one in six of these projects reaches production while the rest quietly discover they signed up to build the hard part by hand. The generalized graph is a commodity. The domain graph is the moat. And the reason the whole industry keeps selling you the first while you need the second is that the first can be manufactured — and the second can only be known.

Next time: if the domain graph has to be authored rather than generated, what does authoring it actually look like — and how do you tell, before you commit a budget, whether the people offering to build yours can tell a real exception from a broken one?

Here is what I have noticed, though, from a different seat. The VP running applications at a mid-market manufacturer, the one whose team keeps the SAP estate alive, is not in those rooms. And the fight that will actually determine whether their company’s AI works is not the fight about agents at all. It is a quieter fight, one layer down, that almost nobody outside the data-platform world is narrating for an SAP audience — and the two largest vendors in that company’s life are already deep into it, wired directly into each other, each betting the other is about to lose.

The fight is over who owns the context layer. And it is worth understanding, because whoever wins it sets the terms for every AI decision that company makes for the next ten years.

What the context layer actually is, in one plain paragraph

Strip the branding off and it’s simple. An AI agent, on its own, is a capable stranger. It can reason, but it doesn’t know your business — that revenue is computed your way, that a customer relates to an order through your particular process, that the thing labeled one way has meant another since a reorg years ago. The context layer is whatever supplies that knowledge. It’s the difference between an agent that gives a confident, plausible, wrong answer about your business and one that gives a right one. Everyone in the industry now agrees this layer is where the value is — one vendor calls the problem of an agent starting without it the “cold start” problem, which is a good name for it. The disagreement — and it is a large, expensive, strategically loaded disagreement — is over who gets to own that layer for you.

Two answers are being fought out in public right now. They are not subtle, and they are not compatible.

Microsoft’s answer: live in our house, and everything else becomes a guest

Microsoft’s play is the most straightforward land-grab in enterprise software, and they are not hiding it. The stated strategy is to make their data platform the center of gravity for your entire data estate — one place where all of it lives, or at least is seen, governed, and activated. Their pitch is that the fragmented mess of systems every enterprise actually runs should resolve into a single logical home, and that home is theirs.

Watch what that does to your ERP. In the Microsoft picture, your SAP system doesn’t stay the center of your operational world — it becomes a source. Its data is mirrored or shortcut into the unified lake, sitting alongside your documents, your spreadsheets, your collaboration history, your email. And then — this is the part worth sitting with — Microsoft builds a context layer over that combined pile and offers to ground every agent in it. They’ve even started building the application surfaces that traditionally lived around the ERP: the order-management screens, the vendor portals, the exception queues — the operational work that today runs in spreadsheets and manual report-pulls. The logic is coherent and, honestly, compelling: if your company already lives in this vendor’s documents, email, and collaboration tools every day, making that the home for your business’s meaning is a small, natural step. Your ERP becomes one connected room in a house someone else owns.

For a company whose people spend their whole day in that vendor’s productivity tools, this is a genuinely strong offer. It meets them where they already are. That is exactly what makes it dangerous to accept without noticing what you’ve handed over.

SAP’s answer: keep your data anywhere, but the meaning is ours

SAP is not conceding the house. It is fighting on different ground, and the ground it chose tells you everything.

SAP’s counter, said almost precisely this way by one of its own reference customers, is that compute can happen anywhere and the data can stay at the source — but business context is managed once, centrally, in SAP’s foundation.

Read that again, because it’s a genuinely clever move. SAP is effectively saying: fine, Microsoft, host the data, we won’t fight you for the storage. But the meaning — what your order-to-cash actually is, how your processes actually relate, the semantics that came from decades of running your business on our software — that’s ours, managed in our layer, and you’re all just borrowing it.

SAP claims this layer goes beyond a simple knowledge graph to model “how your business actually works, not just what the data says.”

So the collision is clean. Microsoft says the data lives in my house. SAP says host it wherever — the meaning is mine. Both are claiming to be the context layer. They are claiming it from opposite directions, and both claims can’t win.

The tell: they’ve wired themselves together instead of going to war

Here’s the detail that turns this from a vendor cage-match into something more interesting and more revealing. Microsoft and SAP are not blocking each other. They’re interconnecting. SAP’s foundation and Microsoft’s lake now share data bidirectionally, zero-copy, with SAP’s models publishing natively into Microsoft’s environment and Microsoft mirroring SAP’s data into its own. On the surface, that reads as partnership. Underneath, it’s the opposite: it’s two companies who’ve each concluded that their layer is the one that will matter, so they can afford to be generous about the layer they think is becoming a commodity. Microsoft will happily let SAP’s meaning flow in, because Microsoft is betting the home is what wins. SAP will happily let its data live in Microsoft’s lake, because SAP is betting the meaning is what wins. The friendliness is the confidence. Each is giving away the thing it thinks is losing.

And it isn’t only these two. The large data-and-AI platforms are making a third version of the same bet — be the context layer that sits across everyone’s estate, SAP and Microsoft included, grounding every agent from the middle rather than from a home or a system of record. Which tells you how big the prize is: not one major vendor has looked at this and decided it isn’t worth owning. They have all concluded the same thing — whoever owns the meaning of your data owns the account. The whole industry is racing to own this layer from every direction at once.

Which raises the question the whole race is stepping around.

The layer nobody is fighting for

Notice what every one of these context layers actually models. Microsoft’s, SAP’s, the data platforms’ — read their own descriptions and it’s the same thing every time: the definitions of your customers, orders, products, revenue, and the relationships between them. What your data means. That’s the layer being fought over, standardized, commoditized, and claimed from four directions.

It is not the layer that decides whether your AI works.

Here is the distinction that the entire agent conversation is missing, and I want to be precise about it because it’s the whole point. There are two completely different things an AI has to understand about your business, and they get collapsed into the one word “context” constantly.

The first is what your data means — revenue is computed this way, a customer relates to an order like so. This is the layer Microsoft and SAP are at war over. Definable, model-able, and — because the whole industry is racing to own it — on its way to becoming a commodity.

The second is whether your work actually came out right — this order shipped but was never billed, is that revenue quietly leaking or a legitimate arrangement that bills later; this step happened out of sequence, does that break the transaction or is it a valid exception your business has run for years. Not what the data means. Whether the thing that happened was the thing that was supposed to happen.

No context layer in this fight models the second one. And here’s the part that should stop you: the vendors know the second one is the real risk. SAP, describing why you need its context layer, warns that without it agents can “optimize for the wrong outcome.” That’s precisely a whether-your-work-came-out-right problem — and SAP, having named it exactly, answers it with a what-your-data-means solution. Everyone in this race is selling the meaning of your data as the cure for a problem that lives in the meaning of your work. The two are not the same layer, and the gap between them is where enterprise AI actually fails.

That gap is invisible in the agent conversation because it’s invisible in a demo. A demo runs on clean data and the happy path, where the work did come out right and a confident reading happens to be correct. Production is where the exceptions live — and production is where the layer nobody’s building would have earned its keep.

Why this matters more for the SAP customer than for anyone else

Put the two things together and you can see why the VP of Apps at a CPG manufacturer is in a stranger position than the CIO reading the analyst reports.

The context war is happening above their head, in a vocabulary they don’t live in, between two vendors they can’t avoid — one hosting their estate, the other owning their meaning, both wired together and both certain they’ll win. Whatever the outcome, that company’s SAP data will end up grounded in someone’s context layer. That part will get solved; four of the largest technology companies in the world are competing to solve it.

But the thing that determines whether their AI survives go-live — whether it can tell a real problem from a legitimate exception in their specific order-to-cash, across the messy operating reality of a live business — is the one layer nobody in the war is building. It won’t arrive as a product from Microsoft or SAP, because it can’t be defined once and shipped the way a semantic layer can. It has to be understood, in the specific, by someone who knows how that business actually runs in every mode it runs in. That knowledge doesn’t live in a data platform. It lives in the practitioners who’ve watched the process behave across a go-live, a quarter-close, a cutover, a quiet month — and it is the least documentable, least commoditizable thing in the enterprise.

And sit in the CIO’s chair for a second, because this is where it stops being a strategy story and becomes your problem. Whichever way you go, you are choosing where your business’s meaning lives — and that is a more permanent decision than where your data lives. Move your data and you pay a migration cost, once. Move your meaning — re-encode what your business means inside a different vendor’s layer — and you may find you simply can’t, because by then a thousand agents, reports, and decisions depend on it computing exactly the way it does today. Owning the semantic layer is stickiness for the vendor. For you, it is the most durable dependency you will take on this decade, and you are being asked to grant it to whichever side wins a fight you didn’t know you were in. That would be a defensible bet to make deliberately. Almost nobody is making it deliberately.

The one line to carry out of this

The agent conversation is loud, and it’s loud in the wrong rooms. One level beneath it, two giants are fighting over who owns the meaning of your data — and they’re so confident it’s the prize that they’ve wired themselves together and started giving away everything else. They might both be right that it’s worth owning. They are both missing that it isn’t the layer that decides whether your AI works.

Whoever wins the war for the context layer, the same question survives it, unowned: does your AI actually understand whether your business did the right thing? The meaning of your data is being fought over by the largest companies in technology. The meaning of your work is still sitting in your own people, un-modeled, unclaimed, and — for now — entirely yours.

And if your instinct at this point is fine, then I’ll have someone build that layer myself — hold that thought. There is a whole market now selling the tools to do exactly that, and most of the companies that buy them never reach production. Why that happens, and what it reveals about which layer is actually hard, is where this goes next.

That’s the layer worth watching. Not because a vendor is about to win it. Because none of them is even fighting for it.