Part 1: One agent, five platforms: why I am building the same invoice-exception agent five times

Part 1 · One Agent, Five Platforms

Every integration vendor now sells an agent platform. MuleSoft has Agent Fabric. Boomi has Agentstudio. SAP has Joule Studio. Microsoft has Foundry Agent Service. AWS has Bedrock AgentCore. Each one has a polished demo, a reference architecture and a slide that says "enterprise-ready".

What I have never seen is all five built for the same job, tested the same way, and compared on evidence. So that is what this series does.

I'm going to build one agent, an invoice-exception agent, five times: on MuleSoft, Boomi, SAP, Azure and AWS. Same tools, same test set, same human approval gate, same scorecard. Then I'll tell you what each platform made easy, what it made hard, and which kinds of teams each one suits.

The job: invoices that fail the match

If you've worked near accounts payable, you know this queue. A supplier sends an invoice. The ERP compares it with the purchase order and the goods receipt, the classic three-way match. Most invoices pass and get paid. The ones that fail land in an exception queue, and a person has to work out why.

The reasons are familiar:

• Price variance. The invoice price doesn't match the PO price.
• Quantity variance. More was invoiced than was received.
• Missing goods receipt. The goods may have arrived, but nobody booked the receipt.
• Duplicate invoice. The same invoice, sent twice, sometimes with a new number.
• Closed purchase order. The PO was closed before the invoice arrived.
• Tax mismatch. The tax on the invoice doesn't match what's expected.

Each case means looking up the invoice, the PO, the receipts and the supplier's history, deciding what happened, and proposing a fix: adjust the price, wait for the receipt, reject the duplicate, ask the supplier. Then someone with authority approves it and it gets posted. It's slow, repetitive and important, because mistakes here mean paying the wrong amount.

All examples in this series use a fictional distributor, Arden Medical Supply. Volumes and figures are illustrative.

Why this is a good test for agents

I picked this job because it contains every hard part of enterprise agents in one small process:

1. Rules and judgement mixed together. The match itself is deterministic and should never be done by an LLM. Working out why a match failed, from the supplier's history and the documents, is where an agent can help.
2. Several tools. The agent needs to read from at least four sources before it can propose anything.
3. A human gate. No agent should post a financial adjustment on its own. A person approves every fix.
4. A write to a system of record. The final step changes the ERP, so the platform's controls actually matter.
5. A cost of being wrong. A bad proposal costs money or a supplier relationship. That makes evaluation real, not decorative.

If a platform handles this well, it will handle most approval-style processes. In my first series, Building an Agentic Change-Approval MVP on MuleSoft, the process was SAP change promotion. The shape was the same: rules, an agent that proposes, people who decide, and a system of record at the end.

The ground rules

A comparison is only useful if it's fair. These are the rules every build follows:

• One tool contract. Nine tools, defined once: get_invoice, get_purchase_order, get_goods_receipt, run_three_way_match, get_supplier_history, check_duplicate_invoice, request_approval, post_invoice_adjustment, notify_supplier. Same names, same inputs, same named errors, such as APPROVAL_MISSING and PO_CLOSED, on every platform.
• One golden set. Thirty illustrative invoices covering all six exception types, each with the expected classification and the expected proposal. Every build is scored against the same set.
• One approval gate, enforced in code. The tool that posts to the ERP rejects any call without a valid approval_id. The gate lives in the API, not in the prompt, so no prompt can talk its way past it. That was the most important lesson from series 1, and it applies on every platform.
• Scores only from evidence. Every score links to a build note or an official doc page. No score comes from a press release.
• A fictional company. No client data, no client names.

The five platforms, as of October 2026

Here is what each vendor offers for this job today. I'll verify each in detail when I build on it.

• MuleSoft: Agent Fabric (broker and registry), the MCP Connector for exposing tools, and Omni Gateway policies for agent and LLM traffic. I used all of these hands-on in series 1.
• Boomi: Agentstudio, Boomi's platform to build, govern and orchestrate agents, with MCP support including creating MCP servers, an agent registry and built-in guardrails.
• SAP: Joule Studio in SAP Build, where you create Joule agents and Joule skills, assign tools and configure MCP servers, with SAP as the system of record.
• Azure: Microsoft Foundry Agent Service, with Entra for agent identity and API Management in front of the tools. A2A support for Foundry agents is in public preview.
• AWS: Amazon Bedrock AgentCore: Runtime, Gateway (which turns APIs and Lambda functions into MCP tools), Identity, Memory and Observability. AgentCore Runtime supports A2A.

Two open protocols tie this together. MCP (the Model Context Protocol, latest specification revision 2026-07-28) connects an agent to its tools. A2A (the Agent2Agent protocol, now at a stable 1.0 under the Linux Foundation) connects agents to each other. Part of this series is testing how real that interoperability is when the agents live on different vendors.

How I'll score them

Each build gets a 1–5 score on eleven criteria: tool exposure (MCP), agent build experience, multi-agent and A2A, human-in-the-loop, identity and access, governance and gateway, observability, evaluation support, deployment and CI/CD, cost transparency, and data residency and on-prem options. Part 5 explains each criterion and why every score needs evidence. The final scorecard is not "who won". It's which platform fits which kind of team and job.

The map

The series runs every day, weekends included, from today to 1 December. Every part is a full article here and on Medium, with a short companion post on LinkedIn.

• Week 1: Foundations (Parts 1–6). The job, the reference architecture, the 2026 protocol stack, the scorecard, and where the agent must stop and ask a person.
• Week 2: Design once (Parts 7–13). The shared tool contract, named errors, read-only tools first, the golden set, the MuleSoft build, and setting up five trial environments.
• Weeks 3–4: The builds (Parts 14–27). Boomi, SAP, Azure and AWS, each in two parts with scores, plus side-by-side comparisons.
• Week 5: Across vendors (Parts 28–34). A2A between two platforms, agent cards, identity and governance across five vendors, data residency, versioning and the approval experience.
• Weeks 6–7: Run it and decide (Parts 35–43). Evaluation, token cost per invoice, observability, failure modes, kill switches, total cost of ownership, the final scorecard and a reusable blueprint.

The teaser said Tuesdays and Thursdays. I have moved it to a daily schedule so the builds and the comparisons stay close together.

What I'm not doing

I'm not ranking vendors on features I haven't used. Where something is announced but not yet available to me, I'll say so and leave the score blank. I'm also not claiming any platform is "best". Your existing estate, your team's skills and where your data has to live will matter more than any score I give.

Tomorrow, Part 2 looks at the six exception types in detail: which ones are pure rules, which need judgement, and which should always go to a person.

Which platform do you expect to score highest, and why?

This series describes a reference build on a fictional company. Product capabilities are based on vendor documentation as of October 2026; check current docs before you build.