On stage, someone types: why won’t goods receipt post against purchase order 4500012345, line 30? The agent reads the error, follows the order to its configuration, finds the over-delivery tolerance that tripped, and explains it in seconds. It’s a real capability, and it gets better every quarter.

Now the same problem, the way it reaches a support queue on a Monday morning: Goods receipt won’t post for material 400_AX17. Urgent.

Were they receiving against a purchase order? Posting an inbound delivery? Issuing components to a production order? Moving stock between storage locations? You don’t know the plant. You don’t know the order. You don’t even know it was a purchase order, or a goods receipt at all.

Nobody was careless. The person who wrote it knows exactly what they were doing and which message stopped them, because they’ve been looking at it for twenty minutes. Everything an agent would need is in their head.

The demo started with a question that was already answerable, because someone made it that way before the session began. Behind that one purchase order sat a company code, a purchasing organization and a plant. Tolerances configured. A supplier and a material, loaded and clean. The agent didn’t find any of that. It followed a path someone else had built. What you saw on stage was the happy path, at the end of an implementation. Monday morning is everything the test script left out.

We’ve done this before

We know how implementations begin. Every SAP project gets built in the same order, and anyone who has lived through one could recite it half asleep.

First the organization: company codes, plants, sales organizations, the skeleton everything else hangs on. Then the configuration: pricing procedures, account determination, the rules for how the business runs. Then the master data: customers, suppliers and materials, loaded and reconciled against the old system. Then testing: unit tests, string tests, integration tests, each one proving a little more of the process holds together.

Nobody starts with an inbound IDoc creating a sales order, a background job releasing the delivery, the warehouse picking and shipping it, and the invoice posting before the truck clears the gate. Lights-out order-to-cash is where an implementation ends up, not where it starts.

Data conversion taught the same lesson the hard way. The load tool was never the hard part. The hard part was the model: building the data dictionary, deciding what every field had to mean so execution and reporting could both run on it, and living with the trade-offs where they pulled in different directions. Once the model was right, the cleansing was a grind: spreadsheets, VLOOKUPs, record-by-record matching for weeks. Hard work, but you knew what you were aiming at, because the model told you. Mock loads tested the model. Cutover made you commit to it.

Everyone started at the transaction

Then AI arrived. Read the keynotes, the vendor announcements, the posts in your feed. The agents are reprocessing the failed IDoc, releasing the delivery, clearing the billing block. That work matters, and it’s coming. But we’re starting it in the order we spent thirty years learning not to.

In my own lab, most of the agents I build point the other way.

Point an agent outward, at the work, and it acts on a business process. Point it inward, at the system, and it builds what every outward agent will need. Same models, same tools, same skills. Different target.

The difference is smaller technically than people assume, and bigger in consequence. An inward agent is the digital employee who stitches the project together: the meeting transcript where a decision was made, the user story in Jira or Azure DevOps that carried it, the design document that explained it, the change that built it, the test script that proved it, and the ticket that came in yesterday because of it. Its work compounds: every pass makes the next answer cheaper to produce and easier to trust. An outward agent consumes that work. Without it, the outward agent is a very fast new hire on their first day, handed the keys to every shared drive and project tool and told to figure it out. It’s all there. It’s scattered, some of it contradicts the rest, and nothing says which version is true.

The first inward agent most organizations need is the least glamorous one. It reads each new artifact as it arrives and ties it to what’s already there. One connection at a time, it builds the map every other agent will depend on. It doesn’t answer anything. It makes the next answer possible.

The most important line on that map is also the hardest to draw. A project team talks in processes, RICEFs, design decisions and test scripts. The system only knows what actually changed. For thirty years, that meant the transport. Now some of what changes the system’s behavior never touches one: an agent promoted through a Git pipeline, a skill switched on in a cloud tenant. The reasons live in the project’s language, and the truth lives in every path a change can take. Connect the two and every other agent has something to stand on. It’s harder than it sounds, and it’s getting harder.

Whose foundation?

If foundations come first, the obvious question is whether SAP is already building them. It is, and more of it has shipped than most people realize.

SAP’s Sapphire 2026 keynote promised to show how SAP provides the foundation of applications and data that AI needs.1 Part of that is already real. SAP’s knowledge graph describes the S/4HANA data model across 452,000 ABAP tables, 80,000 CDS views and 7.3 million fields,2 and SAP’s MCP servers give agents a supported way into the system.5 That floor is SAP’s to build, and SAP is building it.

Think back to the implementation, though. S/4HANA isn’t software you install and push to users. It’s closer to a framework, and the implementation is the work of deciding which parts matter to your business and how they fit. The industry spent thirty years learning to do that well. Today there’s SAP Activate, best practices for nearly every process, and system integrators with methodologies decades deep.

Your floor

SAP’s layer is built from SAP’s standard. Your Z fields didn’t come from SAP. Neither did your enhancements, your custom reports, the interfaces to your warehouse system and your carriers, or the plant that has been using a standard field to mean something else entirely since go-live.

That last one is the dangerous one. A graph built from SAP’s standard will describe that field confidently, by its standard meaning, and be wrong.

Joule will answer questions about SAP’s processes well. Your agents have to answer questions about yours.

SAP’s roadmap acknowledges this floor. Its architecture guidance names custom fields, custom APIs and tenant-specific configuration, and describes a customer-specific knowledge graph as the long-term vision.3 The next phases bring SAP-managed customer data, then content customers curate themselves.4 Neither has shipped yet, and dates have moved. That’s normal for something this new.

When they arrive, they’ll be one good place to put what makes your business yours. Not the only one. If you’re still on ECC, SAP’s packaged path doesn’t reach you today. And plenty of organizations will think hard about where their meaning should live, and what it costs to keep it there.

Either way, a place to put it isn’t a model of it, and this model isn’t configuration. Configuration is multiple choice: a field is required or it isn’t, a value comes from a dropdown. This is the essay question.

Take one line from a standard operating procedure in that shared drive, the kind your agents will read: a supervisor must approve, should review, or may override. To a person, those are shades of the same instruction. To an agent, they’re three different rules, and it will act on the difference whether anyone meant it to or not. Lawyers have spent centuries defining words like these, and internet standards wrote theirs down in 1997.6 Most businesses have never had to. Somebody now has to decide what goes in, what each word in it means, and who owns the answer when it changes.

And this time there’s no playbook. There’s good theory, and a handful of people who have done it once. There’s no Activate for meaning yet. The temptation will be to load everything, the way we once rebuilt the AS/400 inside SAP rather than decide what mattered.

What would you build on it first?

Wherever your foundation ends up living, whether inside SAP’s platform, alongside it, or under a system SAP’s AI doesn’t reach yet, the work is the same, and it’s yours.

So imagine it’s done. Every ticket, decision, change and document connected, and the meaning behind them settled. What would you point it at first?

