SAP Joule vs. custom BTP agents — when to extend the copilot and when to build your own

Two paths, one platform

The question we hear most from architecture teams is no longer “should we do agents?” but “do we extend Joule or build our own?” SAP’s Architecture Center answers with a deliberate split: low-code agent development in SAP Build via Joule Studio, and — “for complex, mission-critical use cases requiring deep customization” — a full pro-code development stack on SAP BTP. Both are first-class routes. The framework below is about matching your use case to the right one, because the costs of a mismatch run in both directions: pro-code effort wasted on a task Joule Studio handles in a workshop, or a no-code agent straining to express logic it was never meant to hold.

What “extending the copilot” actually gets you

Joule’s standard surface is wider than most teams assume. On the developer side, Joule for Developers generates code, UI, data models and sample data across SAP programming models for Java, JavaScript and ABAP, and can refactor code, create unit tests, and generate code explanations from natural-language queries — embedded across SAP Build Code, Business Application Studio, ABAP development tools for Eclipse and SAP Fiori apps. Availability differs by embedding, and SAP marks it explicitly where it is firm: Joule with SAP Signavio solutions is generally available as of February 2026.

The extension story then runs through Joule Studio, announced in its expanded form at Sapphire 2026 as a “fully managed offering that empowers enterprises to build and manage the full life cycle of AI agents, applications, and workflows”. Its pitch is speed and reach: users describe their goals in natural language, “enabling anyone in the business to quickly create an automated solution”, deployment lands in a “secure, production-ready environment with zero infrastructure management required”, and deployed agents are immediately available to users through the Joule interface — no rollout project, no new front end. SAP is currently sweetening the entry: free design-time access through the end of 2026 under fair-use limits. One availability caution: apart from the Signavio embedding, the fetched SAP pages describe Joule Studio’s managed offering without attaching a blanket GA statement — treat availability per capability, not per brochure.

When to build your own on BTP

SAP’s guidance is specific about the boundary. Low-code suits automating well-defined business processes — SAP’s own examples are “approve purchase order” and “check invoice status”. Pro-code is for complex, multi-step, conditional or dynamic workflows requiring programmatic control. On that side of the line you work directly with SAP AI Core as the runtime environment for AI operations and managed agent execution, and the Generative AI Hub as the central access point to foundation models across providers — Azure OpenAI, AWS Bedrock, Google Vertex AI and more.

Custom does not mean core-invasive. SAP’s clean-core guidance — keep the core “clean, standard, and upgrade-stable while still enabling business-specific differentiation where it counts” — pushes exactly this workload to side-by-side extensibility: decoupled applications that run independently from the core on SAP BTP, with SAP recommending you choose between side-by-side and on-stack per use case, applying a BTP-first strategy. A custom agent is, architecturally, a side-by-side extension: your differentiating logic lives on BTP, and the ERP core stays upgrade-stable underneath it.

The decision framework

Synthesizing SAP’s published guidance into the checklist we use at IOTEK (the synthesis is ours; each criterion traces to the sources above):

• Process shape. Well-defined, bounded, describable in a sentence → extend via Joule Studio. Multi-step, conditional, dynamic → custom on AI Core.
• Control depth. Need programmatic control over orchestration, model choice or tool behavior → pro-code. Standard patterns suffice → low-code.
• Model strategy. Committed to specific foundation models or multi-provider routing → the Generative AI Hub path gives you that centrally.
• Consumption surface. If the answer is “wherever Joule already is,” Joule Studio’s immediate exposure through the Joule interface is hard to beat.
• Clean-core posture. Both paths respect it; a custom agent belongs side-by-side on BTP, never as core modification.
• Team reality. Free design-time access through end-2026 makes Joule Studio the cheap experiment; a pro-code agent is a software product your team must own, version and regression-test.

For the multi-vendor picture: Microsoft frames its own SAP-AI landscape the same way — out-of-the-box (Joule and Microsoft 365 Copilot), extend with custom agents (Copilot Studio), build enterprise AI solutions (Foundry), with the options “complementary, not competing”. That is Microsoft’s framing of its own stack, not SAP guidance, but the three-layer logic is the same and it travels well.

The interoperability line to watch

The extend-vs-build decision is getting less binary. SAP states that it fully embraces A2A (Agent2Agent) as “the preferred standard for multi-agent collaboration and vendor-to-vendor interoperability”, with Joule acting as an A2A client to external agents while agents use MCP to discover and consume tools. And SAP has said Joule’s bi-directional A2A capabilities “will be generally available in Q4,” enabling third-party agents to securely call on Joule Agents — a roadmap commitment, not a shipped feature, but one that means a custom agent built today should speak A2A/MCP so it can join the orchestration layer tomorrow.

Extend Joule when the process is standard and the value is speed; build on AI Core when the logic is genuinely yours and the value is control. Keep the core clean either way — and whichever path you choose, check the availability status of every capability in the pitch, because in this portfolio GA is the exception you verify, not the default you assume.

Sources