Joule Studio: SAP Joule Studio 2.0, Agent Builder, Cost and Activation

Joule Studio is a capability in SAP Build that lets developers design Joule agents and Joule skills on a low-code, no-code canvas. SAP's own framing is worth quoting because it explains the architecture: "Since it is part of SAP Build, Joule Studio has native access to all your connectors, automations, apps, and actions, enabling you to reuse artifacts, leverage shared APIs, and operate within a single governance framework."

That answers the question people keep typing into Google as "Joule Studio is part of which SAP suite". It is not a standalone product and it is not part of Joule itself. It is a capability inside SAP Build, which is why the entitlement you buy is an SAP Build developer license rather than anything with Joule in the name.

There are two builders inside it, and they solve different problems:

• Skill builder creates Joule skills, which are rule-based, deterministic tasks. Released earlier in 2025.
• Agent builder creates Joule agents, which plan, reason and execute multi-step work across systems. Generally available since 19 December 2025.

The distinction matters commercially as well as technically, because SAP prices the two differently. Skills cost nothing extra to orchestrate or invoke. Agents are free only under a promotion with an end date on it.

One architectural detail deserves more attention than it gets. SAP says Joule Studio "enforces principal propagation, meaning the user's identity in Joule is passed through end-to-end so that any triggered skill or agent runs strictly within that user's security context, applying the same authorization checks and access restrictions." In plain terms, an agent cannot read data the person talking to it could not already read. If you have been asked by an audit or security team how a custom agent avoids becoming a privilege-escalation path, that sentence is the answer.

Joule Studio 2.0 is the managed edition. The version that is GA today is formally called Joule Studio, Classic Edition, and it expects you to own and wire up the underlying BTP services yourself. Joule Studio 2.0 removes that work: SAP manages the provisioning, so teams do not stand up Cloud Foundry or SAP AI Core themselves.

As of August 2026 it is available through Early Adopter Care, with general availability targeted for Q3 2026. That is a target rather than a commitment, and SAP has not published its entitlement or pricing model yet, so any 2026 budget line for Joule Studio 2.0 is an estimate.

Reported additions in the 2.0 line include a broader set of development environments and agent frameworks, with Cursor joining VS Code as a supported environment and AutoGen and LlamaIndex joining LangChain as supported frameworks. SAP has also positioned a partner-facing self-service track, with TCS, Wipro and NTT DATA named among early access partners publishing agents for HR onboarding, accounts payable automation and predictive maintenance.

The practical read for a buyer: if you already own SAP Build and have BTP skills in house, Classic Edition is available now and its agent runtime is free through the end of 2026. If you do not want to own the plumbing, 2.0 is the thing to wait for, and you should plan around a target date rather than a published one.

There is no separate Joule Studio price tag. You pay for the entitlements underneath it, and right now the agent runtime itself is promotional. Here is the actual commercial shape, from SAP's own activation guidance:

That last row is the one that surprises people. SAP is explicit about it: "for both custom skills and agents, the underlying components they use will still follow their standard commercial models." A free agent that calls three billable services all day is not a free workflow. Model the downstream consumption, not the agent.

The SAP Build commercial model was unified across four purchasing routes: Subscription, BTPEA (Business Technology Platform Enterprise Agreement), PAYG (Pay As You Go), and CPEA (Cloud Platform Enterprise Agreement). Which one you are on changes the unit price, not the entitlement you need.

On the promotion, treat 31 December 2026 as a real cliff rather than a formality. SAP has not published what custom agent execution costs afterwards. If you are building a business case that runs into 2027, the honest version has an unpriced line in it.

This is where most activations stall. You need access to a BTP global account carrying all three of the following entitlements, available through the Subscription, BTPEA, CPEA or PAYG model:

Two placement rules sit on top of the entitlement list, and neither produces a helpful error if you get it wrong. Build Process Automation has to be activated in the same subaccount as the Joule instance. And the subaccount has to be in a region where both Joule and Build Process Automation are offered, because those two region lists are not identical.

Then there are the role collections. On the Build Process Automation subaccount, assign the Process Automation roles: ProcessAutomationAdmin, ProcessAutomationDelegate, ProcessAutomationDeveloper, ProcessAutomationExpert and ProcessAutomationParticipant. On the Joule subaccount, create joule_extensibility and end_user.

Once the entitlements are in place, SAP describes the activation as three steps. In practice it is worth treating it as five, because two of them are waits rather than actions.