• Your support queue, researched before anyone opens a ticket.

• Your next enhancement, checked against everything it will touch before anyone writes the spec.

• Your next rollout, starting from what the last one learned instead of starting over.

• Your Joule use cases, chosen by where the questions actually come from.

• Your first agents, placed where the map says they’ll do the most good.

Your answer tells you where to start building.

The playbook for this doesn’t exist yet. It’s being written by the people who start first.

Everyone at Sapphire will be showing you the agent. Ask what it’s standing on, and who built it.

The transport request carried an owner, a release, an import history and an approver. When an auditor asked what was running in production on a given date, the system answered without anyone having to remember. Nobody designed that as a governance program. It came with how changes moved.

SAP TechEd opens in Berlin this week. On October 8, SAP described the new Joule Studio as “soon to be generally available.” The lifecycle it has published is worth reading closely.

The pipeline is real

SAP’s own training material lays out the path. You describe the outcome you want. Joule Studio produces a requirements document, then a technical specification, then code. Before release, it runs automated evaluations and produces a test report with pass/fail results. The solution deploys to an SAP-managed runtime, and AI Agent Hub governs it from there.

Version control is built in. In SAP’s words, “Solutions are pushed to GitHub for review and repeatability.”

Git gives you full history, real diffs and review before merge. The evaluations give you evidence before release. That’s good engineering.

So the question isn’t whether the pipeline is sound. It’s whose habits come with it.

Change Control and Change Enablement

SAP has already named the difference. In its Cloud ALM training, SAP calls ChaRM and Focused Build “Change Control,” the stricter model, and Cloud ALM “Change Enablement,” the more flexible one. Those are SAP’s words, not mine.

They describe two cultures. SAP teams have spent careers in a world where an error in production is a failure: someone explains it, and the fix goes through the same gates that should have caught the mistake. Teams raised on Git work from a different assumption. You move fast, and if something breaks, you roll it back.

Git-style controls for ABAP have existed since 2019, when SAP shipped the Git-enabled Change and Transport System with S/4HANA 1909. I’ve never heard of a team that actually adopted it. Nobody publishes an adoption figure, and I looked. Transports already did the job, and the audit evidence was built around them. Nothing forced a move.

Agents force it. An agent definition, a prompt or an evaluation set doesn’t travel in a transport. For this kind of change, the Git pipeline is no longer optional. It’s how SAP builds.

Each culture is right about the thing it was built for. The trouble starts where they meet.

What a revert can’t reach

Rolling back works when the code is the only thing that changed.

Take an agent that creates credit memo requests for pricing disputes. On Tuesday someone changes its instructions. By Thursday it has created two hundred requests, and billing has already turned most of them into credit memos. On Friday the team reverts the agent to last week’s version in one clean commit.

The agent is fixed. The documents are not.

In SAP, you don’t delete a billing document. You cancel it with another document that points back to it, and every step stays in the document flow. That’s by design, and it’s why finance teams trust the system. It also means the cleanup is a business process with a cost, not a Git command.

A revert undoes the agent. It doesn’t undo what the agent posted.

So for agents that write to SAP, the control has to sit before production, where SAP teams have always put it. This isn’t a case against the pipeline. It’s a case for building the signature into it.

Named, not described

SAP knows a sign-off belongs there. Its lifecycle material says tracing, metrics and logging support “production sign-off.” Its announcement of the new Joule Studio mentions “controlled deployments.” AI Agent Hub holds agents that haven’t passed governance checks “in a pending state until cleared.”

SAP’s recommended Joule landscape runs Development, Test and Production and says to “promote qualified changes to production.” It’s the shape of change control, and the same people run it. What it doesn’t say is what carries the approval from one tier to the next, or what proves production is running what QA approved.

All of that names a sign-off. Nothing SAP has published that I could find says who signs, what gets recorded, or how a change to an agent links to a change request the way a transport does.

TechEd may fill some of this in. Either way, the record is yours to define, because only you know which agents touch which documents.

Write the record

Here’s what I’d require before any agent that writes to SAP goes live or changes. It’s the transport record, rebuilt for agents.

What changed. The definition, the instructions, the tools it can call, and the model and its version. If the model can be retired or swapped without a commit, record which version was approved.

Blast radius. What it can write, to which documents, how often, and under whose authorizations. An agent acting with a clerk’s roles and the same agent acting with a finance manager’s are not the same change, and QA tested it with test roles. Where a connection uses a technical user instead, the blast radius is whatever that user was granted, for everyone.

The evidence. The evaluation report for this version, not the last one. The test case has to be “what happens when it’s wrong,” not only “does it work.” It also needs proof that production is running the same version, model and configuration that passed QA.

Who approved. A named person with the authority to approve. SAP has already defined a role for this, the Agent Manager, typically an enterprise architect or IT governance lead. Make sure the role belongs to someone in your organization.

The way back. Not only reverting the agent, but how documents it has already posted get reversed, and who owns that.

Complete means complete. Training content checked, process documentation updated, test cases updated and rerun.

The roles shift with it. Everyone in the chain knows how to read the blast radius of a transport: the consultant, the tester, the change board, and Basis as the last line of defense. An agent’s blast radius sits where none of them were trained to look, and when the deploy command is the release, whoever runs it is making the call. The transport coordinator becomes a release owner who reads evaluation reports alongside import logs. The functional consultant who wrote test scripts now writes the evaluation set. No job goes away, but every one of them gets new things to read.

This week

Pick one agent you have in pilot, or one you plan to build. Have each person in the chain write down what it can post, to which documents, on which model, and under whose authorizations. Then compare the answers. Wherever they differ, or someone has to go ask, that’s where the record starts.

If you run Cloud ALM, a manual transport reference is one place to tie that record to your existing change process until something better exists.

Then take three questions to SAP or your implementation partner. Who signs the production sign-off? Where is it recorded? What happens to an approved agent when its model changes underneath it, or when a different user runs it?

The pipeline will get you to production faster than anything SAP has offered before. It just won’t sign off for you.

Each lead reads their status. On track. Two items complete. One date moved a week. Green, green, amber, green.

At 10:52 the program manager raises the one question that needed the whole room: do we start the second mock data load next week, or wait for the client refresh in two weeks? Three people start to answer. At 11 a.m. the call ends, and the decision moves to next week’s call.

By then, starting next week is no longer possible. Nobody chose to wait for the refresh. Moving the decision made it.

Everyone on that call is good at their job. The status was accurate. The meeting did what status meetings do.

Status is a fact. Show it.

Everything read aloud in the first 50 minutes was already written down. It is in the plan, on the board, in the workstream trackers. Dates are easy to get.

So put it where it already lives. Send it as a pre-read to the people senior enough to have it pushed to them. Leave it ready to pull for everyone else. Put it on the screen when the call starts, and don’t read it out.

