Prebuilt vs custom Joule Agents: use, extend or build

In 30 seconds

What it is Use prebuilt where the process is standard, extend where it bends, build where it differs.

You use it when A business team asks for an agent and you must decide whether SAP already ships it, whether to extend it, or whether to build.

Next in this section SAP Business AI Explained: Joule Work, Assistants, Agents and Studio →

Use prebuilt where the process is standard, extend where it bends, and build only where it truly differs. You maintain what you build.

Part 13 of 26 in SAP Business AI, Explained.

The first question in nearly every agent workshop I run is “can we build one that…”. I’d rather start by asking whether SAP already ships it, because every agent you build is one you test, secure and upgrade for as long as it runs.

Use SAP’s ready-made agent when your process is standard, add your own rules when it’s nearly right, and build only when the process is genuinely yours.

Buy, bend or build

SAP recommends prebuilt Joule Agents for standard processes, with fast time to value and SAP-managed updates.
SAP’s Joule Studio post describes extending a standard agent with your own logic without touching its core. Today that means custom instructions, with MCP (Model Context Protocol) tools and n8n hooks described as coming soon. SAP sources differ on when these become available, so check the Joule capability watch.
SAP says to build custom in Joule Studio when a workflow is unique enough that standard agents only partly fit, and that you then own the full lifecycle.

The everyday picture

In the series hospital, a prebuilt agent is a specialist doctor hired from an accredited agency. The agency trains them and answers for their standards. An extension is the same doctor following your hospital’s own protocols. A custom agent is a doctor you trained yourself, which can be right for a rare specialty, but now you own their training, their licence renewals and every mistake.

How I run the decision

Check the catalogue. SAP lists Joule Agents and Assistants by line of business on its Joule Agents page. Start there before anyone opens Joule Studio.
Run the prebuilt agent against your real process variants. Note where it’s right, where your rules differ and where it has no answer.
Where only the rules differ, add your instructions on top of the standard agent in Joule Studio. SAP’s post says your logic layers on top while SAP keeps maintaining the base.
Where the process is yours, use Joule Studio’s intent-based development to generate requirements, specification, code and tests for a new agent.
Register every result the same way, with an owner, autonomy level and approval in SAP AI Agent Hub before go-live.

One design review, three requests at NextSAP

NextSAP Utilities is a Dubai multi-utility (electricity, water, gas and district cooling) with about 5 million customers and a shared services team in India, running SAP S/4HANA with SAP Utilities and SAP FI-CA, plus SAP SuccessFactors and SAP Ariba. It’s the fictional company used across this site’s SAP content, here to make the choices concrete.

Rashid, the procurement lead, Elena, the collections lead, Omar, the finance controller, and Priya, the IT platform owner, bring three requests to one design review.

1. Sourcing and supplier risk: use as is

Rashid’s team runs about 35 sourcing events a quarter, worth roughly AED 60 million (UAE dirhams), and their process is close to standard SAP Ariba sourcing. SAP describes a Joule Sourcing Agent that helps managers refine sourcing events and assess geopolitical risks. Rashid’s test on five past events shows it matches how his team works, so they use it as is, at L2 Propose. Priya’s team builds nothing.

2. Collections prioritiser: extend

In this series, the collections prioritiser is a prebuilt agent pattern that ranks overdue accounts (check SAP’s catalogue for the exact agent in your release). It fits well, but Elena’s team has a local rule. Commercial customers in a formal payment plan agreed by Layla, the CFO, must never be called by the agent’s list, whatever their age. That covers 85 accounts worth AED 3.2 million. That’s a business rule, not a new process, so they extend the prebuilt agent with a custom instruction to exclude those accounts and keep SAP’s base behaviour for the rest.

3. Payment clarification: build custom

At a utility, contract accounting is native. NextSAP runs billing, payments, dunning and deposits for electricity, water, gas and district cooling for about 5 million customers on SAP contract accounting (Contract Accounts Receivable and Payable, FI-CA). It receives about 140 unclear incoming payments each working day that the bank statement didn’t auto-match, and they land on clarification account 1190100. Many come from commercial customers paying several bills in one transfer with a free-text reference, such as Marina Bay Café LLC, or from Al Noor Property Management paying for many premises in one go. Matching them needs NextSAP’s own contract-account logic. Anyone who has worked FI-CA clearing will recognise this one. They build a custom agent in Joule Studio at L2 Propose. Omar’s team owns the process, and Priya’s team owns the code, tests and upgrades.

The review ends with one sheet: one agent needs no build, one needs a small extension, and only one needs a full project. In my experience, custom builds usually end up the minority.

SAP’s published stories show the same split. SAP describes Bosch using a prebuilt Joule Classification Agent to route customer service cases in real time, replacing rigid rule-based workflows. It also describes Uniper using Joule Studio to build a custom procurement agent that turns complex procurement processes into conversational actions.

Questions that settle it

