Level 13 — Interoperability, MCP/A2A, and Multi-Agent Systems

From one harness to many systems

Level 12 built a durable harness around one agent. It queued work, recovered after failure, enforced permissions, isolated execution, traced decisions, and tested the run. Level 13 asks what happens when that harness talks to tools or agents built somewhere else.

Picture three school clubs building three different robots. One robot expects a command like {"action":"open"}, another expects {"command":"open"}, and a third expects the number 7 to mean "open." Every pair can still be connected, but somebody has to write a special translator for each connection. As more robots and tools appear, the pile of one-off translators becomes hard to maintain.

A shared communication rule changes that picture. The systems can agree on how to name requests, where to put data, how to report errors, and how to say which version of the rules they understand. They still remain separate programs, but they no longer need a private language for every pair.

That shared language does not mean every participant is safe to trust. A school ID card can prove which student you are without giving you permission to enter every locked room. In the same way, a program can speak the correct protocol and still ask for an action that local policy must reject.

Interoperability means independently built systems can use the same documented communication rules. Those rules are a protocol. A protocol can define messages, fields, operations, versions, and errors. It gives both sides a common language, but it does not make either side trusted.

Two protocol boundaries

This level uses two pinned protocol versions. For tool and context integration, the course uses the Model Context Protocol release dated 2026-07-28. Its core requests are stateless: each request carries the protocol and client information needed at that boundary. A client may use server/discover to ask what the server supports.

For agent-to-agent work, the course uses Agent2Agent Protocol v1.0.0. A2A uses Agent Cards for discovery and defines visible objects such as messages, tasks, task status, and artifacts.

At the 2026-09-29 review, the official A2A documentation still labels v1.0.0 as the latest released specification. The project repository also has a v1.0.1 patch release with specification bug fixes. Course conformance examples stay pinned to v1.0.0; patch notes are extra compatibility evidence.

Versions matter because protocols change. An old blog post or SDK example may use fields or connection rules that no longer match this course.

Keep two kinds of knowledge separate. Stable engineering ideas include input validation, narrow authority, compatibility checks, task identity, and treating remote output as untrusted data. Version-sensitive details include exact operation names, headers, fields, capability declarations, and supported bindings.

Protocols exist to reduce custom pair-by-pair adapters. Without a shared protocol, every client may need to learn every server's private request shape. A documented boundary gives you one reusable place to discover capabilities, validate requests, handle errors, trace operations, and plan upgrades.

Learning path

The first half focuses on MCP. You will separate tools, which are callable actions, from resources, which are data you can read. You will study client/server roles, discovery, versions, validation, and trust. The Labs use fixed protocol-shaped fixtures so you can test the boundary before adding network or SDK complexity.

After the checkpoint, you will shift to A2A. A remote agent is more than a tool with a long prompt. It can manage its own task, report status, and return artifacts. A2A gives the two systems visible objects for that collaboration without exposing private memory or internal tools.

The final Lessons treat multi-agent work as a distributed system: several independent processes can update state at different times. They can race, retry the same task, or report conflicting evidence. Safe coordination therefore needs ownership, version checks, conflict rules, budgets, and system-level evaluation. More agents do not automatically mean better results.

Level Project

The Level Project, Interoperable Agent System, integrates a version-aware MCP boundary and a version-aware A2A boundary around the durable harness from Level 12. The project uses recorded fixtures so you can prove version checks, trust boundaries, task identity, conflict handling, and release metrics without depending on public servers or live model providers.

What mastery looks like

By the end of Level 13, you should be able to explain which protocol boundary you are using, which version you expect, what the remote party is allowed to do, how its data is validated, how tasks are coordinated, and what evidence would show that the whole system behaved correctly.

A useful way to read this level is to keep asking the same four questions at every boundary: What was discovered? What is actually allowed? What must be validated? What evidence will prove the result? Repeating those questions makes MCP, A2A, and multi-agent coordination easier to compare. The protocol objects change, but the engineering habit stays the same: make authority and evidence explicit before adding more automation.

Key Takeaways

• Protocols create shared communication boundaries; they do not create trust by themselves.
• MCP material in this course is pinned to the 2026-07-28 release.
• A2A material is pinned to v1.0.0.
• Remote capabilities, messages, tasks, and artifacts remain untrusted inputs until validated.
• Multi-agent coordination needs distributed-system controls such as ownership, versioning, conflict handling, and system-level evaluation.

Next Lesson

Start with L13.1 — Why Interoperability Matters.