The question “what changed since last week?” is answered before anyone joins.

A pre-read is only as good as the word “complete”

A pre-read works only if written status means what spoken status means, and the word that slips most is “complete.”

A change gets called complete when the configuration has moved. Nobody has yet looked at whether the training content needs to change, whether the process design document still describes what was built, or whether the test cases still test it.

Give “complete” its checklist: configuration or code moved, test cases updated and run, process design document updated, training content checked. Then a pre-read that says complete can be trusted without anyone asking.

The room has a memory now

Teams records the call and transcribes it. Copilot can read every meeting in a program before the director who owns it has finished her coffee.

So the words spoken in the room are now part of the record, and the question becomes which words are worth adding.

On Tuesday the answer was 50 minutes of status the record already held, and eight minutes of a decision that got made by default.

Spend the spoken time on decisions

Make the agenda a list of open decisions, not a walk through the workstreams. For each one, the chair asks five questions, and the people who know answer out loud.

1. What has to be true for us to decide?

2. What else does this impact?

3. What options did we rule out, and why?

4. Who owns the decision, are they here, and when is it due?

5. Any concerns we haven’t heard yet?

Here is Tuesday’s decision, run that way.

What has to be true? The target client has to be refreshed to include the latest configuration changes, and the data extract has to reflect the latest design decisions. The extract we have predates the last two design decisions.

What else does this impact? Every system integrated with SAP needs its master data aligned to the new load, or integration testing fails on mismatched customer and material numbers. The first one affected is the distributor EDI feed for one entity. In this program, “EDI” means four different vendor integrations depending on the company and the country, so name which one.

What did we rule out? Loading next week on the old extract. Data built to an earlier design would not tell us whether the load works against this one.

Who owns it? The data migration lead owns it and is here. The Basis team isn’t on this call, so the cutover lead confirms the client refresh with them by Friday, and the data migration lead makes the call on Monday.

Any concerns? One voice: if the refresh slips, there is no room for a third mock before the freeze.

That took about two minutes. In the room, “EDI” would have been enough, because everyone knew which feed. The second question is where words leave the room, so that is where they have to be exact.

Then check the dependencies

Status shows what each team is doing. It rarely shows what one team is quietly waiting on from another.

So before the call ends, each workstream lead answers two questions, in a sentence each:

What do you need from another team to finish next week’s work, and do they know?

What are you not getting to next week that someone else may be waiting on?

Master data needs the updated reporting requirements by Wednesday. Then the follow-up: from whom? Several teams own a piece of those requirements, and each assumed another was pulling them together.

That is the dependency nobody had written down, because nobody had claimed it.

In the last two minutes, the chair reads back the decisions and the dependencies that were named. Anyone who heard them differently says so while the people who could correct it are still there.

The stand-up version

The same rule holds at the daily stand-up. The board is on the screen, so nobody needs to read it.

Say out loud only what the board doesn’t show. Name the item by its number, not “this one.” Give a blocker its shape: blocked by what, since when, and what would release it.

The two dependency questions work here too, on a shorter horizon: what do you need from someone else today, and what are you not getting to that someone may be waiting on?

What the record holds now

The director asks on Friday what changed in cutover risk. The status was in the pre-read all along. What she finds now in the transcript is a decision with its conditions, a named impact, an option ruled out with its reason, a name and a date, a concern about the freeze, and a dependency nobody had claimed.

Status was always in the record. A meeting can add only what nobody has written down yet.

Two cautions

Report on the work, not the people. Tell everyone what is recorded, what is drawn out of it, and how it is reported. Report by decision and by topic. A transcript read as a log of who said what turns a working meeting into a performance review, and people start talking to the reader instead of to each other.

Ask, don’t infer. It is tempting to let software judge how worried the room sounded. In the EU, the AI Act prohibits systems that infer emotion in the workplace, and the Commission’s guidance ties that to voice and facial expression. The fifth question gets you the same signal by asking for it, and a concern someone chose to state is worth more than one a model detected. Check the specifics with counsel for the countries you operate in.

This week

Take your next status call. Send the status as a pre-read, put it on the screen, and don’t read it out.

Use the time for the two or three decisions that are open, and ask the five questions. Before you close, ask every workstream lead the two dependency questions, then read the decisions and dependencies back.

Then ask Copilot, or whichever AI assistant you use, to summarize this week’s call and last week’s, and put the two summaries side by side.

The rule, and why it worked

I have never seen anyone validate a stock requirements list by hand.

Not once. No project team I have worked with has counted the receipts and issues on an MD04 screen against the underlying tables to confirm that SAP got the arithmetic right. Nobody I know of sat down and verified, condition by condition, that every standard pricing condition on a sales order calculated correctly.

That was not laziness. That was the correct allocation of finite test effort. The mapping was deterministic, the vendor warranted it, and the failure mode would have been catastrophic and obvious rather than subtle and silent. So you tested your pricing routines, your custom fields, your user exits, your output determination - the things you built - and you trusted the rest.

Fiori inherited the rule without anyone needing to restate it. New tile, same logic: validate the custom fields, trust the delivered app. The underlying service was the same service, so the data was the same data.

The rule works because the boundary is visible. You can point at the custom field. You can point at the Z-program. The line between what is yours and what is the vendor’s is drawn in the repository, and it has been drawn there since the beginning.

What you built when you turned the skills on

Now activate a few dozen conversational skills.

Every one of them is SAP-delivered. By the old rule, the whole thing is trusted, and a test plan written by anyone experienced would say so - scope it, confirm a handful of representative responses, move on.

Except you did build something. You chose that set, skill by skill. Nobody at SAP decided which skills your business would run, in what combination, for which roles. That selection is a customer artifact with no vendor warranty attached to it, and the behavior a user experiences is determined as much by that selection as by any individual skill.

So is the vocabulary you taught the assistant. Every mapping from one of your words to one of SAP’s is yours, and nobody warrants that either.

None of it appears in a transport. It has no object type. There is nothing to point at in a scoping meeting, which is exactly why it falls off the test plan - not by decision, but by default.

The boundary did not move. It stopped being visible.

The five things between the question and the answer

Once the line is drawn correctly, what to test becomes obvious, and none of it is field validation.

Routing. Does the question reach the intended skill? With one skill this is trivial. With several dozen, more than one can plausibly match a given phrasing, and the selection is made across the set.

Extraction. Did it pull the right parameters - this order, this plant, this date range - out of how the user actually talks rather than how a test script writes?

Fidelity. Suppose the right skill ran, with the right parameters, and the service returned the right data. Does the answer represent that data faithfully, with the unit, the date and the context that give the number its meaning? A tile never restated the number in a sentence.

Completeness. The service returned fourteen fields and the answer mentioned three. Which three, and was the omission material to the decision the user was about to make?