Question	If yes	If no
Is the process close to SAP standard?	Start with a prebuilt agent	Lean towards custom
Does the prebuilt agent fit your variants as is?	Use as is	Ask the next question
Is the gap only your rules or policy?	Extend with custom instructions	Ask the next question
Does it differentiate you, so you would never want a standard version?	Build custom in Joule Studio	Revisit, you may be over-engineering
Does it need data from outside SAP?	Check the extension roadmap and connectors before deciding to build	No extra build reason
Can you accept owning upgrades and retesting?	Building is viable	Prefer prebuilt or extend
Is there a named owner for the agent’s whole life?	Proceed	Stop until there is one

	Prebuilt as is	Extended	Custom in Joule Studio
Who maintains the base	SAP	SAP	You
Your effort	Enable, test, govern	Write rules, test, govern	Design, build, test, secure, govern, upgrade
Upgrade safety	Highest	High, if your logic stays outside the core	Your responsibility
Time to value	Fastest	Fast	Slowest
Fit to unique process	Lowest	Medium	Highest

What each option leaves on your plate

A prebuilt agent gives you SAP’s process expertise and SAP-managed updates, but doesn’t know your local exceptions until you tell it. An extension adds your rules while SAP keeps maintaining the base, per SAP’s Joule Studio post. It can’t add new tools today, since SAP describes MCP tools and n8n hooks for extensions as coming soon.

A custom agent automates a process that’s yours alone, without SAP’s lifecycle care. SAP says you take on full lifecycle responsibility. That’s why I push teams to extend before they build, and to build only what differentiates them.

Explain it to your CFO

We use the ready-made digital helpers wherever our process is normal, because the supplier keeps them up to date. Where our rules differ, we add our rules on top instead of rebuilding.
We only build our own where it gives us an edge, and we budget to look after it every year.

Who signs off what

Who checks the catalogue first? I’d make the solution architect confirm no prebuilt agent fits before any custom build is approved.
What’s your evidence threshold for “does not fit”? A test on at least 20 real process cases, with gaps written down by the process owner.
Who owns a custom agent after go-live? A named process owner for outcomes and a named platform owner for code, both recorded in SAP AI Agent Hub before approval.

Go deeper

Technical detail for architects and developers

SAP’s Joule Agents FAQ is plain about the split: use prebuilt agents for standard processes with SAP-managed updates, build custom in Joule Studio when standard agents only partly address your needs, and expect most organisations to run a hybrid.

On how extensions work, the Joule Studio post on SAP Community says you can extend any SAP standard agent without touching its core. Today you add business logic through custom instructions. SAP lists MCP (Model Context Protocol) tools and n8n hooks as coming soon, with hooks firing before or after a workflow. SAP’s worked example is an accounts payable agent whose match failures trigger an after-processing hook that routes the exception for review. Check the current status in the capability watch linked above.

In the SAP Community purchase requisition session, Joule Studio generated agent code, MCP servers for each required API (application programming interface) and test cases. Each MCP server and the agent deployed separately and could be reused by other agents. The presenter noted that authorisation set-up for system access remained a separate step. Custom OData (Open Data Protocol) APIs had to be described manually because Joule Studio discovers only published SAP APIs.

SAP’s Joule Agents page says Joule Studio supports low-code and pro-code, with frameworks such as LangChain and LlamaIndex.

Governance is the same for all three. A community post on agent mesh design describes agents discovered by SAP AI Agent Hub starting as unverified, with a verification record leading to verified or rejected. I treat that as the gate for prebuilt, extended and custom agents alike. A prebuilt agent still needs an owner and an autonomy level in your landscape.

For upgrade safety, keep your logic outside the standard agent’s core, version it in Git, and rerun your evaluation set after every SAP release that touches the base agent.

Words you’ll hear

Prebuilt Joule Agent: an agent SAP designs, ships and maintains for a standard business process.
Agent extension: your own logic layered on a standard agent without changing its core, built in Joule Studio.
Custom agent: an agent you design and build yourself, usually in Joule Studio, and maintain for its whole life.
Custom instructions: plain-language rules you add to an agent to reflect your policies.
n8n hook: a planned extension point that triggers an n8n workflow before or after an agent step.
Lifecycle responsibility: owning testing, security, upgrades and retirement of something you built.
Clean core: SAP’s principle of keeping standard software unmodified, with changes made outside it.

Keep going

Independent explainer, not affiliated with or endorsed by SAP SE. SAP, Joule and other SAP product names are trademarks of SAP SE.

Frequently asked questions

When does SAP recommend prebuilt Joule Agents?

SAP's Joule Agents FAQ says to use prebuilt agents when your needs match standard processes in areas such as finance, HR or procurement and you want fast time to value with SAP-managed updates.

When should I build a custom agent in Joule Studio?

SAP says to build custom when your workflow is unique enough that standard agents only partly cover it, and notes that you take on full lifecycle responsibility for what you build.

Can I change a prebuilt agent without touching SAP's code?

SAP's Joule Studio post describes agent extensions that add your own business logic on top of a standard agent. Today that means custom instructions, and MCP tools and n8n hooks are described as coming soon.

Do most companies choose one approach?

No. SAP says most organisations take a hybrid approach: prebuilt agents for common processes, with Joule Studio used to extend or build where the business case justifies it.