What Actually Happens Behind Joule’s Front Door

In Part 1, we talked about Joule as the new front door to SAP – the place where work starts with a question, not a tile.

This post goes one step deeper:

“Behind that front door, what is actually running the show?
What are ‘agents’ and ‘skills’ in real SAP terms?”

Most of this comes from four TechEd Berlin 2025 sessions on Joule and automation (AI823, AD819, AI105, AD202). This is my “edited for humans” version of what they showed.

1. From “Build an App” to “Build a Capability”

For years, our SAP pattern looked like this:

requirement → design → Fiori app → CDS/RAP → done.

In the Joule world, the pattern shifts:

requirement → skills + agents → optional UIs on top.

The mindset change is simple but important:

  • Capabilities first.
    We start by defining what the system should be able to do (skills) and how the assistant should use those skills (agents). Screens come later, if they are still needed.
  • SAP Build as backbone.
    Workflows, automations, RPA and events live in SAP Build. Joule and agents sit above that backbone instead of trying to replace it.
  • Joule Studio as the agent factory.
    This is where we give agents their purpose, their tools, and their guardrails.

You still can (and will) build Fiori apps. They just stop being the center of the universe.

2. Skills and Agents in Plain Language

Every Joule session used the same mental model, and it’s worth keeping.

2.1 Skills: small, reliable “doers”

Skills are tiny, predictable operations:

  • They take clear inputs and return clear outputs.
    For example: “Get blocked purchase orders for company code X” or “Create sales quote Y.”
  • They don’t reason — they just execute.
    A skill doesn’t decide why you need blocked POs; it simply returns them.
  • They are usually backed by SAP Build, RAP/CAP, or Integration Suite.
    Technically, a skill often calls a workflow, API, or bot you already have.

If you like analogies, skills are micro-APIs with business meaning.

2.2 Agents: planners that orchestrate skills

Agents enter when the request sounds more like a task for a colleague:

“Help me buy a headset within policy.”
“Explain why this cost center jumped 20%.”

They:

  • Understand intent and turn it into a plan.
    Break a vague question into steps and decide which skills are needed.
  • Call skills in the right order and interpret their results.
    They decide: first check budget, then open POs, then contracts, then propose actions.
  • Talk to the user in normal language.
    They summarize findings and ask for confirmation before doing something irreversible.

So you can think of it like this:

  • Skills = thinking fast. Small, precise, repeatable.
  • Agents = thinking slow. They reason, sequence skills, and present answers.

If the “thinking fast” layer is messy, no amount of agent magic will fix it. That’s where we, as SAP teams, come in.

3. Where We Build This: Joule Studio + SAP Build

SAP showed a clear split of responsibilities.

3.1 Joule Studio – where the agent’s brain lives

In Joule Studio, you don’t start from a huge technical form. You start by describing the scenario:

“I want an agent that helps employees request IT equipment.
It should check existing PRs, look up catalog items, verify policy limits, and escalate to procurement if needed.”

Joule Studio uses that description to propose:

  • a purpose and basic behavior,
  • a list of tools/skills the agent might need.

You then refine it by talking to it:

  • “Don’t allow this for interns.”
  • “Always ask for confirmation before placing orders.”
  • “If budget is over X, add the manager to the notification.”

Finally, you wire it to real tools:

  • SAP Build workflows and automations (approvals, PR creation, follow-ups),
  • APIs, Integration Suite flows, or bots for non-SAP systems,
  • Grounding sources like policies or contracts,
  • Sometimes even other agents.

The “vibe coding” experience is there to speed up iteration, but the architecture decisions are still ours: which tools are safe, which data is exposed, and how far we let the agent go without human approval.

3.2 SAP Build – muscles and plumbing

Underneath, SAP Build remains the backbone:

  • Workflows handle approvals, exceptions, and long-running tasks.
  • Automations / RPA do repetitive UI or integration work.
  • Events react when something interesting happens: a PR stuck too long, a threshold crossed.

Most serious Joule agents are really nice front-ends on top of solid Build content. That’s actually good news: we can reuse a lot of what we already have.

4. Two Faces of a Good Agent

One practical pattern from the orchestration sessions stuck with me:

Every serious agent should work in two modes.

4.1 On-demand: conversational mode

This is the classic Joule experience:

  • The user opens Joule in S/4, Work Zone, or Teams.
  • They ask: “Show me German PRs that are stuck.”
    “Why did marketing costs spike last month?”
  • Joule routes that question to the right agent.
  • The agent calls skills, interprets the results, and answers with:
    • a short narrative,
    • a list with deep links,
    • or a suggested next step.

The user is in control and “pulls” help when they need it.

4.2 Proactive: system-triggered mode

The same agent can also run in the background:

  • SAP Build watches for events:
    • PRs idle for more than N days,
    • spend increasing faster than budget,
    • invoices overdue beyond a threshold.
  • When something fires, it triggers the agent.
  • The agent analyzes the situation, checks policies or history, and produces a recommendation or a pre-filled action.
  • The result shows up as a Task Center item, a Joule notification, or an update inside an app.

Same brain, two entry points.
Designing with both in mind turns agents from “smart chat widgets” into co-workers that tap you on the shoulder when something matters.

5. Why This Matters for SAP Teams

So what do we, as SAP architects and developers, actually do with all of this?

For me, three consequences are clear.

  1. We design capabilities, not just screens.
    For every new requirement, we should ask:
    “Which skills and agents should exist so Joule can help here?”
    Apps then become focused views on top of those capabilities, not the whole solution.
  2. We extend SAP’s standard agents instead of rebuilding them.
    SAP will ship more line-of-business agents for Finance, Procurement, Supply Chain, etc. Our job is to extend them with:
    • company-specific skills (RAP services, Build workflows, external APIs),
    • local rules and thresholds,
    • internal documents and policies for grounding.
  3. We treat security and observability as design requirements.
    Agents must:
    • act under real identities (no anonymous “super-user” bots),
    • respect existing roles and authorizations,
    • leave a trace of what they did and why.
      Without that, no CIO will promote an agent beyond a pilot.

This is not about replacing us with Joule.
It’s about moving our work up a layer: from building screens around transactions to building capabilities that smart assistants can use.

6. What’s Next: ABAP in the Age of Joule

In Part 3 – “ABAP in the Age of Joule”, we’ll zoom in on the developer side:

  • how Joule for Developers feels in the ABAP workflow,
  • how ABAP/RAP services become tools that agents can call,
  • and how upcoming models like SAP-ABAP-1 fit into this picture.

That’s where we finally answer the question many ABAP developers now have:

“Where does our code live in this new agent world?”

If you want to see the original sources, most of these ideas come from four SAP TechEd Berlin 2025 sessions: AI823, AI105, AD819, and AD202v.

Together they tell a simple story: Joule Studio + SAP Build is where the SAP agent factory lives.