(A coffee conversation from TechEd Berlin Virtual 2025)
If we were colleagues and you met me at the coffee machine after TechEd Berlin 2025, you probably wouldn’t ask:
“Can you list the new Joule capabilities by area?”
You’d ask something simpler:
“So… this Joule thing. Is it real, and does it actually change how we work with SAP?”
This blog is my answer to that question — not as a marketing message, but as a conversation between SAP people who live in the real world of projects, deadlines and users who don’t read release notes.
It’s Part 1 of 3:
- Part 1 (this one): What Joule is really trying to become – the front door to SAP
- Part 2: What we find behind that door – agents, skills, Joule Studio
- Part 3: What this means for us as ABAP / SAP developers in the Joule era
Let’s start with a very normal Monday morning.
1. A Monday Morning With and Without Joule
Imagine a Finance Manager on Monday at 8:30.
Without Joule
She logs into SAP, opens the launchpad, starts hunting for the “right” app, waits for filters to load, adjusts variants, runs a report, exports to Excel, and repeats the dance in another app. It can easily take 20–30 minutes before she knows why a cost center exploded last month. By that time, the coffee is already cold.
With Joule as the front door
Same person, same data, different starting point:
She opens Joule and writes:
“Last month’s costs in Plant 2000 spiked. What happened?”
Joule pulls the relevant KPIs, compares them to history, and answers in plain language: where the spike is, which orders and vendors are involved, and what looks unusual. Then it asks:
“Do you want a short summary to send to your manager?”
Nothing magical is happening in the back-end; it’s still S/4, BW and friends. The difference is where the work starts: not from a tile, but from a question.
That was the main message I heard again and again at TechEd:
Joule is not meant to be a side feature.
It is supposed to become the front door to SAP work.
2. What Joule Is Really Trying to Be
After living in the Joule sessions for a few days, I stopped thinking of Joule as “a chatbot” and started seeing it in three roles.
2.1 One assistant across the SAP landscape
Today our landscapes feel like separate islands: one entry for S/4, another for Ariba, another for SuccessFactors, another for analytics, plus a completely different world in Microsoft 365.
Joule’s first job is to sit above that and become a single assistant layer:
- You meet the same Joule in Work Zone, in Fiori apps, and inside Outlook or Teams.
- Joule knows where you are and what you are looking at: a sales order, a vendor email, a contract, a project.
- You start from intent (“help me with this issue”) and let Joule pick the right apps and data behind the scenes.
From the user’s perspective, this is a big shift: less navigation, more conversation.
2.2 A conductor for agents and skills
From the inside, Joule is less like one giant brain and more like a conductor in front of an orchestra.
- Skills are small capabilities that do concrete work: create a purchase order, fetch open items, start a workflow, run a vector search. Each skill talks to a specific system or API.
- Agents are smarter components that can plan a sequence of steps: analyze a margin drop, guide a buyer through resolving an invoice issue, or prepare a briefing for a customer meeting. Agents decide which skills to use, in which order, and when to ask the user for clarification.
Joule listens to what the user wants, selects the right agents, and lets them orchestrate the skills. Our job, as SAP developers and architects, is to provide clean skills, reliable data, and well-defined agents that Joule can trust.
2.3 Role-based assistants, not one mega-bot
SAP is not building “one bot to rule them all.” Instead, Joule is arriving as role-based assistants:
- A Finance assistant that thinks in cash, margin, and closing tasks.
- A Procurement assistant that thinks in suppliers, contracts, and spend control.
- A Supply Chain assistant that thinks in inventory, capacity, and delays.
Each assistant speaks the language of that role, has access to a tailored set of agents and skills, and surfaces the metrics and actions that matter for that persona.
For us this changes the design question from:
“How do we build an enterprise chatbot?”
to:
“How do we make the Finance / Procurement / Supply Chain assistant smarter for our company?”
3. How Joule Sees Your Data
The second important shift is in how Joule sees the landscape behind the scenes. We usually talk in terms of systems and tables: S/4, Ariba, SuccessFactors, BW, SharePoint, Excel. Joule’s view is different.
3.1 From systems list to business graph
Two components are key here:
- SAP Business Data Cloud gives a semantic layer: a consistent catalog of business objects – customers, vendors, contracts, cost centers, projects, orders – and their relationships. Instead of “table VBAK joined to table KNA1”, you get named business entities connected in a graph.
- SAP Knowledge Graph links those business entities to each other and to unstructured content: contracts, policies, manuals, notes, emails.
With this in place, Joule doesn’t just see “Customer 1000001.” It sees:
“Customer X has these sales orders and invoices, has these open disputes, appears in these contracts, and is linked to these risk indicators and service tickets.”
The power is not in one model, but in having numbers and documents living in the same business graph.
3.2 RAG inside SAP: more than “vectorize all PDFs”
Many of us first met RAG as “put all your PDFs into a vector database and ask questions.” Inside SAP, the bar is a bit higher.
A document is not just an embedding; it is anchored to business objects:
- A contract PDF is linked to a specific vendor, plant, and validity period.
- A policy document is tied to certain processes, regions, and roles.
- A project charter is connected to WBS elements, cost centers, and milestones.
When those links are in place, Joule can answer questions like:
“Show me European suppliers with high spend, recent incidents, and risky contract clauses.”
That answer might combine KPIs, incidents, and highlighted paragraphs from contracts. For that to work, our job is to model data and documents so they can participate in the graph, not just in isolated reports.
4. Joule in a World of Other Assistants
The third theme from TechEd: SAP does not pretend Joule is the only assistant in the building.
4.1 Joule and Microsoft Copilot
Many workdays now start in Outlook, Teams, Word, or PowerPoint with Microsoft Copilot in the corner. When a conversation or email touches SAP data, Copilot can delegate to Joule to get the facts and trigger actions in S/4 or other systems. When you are in an SAP screen with Joule open, Joule can in turn reach into Microsoft 365 for calendars, emails, and documents.
The user doesn’t care which assistant did what; they just see a single flow of help. For us, it means our agents and skills need to be robust enough to be called from either side.
4.2 Joule talking to other agents
SAP is also investing in Agent-to-Agent (A2A) standards and MCP (Model Context Protocol) so agents from different vendors can work together. In a realistic landscape, we might have:
- Joule agents that know SAP processes.
- A partner agent specialized in contract analysis or ESG scoring.
- A custom agent we built on a hyperscaler for anomaly detection or forecasting.
With A2A and MCP, these agents can ask each other for help instead of living in silos. That means we don’t have to choose between “SAP AI” and “our AI” – the future looks more like a network of cooperating agents, with Joule as one of the key entry points.
5. What This Means for SAP Teams
All of this matters only if it changes our design habits. For me, three shifts are already clear.
- Start with what the assistant should do, not which app we should build.
Instead of “we need a new Fiori app,” start with “what should the assistant be able to do here?” Explain a variance, guide a buyer, prepare a briefing, check policy compliance. Only then decide whether a new screen is still needed. - Extend SAP’s role-based assistants with company-specific intelligence.
SAP provides generic Joule assistants for Finance, Procurement, Supply Chain, etc. Our job is to extend them with agents and skills that know our data, rules, and risk patterns. That’s where our domain knowledge becomes a real differentiator. - Treat BTP + Joule Studio as the control room.
Agents and skills live and are orchestrated on BTP. Core systems like S/4, Ariba, SuccessFactors, and even non-SAP systems focus on clean APIs, events, and stable business logic. Brains and choreography sit in one place; transactional reliability sits in another.
6. Closing: Why Joule Feels “Real” After TechEd
After this TechEd, my answer to the original coffee question is:
Yes, Joule is real — not because of one spectacular demo,
but because it quietly reorders where work can start in SAP.
Instead of beginning every task with “Which app should I open?”, we can increasingly begin with:
“Joule, can you help me with this situation?”
In the next blogs I’ll go deeper:
- Part 2: What’s happening behind the front door – how Joule Studio structures skills, tools, and agents.
- Part 3: “ABAP in the age of Joule” – how ABAP code, RAP objects, and the coming SAP-ABAP-1 model become tools in the agent world.
If you want to go back to the source, all of this thinking comes from six SAP TechEd Berlin 2025 Joule sessions: AI823, AI105, AD104, ST123v, AD819, and AD202v. Each session adds its own angle, but together they tell one consistent story: Joule is becoming the intelligent front door to SAP.