In a year, SAP’s Joule has gone from a copilot that suggests to an agent platform that acts. It is real and it is capable - but it comes with prerequisites that decide whether you can use it at all. Here is the straight picture for anyone building on SAP.

The last article covered the open standards - MCP and A2A - that let agents connect to the systems you run. This one narrows to SAP, because if your ERP is SAP, Joule is the first thing your team will reach for, and it has moved quickly enough that it is worth separating three things: what it is now, where it is strong, and the prerequisites that catch people out.

From copilot to platform

A year ago, Joule was an assistant embedded across SAP that answered questions and drafted things. In 2026 it is an agent platform. SAP now offers more than forty specialised Joule agents and a couple of thousand pre-built “skills” across its applications, and - more importantly - a way to build your own.

It helps to keep two terms straight. A skill is a single, rule-based action, such as calling a specific SAP transaction. An agent is the layer above: it plans, reasons and orchestrates several skills to handle a multi-step task. The tool for building both is Joule Studio, whose agent builder became generally available in early 2026. At Sapphire in May, SAP went further with a fully managed version of Joule Studio - browser-based, with no infrastructure to stand up - aimed at business users as much as developers; that managed version is in early access, with general availability targeted for later in 2026. Dates and availability move quickly here, so confirm them before you plan around them.

Where it is strong

Joule’s real advantage is that it is native. Its agents are grounded in your SAP data, processes and business semantics, which a generic assistant bolted on from outside is not. The pre-built agents map onto exactly the functions this series has covered: a cash-management agent that reconciles and reports on cash positions, a dispute-resolution agent that works invoice discrepancies end to end, a procurement agent that compares supplier bids, a supply-chain agent that checks material and capacity and can release production orders. Early adopters report meaningful time savings on these, though the specific figures are SAP’s and are worth treating as indicative until you see them in your own environment.

Just as important for your IT team: a Joule agent runs inside the requesting user’s security context, applying the same SAP authorisation checks as any other access, with audit trails and role-based controls. It is not a side door around your permissions model. That native grounding and governance is the real case for Joule over a general-purpose bot.

It speaks the open protocols too

Joule is not a walled garden. Its agents can call MCP servers to reach non-SAP tools and data, and SAP has its own agent-to-agent protocol so Joule agents can interoperate. There is even a storefront MCP server on the way for SAP’s commerce products, letting agents transact without a traditional interface. In other words, Joule plugs into the same open standards we described last time - which is what lets it sit inside a wider, multi-vendor agent estate rather than trying to replace it.

Now the part that catches people out

Here is what the launch material tends to skip. Joule has hard prerequisites, and they decide whether it is available to you at all.

• It requires cloud SAP. Joule and the agent-to-agent protocol are available only to customers on RISE with SAP or GROW with SAP. On-premise ECC systems get neither, regardless of how ready you are to invest. If you are not on cloud S/4HANA, the agent conversation is really a migration conversation first - and with mainstream ECC support ending in December 2027, that clock is already running.

• Customisation blunts the pre-built agents. The more heavily tailored your SAP estate, the less the out-of-the-box agents simply work, and the more they need extending or bridging.

• Consumption pricing is easy to under-budget. Joule is charged through consumption-based AI units, and the allowance bundled into a RISE contract is typically enough for pilots, not for production scale. Model the running cost before you commit to a rollout.

• Adoption is still early. Independent surveys of the SAP base in 2026 put production use of SAP’s business AI in the low single digits of a percent, with most AI-active companies reaching for non-SAP tools instead - partly because of these very prerequisites.

So is Joule the answer? That is usually the wrong question

It is tempting to frame this as “Joule or not Joule”. For a real business it is rarely that binary.

No enterprise is only SAP. You have a data warehouse, cloud services, non-SAP applications and a customised SAP history of your own. Joule is strong for SAP-centric processes on a reasonably clean, cloud SAP core. It is not the tool for the parts of a process that live outside SAP - and most end-to-end processes cross that line somewhere.

The question is rarely “Joule or not Joule?” It is which parts of a process run natively in SAP, and which need to reach beyond it.

So, the practical answer is both: use Joule where it fits, and use the open interfaces from the last article - MCP and A2A - to bridge everything it does not reach, including your Google Cloud estate. That is the vendor-neutral position, and it is the one that survives contact with a real landscape.

What “agent-ready” means for an SAP estate

For an IT leader, “agent-ready” is less a switch to flip than a short set of honest questions:

• Are we on RISE or GROW - or is a move to cloud SAP the real first step?

• How clean, or how customised, is our core?

• What is our consumption budget for production, not just for pilots?

• Which of our priority processes are SAP-only, and which cross into other systems?

Answer those and you know what is buildable in Joule now, what needs bridging, and what is groundwork before anything agentic pays off.

The bottom line

Joule is a real, fast-moving capability, not vapourware, and for an SAP-centric business it is the natural place to start. But “making SAP agent-ready” is mostly about the state of your estate - which contracts you are on, how clean your core is, and how well SAP connects to everything around it - rather than about switching a feature on. Mapping that out for your own landscape is exactly where we would begin. Click on SAP to know more.