Part 4: The 2026 agent protocol stack: MCP, A2A, gateways and identity

Part 4 · One Agent, Five Platforms

In Part 3 I drew the reference architecture: five layers from channel to system of record. This part zooms into the protocols that hold it together. Every platform in this series is converging on the same stack, so it's worth learning it once, before the builds start.

There are six layers to know. Four rest on open standards, one is configured differently on every platform, and one is your own code.

1. Agent to tool: MCP

The Model Context Protocol is how an agent discovers and calls tools. A server lists its tools with a name, a description, an input schema and, optionally, an output schema and annotations such as "read-only". The agent picks a tool, calls it, and gets a result or a named error back.

For the invoice agent, all nine tools from Part 1 are MCP tools: get_invoice, run_three_way_match, request_approval, post_invoice_adjustment and the rest. Define them once and every platform can host or call them.

The current specification revision is 2026-07-28. The changes that matter for enterprise builds:

• A stateless core that runs on ordinary HTTP infrastructure, behind the load balancers and gateways you already have.
• Authorization aligned more closely with OAuth and OpenID Connect, so tool access can use your existing identity provider.
• Tasks, an extension for long-running work, and MCP Apps, an extension for server-rendered UIs.
• A formal deprecation policy, so the protocol can change without breaking existing servers.

2. Agent to agent: A2A

The Agent2Agent protocol is how one agent asks another to do something, including across vendors. Version 1.0 is the first stable release. It's now hosted by the Agentic AI Foundation, under the Linux Foundation, alongside MCP.

Three ideas are enough to start:

• Agent cards. Each agent publishes a card at /.well-known/agent-card.json describing its skills, endpoints and how to authenticate. Cards can carry a JWS signature, which protects their integrity. A signature doesn't make an agent trustworthy; you still decide which signers you accept.
• Tasks with a lifecycle. A request becomes a task that moves through states such as submitted, working, input-required, auth-required, completed, failed, canceled or rejected. That suits work that takes minutes or needs more information.
• Three equivalent bindings. JSON-RPC, gRPC and HTTP+JSON, all functionally equivalent, so the choice is operational.

In this series, the invoice agent will call a supplier-communication agent on a different platform in Parts 28–29. That's where we test how real cross-vendor A2A is.

3. The gateway

Between agents, tools and models sits a gateway. It isn't a single standard, but every platform has one, and the jobs are the same:

• Allow-lists: which agent may call which tool or agent.
• PII detection before data reaches a model.
• Token limits per agent, so one bad prompt can't burn the month's budget.
• Routing, rate limits and audit for MCP, A2A and LLM traffic.

In series 1 this was Omni Gateway. On the other platforms it's an AI gateway, API Management or a managed gateway in front of tools. The policies are portable as ideas, not yet as configuration.

4. Identity: who is the agent?

Every call in this stack should answer one question: which agent is this, acting for whom, with what permissions?

The standards underneath are familiar: OAuth 2 and OpenID Connect, which both MCP authorization and A2A agent cards build on. What differs by vendor is how an agent gets its own identity. Some platforms give agents first-class identities in the directory; others use workload or service identities. Either way, the rules are the same: each agent has its own identity, least privilege per tool, and nothing runs as a shared admin account. Part 23 compares two approaches in detail.

5. The human gate

This layer isn't a protocol. It's your process API, and it's the most important line in the stack.

request_approval creates a task for a person. Approval returns an approval_id. post_invoice_adjustment and notify_supplier reject any call without it, with the named error APPROVAL_MISSING.

Neither MCP nor A2A enforces this for you, and they shouldn't. Protocols move messages; business rules decide what's allowed. Keep the gate in your own code, where it survives any change of model, agent or platform. Part 6 looks at exactly where the invoice agent must stop and ask.

6. Telemetry

To run this stack you need to follow one invoice across agents, tools and models. OpenTelemetry is the standard, and its GenAI semantic conventions define spans such as invoke_agent and execute_tool. Those conventions are still at Development status, so names can change between releases. Use them, and keep your dashboards easy to update.

What is standard and what is not

Standard, and worth investing in once:

• Tool contracts as MCP.
• Agent cards and task handling as A2A.
• OAuth 2 and OpenID Connect for identity.
• OpenTelemetry traces.

Vendor-specific, and worth treating as replaceable:

• The agent runtime and studio.
• Gateway policy configuration.
• How agents get their identities.
• Registries, evaluation tools and dashboards.

Yours, always: the human gate and the business rules in your process APIs.

This split shapes how I'll score the builds. A platform that supports the standard layers well makes everything above it portable. A platform that only works with its own versions of them may be faster to start with, but costs more to leave.

Which layer is weakest in your organisation?

---

This series describes a reference build on a fictional company. Protocol details are based on the MCP 2026-07-28 specification and A2A 1.0 as of October 2026; check current specs before you build.