Part 11: Build 1 — MuleSoft: Agent Fabric, the MCP Connector and Omni Gateway

Part 11 · One Agent, Five Platforms

The foundation is done: the tool contract, the named errors, the approval gate, the rollout stages and the golden set. Now each platform has to carry it. MuleSoft goes first because it's the platform I know best, so the bar it sets should be clear for the other four.

One thing up front. This build is documentation-only. Every statement and every score below comes from MuleSoft's official documentation as I read it on 30 October 2026, linked in the text. I haven't run this invoice agent on MuleSoft yet. Where a criterion can only be judged hands-on, the score stays blank, as Part 5 promised.

How the pieces map

Using the five layers from Part 3:

• Channel: the AP exception queue and approver inbox stay where they are. A Mule flow picks up each exception.
• Agents: an Agent Fabric agent network. Its agent broker, defined in Agent Script, routes work to the invoice-exception agent. The agent network docs say every broker graph starts on an A2A trigger, and agents must be A2A-compliant.
• Tools: the nine tools, exposed as an MCP server with the MCP Connector.
• Process APIs: the business rules and the approval check, as Mule flows.
• Systems of record: the ERP and workflow, reached through existing system APIs.

Across those layers sits Omni Gateway (formerly Flex Gateway), which governs agent, MCP and LLM traffic. Series 1 covered the agent network, MCP tools and gateway policies for a different use case. This part keeps to what's specific to the invoice agent.

1. The tool contract as MCP tools

The MCP Connector reference describes a Tool Listener per tool. Each has a name, an LLM-facing description, a required Parameters Schema (a JSON Schema for the inputs) and an optional Output Schema. The flow behind it runs on every tools/call. Streamable HTTP is the recommended transport; SSE is deprecated.

That lines up with the contract from Part 7: nine Tool Listeners, one per tool, each calling a process API.

Two gaps to check in a hands-on build:

• Named errors. A Tool Listener can return On Error Responses when its flow fails. That's where the JSON error shape from Part 8 goes. The reference I read doesn't say whether the result carries isError: true, which matters for how the agent reads it.
• Protocol version and annotations. The release notes list MCP 2025-06-18 for current versions (1.7.3, released 23 October 2026), not the 2026-07-28 revision. The Tool Listener reference doesn't mention annotations such as readOnlyHint. Neither blocks the design, because the approval check never depended on annotations.

For APIs you don't want to wrap by hand, the Agent Fabric overview also lists MCP Bridge, which turns an existing API into an MCP server without custom code.

2. The agent network

The broker is the invoice-exception agent's front door. Following Part 2, rules run first: the Mule flow calls run_three_way_match and check_duplicate_invoice before the broker is involved, so the six rules-only invoices in the golden set never reach the LLM.

The broker's LLM can be called through Omni Gateway's LLM proxy, so token limits and PII checks apply to model traffic too. The supplier-communication agent arrives in Parts 28–29. Agent Fabric's A2A Connector and A2A Bridge are the documented routes for agents on other platforms.

3. Gateway policies

The Omni Gateway agent policies page lists 32 policies across MCP, A2A and LLM traffic. The ones this design needs:

• MCP Global Access: allow and block rules for which tools are exposed. This is how the stages from Part 9 work as configuration: stage 1 allows only the six read tools.
• MCP Attribute-Based Access Control: access to tools by claims, headers or tier.
• LLM PII Detection and LLM Token Based Rate Limit on model traffic.
• MCP Schema Validation for requests against the MCP spec.

4. The approval gate

The gate lives where Part 6 put it: in the process API. The post_invoice_adjustment and notify_supplier flows check the approval_id against the workflow's approval record, and return APPROVAL_MISSING through the Tool Listener's error response if it's missing, expired, used or doesn't match.

The agent network docs I read describe no built-in approval step, and that's fine. A gate in a Mule flow is ordinary integration work, and it doesn't move if the agent or model changes.

Provisional scores

Documentation-only scores are capped at 4, because Part 5 reserves a 5 for something that worked in the build without workarounds. Blank means I can't score it fairly without a hands-on build.

1. Tool exposure (MCP): 4. Tool Listener with input and output schemas, plus MCP Bridge. Check isError and protocol version in the build.
2. Agent build experience: blank. Effort can only be judged by building.
3. Multi-agent and A2A: 4. Broker over A2A agents, A2A Connector and Bridge, A2A v1 policies.
4. Human-in-the-loop: 3. No native approval step documented for agent networks; the gate is built in a Mule flow.
5. Identity and access: 3. Gateway authentication, ABAC by claims and external vaults are documented. A distinct identity per agent isn't clear from the pages I read.
6. Governance and gateway: 4. Tool allow and block rules, PII detection, token limits, a registry and a kill switch.
7. Observability: 4. Traces are built on OpenTelemetry spans, cover agents, brokers and MCP servers, and can be exported.
8. Evaluation support: 2. An A2A Quality Evaluation policy scores responses with an LLM. Running the golden set needs my own harness, as in series 1.
9. Deployment and CI/CD: 3. The Anypoint CLI plugin builds, publishes and deploys agent networks. No rollback procedure is documented, and moving a network to a different target means deleting and redeploying.
10. Cost transparency: 3. Budget Management tracks token and dollar spend. Cost per invoice isn't a documented view.
11. Data residency and on-prem: 3. Runtime Fabric gives a customer-managed runtime, but agent network deployments are available only on the US and EU cloud hosts.

That's ten scores out of eleven, and the average isn't meaningful yet. These scores will change when I run the build: I'll update this part, note what changed and carry it to the final scorecard.

What this sets for the other four

Three things to compare against: tools defined declaratively with schemas, allow and block rules that make staged rollout pure configuration, and OpenTelemetry tracing across agents and tools. The open questions are the same everywhere: does the platform pass named errors back intact, and how much of the approval gate do you build yourself?

Part 12 looks at what carried over from series 1 to this build, and what didn't.

If you use MuleSoft, which part of this would you change?

---

This series describes a reference build on a fictional company. This part is based only on MuleSoft's official documentation as of 30 October 2026; no hands-on build has been run yet. Views are my own. Check current docs before you build.