Scope. Did it answer the question asked, or an adjacent question that sounded the same? This is where the ambiguity from two issues back lands - the assistant returning open order value to someone who meant unshipped units, or measuring past due against the confirmed date when the reviewer meant the date the customer asked for. Last issue’s gap lands here too: answering who are our top customers from the sold-to, for a sales lead who meant the accounts behind the distributor.

AI evaluation tooling has names for these: tool selection, tool input accuracy, tool output utilization, response completeness, intent resolution. What is new is that they now belong in an SAP test plan.

None of that is a question about the service. The service is the same service, and you should trust it exactly as far as you trusted the Fiori tile in front of it. What you are testing is whether the path from question to answer holds.

Negative tests, which you have never written

There is a category here with no precedent in any SAP test plan you have ever run.

SAP describes how selection works. Joule matches a request to the best-fitting skill, using the skill’s description, the user’s role, the conversation so far and the business context. The test trace in Joule Studio opens by showing which skill or agent was selected. Practitioners building custom skills advise testing in both directions: queries that should trigger the skill, and queries that should not.

That makes the test object selection.

You have never written a Fiori test script with a section headed queries that should not open this tile, because the user opening the tile was the user’s decision and the system had no opinion about it. Now the system has an opinion, and the opinion is testable, which means it is also wrong sometimes in a way that belongs to you.

That trace is a test tool. Find out what record you get in production, when a ticket arrives and somebody has to work out what the assistant actually did.

The part that is not a gate

The consequence changes the shape of the work rather than just its content.

If selection means the best fit among the skills available, then adding to the set can change behavior for what was already there. Activating one more skill is not an isolated change - it introduces a new candidate into every selection decision the system makes.

Nothing in your estate has ever worked that way. Activating a Fiori tile has never altered what an existing tile does. Adding a transaction has never changed what another transaction returns. Every surface you have ever added has been additive and inert with respect to the others.

That is worth establishing in your own tenant rather than taking on faith, and it is a half-day experiment: baseline a set of utterances, activate one more skill, run them again, and see whether anything moved. If it did, your acceptance testing is not a gate you pass once before go-live. It is a regression corpus, owned by someone, rerun every time the skill set changes.

And the set keeps growing. Every release delivers new skills, and like a support package, nothing runs until you activate it. Each activation is a change to the set.

Run this before your next activation. Write down twenty real questions your users would actually ask — their phrasing, not yours. For each, record which skill should answer, which parameters should be extracted, and what the answer must contain to be useful. Run them as one test user with a fixed role, starting a fresh conversation for each, because role and conversation history both feed selection. Then activate one more skill and run them again. If any answer changed, you have found the thing that has no precedent in twenty-five years of SAP testing, and you now know what your test plan is missing.

The rule still holds. Test what you built, trust what the vendor shipped.

What is new is that you built something you cannot point at - and testing it produces an artifact your estate has never needed. Not a test plan. A set of real utterances that goes stale the moment somebody activates a skill nobody thought was related.

There is no precedent for that one. You build it from nothing.

Most people say one.

SAP has four. Sold-to, ship-to, bill-to, payer - and the distinction is not pedantry. It exists because somewhere in the world a company orders from one address, receives at another, gets invoiced at a third, and is paid for by a fourth, and the standard has to hold all of that.

And those are only the four it insists on. It has room for the broker, the commission partner, the carrier, and anyone else with a role in the deal.

Most of your people will never need those distinctions. Some of them badly do, and have been quietly getting it wrong for years.

Now run it the other way. If you make cleaning and paper products and sell them through distributors, ask a sales lead who their customers are. You will hear about hotels, office buildings and hospitals, the accounts that buy your product from the distributor. Your business has a name for them: secondary customers. The distributor is the sold-to. The secondary customer is on the distributor’s invoice, not yours. Whether that data ever reaches you depends on the market and on what the distributor is willing to share.

So the gap runs in both directions. SAP is more precise than you in places, and you are more precise than SAP in others, and nobody has ever had to reconcile the two because nobody was ever speaking to the system in words.

Two options, and neither is free

When your word and the vendor’s word disagree, you have exactly two moves.

Align. Teach the organization to use the standard term. This is change management, and it is the kind that actually sticks, because the system reinforces it every day — people learn the word by using the thing. It is also slow, it is unpopular in the places where the old word carries identity, and it does not work at all on a term people have been using since before you implemented.

Bridge. Leave the language alone and make the system carry the translation. This is the option everyone reaches for first, because it appears to cost nothing and upsets nobody.

It costs something. Every term you bridge is a mapping you now own - forever, through every upgrade, in every language you operate in, maintained by someone who has to be told when the business quietly changes what the word means. Bridging is not avoiding the decision. It is choosing the option whose cost arrives later and lands on a different team.

And that cost just multiplied. Until now the translation lived in people. Someone knew that when sales said customer they meant the hotel, and built the report that way. An assistant has no such someone.

There is not one assistant. Every prompt, every Joule skill, every agent, every third-party application with its own AI needs the same translation, and each one gets it separately unless somebody decides otherwise.

SAP’s knowledge graph knows SAP’s model. An ontology you buy knows an industry’s best practice. Meanwhile Microsoft 365 is building its own picture of your vocabulary, every day, from every email, document and meeting your people put through it. None of these agree with each other, and you signed off on none of them.

Every term you keep is a term you now have to teach in every one of those places, and keep teaching.

The test

Which term gets which treatment is not a language question. It is a question about whether the word is carrying meaning or carrying history.

A term is carrying history when the only reason it exists is that it exists. An inherited word from an acquisition. A local convention nobody defends. A habit from a system you retired in 2015. Nothing is lost by changing it, and something is gained - an organization that speaks the same language as the system it runs on has fewer places to be wrong.

A term is carrying meaning when it encodes a distinction your business actually makes and the reference model does not. The secondary customer. Two kinds of promotional order that book margin differently and draw on different budgets. A product status that matters for a regulatory reason specific to your industry. A customer classification that drives how your commercial teams are paid. Flatten those to the standard word and you have not simplified anything. You have deleted information your business needs and will continue to need, and the people who relied on it will build a workaround within a month.

Most organizations cannot currently tell these apart, because telling them apart requires someone who can look at a term and know whether it survives translation. That is not a linguist and it is not a configuration analyst. It is someone who knows the business and the system well enough to recognize when a word is load-bearing.

The part worth being honest about

There is something uncomfortable in the align option and it should be said out loud.

Deciding that your people will stop saying one word and start saying the vendor’s is a cultural intervention conducted on behalf of a software taxonomy. Sometimes that is exactly right - standardization is a large part of why you bought a standard system, and every distinction you preserve is a distinction you maintain. Sometimes it is a company surrendering something that mattered because nobody in the room could articulate why it mattered, and the person who could was not invited.

