第 5 部分：評分表——11 項準則，以及每項評分為何都需要證據

Part 5 · One Agent, Five Platforms

Before any build starts, you should know how the five platforms will be judged. Otherwise every score later in the series is just my opinion, written after the fact.

So this part fixes the rules in advance: eleven criteria, one scale, one evidence rule, and a clear list of what I won't score.

The eleven criteria

Each one maps to a layer or concern from the reference architecture and the protocol stack.

1. Tool exposure (MCP). How easily the shared tool contract from Part 1 is hosted and exposed as MCP tools, including schemas and named errors.
2. Agent build experience. The effort and clarity needed to build, prompt and configure the invoice-exception agent.
3. Multi-agent and A2A. Native support for agent-to-agent calls, agent cards and orchestration.
4. Human-in-the-loop. Approval tasks, pausing and resuming, and an audit trail of each decision.
5. Identity and access. Agent identity, least privilege per tool and credential handling.
6. Governance and gateway. Allow-lists, PII detection, token limits and a registry of agents and tools.
7. Observability. Traces, logs and dashboards, and whether one invoice can be followed across steps.
8. Evaluation support. Built-in evaluation, golden sets and judge-based scoring.
9. Deployment and CI/CD. Versioning, promotion between environments and rollback.
10. Cost transparency. How clearly you can see model, token and platform cost per invoice handled.
11. Data residency and on-prem. Regional control, and private or on-premises runtime options.

These are the questions an architect has to answer before taking an agent to production. They're deliberately not about which platform has the most features.

The scale

Every criterion gets a score from 1 to 5, with fixed meanings:

• 5: Native, documented, and it worked in the build without workarounds.
• 4: Well supported, with minor gaps or extra steps.
• 3: Supported, but with notable gaps or manual work.
• 2: Possible only with workarounds or custom code.
• 1: Not supported, or would need a significant custom build.

All criteria start with equal weight. If your organisation cares more about data residency than developer experience, you can change the weights in your own copy and the totals will follow. The weights are a lens, not a verdict.

The evidence rule

No score without evidence. Every score links to at least one of:

• A build note: what I did, what happened and a screenshot, from my own trial environment.
• An official documentation page: the vendor's own docs, dated, for features I couldn't exercise in a trial.

Press releases, keynote demos and roadmap slides don't count. If something is announced but not available to me, the score stays blank and I say why. A blank is more useful than a guess.

Two practical limits apply. First, these are trial environments on a fictional company, so production-scale behaviour such as throughput or support response isn't tested. Second, where a trial's terms limit publishing performance or benchmark results, I'll score from documentation and build experience only, and say so.

What a score looks like

Every score in the build parts will follow the same short format. Here is the shape, with placeholder content rather than a real platform:

Human-in-the-loop: 4/5. request_approval created a task in the platform's workflow with no custom code. Pause and resume worked natively. Exporting the decision audit needed a small script.
Evidence: build note with screenshot; vendor documentation page (dated).

One line of judgement, one line of evidence. If I can't write the evidence line, I don't write the score.

What I won't score

Some things matter, but don't belong in a platform comparison:

• Model quality. All five can call similar models. The model choice affects output far more than the platform, so I'll keep the model as constant as I can and leave it out of the scores.
• List prices and discounts. Pricing is negotiated and changes often. Cost transparency is scored; the price itself isn't. Part 41 covers total cost of ownership with sourced or clearly illustrative figures.
• Roadmaps. Only what is available today.
• Look and feel. Unless it changes how fast you can build or approve, it's out.
• Vendor support quality. A trial can't measure it fairly.

Where the scores appear

Each build ends with its scores and evidence links:

• Part 11: MuleSoft
• Part 15: Boomi
• Part 18: SAP
• Part 22: Azure
• Part 25: AWS

Part 42 then brings all five together as a heatmap and a decision matrix by context: a MuleSoft shop, an SAP-centric landscape, a Microsoft 365 organisation, an AWS-native team, and a regulated or on-prem environment. The goal isn't a winner. It's which platform fits which situation.

How to challenge a score

If you think a score is wrong, comment with a link to the documentation or describe what you saw in your own build. If the evidence holds, I'll update the score, note the change in the article and carry it into the final scorecard. Scores that can't change when the facts change aren't worth much.

One more rule, carried over from series 1: everything is built on a fictional company, Arden Medical Supply. No client data and no client names, in any build.

Which criterion matters most to you?

This series describes a reference build on a fictional company. Scores reflect hands-on trial builds and official documentation as of the date of each part; check current docs before you decide.