Every agent demo starts with a good question.
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.