Part 3: A platform-neutral reference architecture for enterprise agents

Part 3 · One Agent, Five Platforms

Before choosing a vendor, draw the architecture. When I did that for the invoice-exception agent, most of the picture turned out to be the same on every platform. The vendor choice changes how each box is built, not which boxes exist.

This part is that picture. Every build in this series, from MuleSoft in Part 11 to AWS in Part 25, will be drawn on top of it.

Five layers

Read it from the top, the way a request flows.

1. Channel. Where work arrives and where people respond: the AP exception queue, email, Teams or Slack, and the approver's inbox. This layer is entirely vendor-specific and usually already exists. The agent should fit into it, not replace it.

2. Agents. The invoice-exception agent, and later a supplier-communication agent. This is where the LLM reasons, plans and calls tools. Each platform has its own runtime here: Agent Fabric, Agentstudio, Joule, Foundry Agent Service, AgentCore. When one agent needs another, especially on a different platform, the open standard is A2A, now at a stable 1.0.

3. Tools. The nine tools from Part 1, defined once with the same inputs, outputs and named errors. The open standard here is MCP. Every platform in this series can host or consume MCP tools in some form, which is what makes a fair comparison possible.

4. Process APIs. The business rules: tolerances, duplicate checks, posting rules and, most importantly, the approval check. post_invoice_adjustment rejects any call without a valid approval_id. This layer is your code, on whatever integration platform you already use.

5. Systems of record. The ERP with its invoices, POs and goods receipts, the supplier master, and the workflow engine. These exist today, and they should stay boring.

Four concerns that cut across every layer

• Gateway. Tool allow-lists per agent, PII detection before data reaches a model, and token limits. In series 1 this was Omni Gateway; every platform has an equivalent.
• Identity. Each agent gets its own identity with least privilege per tool, rather than borrowing a user's or a shared service account.
• Observability. One trace across all five layers, so you can follow a single invoice from queue to ERP. OpenTelemetry is the obvious standard, with one caveat below.
• Human approval. The request for approval goes through the workflow; the enforcement happens in layer 4. Those are two different things, and mixing them up is the most common mistake I see.

Where the approval check lives

This deserves its own section, because it's the one design decision that makes the rest safe.

The approval check lives in the process layer, not in the prompt and not in the agent runtime. The agent can call request_approval, which creates a task for a person. When the person approves, the workflow returns an approval_id. Only then will post_invoice_adjustment or notify_supplier succeed.

If the agent is misled by a strange invoice, skips a step or is simply wrong, the post fails with APPROVAL_MISSING. No prompt can change that, because the check isn't in the prompt. That was the core lesson of series 1's human-in-the-loop post, and it carries over unchanged to all five platforms.

It also means you can change the agent, the model or even the platform without re-validating the control. The control didn't move.

What is standard and what is not

Here's how I'd split it today:

Open standards:

• MCP for agent-to-tool. The latest specification revision is 2026-07-28.
• A2A 1.0 for agent-to-agent, governed by the Linux Foundation, with agent cards that describe what an agent can do.
• OpenTelemetry for traces, with a caveat: the GenAI semantic conventions, which define spans such as invoke_agent and execute_tool, are still at Development status, so attribute names can change between releases. Use them, but don't build dashboards you can't update.

Vendor-specific:

• The agent runtime and studio where you build and prompt the agent.
• The agent and tool registry.
• Gateway policies and their configuration.
• Identity integration (Entra, IAM, platform-native identities).
• Evaluation tooling and dashboards.

The practical consequence: invest in the standard layers as reusable assets (tool contracts, agent cards, trace conventions) and treat the vendor layers as replaceable. Part 4 goes deeper into the protocol stack.

Why draw this before picking a vendor

Three reasons.

It keeps the comparison honest. If every build has to fill the same boxes, it's easy to see where a platform covers a box natively, where it needs extra work and where it can't help at all.

It shows what you already own. Layers 4 and 5, and most of the channel, already exist in most enterprises. The agent platform decision is mainly about layers 2 and 3 and the cross-cutting concerns.

It limits lock-in. If the tool contract is MCP, the agent card is A2A and the approval check is in your process API, moving the agent between platforms is work, but not a rewrite.

In series 1 I drew a similar picture for a single MuleSoft build. The difference here is that each box now has to work on five platforms.

How the rest of the series maps onto it

• Layers 2–3 standards: Part 4 (the protocol stack), Parts 7–9 (tool contract, named errors, read-only tools first), Parts 28–29 (A2A and agent cards).
• Layer 4 and the gate: Part 6 (where the agent stops and asks), Part 19 (keep the system of record boring).
• The five builds: Parts 11–25, each drawn on this diagram with its own components.
• Cross-cutting: Parts 30–31 (identity and governance), Part 32 (data residency), Parts 37–39 (observability, failure modes, kill switches).

If a later part doesn't fit somewhere on this picture, it probably doesn't belong in the series.

What is missing from this picture in your landscape?

---

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.