没人愿意负责的 21 步变更：为何 SAP 变更晋升是 Agent 用例

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. The process: 21 steps, 11 stages, many owners A typical change promotion in a validated SAP landscape looks roughly like this: Request intake: someone raises a change request, often with missing information. Change setup: a change document is opened and transports are linked. Documentation: change and test documentation is written. Business validation: a business owner approves the change. Transport management: transport contents and dependencies are checked. Change execution: transports are imported into QA. Technical validation: import logs and return codes are reviewed. QA validation: QA signs off. OQ testing: operational qualification evidence is collected and reviewed. Production readiness: checklists, risk and rollback are confirmed. CAB and release: the change advisory board approves, and the change goes to production. Break those stages into individual tasks and you get about 21 steps, spread across business, basis, development, QA, validation and release management. Where the time actually goes 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. Why this is an agentic problem, not just a workflow problem 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: Judgement on unstructured input. Is this change request complete? Does the description match the transport contents? A rules engine struggles with this. An LLM with the right context handles it well. Reading and summarising technical output. Import logs, return codes and dependency lists need to be interpreted and explained to a non-technical approver. Drafting documentation. Change and test documents follow templates but still need writing. Assembling evidence. Validation reviewers need proof that tests ran and passed, collected from several systems. 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. Why MuleSoft 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: MCP Connector. It exposes Mule flows as Model Context Protocol tools. Existing system APIs for SAP and the ITSM tool become tools an agent can call, with the connectivity, error handling and credentials already in Mule. Omni Gateway (formerly Flex Gateway). It sits in front of APIs, LLM traffic, MCP servers and A2A agents, and applies policies such as MCP tool allow-lists, attribute-based access control, PII detection and token-based rate limits. Agent Fabric. It adds a registry for discovering agents and tools, a broker for orchestrating them, governance through the gateway, and a visualizer for seeing how agents interact. The Agent Network 2.0 release brought "guided determinism", which keeps the LLM for reasoning and moves control flow into a defined graph. That's exactly what a regulated process needs. MuleSoft Vibes. It covers the developer side: skills, rules and workflows that let a team scaffold these APIs and tools consistently. 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. Who builds what One decision shaped this MVP early: the agent layer and the integration layer are owned by different teams. The agent team owns agent logic, prompts and evaluation. The integration team owns the MCP tools, the Mule APIs behind them, and connectivity to SAP and the ITSM tool. The platform team owns the gateway, policies, environments and deployment. 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. What's next 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.