Evidence-linked trend hypothesis
Agent protocols become the interoperability layer
MCP, A2A, ACP, extension systems, and agent-facing APIs are turning tool discovery and cross-agent communication into an explicit interoperability layer.
Source ledger
Publishable sources attached to this record.
| # | Source | Role | Public status |
|---|---|---|---|
| 1 | microsoft.comsource | primary receipt | source_urls |
| 2 | anthropic.comsource | supporting receipt | source_urls |
| 3 | blog.mozilla.aiarticle | supporting receipt | source_urls |
| 4 | cloud.google.comsource | supporting receipt | source_urls |
| 5 | anthropic.comsource | supporting receipt | source_urls |
Showing 5 of 7; the complete set is exposed in the JSON route.
What is changing
Agent integrations are moving away from one bespoke connector per model or application. MCP exposes tools and resources. A2A describes communication between agents. ACP connects coding agents to compatible clients. Extension systems and agent-facing APIs are converging on the same separation: a harness should be able to discover and invoke capabilities without owning every integration.
This is not only a standards story. Managed MCP services, protocol proxies, tool-search mechanisms, and protocol-aware interfaces show the operational layer forming around the specifications.
What the archive adds
- Microsoft Research documents tool-space interference, evidence that protocol compatibility must include selection quality rather than only schema access.
- Anthropic’s code-execution pattern and Mozilla’s MCP proxy move protocol calls into smaller, inspectable execution surfaces.
- Google Cloud’s managed MCP servers and the transfer of MCP to a neutral foundation indicate that interoperability is becoming ecosystem infrastructure.
- A2A and ACP widen the thesis from tool invocation to cross-agent and client-agent compatibility.
Operational consequence
Teams should preserve direct APIs as the source of truth while exposing a thin, versioned protocol layer with discovery metadata, scoped authorization, idempotency rules, and observable failures. Protocol adoption should be judged by portability and completed-work reliability, not by the number of registered tools.