Part 26: Five builds, five differences

Part 26 · One Agent, Five Platforms

Five builds are done: MuleSoft, Boomi, SAP, Azure and AWS. Each one hosted the same nine tools from Part 7 and kept the same approval rule from Part 6. This part puts them on one screen: what actually differed, in five rows.

It's a summary of Parts 11 to 25, all documentation-only. On 15 November 2026 I spot-checked two of the facts most likely to move, the MuleSoft MCP Connector version and Boomi's runtime regions, and neither had changed. There's no winner here. That needs hands-on builds.

1. Where the tools live

• MuleSoft (Part 11): one Tool Listener per tool in a Mule flow, through the MCP Connector.
• Boomi (Part 14): an API Product exposed as an MCP server in API Control Plane, one tool per endpoint.
• SAP (Part 17): MCP Gateway in Integration Suite, the path SAP's API Policy endorses for agents.
• Azure (Part 21): three hosts (Logic Apps, Functions, API Management) behind one API Management front door.
• AWS (Part 24): one AgentCore Gateway that merges every target into a single MCP server.

The difference: how many MCP servers the agent sees, and who owns the door in front of them. On SAP, it's the ERP vendor. On the others, it's your integration or cloud team.

2. How the agent is built

• MuleSoft: an agent broker in an Agent Fabric network, written in Agent Script and reached over A2A.
• Boomi (Part 15): low-code in Agent Designer, using Structured mode for JSON in and JSON out.
• SAP (Part 18): Joule Studio, low-code or pro-code, on SAP's managed runtime.
• Azure (Part 22): a prompt agent in Foundry Agent Service.
• AWS (Part 25): any framework in AgentCore Runtime, one microVM per session.

The difference: low-code versus code, and whose runtime it runs on. The build experience itself is the one criterion I couldn't score anywhere from documentation.

3. Where the guardrails sit

• MuleSoft: Omni Gateway policies on agent, MCP and LLM traffic: tool allow and block lists, PII detection, token limits.
• Boomi: guardrails inside the agent, plus AI Gateway for model and tool traffic.
• SAP: content filtering and data masking in the generative AI hub, plus the API Policy on how agents get in.
• Azure: API Management as the AI gateway, per-agent tool allow-lists, and Foundry content filters.
• AWS: Policy, with Cedar rules checked on every tool call at the gateway.

The difference: in the agent, in a gateway, or in the vendor's rules of access. The strongest designs put the hard rules outside the agent's code.

4. Where the approval lives

• MuleSoft: no built-in approval step for agent networks. The gate is a Mule flow.
• Boomi: Requires Approval on a tool asks before a call. The finance gate is still the process API.
• SAP: the ERP's own flexible workflow, with approvers in My Inbox.
• Azure: a Logic Apps workflow posts a Teams card and waits. It has to run asynchronously, because tool calls time out after 100 seconds.
• AWS: Step Functions waits on a task token. The approval page and the approver's identity are yours to build.

The difference: SAP is the only platform where the approval lives in the system that posts the invoice. Everywhere else, the approval is assembled from parts.

5. What you can see

• MuleSoft: OpenTelemetry traces across agents, brokers and MCP servers, with export.
• Boomi: session traces with tool calls, tokens and latency. No export documented.
• SAP: gateway logs, traces and analytics, on a runtime SAP monitors.
• Azure: generally available OpenTelemetry tracing in Application Insights.
• AWS: OpenTelemetry plus CloudWatch dashboards. CloudTrail covers only some components so far.

The difference: whether traces leave the platform. That decides whether one operations team can watch agents from several vendors.

What didn't differ

Some things stayed the same on all five, and they matter more than the differences:

• The contract. The same nine tools, the same schemas and the same named errors from Part 8. Azure and AWS both advise flat schemas, and AWS prefixes tool names. None of them forced a change to the contract itself.
• Rules first. The three-way match and duplicate check run before the agent, as Part 2 said.
• The gate. On every platform, post_invoice_adjustment checks the approval_id in the process API, as Part 19 argued. No platform's built-in approval replaced that check.
• The open question. On all five, the documentation didn't say how a failed tool call reaches the agent, or whether isError is set.

Why there's no winner yet

The provisional averages are MuleSoft 3.3, Boomi 2.8, SAP 3.0, Azure 3.6 and AWS 3.6. But they're documentation scores, capped at 4, with a different number of criteria scored for SAP. Part of the gap is simply how much each vendor documents.

The differences above are more useful than the averages. They tell you which platform fits your constraints: where your approvers work, who owns your gateway, and whether your operations team needs one place to see every agent.

Part 27 asks the bigger question: where should the agent runtime live?

Which difference surprised you?

---

This series describes a reference build on a fictional company. This part summarises Parts 11 to 25, which were based only on vendor documentation; no hands-on build has been run yet. Views are my own. Check current docs before you build.