For thirty years, a change in SAP came with a signature.
The transport request carried an owner, a release, an import history and an approver. When an auditor asked what was running in production on a given date, the system answered without anyone having to remember. Nobody designed that as a governance program. It came with how changes moved.
SAP TechEd opens in Berlin this week. On October 8, SAP described the new Joule Studio as “soon to be generally available.” The lifecycle it has published is worth reading closely.
The pipeline is real
SAP’s own training material lays out the path. You describe the outcome you want. Joule Studio produces a requirements document, then a technical specification, then code. Before release, it runs automated evaluations and produces a test report with pass/fail results. The solution deploys to an SAP-managed runtime, and AI Agent Hub governs it from there.
Version control is built in. In SAP’s words, “Solutions are pushed to GitHub for review and repeatability.”
Git gives you full history, real diffs and review before merge. The evaluations give you evidence before release. That’s good engineering.
So the question isn’t whether the pipeline is sound. It’s whose habits come with it.
Change Control and Change Enablement
SAP has already named the difference. In its Cloud ALM training, SAP calls ChaRM and Focused Build “Change Control,” the stricter model, and Cloud ALM “Change Enablement,” the more flexible one. Those are SAP’s words, not mine.
They describe two cultures. SAP teams have spent careers in a world where an error in production is a failure: someone explains it, and the fix goes through the same gates that should have caught the mistake. Teams raised on Git work from a different assumption. You move fast, and if something breaks, you roll it back.
Git-style controls for ABAP have existed since 2019, when SAP shipped the Git-enabled Change and Transport System with S/4HANA 1909. I’ve never heard of a team that actually adopted it. Nobody publishes an adoption figure, and I looked. Transports already did the job, and the audit evidence was built around them. Nothing forced a move.
Agents force it. An agent definition, a prompt or an evaluation set doesn’t travel in a transport. For this kind of change, the Git pipeline is no longer optional. It’s how SAP builds.
Each culture is right about the thing it was built for. The trouble starts where they meet.
What a revert can’t reach
Rolling back works when the code is the only thing that changed.
Take an agent that creates credit memo requests for pricing disputes. On Tuesday someone changes its instructions. By Thursday it has created two hundred requests, and billing has already turned most of them into credit memos. On Friday the team reverts the agent to last week’s version in one clean commit.
The agent is fixed. The documents are not.
In SAP, you don’t delete a billing document. You cancel it with another document that points back to it, and every step stays in the document flow. That’s by design, and it’s why finance teams trust the system. It also means the cleanup is a business process with a cost, not a Git command.
A revert undoes the agent. It doesn’t undo what the agent posted.
So for agents that write to SAP, the control has to sit before production, where SAP teams have always put it. This isn’t a case against the pipeline. It’s a case for building the signature into it.
Named, not described
SAP knows a sign-off belongs there. Its lifecycle material says tracing, metrics and logging support “production sign-off.” Its announcement of the new Joule Studio mentions “controlled deployments.” AI Agent Hub holds agents that haven’t passed governance checks “in a pending state until cleared.”
SAP’s recommended Joule landscape runs Development, Test and Production and says to “promote qualified changes to production.” It’s the shape of change control, and the same people run it. What it doesn’t say is what carries the approval from one tier to the next, or what proves production is running what QA approved.
All of that names a sign-off. Nothing SAP has published that I could find says who signs, what gets recorded, or how a change to an agent links to a change request the way a transport does.
TechEd may fill some of this in. Either way, the record is yours to define, because only you know which agents touch which documents.
Write the record
Here’s what I’d require before any agent that writes to SAP goes live or changes. It’s the transport record, rebuilt for agents.
What changed. The definition, the instructions, the tools it can call, and the model and its version. If the model can be retired or swapped without a commit, record which version was approved.
Blast radius. What it can write, to which documents, how often, and under whose authorizations. An agent acting with a clerk’s roles and the same agent acting with a finance manager’s are not the same change, and QA tested it with test roles. Where a connection uses a technical user instead, the blast radius is whatever that user was granted, for everyone.
The evidence. The evaluation report for this version, not the last one. The test case has to be “what happens when it’s wrong,” not only “does it work.” It also needs proof that production is running the same version, model and configuration that passed QA.
Who approved. A named person with the authority to approve. SAP has already defined a role for this, the Agent Manager, typically an enterprise architect or IT governance lead. Make sure the role belongs to someone in your organization.
The way back. Not only reverting the agent, but how documents it has already posted get reversed, and who owns that.
Complete means complete. Training content checked, process documentation updated, test cases updated and rerun.
The roles shift with it. Everyone in the chain knows how to read the blast radius of a transport: the consultant, the tester, the change board, and Basis as the last line of defense. An agent’s blast radius sits where none of them were trained to look, and when the deploy command is the release, whoever runs it is making the call. The transport coordinator becomes a release owner who reads evaluation reports alongside import logs. The functional consultant who wrote test scripts now writes the evaluation set. No job goes away, but every one of them gets new things to read.
This week
Pick one agent you have in pilot, or one you plan to build. Have each person in the chain write down what it can post, to which documents, on which model, and under whose authorizations. Then compare the answers. Wherever they differ, or someone has to go ask, that’s where the record starts.
If you run Cloud ALM, a manual transport reference is one place to tie that record to your existing change process until something better exists.
Then take three questions to SAP or your implementation partner. Who signs the production sign-off? Where is it recorded? What happens to an approved agent when its model changes underneath it, or when a different user runs it?
The pipeline will get you to production faster than anything SAP has offered before. It just won’t sign off for you.