Build Your First SAP AI Agent: Joule Studio + MCP

Ten lessons of preparation land here. You understand LLMs, prompting, RAG, tool-calling, the SAP stack, Joule, and MCP. This is the lesson where you stop learning about agents and actually assemble one.

Reality check before you start. The Agent Builder in Joule Studio reached general availability in January 2026, with MCP support. The exact UI, feature names, and entitlement terms move fast enough that pixel-perfect instructions would be stale within a quarter — verify your current steps and entitlement before you build. SAP has indicated Joule Studio access was time-boxed and free through part of 2026; confirm current terms rather than assuming pricing is permanent. Treat everything below as the durable shape of the process, not a click-by-click script.

The anatomy of a Joule Studio agent

Every agent you build has exactly three parts, and each one maps directly to a lesson you’ve already completed:

1. Instructions — the agent’s system prompt: its purpose, its rules, its tone (Lesson 3). “You are a Business Partner assistant. You can read, create, update and block BPs. Never delete — BPs can only be blocked. Always confirm the BP number after a create.”
2. Tools — what it can actually do, exposed over MCP (Lessons 7 and 10). Each tool is a name, a description, and a JSON schema; your runtime executes them, never the model — the single most important sentence from Lesson 7, still true here.
3. Grounding — what it can know, via RAGe, the Knowledge Graph, or attached documents (Lessons 5 and 9).

That’s the entire anatomy. Instructions, tools, and grounding, wrapped in the reason-act loop you learned in Lesson 7. Nothing more exotic is hiding underneath.

The build path, in its durable shape

Stand up your tools as an MCP server — a small service, commonly Node.js plus the SAP Cloud SDK on BTP — exposing tools like read_bp and create_bp, and calling released SAP OData APIs only, never internal function modules; that’s the Clean Core rule waiting for you in Lesson 13. Deploy it, typically on BTP Cloud Foundry, and register it as a destination in your BTP subaccount. Create the agent itself in Joule Studio: add the instructions, then add the MCP server as a tool source through that destination, so its tools auto-discover. Add a grounding source if the agent needs document knowledge. Test it with real prompts — including one it should refuse, for lack of data or lack of permission. Only then, activate it, and it becomes available inside Joule.

We’ve already written the full code, so this lesson doesn’t have to

This lesson deliberately stays conceptual, so it stays accurate as the UI inevitably shifts underneath it. For the complete, copy-paste implementation — every tool’s TypeScript, the MCP server entry point, the BTP destination configuration, deployment, and Joule Studio registration — go build the real thing with our two hands-on guides:

• Business Partner CRUD agent — read, create, update, block, including the “you can’t delete a BP, only block it” pattern that trips up almost everyone the first time.
• Sales Order creation agent — header plus line-items, deep insert.

Work through those two tutorials, and you will have built exactly the agent this lesson has been describing — with running code, not just a diagram.

Try it yourself — the version that needs no infrastructure at all

Even without standing up a full server today, there’s a genuinely high-value version of this exercise you can do right now:

1. Build a read-only agent in Joule Studio — or storyboard it on paper if you don’t yet have entitlement — with one instruction block, one grounding source, and one read-only tool.
2. Test it with three questions, including one it should refuse, because the answer isn’t in its grounding or the permission isn’t there.
3. Record exactly where it succeeds and where it fails. The refusal case is the one that matters most: an agent that says “I don’t have that information” is a categorically safer agent than one that quietly invents an answer instead.

Start read-only. Always. Earn the right to let an agent act by proving it, which is the entire subject of the next lesson, and governing it, which is the capstone after that. An agent that acts before it’s been tested and governed isn’t a shortcut — it’s the setup for an incident review nobody enjoys attending.

Key takeaways

• A Joule Studio agent is instructions plus tools, via MCP, plus grounding — wrapped in the reason-act loop.
• The build path: MCP server → BTP destination → agent in Joule Studio → grounding → test → activate.
• Expose tools over released OData APIs only — never internal function modules. That’s Clean Core, and it’s non-negotiable.
• The Agent Builder reached GA in January 2026 — verify current UI and entitlement terms before you build; never assume pricing is permanent.
• Start read-only, always. Write and act capabilities are earned, not defaulted to.

Next: you’ve built it. Now prove it’s actually good — and that it stays good after the model underneath it inevitably changes.