Part 10 of 10 · Building an Agentic Change-Approval MVP on MuleSoft
This is the last part. Over nine posts we took one painful process, promoting an SAP change from development to production, and built an agentic MVP for it on MuleSoft: from the 21-step process and the 2x2 that decides what to automate, through the architecture, the agent network, MCP tools, gateway policies, Vibes, testing, CI/CD and production support.
This part pulls it together: what worked, what we'd change, and a blueprint you can reuse for your own process.
Five things that worked
1. Starting with the process, not the agents. We mapped all 21 steps before writing a single prompt, and sorted each one into rules, agent or person. Most steps didn't need an agent at all. That map is still the most useful artifact in the project.
2. Enforcing human gates in code. Every approval is checked by a Process API before anything touches SAP, as in the human-in-the-loop post. The agent can't skip a gate, however it's prompted, because the gate isn't in the prompt.
3. Exposing Process APIs as tools, never System APIs. The business rules the integration team had already built became the safety layer for the agents. We reused far more than we wrote.
4. Letting deterministic checks decide. The AI proposes a package, a risk class, a transport order. Schemas, Process APIs, gateway policies and people decide whether it goes ahead. The same rule applied to the AI developer: Vibes proposes code, hooks and CI decide.
5. Testing exactly wherever we could. Only the LLM steps get scored. Everything else gets an exact test, which kept the test suite ordinary, fast and trusted.
Five things we'd do differently
1. Write tool descriptions and named errors first. Most of the agent problems we debugged, including loops, came from tools that didn't say when to use them or what to do after an error. Next time we'd write those before any agent prompt.
2. Build the golden set before the first agent. We built it after the first version worked. Having it from day one would have made every early prompt change measurable instead of a judgement call.
3. Set token budgets from the start. We added the LLM rate-limit policy after a prompt change multiplied token use. A budget per agent from day one is cheap and catches that immediately.
4. Keep agents smaller. One of our first agents had too many tools and made poor choices between them. Splitting it into two agents with a few tools each fixed more than any prompt rewrite.
5. Plan support before go-live. The correlation ID, the dashboard, the runbooks and the pause switch from Part 9 all came late. They should be part of the first release, not the first incident.
The blueprint
If you want to apply this to your own process, this is the order we'd follow:
- Map the process. List every step and sort each one: rules, agent or person.
- Find the gates. Enforce every approval in a Process API, not in a prompt.
- Expose tools. MCP tools over Process APIs, with descriptions written for an agent and named errors.
- Design the network. Small agents with few tools each, and a broker graph with loop limits and escalation to a person.
- Govern traffic. Tool allow-lists, PII detection and token budgets in Omni Gateway.
- Build with standards. Skills, rules and workflows for the AI developer in Vibes; hooks and CI to check the result.
- Test, ship and run. Exact tests plus a golden set, one versioned release for Mule apps and the agent network, and a runbook for each failure mode.
Steps 1 and 2 are the ones teams want to skip, and they're the ones that make the rest safe.
Where else it fits
Nothing in the blueprint is specific to SAP. The same shape works for any multi-step process where people approve and systems execute: access requests, vendor onboarding, configuration promotion in Salesforce or Workday, or release management in general. If your process has a checklist, a few approvers and a system of record at the end, it's a candidate.
Thank you
Thanks for reading along, and to everyone who commented and asked questions. All ten parts stay together in the series.
What process in your organisation would you put through this blueprint first? And what should the next series cover?
This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.
Top comments (0)