Both of those happen. They look identical in a workshop.

You have made this decision before

Now the part that should feel familiar.

Most Z-fields in your system record a decision that your business needed a distinction the standard did not make. So do the custom tables, the extensions, the places somebody chose not to use what was delivered. You argued about them. Somebody asked whether standard could work. Somebody else explained why it could not. The ones that survived are the distinctions your organization was prepared to pay to keep.

If your secondary customer is in the system at all, it is there because somebody won that argument.

Your custom fields are your untranslated vocabulary, already made structural.

You have a discipline for this. You called it fit-gap. You have just never run it on words.

Which means you are not starting from nothing, and you are not being asked to learn a new practice. You are being asked to point an old one at something it was never aimed at - with the same tests you always used. Can standard do this? What breaks if we conform? What are we really protecting, and is it worth carrying?

What to do with it

Take a dozen terms. Not a glossary project - a dozen, the ones your people actually say in operating reviews.

For each, write down what your organization means, what the delivered system calls the nearest thing, and whether the gap is history or meaning. That is a workshop, not a program, and the arguments it produces are the deliverable. The terms nobody argues about are the ones to align. The terms that produce a fight are the ones carrying something, and the fight is how you find out what.

Then name an owner for the ones you bridge - because a mapping without an owner is a defect with a delay on it.

And notice what you have when you are done: a list of the distinctions your business makes that the reference model does not. Which is not a vocabulary artifact at all. It is the clearest statement of what makes your operation specific that anyone in your company has ever written down.

Nobody asked for it until the system needed to be spoken to.

Commercial means open order value. What customers have committed and not yet received.

The plant means units — tons, cases, pallets, whatever they run on. And the value behind them, because there is a KPI on each.

Finance counts what has shipped and not yet been invoiced. The plant stopped counting that the moment the truck left the yard.

The controller means outstanding performance obligations. That one is not an opinion. It is a revenue standard, and it may exclude things everyone else in the room is counting.

Nobody there is confused. Each of them knows which number is theirs, and has known since their second week.

Then somebody asks how much of it is past due.

Past due against what? The date the customer asked for. The date you first confirmed. The date standard lead time would have produced. Three numbers, three different stories about whether you have a problem, and every one of them defensible.

And none of it has ever caused any trouble.

The screen never accepted the question

Open any standard report or transaction and the ambiguity disappears — not because SAP resolved it, but because the screen never accepted the question in the first place.

There is a report for open orders. A different one for deliveries due. The revenue figure comes out of a period-end process with its own rules and its own owner, and nobody confuses it with a shipping report because you have to go somewhere else entirely to get it. If you want past due measured against first confirmed date rather than requested, you change a selection field. Deliberately. Having already decided which one you meant.

And every dashboard your company built was specified by somebody who had to state exactly which reading they meant, reviewed by somebody who argued about it, and approved before it was built. Your definitions are not undocumented. They are documented in requirements, in specs, in tickets, in the selection variants somebody saved and named. They are just not documented anywhere a system can read them, and never in one place.

None of that was a limitation anyone worked around. It was the design — and it is the design in every enterprise system ever built. Every screen your company configured, every variant it saved, every dashboard it approved is your company’s vocabulary encoded as software: your definitions, your operating culture, your language, made into a thing with a transaction code in front of it.

Interface design has spent its whole history eliminating ambiguity rather than interpreting it. Role-based screens. Layout variants. Transactions that answer one question and refuse the rest. A scheduler and a controller need different things from the same data, and the entire discipline of enterprise UX exists to make sure neither of them is ever asked what they meant.

You do not tell the screen what you want. The screen already decided, by knowing who you are and why you are there.

A field label is immune to language, too. It is a fixed target, the same target in every locale, because it is not language — it is a coordinate. It does not care that Portuguese and Mandarin divide the world differently, that Spanish encodes formality in ways that change who a sentence is addressed to, that two regions use the same word for different things and each is certain theirs is standard, that your company invented terms nobody outside it would recognize, or that the person asking is in a hurry and phrases things their own way.

An AI assistant has none of that. It gets a sentence — and natural language is not a coordinate.

Where the resolution actually lived

A sentence, and nothing else. No role, no transaction, no selection screen.

So the ambiguity is still there. It never went anywhere. It was being resolved somewhere else, and most organizations have forgotten they are doing it.

Some of it is written down. In the functional spec behind a report, where somebody had to state which date the aging was measured against. In the pricing specification that says what counts toward the commission basis. In the transport description, the change request, the design decision log from a project that closed in 2019. In the test scripts, where somebody wrote down the expected result and therefore the definition. In the selection variant somebody saved and named Backlog — Ops, which is a definition nobody would recognize as one.

Your definitions are in there. Scattered across systems that do not talk to each other, written in the language of whichever project produced them, never indexed, never assembled, and never once reconciled against each other.

The rest lives in people. It lives in training. It lives in the fact that the plant and the controller open different reports, and each of them knows which number is theirs. It lives in the moment a new hire asks what the backlog is and somebody who has been there eleven years says when this group says backlog we mean unshipped units, and if finance is in the room they mean value including what has shipped but not billed, and if anyone says past due you need to ask against which date.

That sentence is one of the most important pieces of information in your company, and it exists nowhere. Not in a functional spec. Not in a configuration table. Not in any document your auditors have ever asked to see. The dashboard requirement captured one reading for one report. The map was never drawn.

It has also never needed to be, because it was only ever required by humans, who picked it up by working there.

And notice that one of those readings is not a preference. Open order value and unshipped units are an operational disagreement — both defensible, neither wrong. Outstanding performance obligations is an accounting standard with a rule behind it. An assistant returning open order value to somebody who meant performance obligations has not picked a side in a departmental argument. It has answered a regulated question with an unregulated number.

What actually moved

The specific thing that changed is narrower than the general excitement about AI suggests.

Go to a stock requirements list. You type a material and a plant. If you type the wrong material you get a perfectly correct answer to a question you did not mean to ask, and everybody in the building understands whose error that was. Nobody has ever opened a ticket asking IT to fix the system so it knows which material they meant. The parameter was your job. The system’s responsibility began after the parameter was supplied, and that boundary was absolute.

Ask conversationally and the system derives the parameter. Which measure. Which state. Which baseline date.

That derivation is now a system behavior. And system behaviors have defects.

The screen made you decide. The sentence lets you not.

It will arrive as a ticket

So here is what happens, and it will happen in the first month.

Somebody opens a ticket saying the assistant reported the wrong backlog. The ticket is specific, the screenshot is attached, and the person is right that the number is not the number they wanted.

It will be routed to whoever supports the interface. That person will check the service, confirm the data is correct, confirm the call was correct, and find no defect — because there is not one. The assistant answered a different question than the one the user believed they were asking, which is something that has happened between two humans in your company every day for thirty years and has always ended in a short conversation.

