Part 3: Designing the agent network, and what the broker's graph actually looks like

Part 3 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 2 put the architecture on one page: agents in Agent Fabric, Omni Gateway in front of everything they touch, and MCP tools over Mule APIs. This part goes one level down. How do you decide where each of the 21 steps lives, and what does the broker's graph actually look like?

Step 1: sort every step before drawing anything

We started with a spreadsheet, not a diagram. One row per step, and four questions per row:

1. Does it follow rules or need judgement? (See the 2x2.)
2. How bad is a mistake, and can we undo it?
3. Which system of record does it read or change?
4. Who has to sign off, if anyone?

The answers put each step in one of four places: an agent (judgement, low risk), an MCP tool (rules), a human gate (judgement, high risk), or a tool behind a gate (rules, high risk).

Once every step is sorted, the agents almost name themselves. Steps that need the same kind of judgement and the same context belong together. In our process that gave four agents:

• Intake agent: completeness and risk classification.
• Planner agent: transports, dependencies and sequence.
• Change agent: documentation, evidence and log analysis.
• Approval agent: building packages and requesting gates.

Each agent gets a short list of tools, and no agent gets a tool it doesn't need. The Intake agent can't import anything into SAP, because it never sees that tool.

Step 2: draw the broker's graph

With Agent Network 2.0 in Agent Fabric, the broker coordinates agents using a defined graph ("guided determinism"). The LLM still reasons inside each step, but the order of steps, the branches and the gates are part of the graph, not left to the model.

Here's the graph for the MVP scope, the first three stages of the process:

Reading it top to bottom:

1. A change request arrives.
2. The Intake agent checks completeness and classifies risk.
3. A rule-based branch decides what happens next. If the request is incomplete, it goes back to the requester. That loop runs at most twice before a person takes over.
4. The create_change tool opens the change record in the ITSM tool. No LLM is involved.
5. The Planner agent maps transports and dependencies, calling read_transport as it needs to.
6. The Approval agent builds the package for the business owner.
7. The business owner approves or rejects. A rejection closes the request with a reason.
8. Only with a valid approval ID can create_sap_change_doc run.
9. The request hands off to stage 4, which is outside the MVP.

Three rules the graph enforces

Every loop has a limit

An agent that's allowed to retry forever eventually will. Every loop in the graph has a counter and an exit to a human. "Two tries, then a person" is a good default for anything involving a requester.

Validate between steps

Each agent's output is checked against a schema before the graph moves on. If the Intake agent returns a risk level that isn't one of the allowed values, the step fails loudly instead of passing nonsense to the Planner. This is cheap to build and catches a lot of quiet errors.

Gates are edges, not instructions

The approval isn't a line in a prompt asking the agent to wait. It's the only edge from node 7 to node 8, and the tool on node 8 checks the approval ID again in the integration layer. As covered in the human-in-the-loop post, the model can't skip the gate, and the API wouldn't let it even if it tried.

What the graph doesn't do

It doesn't make the agents smarter. A bad prompt in the Planner agent still produces a bad plan. What the graph gives you is a guarantee about structure: whatever the agents decide, the process still runs in the right order, with the right people involved and a record of what happened. In a regulated environment, that structure is what auditors and quality teams care about first.

Who owns what

• Agent team: the four agents, their prompts and output schemas, and the broker graph.
• Integration team: the MCP tools behind nodes 4, 5, 7 and 8, and the approval check.
• Platform team: the gateway policies that decide which agent can see which tool.

Next

Part 4 gets hands-on with the integration side: turning Mule APIs into MCP tools with the MCP Connector, and why tool names and descriptions matter more than you'd expect.

Where would you put the loop limit, and what would you do when it's hit?

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.