Varad
For most employees, Joule is the thing you type a question into and get an answer back from. For developers, it is something else entirely. It is a platform you build on, extend, and shape into something that solves a very specific problem your business actually has. If you have spent any time inside SAP Build or poked around Joule Studio, you already know there is a lot more going on under the hood than the conversational interface suggests. This guide is for the people who want to go past asking Joule questions and start building the skills, agents, and extensions that make Joule genuinely useful for their organization.
What Building on Joule Actually Means
Before diving into tools, it helps to separate two concepts that get used almost interchangeably but mean very different things technically. A Joule Skill is a structured, rule based capability that calls a specific API action. Think of it as a focused, deterministic task, something like fetching a purchase order status or submitting a leave request. A Joule Agent is a different animal entirely. An agent plans, reasons, and orchestrates multiple skills to handle complex multi step queries, deciding on its own which skills to invoke, in what order, and how to combine their outputs into a single coherent answer. Skills are the tools. Agents are the workers that decide which tools to pick up and when.
This distinction matters because it shapes how you approach a new project. If a business problem can be solved with one clean API call and a predictable response, building a skill is usually faster and easier to maintain. If the problem involves ambiguity, multiple steps, or a need to handle exceptions intelligently, you are looking at agent territory.
Getting Oriented Inside Joule Studio
Joule Studio is SAP’s development environment for building, deploying, and managing the full lifecycle of custom agents, skills, and workflows. It lives inside SAP Build and supports both low code and pro code approaches, which means it works whether you prefer dragging components onto a canvas or writing code directly. Because it sits inside SAP Build, Joule Studio has native access to your existing connectors, automations, and actions, so you are not starting from zero every time. You can reuse what your organization has already built rather than reinventing connections to the same backend systems over and over.
One detail that trips people up early is how Joule Studio handles identity. It relies on SAP Cloud Identity Services to make sure agents have the correct authorization for whatever task they are completing, and it enforces something called principal propagation. In practice, this means the actual user’s identity in Joule gets passed through end to end, so any skill or agent that gets triggered runs strictly within that specific user’s security context. The agent does not get some elevated, generic service account level of access. It only sees and does what the requesting user is actually permitted to see and do. This is a foundational governance feature, not an optional add on, so build with that constraint in mind from the start rather than treating it as something to fix later.
Building Your First Skill
Skill Builder, the component inside Joule Studio responsible for creating skills, has been generally available since mid 2025, so it is mature at this point and well documented. The typical flow looks something like this. You start with an Action Project, which defines which endpoints from your backend service Joule is allowed to call, what input parameters those endpoints accept, and what output structure they return. Actions act as the bridge between your destinations, meaning the backend systems you have already connected, and the skills you eventually expose to Joule.
A configuration detail worth flagging here because it causes a surprising amount of wasted troubleshooting time involves the destination property sap.processautomation.enabled. If this property is not set to true on your destination, that destination simply will not appear in the Joule Studio destination browser. There is no error message explaining why. It just is not there. If you are staring at an empty destination list wondering what went wrong, check this property before you start questioning your network configuration or credentials.
Once your action project exists, you publish the relevant actions to the library. This step matters more than it sounds like it should. Actions that are released but not published will not show up when you go looking for them inside the Skill Builder’s browse dialog. Both creating and publishing are required steps, not one or the other.
From there, you create the actual skill inside Skill Builder, give it a clear name and description, and select which published action it should call. The description you write is not just documentation. Joule uses it to determine which skill to trigger when a user asks a natural language question, so vague or generic descriptions lead directly to a confused Joule that picks the wrong skill or fails to find a relevant one at all. Be specific about what the skill does and when it should be used.
Moving Up to Agent Builder
Agent Builder reached general availability at the start of 2026, and it represents a meaningful step up from skill creation. Where a skill executes one task deterministically, an agent reasons through a request, decides which skills to call and in what sequence, processes the results, and synthesizes a final response that addresses the original question even if it required multiple steps to get there.
Building an agent starts with a clear instruction prompt that frames its role. Something like defining the agent as an assistant with access to a specific knowledge base, master data, or set of system logs, and giving it explicit guidance about what kinds of questions it should help with and how it should ground its answers. Vague instructions produce agents that hallucinate or wander off task. Specific instructions, tied to the actual skills you have made available to it, produce agents that behave predictably.
A particularly useful feature here is agent extensibility. Rather than building every agent completely from scratch, you can take SAP’s existing ready to use Joule agents and adapt them by adding your own tools along with pre and post processing logic, all in a way that stays compatible with future upgrades. This matters a lot in practice, because building net new agents for every single use case is expensive and creates long term maintenance burden. If an existing native agent already covers eighty percent of what you need, extending it is almost always smarter than starting fresh.
Grounding Your Agents in Real Data
An agent without context is just guessing dressed up in confident language. This is where document grounding becomes essential for anything you build through Joule Studio. By connecting your agent to a document grounding tool backed by SAP AI Core and an object store, your agent’s responses get tied to actual business documents rather than generic training knowledge. If you are building something like a compliance assistant or a policy advisor, skipping this step is the difference between a tool people trust and one they quietly stop using after the first wrong answer.
Beyond documents, agents can also reason over relationships between data, processes, and business objects across the broader SAP ecosystem. This is what separates a genuinely useful agent from a glorified chatbot. Context turns guessing into informed decision making.
Connecting Beyond SAP
Modern enterprise development rarely lives entirely inside one vendor’s walls, and SAP has clearly recognized this. Joule Studio now supports connecting agents to non SAP systems through the Model Context Protocol, an open standard that lets AI systems talk to external tools without a fully custom integration for every connection. It also supports bi directional Agent to Agent communication, which allows third party agents to securely call on Joule Agents and, just as importantly, lets Joule Agents call out and act within processes managed by external systems.
For workflow orchestration specifically, SAP has partnered with n8n to embed a fully managed workflow environment directly inside the platform. This means you can wrap an agent in a visual workflow for things like human in the loop approvals, routing tasks to the right team, or handing tasks off between multiple agents, all without leaving SAP’s governance boundary. If your use case involves any kind of approval step or multi team handoff, building that logic in n8n rather than trying to cram it into the agent’s own reasoning tends to produce a cleaner, more auditable result.
Framework Flexibility for Pro Code Developers
If you are coming from a pro code background and already have strong opinions about which agent orchestration framework you prefer, recent updates are worth knowing about. Joule Studio has expanded its supported frameworks beyond LangChain to also include AutoGen and LlamaIndex, giving developers more freedom to use tools they are already comfortable with instead of being locked into a single approach. There is also growing support for working inside familiar coding environments, including integrations with tools like Cursor and VS Code style extensions, which lowers the friction for developers who want to build with the same setup they already use for everything else.
Testing and Debugging Your Agents
Do not skip building in visibility from the start. One advantage of working through Joule Studio rather than hand rolling everything is that you get traceability into how an agent reached a particular answer, which skills it called, and in what order. This visibility is genuinely valuable for debugging when something goes wrong, and it becomes essential for auditability once an agent moves into production and someone eventually asks why it took a particular action. Build test cases around realistic, slightly messy user questions rather than only the clean examples you used during initial development. Real users phrase things oddly, leave out context, and ask multi part questions that stress test your agent’s reasoning in ways a tidy demo never will.
Practical Tips Before You Start Building
A few habits separate developers who ship useful agents from those who end up with abandoned prototypes. First, inventory your highest value automation candidates before touching the platform at all. Look specifically at repetitive, rules based processes that consume time from skilled employees, and exception handling workflows that already have clear escalation logic, since those translate cleanly into agent behavior. Second, check what already exists before building anything new. With thousands of prebuilt Joule Skills now available across SAP’s library, there is a real chance the capability you need already exists or is close enough to extend rather than recreate. Third, treat your agent’s instruction prompt and skill descriptions as first class artifacts that deserve real editing and iteration, not an afterthought you write once and forget. Finally, get comfortable with the SAP Community. There is a genuinely active group of people building on Joule Studio who share working examples, troubleshooting fixes, and templates, and learning from someone else’s already solved problem is almost always faster than solving it yourself from scratch.
Where This Is Heading
The platform is moving fast, and the direction is consistently toward lowering the barrier between having a business idea and having a working agent in production. Newer developments point toward describing a desired outcome in plain language and getting a much larger head start on the technical scaffolding needed to build it, alongside expanding interoperability between custom built agents and SAP’s own native ones. For developers, the practical takeaway is straightforward. The skills you build today around clear instructions, tight grounding, proper identity handling, and thoughtful reuse of existing components are going to keep paying off even as the tooling around them continues to evolve. Start with one well scoped skill, get it genuinely useful, and let your understanding of the platform grow from real production experience rather than trying to master every capability before you ship anything at all.
