Part 2 of 10 · Building an Agentic Change-Approval MVP on MuleSoft
In Part 1 I set out the use case: automating the approval and promotion of SAP changes in a regulated company, with agents doing the reasoning, integration tools doing the actions and people doing the approving. The two follow-ups covered which steps should be agents at all and how to enforce approval gates.
This part puts the whole thing on one page.
The layers, top to bottom
People. A requester raises the change. Approvers (business, QA, validation and the change advisory board) make the decisions. They work in the tools they already use; the agents come to them, not the other way round.
Agent network (Agent Fabric). Four agents, each with a narrow job:
- Intake agent: checks the request is complete and enriches it.
- Planner agent: works out transport dependencies and sequence.
- Change agent: drafts documentation, collects test evidence and reads import logs.
- Approval agent: builds the approval package and requests each gate.
A broker coordinates them. With Agent Network 2.0, the broker's flow is a defined graph: the LLM reasons inside each step, but the order of steps and the gates between them are deterministic. In a regulated process, that's the difference between "the model decided to skip QA" and "it can't".
Governance (Omni Gateway). Omni Gateway, formerly Flex Gateway, sits in front of everything agents touch: MCP servers, other agents over A2A, and the LLM provider. Policies here decide which tools an agent may see, check the caller's claims, detect PII, limit token usage and log every call.
MCP tools. One MCP server, built in Mule with the MCP Connector, exposes a small set of business-level tools: create_change, read_transport, request_approval, import_to_prod. Agents see tools, not APIs.
Process API. change-process-api orchestrates the multi-step work behind each tool, verifies approvals before anything irreversible happens, and writes the audit record.
System APIs. One per back end: SAP (through RFCs), the ITSM tool and test management. They hide connection details and normalise errors.
Systems of record. SAP, the ITSM tool, test management and the LLM provider. None of them is called directly by an agent.
Platform. Agent Registry and Exchange for discovering agents and tools, Agent Visualizer for seeing how agents interact, and CloudHub 2.0 or Runtime Fabric for deployment.
Three design decisions worth explaining
1. Tools are business actions, not API endpoints
It's tempting to expose every System API operation as an MCP tool. Don't. An LLM choosing between 40 low-level operations makes more mistakes and burns more tokens than one choosing between five clear business actions. The MCP tool layer is where we decide what an agent is allowed to want.
2. A Process API between tools and systems
The MCP server could call System APIs directly. We put a Process API in between because that's where cross-system rules live: "an import needs a valid approval for this exact change" spans ITSM and SAP. Keeping that logic in one place means it's tested once and enforced for every caller, agent or human.
3. The gateway covers outbound LLM traffic too
Most teams think of a gateway as inbound protection. Here it also governs what leaves: prompts going to the LLM provider pass through the same policies for PII and token limits. If a change record contains something sensitive, it's caught before it reaches a model.
Who owns what
The colours in the diagram are the team boundaries:
- Agent team (purple): agents, prompts, the broker graph and evaluation.
- Integration team (teal): the MCP server, Process API and System APIs.
- Platform team (dark grey): Omni Gateway policies, registry, observability and environments.
Each team can ship independently as long as the contracts between layers (tool definitions and API specs) stay stable. Those contracts are published in Exchange, which makes them the shared source of truth.
Starting small
The full process has 21 steps. The MVP starts with the first three stages: request intake, change setup and creating the change in SAP, with stubbed back ends so the whole chain can be tested end to end before touching real systems. Later parts show how the remaining stages slot into the same layers without changing the shape of the architecture.
Next
Part 3 goes one level down into design: how we decided where each of the 21 steps lives, and what the broker's graph actually looks like.
Which layer would you push back on? I'd especially like to hear from anyone who exposes System APIs directly as MCP tools.
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)