Now it ends in a queue.

And nobody in that queue owns the fix, because the fix is not code. Your organization already decided what backlog means — repeatedly, in specs and reports and transports. What it has never decided is which of those decisions applies when somebody asks in a sentence, and whether the answer is the same for everyone who asks.

That is not a support ticket. That is a vocabulary exercise nobody has ever had to fund, arriving disguised as a defect and routed to people with no authority to resolve it.

The part worth sitting with

None of this is new ambiguity. Every bit of it has been sitting in your organization since the day you went live, resolved quietly and constantly by people who learned the answer from other people.

What is new is that it is no longer being resolved on the way in. It is being resolved by a system, consistently, at scale, according to a reading nobody chose — and for the first time, being wrong about it produces an artifact with a ticket number.

Four people will look at that order this morning and none of them wants the same thing from it. The rep is on the phone in twenty minutes and needs to know what can be done to improve the date. The planner needs to know what else moves to make the tenth. The finance manager needs to know whether the exception the rep is asking for is permitted, and who signs it. The operations director needs to know what this does to this week’s fill rate, and why this customer keeps coming up.

Ask any of those questions of an AI assistant sitting inside your SAP system and you will get an answer. What is not obvious from the answer is where the knowledge behind it came from.

Those answers will not all come from the same place. Some of what the assistant knows arrives with SAP. Some of it you supply. And some of it you can decide to own outright. Most estates end up with more than one, which is why it is worth knowing what each one commits you to.

SAP’s semantics — the Knowledge Graph

SAP’s framing at Sapphire was three layers: public models, SAP’s context, and the customer’s context.^[1] The middle layer is where the investment is going, and the Knowledge Graph sits at the centre of it.

SAP describes it as an SAP-managed semantic layer.^[2] What it contributes is the connective tissue — what a sales order is, how a schedule line relates to a delivery, which documents depend on which. An agent working from it can traverse from the rep’s order toward the planner’s question without being handed the model each time it is asked. That is the difference between an assistant that can quote a field and one that can follow a relationship.

Two things are worth separating before you plan around it.

The first is that a semantic layer describes. It does not enforce. When an agent goes on to post something, it goes through the same API the rest of your estate uses, and that is where availability checks, credit checks and incompleteness rules run — exactly as they did when a batch input session called a transaction. The graph makes an agent legible to your data. The write path is what keeps it safe.

The second is that knowing what a sales order means is not the same as retrieving yours. Meaning comes from the graph. Your actual orders, customers and configuration come through supported, authorised access to application data or data products. Nothing has to be copied into the graph for an agent to answer the rep’s question, and the two questions — does it understand this, and can it reach this — have different answers and different owners.

Which makes coverage the thing to establish rather than assume. SAP’s own material puts the S/4HANA graph at 452,000 ABAP tables, 80,000 CDS views and 7.3 million fields, drawn from its metadata model.^[3] That is a substantial delivered foundation. What it does not tell you is how much of your implementation is represented in it.

There is a documented case that shows the gap cleanly, on the data side rather than the graph side: custom fields can arrive in SAP-managed data products while SAP’s delivered analytical models ignore them until you model their use.^[4] Availability is not understanding. Transporting a field is not explaining what you meant by it.

SAP’s architecture guidance is candid about direction here. It names custom fields, custom APIs and tenant-specific configurations, and states that the long-term vision is a customer-specific knowledge graph with a shared enterprise ontology.^[5] Long-term vision is architectural direction, not a delivery date.

So go and establish it rather than inferring it. Does the graph cover the field you repurposed in 2019? The custom object your team built? The second CRM you inherited in an acquisition and never retired, or the three EDI packages doing the same job in three regions, or the process you have not been able to standardise yet because one plant needed it that way? Some of those are roadmap questions. Some of them were never SAP’s to describe, and no delivered semantic layer is going to arrive knowing them.

Then the correction question. The delivered graph is SAP’s to change, not yours. That does not mean your only option is to build something outside — SAP documents customer-managed data products, custom semantics and access controls within the SAP-managed platform.^[6]

So there are three things to establish for your own estate, not two. What the graph already covers. What you can extend yourself. And what it is never going to describe, which you will have to account for somewhere else.

Your documents — grounding

The least glamorous of the four and the most clearly shipping.

You point it at your policy documents. It retrieves from them. It answers the finance manager’s question, and on the documented enterprise plan for Joule document grounding it is metered on records.^[7]

The correction path here is the one most people describe wrongly. It is not edit the document and the answer is fixed. An edit has to reach the retrieval system — ingestion runs on a schedule or is triggered manually — and then the answer has to be re-tested, because a wrong answer can come from selecting or interpreting the wrong material even when every document is correct.^[8] Content accuracy and answer accuracy are two different responsibilities, and only the first one lives in the file you just edited.

What is also true is that part of your content estate becomes a production input. Only the selected content that has successfully indexed, and only what is reachable under the configured retrieval and access rules. That selection is a decision somebody made, and in most organisations it is not written down anywhere as a decision. The retrieval works. What it retrieves is whatever that selection contains.

Your operating knowledge — Company Memory

This is the interesting one.

Built on the Signavio foundation, it ingests from sources your organisation already has — policy documents, process models, agent traces, voice input — and structures what it finds into process atoms, each with a stated purpose, scope and guiding principles, with no manual transcription required.^[9] It aims directly at the director’s question, the one about why this customer keeps coming up, and it addresses the actual reason enterprise agents disappoint: the operating logic of a company is distributed across material nobody has ever consolidated.

It also has the most explicit governance design of the four. SAP states that business owners curate and approve every behaviour in their domain, with a full audit trail for every change, that contradictions are surfaced before an agent acts on conflicting rules, and that a behaviour updated once reaches every connected agent at the next execution without redeployment.

Two things about that.

First, it is the most specific published answer to who can change this among the four — and it assigns that answer to your business owners rather than to SAP. Second, the page carries a label: the solution is in closed beta. What the page establishes is a governance design and an advertised status, not evidence of how that design performs in production. Forrester’s note in May recorded no public production references at announcement;^[10] treat that as a dated snapshot rather than a current finding, and ask SAP directly where it stands now.

There is an implementation question underneath the governance design that is worth thinking through early. If your policy estate looks like most — a 2019 credit policy and a 2023 one, a regional procedure that contradicts the global standard because the region has a carve-out that lives in somebody’s head — then surfacing contradictions is going to produce a queue of decisions your organisation has managed to avoid making for two decades. Those decisions route to business owners who have day jobs. The constraint may not be getting the knowledge in. It may be adjudicating what comes out.

And the shape is worth naming plainly. The raw material is yours, and your people curate and approve what it comes to mean. But SAP supplies the structuring approach — what counts as a unit of operating knowledge, and where one ends and the next begins. Your business owners are approving behaviours expressed in units whose boundaries somebody else drew.

