SAP Joule Studio — How Intent-Based Development Works

The old way of getting an agent built went something like this. A business person explains what they need to an analyst. The analyst writes it up as a requirements document.

A developer reads that document, makes assumptions about the parts that were not spelled out, and builds something. Three weeks later, everyone is in a room discussing why the thing that got built is not quite the thing that was asked for.

That gap — between what someone actually meant and what ends up in production — is where most enterprise software projects quietly lose weeks. SAP Joule Studio is built to close it, and the mechanism it uses has an actual name: intent-based development. Not a marketing phrase, a specific structured pipeline that takes a plain-language description of a business outcome and walks it through to a deployed, working agent.

Here is how that pipeline actually works, what it produces at each stage, and the two different ways you can drive it depending on whether you are a business user or a developer.

🔗 Related reading

Once an agent is built here, it gets tracked and approved elsewhere — SAP AI Agent Hub — Governance or Discovery? covers that.

And the quality of what Joule Studio can build depends heavily on your underlying data model — Clean Core Is the AI Precondition for SAP Agents explains why.

Neither is required reading for this post.

📝 Note

SAP announced Joule Work at SAP Connect 2026 — a new business AI orchestration engine, with Joule Studio repositioned as its “Develop” capability rather than a standalone product. Joule Studio itself is soon to be generally available. None of that changes the mechanics below: the six-phase pipeline and the Low-Code/Pro-Code split are still how agents actually get built, just inside a wider product shell.

What intent-based development actually replaces

The traditional cycle has a structural problem: every handoff is a translation, and every translation loses something. Business intent becomes a requirements document. The requirements document becomes a technical specification, usually written by someone different again.

The specification becomes code, written by someone who was not in the room for the original conversation. By the time anything runs, it has been re-interpreted three or four times.

Intent-based development collapses that chain. You describe the business outcome you want in plain language once, at the start, and the platform carries that intent through every subsequent artifact automatically — generating the requirements, the specification, the code and the tests as a connected chain rather than a series of separate, disconnected translations.

Nothing is a black box along the way; every generated artifact is editable, so a developer can still adjust the technical specification or rewrite the generated code. What changes is the starting point: you are editing something already grounded in the original intent, not building from a blank page.

📌 Key takeaway

Intent-based development is not about removing developers from the process. It is about giving everyone — business user and developer — a shared, traceable artifact chain that starts from the same stated intent, instead of each person re-interpreting a document written by someone else.

The six-phase pipeline

Underneath the plain-language interface, Joule Studio runs a structured, six-phase lifecycle every time, regardless of what you are building — an agent, an application, or a workflow.

Phase	What happens
Intent	You describe the desired business outcome in natural language — the single starting point everything else derives from
Requirements	The platform expands that intent into a structured product requirements document, capturing the business outcome in detail
Specification	The PRD becomes a technical specification with implementation-ready detail — the bridge between business language and code
Code generation	Actual code scaffolding is produced in a real target framework, populated with the specific API calls and business logic the spec calls for
Testing	An evaluation suite is generated alongside the code, so the solution has test coverage from the start rather than bolted on afterward
Deployment	The finished solution deploys to the SAP-managed runtime and is automatically registered as part of your SAP Business AI Platform

Every phase produces a real, inspectable artifact — not an internal state you have to trust blindly. You can read the generated PRD before code exists. You can read the technical specification before it becomes code.

That traceability is the actual point: if the finished agent does something unexpected six months from now, you can walk back through the chain and find exactly where the requirement was stated, rather than starting from raw code with no record of the original intent.

Grounded, not generic — where the business context comes from

A generic AI coding assistant can generate plausible-looking code from a prompt. What it cannot do is know that your specific SAP landscape already has a purchase order approval process, a specific set of custom fields on the customer master, and a particular way finance expects exceptions to be routed.

Joule Studio’s answer to that gap is grounding every stage of the pipeline in three specific sources of business context rather than generating in a vacuum.

Source	What it provides
SAP Knowledge Graph	API discovery and fit-gap analysis — identifying which existing SAP capabilities and APIs are actually relevant to the stated intent
SAP LeanIX	Your specific enterprise landscape — the applications, business capabilities and organisation structure already in place, so the solution fits your environment rather than a generic one
SAP Domain Models	The underlying business semantics and data structures that let generated code reason correctly about SAP objects and processes