1. Create the subaccount and activate Build Process Automation on the build-default plan. Pick a region where both Joule (foundation or standard) and Build Process Automation (build-default) are available.
2. Put Joule and Build Process Automation on the same Cloud Identity Services tenant. If you already run Joule, this usually means including the Build Process Automation subaccount in your existing identity setup rather than creating a new one.
3. Run the Joule Booster to connect Joule and Build Process Automation.
4. Update the formation. Go to System Landscape, then Formations, select the existing Integration with Joule formation, click Include Systems, select the Build Process Automation subaccount, tick Enable Capability Deployment and finalize. Then wait for the formation status to become Ready. This is a genuine wait, not an instant toggle.
5. Verify the role collections on both sides, finalize trust and security configuration, then open Joule Studio.

From there, building an agent starts in the SAP Build lobby: create a project of type Joule agent and skill, fill in the project metadata, then create an AI Agent as an artifact inside it.

The metadata step is worth doing carefully rather than quickly. The agent's name and description are what Joule uses to decide which agent should handle a given user request. A vague description is the most common reason a working agent never gets invoked.

An agent definition in Joule Studio has three parts: goals and instructions, which act as its job description; planning and reasoning, handled by the underlying models; and execution, which needs tools. The tools are the interesting part, because they define the ceiling on what your agent can do.

The sub-agent pattern is the one worth designing around early. SAP's own example is an Inventory Restocking Agent acting as an orchestrator that delegates to a Contract Compliance Checker, which validates each proposed restocking order against supplier contract terms before it is placed. Each sub-agent is a reusable resource other agents can call.

Building that way is not just architectural neatness. As SAP puts it, modular orchestration "avoids relying on a single, monolithic agent to handle everything and ensures clearer separation of responsibilities, simplifies testing and maintenance, and makes it far easier to scale agentic solutions as business needs evolve." A single agent with twenty tools is very hard to debug when it picks the wrong one.

Before deployment, the Studio lets you debug the agent and see each step of its reasoning, actions and data flow, using mock conversations, tool-call scenarios and edge cases. Use it. Agent failures are usually reasoning failures, and they are invisible from the outside.

Yes, and this is the most commercially useful thing on this page, because it contradicts what most buyers have concluded about Joule.

Ready-made Joule agents are gated to RISE with SAP and GROW with SAP. If you run classic on-premise S/4HANA or ECC, you do not get them. That gate is real and it has been written up widely enough that many SAP customers have filed Joule under "not for us" and stopped reading.

Custom agents built in Joule Studio are different. In SAP's wording, "the agents created in Joule Studio work across their on-prem solutions including S/4 HANA and SAP ECC, SAP Cloud solutions, and third-party APIs and applications."

So the practical position for an ECC estate is: you cannot switch on SAP's ready-made Joule agents, but you can build your own against the same runtime, and until 31 December 2026 that runtime is free. For a company that has spent two years being told it needs to migrate before it can touch SAP's agentic roadmap, that is a materially different answer.

The caveat is honest and worth stating: you are buying an SAP Build developer license and doing the integration work yourself. This is a build path, not a switch. But it is a build path that reaches systems the ready-made agents cannot.

If you are choosing between Joule Studio and a general-purpose agent builder, the decision is mostly about where your data and your authorization model live.

Joule Studio's advantage is not the canvas, which is comparable to several others. It is principal propagation and native access to SAP artifacts. An agent built in Joule Studio inherits the calling user's SAP authorizations automatically and can reuse connectors, automations and actions you already built in SAP Build. Reproducing that outside SAP means rebuilding an authorization model, which is where most enterprise agent projects quietly die.

The disadvantage is scope. Everything routes through SAP Build and BTP, so you own subaccounts, formations, entitlements and identity services. Compared with a platform that is one signup away, the time to first working agent is longer, and it is administrative time rather than development time.

A reasonable split: if the work is SAP process work touching SAP data under SAP authorizations, build it in Joule Studio. If the work spans systems where SAP is one participant among several, evaluate a general AI agent marketplace or a cross-platform builder, and use Joule Studio agents as one callable component through MCP.

One more timing note. SAP's Capgemini reference reports building "powerful agents in three weeks" in what they describe as an intuitive no-code environment with connectivity across SAP and non-SAP environments. Treat that as a well-resourced partner benchmark rather than a planning figure, but three weeks for a first production agent is not an unreasonable target once the entitlements are sorted. The entitlements are the long pole.