Your own context service

The first three are things SAP supplies. The fourth is not a capability at all — it is a decision about architecture, which is why it does not sit comfortably beside the others. You maintain your own retrieval and reasoning service and connect it to the assistant, rather than handing the knowledge over for the platform to hold.

Be careful about the reason. Reach is not it. SAP states that Company Memory delivers through MCP at runtime, CLI at build time and chat for business users, to Joule and to any agentic framework — so cross-interface delivery is something the platform is claiming, through the same protocol you would use.

What stays yours is narrower and more durable: authorship, and scope. You decide what counts as a unit of company knowledge rather than inheriting that decision. And you decide what goes in — including the material that no delivered structuring was designed to look at, which for most estates is where a meaningful amount of the operating logic actually lives.

A shared service will not guarantee identical answers. Instructions, permissions and history still differ from one assistant to the next. What it does mean is that disagreements are about interpretation of a shared source, rather than about which source was consulted.

What you pay is operating responsibility, and the bill is specific: keeping the corpus current, enforcing access at retrieval and keeping any inherited source permissions accurate, evaluating answer quality on an ongoing basis, and running an integration the assistant now waits on. None of it is exotic. All of it continues every month after go-live, and it is easy to underweight at pilot stage, when there is one corpus, one use case, and someone who cares about it personally.

The capability decides what your AI can know. The choice decides who keeps it true.

The choice you have already made

Put the four side by side and a distinction surfaces that most intake processes have no name for.

Approving a source document and approving an agent’s behaviour are two different signatures.

Your document libraries may well already have content approval. That is a mature control and plenty of organisations run it properly. What it establishes is that a version of a file was fit to publish. Company Memory’s published design establishes something else — that a business owner approved what the agent will do, as a structured statement of behaviour rather than as a document.

Most people will assume the first covers the second. It does not, and the gap between them rarely has an owner.

There is an open question underneath that worth taking to your own estate rather than assuming: when a grounding connector ingests from a library, does it respect that library’s approval state, or does it take what is there? Ask your integrator. Do not infer it.

All of which is what makes this foundational rather than a feature selection. Whichever combination you end up with, the knowledge does not stay true on its own. Policies change, processes drift, exceptions become norms and nobody writes it down. Someone has to keep each of these current, and those someones are different people with different authority on different clocks.

That obligation is the thing you are actually buying, and it rarely appears as a line item in the case that got the pilot approved. It also gets settled early — usually inside a pilot, by whoever sits closest to the first use case, on the grounds of what could be demonstrated fastest.

So look at your own intake. Somewhere between the team wants an assistant and we approved the pilot there should be a step where someone asks where the knowledge will live, who maintains it, and who can change it when it is wrong. If that step is not there, the question has already been answered by default.

It is worth finding out what you answered.

1. SAP Sapphire 2026 — three-layer framing (public models / SAP context / customer-specific context). SECONDARY as captured. Only unchased source in the piece; see open items at publication.↩︎

2. SAP Business AI Platform product page — “SAP-managed semantic layer” phrasing. SAP primary.↩︎

3. SAP Learning, “Exploring SAP Knowledge Graph” — S/4HANA knowledge graph based on 452,000 ABAP tables, 80,000 CDS views, 7.3 million fields. SAP primary. Establishes the scale of the delivered foundation; does NOT establish identical coverage across customers, and must not be used to claim that.↩︎

4. SAP Learning, Business Data Cloud, “Describing data products” — custom fields arrive in SAP-managed data products while delivered analytical models ignore them until customers model their use. SAP primary. SCOPE: this is a BDC data-product and analytical-model boundary. It illustrates availability versus semantic use. It does NOT establish what the Knowledge Graph understands about any particular custom field. Keep the qualification on any reuse.↩︎

5. SAP Architecture Center, AI-Native North Star Architecture, Foundation Layer — names custom fields, custom APIs and tenant-specific configurations; states the long-term vision as a customer-specific knowledge graph with a shared enterprise ontology. SAP primary. Establishes architectural direction, NOT a delivery date or a capability available today.↩︎

6. SAP Learning, Business Data Cloud — customer-managed data products, custom semantics and access controls within the SAP-managed platform. SAP primary. Establishes a verified capability; does NOT establish an unrestricted customer-editable Knowledge Graph.↩︎

7. SAP Help Portal — Joule document grounding, records-based metering. SCOPE: documented enterprise data-manager service plan. Records are defined in document-size blocks, not database rows. Not a universal SAP grounding meter and not SAP AI Core grounding. SAP primary.↩︎

8. SAP Help Portal — grounding content ingestion, scheduled and manually triggered. SAP primary.↩︎

9. SAP Company Memory preview page (signavio.com/company-memory, page modified 2026-08-17) — Capture / Govern / Deliver; process atoms with purpose, scope and guiding principles; “no manual transcription required”; business-owner curation and approval with full audit trail; contradiction surfacing; propagation at next execution without redeployment; MCP at runtime, CLI at build time, chat for business users, to Joule and any agentic framework; “Solution in closed beta”. SAP-owned primary, fetched and read directly 2026-09-16.↩︎

10. Forrester, SAP Sapphire 2026 analysis, May 2026 — no public production references for Company Memory at announcement. Snapshot, not current status. Date carried in body.↩︎

SAP’s AI Agent Hub lists six capabilities. When SAP announced it at Sapphire in May, two were generally available and four were planned for Q3 2026 — and each of those four executes in a different product.

Q3 closes this month, so some may have landed since. The mapping is what matters.

The two that were available are the two that run inside LeanIX, where the Hub lives. The four that weren’t are the four that execute somewhere else.

The availability line and the ownership line are the same line.

Which means it doesn’t arrive as a product. It arrives as four deliveries, into four other products, with four different owners inside your enterprise — whoever runs your ALM tooling, security, process, and HR.

That looks like a fragmentation problem. It isn’t.

Read the list again

Go back to the six and ask what each one would be if the worker were a person.

AI registry — everything that exists and can be addressed. That’s the company directory.

Evaluation and verification — risk rating, criteria, sign-off. That’s the job description, and the standard the worker is held to.

AI observability — how you measure against that standard. Performance monitoring.

Identity and access control — what it’s allowed to reach, and which tools can be called at all. That’s provisioning.

Agent mining — what the worker actually does, as opposed to what the job description says.

Org chart and skills mapping — where they sit, who they report to, what they’re qualified for.

Six capabilities. Six things you already do for every new hire.

And you don’t run those six in one product for humans either. HRIS, identity platform, performance system, some view of how work actually flows, an org chart. Separate systems are normal. Nobody calls that fragmentation.

Open Outlook and look at your directory. People, conference rooms, shared mailboxes, service accounts — everything in the estate that has an identity and can be reached. Now search it for your agents.

