Part 1 of 10 · Building an Agentic Change-Approval MVP on MuleSoft
Ask anyone who has run SAP in a regulated company how long it takes to move a tested change from QA to production. They rarely answer with a number. They sigh and start describing the process.
That process is the subject of this series. Over ten parts I'll take one real-world use case, automating the approval and promotion of SAP changes from lower to upper environments, and walk it through architecture, design, build, governance, testing, deployment and production support on MuleSoft.
The setting is a fictional regulated medical-device manufacturer. The problem is real, and if you run SAP in pharma, life sciences or any other audited industry, you'll recognise it.
A typical change promotion in a validated SAP landscape looks roughly like this:
Break those stages into individual tasks and you get about 21 steps, spread across business, basis, development, QA, validation and release management.
When you map a process like this, most of the hands-on work is small: fill a form, read a log, check a dependency, attach evidence. Most of the elapsed time is waiting. A request sits in a queue until someone picks it up, discovers it's incomplete, and sends it back.
This matters because it tells you what not to automate. The approvals exist for good reasons: regulators, auditors and your own quality system rely on them. The goal isn't to remove human gates. It's to make sure every person at a gate receives a complete, pre-checked package the moment it's their turn.
You could build this as a classic workflow with a BPM tool or scripts. Many teams have. The trouble is that the hard parts of this process aren't the routing:
Those are reasoning tasks. The actions around them, such as creating the change record, reading transport objects and triggering an import, are deterministic and should stay that way.
That split gives us the core design principle for the whole series:
Agents reason. Integration tools act. Humans approve.
An agent is only as useful as the systems it can reach safely. In this use case the agent needs SAP (through RFCs), an ITSM tool for change records, a test-management tool and document storage. It must never touch production without an approval on record.
That's an integration and governance problem, which is where MuleSoft's recent agent tooling fits:
We'll go through each of these in later parts, always from the angle of what the use case needs rather than as a feature tour.
One decision shaped this MVP early: the agent layer and the integration layer are owned by different teams.
Every architecture diagram in this series is colour-coded that way. Agentic systems cross team boundaries more than most, and making ownership visible early avoids long arguments later.
In Part 2 I'll put the whole reference architecture on one page, covering Agent Fabric, Omni Gateway, MCP tools and the SAP and ITSM back ends, and show where each team's work starts and stops.
If you're working on something similar, I'd like to hear which step you'd automate first. Leave a comment. This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of September 2026; check current docs before you build.