RU
Get in touch
Chapter 30

Assemble MCP Inside A2A and Ship the System

Now it all comes together into one picture. Our example's production architecture uses A2A at the boundary of the independent Review Agent and MCP inside its runtime, for runbooks, CI evidence, and release checks. From outside the coordinator sees the agent; inside the agent sees the capabilities. And each layer keeps its own identifiers, authorization, and failure semantics.

The A2A boundary runs between the Release Coordinator and the Review Agent: Agent Card, SendMessage, Task states, input_required, Artifact. The Review Agent team is free to change the internal implementation as long as it keeps the contract. And inside runs the MCP boundary: the Review Host reads the runbook resource, reads the release snapshot, calls the deterministic review tool - and each server has least privilege. The full production request path passes through both boundaries in turn.

  1. A2A submitted
  2. working
  3. MCP discovery
  4. MCP calls
  5. Validate
  6. Artifact
  7. completed
A2A request
  authenticate coordinator
  create durable Task
  publish submitted/working
  run bounded agent workflow
    MCP discover allowed servers
    read runbook://release-policy
    read release://service/version
    call review_release
  validate + redact artifact
  publish completed
  persist audit + metrics

For such a system to be debuggable, it's critical not to mix the identifiers of the different layers - each has its own purpose.

Field · Purpose · Don't mix with

  • trace id - End-to-end observability; Authorization proof
  • A2A taskId - The delegation lifecycle; MCP request id
  • A2A contextId - A group of related conversations; HTTP session
  • MCP JSON-RPC id - Correlation of one call; A domain job id
  • idempotency key - Protects a side effect; Trace id
  • actor/tenant - Security context; Model-provided metadata

Assembling the final release gate in full - with thresholds for success rate, cost, and latency - can be done in the lab.

Interactive lab 6

Production release gate

0 of 9 checked. Open conditions remain before release.

And this isn't theory: the companion project actually passes its check, and the result is fixed.

Check · Result as of 2026-08-01

  • TypeScript - Strict compile, skipLibCheck: false, no any in source/tests
  • Tests - 14 passed, 0 failed
  • MCP E2E - Modern era, 2 tools, 3 listed resources, 1 prompt, decision ready
  • A2A E2E - Agent Card resolved; a completed Task with a Markdown/JSON artifact and an input-required Task
  • Network/model - Not required; reasoning is deliberately deterministic

The main criterion by which such an architecture's maturity is judged is the independence of the boundaries.

A ready criterion for the architecture. Removing the A2A layer must not change the MCP capability schemas. Replacing an MCP server must not change the public semantics of an A2A skill. If both hold - the boundaries are truly independent, and the system can be evolved part by part.

And the last thing - the discipline without which a book on living protocols turns into a pumpkin.

Recheck versions before deploy. MCP and A2A evolve actively. Keep the protocol conformance tests and read the official changelog on every SDK upgrade, even if the TypeScript compile stays green. A green compile doesn't mean a compatible protocol.

With this the system is assembled in full - from choosing the contract to the release. All the book's technical claims are verified against primary sources; their full list is in the next chapter.

Links