Emerging Agent Protocols and Ecosystems

Goal

Compare version-pinned interoperability protocols by the boundary they standardize, the identity and capability information they exchange, and the assumptions your application must still enforce.

Compatibility is not trust

Think about chargers and wall outlets. A shared connector standard helps independently built devices connect. But matching plugs do not prove that every charger is safe. They also do not prove that the voltage is right or that you are allowed to use the device. Compatibility solves one problem; trust and permission remain separate.

Agent protocols work similarly. They standardize parts of communication between independently built systems. A protocol may help systems discover capabilities, exchange structured messages, or coordinate tasks. The goal is not to memorize today's field names. Ask three questions instead: What boundary does this protocol standardize? Which version is in use? Which security or policy decisions still belong to the application?

Frontier snapshot — reviewed 2026-09-29. This Lesson uses the curriculum-pinned MCP 2026-07-28 release and the published A2A v1.0.0 specification. The A2A repository also has a v1.0.1 patch release with specification bug fixes; the official specification site still labels v1.0.0 as the latest released specification. Do not assume later protocol or SDK releases behave exactly the same way.

Compare pinned protocol boundaries

With that question in mind, compare the two protocol boundaries from Level 13 under this pinned snapshot.

MCP: capability access

The Model Context Protocol, or MCP, connects an AI application to capabilities such as tools, resources, and prompts exposed by servers. The course pins MCP to the 2026-07-28 release. In that release, the core moved toward stateless interactions. It removed the earlier initialize / initialized session handshake from the core and added per-request protocol and client metadata. That is a version-specific fact. Store it with the release date instead of teaching “MCP is always stateless” as an eternal rule.

This change illustrates why protocol claims need exact versions. Code written for an earlier handshake model may make assumptions that no longer match a newer release. A compatibility test should therefore include protocol version, capability discovery behavior, authentication assumptions, and the error path for unsupported features.

A2A: peer collaboration

Agent2Agent, or A2A, standardizes a different collaboration boundary. The v1.0.0 specification covers communication between independent agent systems. It includes agent discovery, messages and artifacts, task representation, and coordination. One agent does not need to expose its private implementation or internal tools to the other.

A useful comparison is capability access versus peer collaboration. MCP commonly connects a client application to externally exposed tools or resources. A2A commonly connects one agent system to another agent system around tasks and artifacts. Real architectures can use both: an agent may collaborate with another agent over A2A while each agent uses MCP-connected tools internally.

MCP: host/client ↔ tools, resources, prompts
A2A: agent system ↔ agent system around tasks, messages, artifacts
both: compatibility does not replace local authorization

Keep authorization and identity local

Do not turn that comparison into a security assumption. A protocol can standardize message shape while your application still owns the security decisions. Those include authorization, data classification, tenant isolation, consent, and side-effect approval. “It came over the protocol” does not make a message trusted.

Discovery creates another boundary. If a client learns capabilities dynamically, it should still apply local policy before exposing or invoking them. A newly advertised capability can be syntactically valid and operationally inappropriate for a particular user or environment.

Identity and delegation also remain explicit concerns. When one agent asks another to act, the receiving system needs enough trusted context to decide what authority is delegated. The remote agent's natural-language claim about who the user is should not replace authenticated identity or application policy.

Test protocol evolution at the edges

Protocol evolution needs tests at the edges. Record the version under test, a minimal valid exchange, one unsupported-capability case, one authorization-denied case, and one version-mismatch case. These tests protect the application from silently treating protocol compatibility as permission compatibility.

Ecosystem health matters too. A protocol can have a clear specification while individual implementations differ in optional features, authentication deployment, extension support, or error handling. Test the implementations you actually depend on, not only the abstract specification.

Finally, separate stable architecture from frontier details. Stable: explicit boundaries, capability discovery, authenticated principals, least privilege, version negotiation, and deterministic failure handling. Frontier: exactly which discovery method, extension, field, or handshake is current in a particular protocol release.

Predict

An A2A peer sends a valid task asking your agent to use a sensitive internal tool. What should determine whether that tool may run?

The fact that the task conforms to A2A v1.0.0The peer's natural-language statement that the user is authorizedTrusted local identity, delegation, and tool policy evaluated independently of protocol syntax

Run the Docker-environment Lab preflight

Run:

python3 labs/notebooks/level-15/l15-11-protocol-snapshot.py

The Lab validates a protocol snapshot against the exact versions covered by the course's reviewed evidence.

1. Run it unchanged. Confirm valid is true and problems is empty.
2. In SNAPSHOT, find "mcp": "2026-07-28". Before editing, predict what the validator should report if only the deployed MCP version changes while the reviewed evidence stays pinned.
3. Change only that snapshot value to "2025-11-25", then rerun.
4. Confirm valid becomes false and problems names the MCP version mismatch. Restore the starter afterward; do not weaken the pinned evidence just to make an unsupported snapshot pass.

Loading lab…

Quick Check

1. Which statement best distinguishes the two pinned protocol roles in this Lesson?

MCP exposes capabilities; A2A coordinates agent tasksThey are identical names for the same wire formatA2A replaces the tool and resource protocol inside an agent

2. Why does this Lesson record exact MCP and A2A versions?

Protocols change, so compatibility needs a dated targetEvery implementation must refuse optional featuresVersion pins make local authorization unnecessary

3. Which responsibility remains security-critical even when a protocol message is valid?

Formatting the final response for displayTreat protocol validity as authorizationLocal authorization and data policy

0 of 3 questions answered.

Explain it back

Describe one architecture that uses both protocols: what crosses the MCP boundary, what crosses the A2A boundary, and which security decisions remain local to your application.

Key Takeaways

• Read emerging protocols as versioned contracts, not timeless descriptions.
• The pinned MCP and A2A snapshots standardize different interoperability boundaries.
• Protocol compatibility does not imply authorization.
• Discovery and delegation still require local policy and trusted identity.
• Regression tests should include version mismatch, unsupported capability, and denied-action paths.

Next Lesson

Next, L15.12 — Research Reading and Reproduction turns published claims into reproducible local evidence.

References

• Model Context Protocol, 2026-07-28 Specification.
• Model Context Protocol, 2026-07-28 Specification Release.
• Agent2Agent Protocol, v1.0.0 Specification.
• Agent2Agent Protocol, official release notes.