This is the same architectural instinct behind the platform generally: an agent, or the code that builds one, is only as reliable as the business context it is grounded in. Joule Studio does not ask you to describe your landscape from scratch in the prompt — it already has access to it.

Two ways in — Low-Code and Pro-Code

Joule Studio does not force a single audience through a single interface. The same six-phase pipeline is accessible two different ways, depending on who is driving it.

	Low-Code Flow	Pro-Code Flow
Who it’s for	Business users and citizen developers	Professional developers with their own toolchain
How you work	Visual, browser-based builder — no local setup required	Your own IDE, using the Joule Studio CLI and a coding agent connected via MCP
What you get	Same six-phase pipeline, generated through a guided visual experience	Same six-phase pipeline, driven from familiar developer tools and version control
Output	The same deployable artifact as Pro-Code	The same deployable artifact as Low-Code

That last row is the detail worth sitting with. Both flows produce the same deployable artifact, automatically registered with Joule.

A business user prototyping through the visual builder and a developer working from the CLI are not building two different kinds of things that need to be reconciled later — they are two entry points into the same pipeline, producing output that lands in the same place.

💡 Practical tip

Do not assume Low-Code means “toy” and Pro-Code means “real.” Start a solution in whichever flow matches who owns the intent. If a business analyst can get further before a developer needs to touch it, let them — the generated artifacts are there for a developer to review and refine later, not to be thrown away and rebuilt.

What happens after deployment

Getting a working agent deployed is not the end of the story, and Joule Studio does not pretend otherwise.

Once a solution deploys to the SAP-managed runtime, it is automatically registered as part of your wider SAP Business AI Platform footprint — which is where separate governance tooling takes over: tracking the agent’s lifecycle, approving it for production use on sensitive tasks, and giving it a proper identity and audit trail.

📝 Note

Building an agent and governing an agent are deliberately separate concerns in this architecture. Joule Studio’s job ends at a deployed, registered artifact. What happens to that artifact afterward — approval, monitoring, identity, retirement — belongs to a different part of the platform entirely, and is worth its own reading if you want the full picture.

At a glance — SAP Joule Studio

Concept	One-line summary
SAP Joule Studio	SAP’s AI-native development environment for building agents, apps and workflows, grounded in SAP business context
Intent-based development	A structured methodology that carries a plain-language business intent through requirements, spec, code, testing and deployment as one traceable chain
The six phases	Intent → Requirements → Specification → Code generation → Testing → Deployment
Business context grounding	SAP Knowledge Graph, SAP LeanIX and SAP Domain Models — so generated solutions fit your actual landscape, not a generic one
Low-Code Flow	Visual, browser-based builder for business users and citizen developers — no local setup
Pro-Code Flow	CLI and your own IDE, with a coding agent connected via MCP, for professional developers
Same output either way	Both flows produce the same deployable artifact, automatically registered with Joule
After deployment	Governance, approval and identity are handled separately, by the platform’s governance tooling

What to take away

The genuine achievement of intent-based development is not speed, even though it is faster than the old handoff chain. It is traceability.

Every artifact in the pipeline — the PRD, the spec, the code, the tests — traces back to a single stated intent, in a way a hand-built agent with no such chain never can.

That matters most on the day something goes wrong. A hand-built agent that misbehaves gives you code and a shrug. A Joule Studio agent gives you a documented chain back to the original business intent, which means the question “is this doing what we meant” has an actual answer instead of a guess.

Building fast was never really the hard part of enterprise software. Building something you can still explain a year later was. That is the problem intent-based development is actually solving.

🔗 Related posts on this site

SAP AI Agent Hub — Governance or Discovery? — what happens to a Joule Studio agent after it deploys and gets registered.

Clean Core Is the AI Precondition for SAP Agents — why the landscape Joule Studio grounds itself in needs to be trustworthy in the first place.

SAP Business AI Platform (BAIP) — BTP, BDC and AI Explained — the wider platform Joule Studio is the Build layer of.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/sap-joule-studio-how-intent-based-development-works/