The thing that makes it work for humans

For people, those systems are connected by a process, not by a product.

Joiner-mover-leaver. Somebody starts, and a sequence fires: a form, an approver, accounts provisioned in each system, roles assigned per system, a manager named, a review date set. They change roles, it fires again. They leave, and a different sequence removes what the first one granted.

The systems stay separate. The process spans them. Somebody owns it.

It isn’t that the process runs well — anyone who has been onboarded knows it often doesn’t. It’s that when it fails, there’s a trigger that should have fired and somebody to call.

For digital employees, the systems are arriving. The sequence isn’t.

That’s the gap. Not missing capability — missing connective tissue, and a role that owns it.

Why the word matters

Say “named user” in an SAP shop and a great deal arrives with it. A form. An approver. Licensing implications somebody will ask about. A role design, an ACL group, an access review, a leaver process. You can’t say the phrase without summoning twenty-five years of accumulated practice, most of it written down, some of it enforced by an auditor who checks it first.

Say “agent” and almost nothing arrives.

The word has been in this ecosystem for decades meaning something different each time — transport agents, monitoring agents, agent determination in workflow. It arrives pre-worn and non-specific.

So you get two words for things that live in the same estate, with overlapping questions about access, approval and review — and one retrieves a checklist while the other retrieves nothing.

Here’s the part that surprised me.

SAP’s reference architecture for agent identity stores agent identities in SAP Cloud Identity Services — in the same Identity Directory that holds your people, each with a Global User ID. Identity Provisioning synchronises their roles and groups across connected applications. Authorization Management defines what each agent identity may do. SAP Cloud ALM is named for agent lifecycle governance, explicitly from development through decommissioning.

Directory, provisioning, authorization, lifecycle to decommissioning.

That’s joiner-mover-leaver, for agents, in the identity platform. The frame isn’t an analogy I’m proposing. It’s the architecture SAP is building.

Which makes the practical question narrower and more useful: not whether to think this way, but whether anyone in your organisation is running the process that architecture assumes.

Try it on one

Take a specific one rather than “an agent.” A digital goods receipt clerk, say. Something narrow enough to picture.

Start with the joiner questions. What systems does it need? What roles in each — not one role, a role per system, designed for the job it’s doing? Who approved it? What is it explicitly not allowed to reach? And when it acts, whose identity does each system actually see?

Then be honest about how that will go. The form has fields nobody understands, somebody picks a licence type without knowing what it means, and the roles get assigned by copying another user.

Copying another user’s roles carries forward permissions nobody has justified for this job. For a person, those mostly go unexercised. A digital employee will exercise them, repeatedly, at speed.

Then ask what happens when its job changes. The mover event is the one everybody skips. Widen its scope, point it at a second plant, add a step — who revisits the permissions, who re-approves, and who removes the access the old job needed and the new one doesn’t?

Then ask how you’d notice, and how you’d correct it. Not how you’d notice it failing loudly. That one takes care of itself.

The hard case is the slow decline — work that still looks fine at a glance but isn’t what it was. A manager is supposed to know what good looks like and review against it. A digital employee degrades the same way: the model changes underneath it, the data shifts, the edge cases stop being edge cases, and it gets quietly worse at the thing you hired it for.

And the failure doesn’t have to look like a mistake. The agent has full authority. It follows the method exactly. It determines no values of its own. It posts the receipt against the wrong storage location — the right quantity, the right material, a reference the process never intended. Every permission checks out. The document is valid. The stock is in a place it isn’t, and nobody finds out until someone counts.

Observability traces individual agent sessions in Cloud ALM. That’s real and it’s the right thing to build. But a trace tells you what happened, not whether it was acceptable — and that’s what the evaluation criteria were for.

Noticing is the easy half. With a person, you’d have a word. With an agent, a correction is a write to something — and there are two very different kinds.

“Use the storage location on the PO for this one” changes the current task.

“From now on, check the storage location against the PO before posting” changes the intended behaviour.

Where does that second instruction persist — this conversation, the agent’s memory, its configuration, or its code? Who tests it, who approves it, and how would you reverse it?

That’s change control, and it should scale with the impact. Some corrections are a conversation. Some are a transport.

Then ask how you’d stop it. Go back through the six and ask what each does at the moment an agent acts. Inventory. Standard. Trace. Identity. Execution paths. Placement.

Most of them are a record or a lens. Two aren’t.

Verification is a stop. SAP states that only verified MCP servers can be called in production workflows, and that access is revoked when verification status changes. Mark an asset unverified and the calling stops. That one lives inside the Hub.

Identity is the other. Disable an agent’s identity in SAP Cloud Identity Services and you remove the credential it authenticates with — and autonomous agents operate on their own dedicated technical identity and tokens, so what you’re removing is the basis on which that agent is trusted anywhere downstream. That’s suspending a worker.

The stops are real. Notice who holds them. One belongs to whoever governs the registry. The other belongs to security.

So the manager who notices something wrong at four on a Friday doesn’t have a control. They have a ticket.

And both are blunter than the moment usually calls for. Verification is a production gate, not a pause. Revoking a credential is not the same as stopping work in flight. Does it stop a run already under way? Does an existing token keep working until it expires? Who is allowed to pull either one, and has anyone tested it?

When the job ends

There are two leaver questions, and only one of them gets asked.

The first is access. When the purpose ends — process retired, pilot concluded, team moved on — who removes it?

The architecture is further along here than most expect: Cloud ALM’s lifecycle governance runs explicitly through decommissioning. So there’s a documented owner, which is more than this question usually gets.

What that doesn’t settle is the trigger. For a human leaver, HR fires it and somebody’s job depends on it running. For an agent, nothing announces that a digital worker has stopped being needed. A lifecycle stage exists. Something still has to tell it the job is over.

That’s the same failure enterprises spent two decades fixing for service accounts, arriving again under a different word.

The second question is the one nobody asks. The work outlives the worker — the records it changed, the outputs it produced, and the evidence of what it did and on whose authority. Who inherits that? Where does it live once the agent is gone?

Observability retention is set for operational reasons. Does it preserve the evidence you’ll need after the agent is retired?

What to do this week

Name one agent as a job, not a technology. Digital junior buyer, digital goods receipt clerk. See whether the people in the room start asking different questions.

Run the lifecycle against it. Joiner: systems, roles per system, approver, restrictions. Mover: who revisits all of that when the job changes. Manager: how you’d notice it degrading, how a correction persists, what an intervention actually stops. Leaver: what happens to the access, and what happens to the evidence.

Then name the owners. Start with the business owner of the job. Name the technical owner who can change or suspend the agent. Agree the handoffs with security and the application owners. That’s a starting pattern, not an org chart — but it’s more than most organisations have written down.

Note which questions have an owner and which get a shrug.

The shrugs are the work.

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.