The Interfaces Are Arriving

Tommy Tran · rss · 2026-09-11 source ↗ Reader 🖥️

Agent Governance (Internal)Agent-to-Agent Protocols Agent Tool Management MCP (Model Context Protocol)Cross-Vendor Protocol Standardization Software Supply-Chain Security

Because rival AI vendors are now donating and independently implementing shared interoperability protocols (MCP, A2A) under neutral, foundation-based governance — repeating the historical pattern of Ethernet and the Language Server Protocol — engineering organizations should treat these protocols as durable, ownable infrastructure worth building on now, even though the standards themselves remain young and cannot resolve the deeper semantic-trust and cross-hop-delegation problems that lie beneath them.

practical · mixed — Opens as exposition (what MCP/A2A are, adoption figures, spec mechanics) and argument (why cross-vendor, neutrally-governed standardization is the year's most consequential AI news), then turns explicitly practical: it ends in a set of engineering-org recommendations (own the integration as an asset, build a security seam, curate a registry, version-pin, participate in standards bodies).

Structure

Part	Role
Opening: Anthropic's December 2025 donation of MCP to the Agentic AI Foundation (a Linux Foundation directed fund cofounded by Anthropic, Block, and OpenAI), with Google's earlier A2A donation to the same foundation family.	Sets up the central evidentiary claim: competitors are cooperating formally, under neutral governance, on interfaces rather than models.
Historical framing: three years of capability-led progress with slower, custom-glue integration; analogy to networking and the Language Server Protocol.	Context and analogy explaining why this is a structural turning point rather than routine news.
MCP mechanics (JSON-RPC, hosts/clients/servers, tools/resources/prompts), its explicit LSP lineage, and its revision cadence (five dated spec revisions since November 2024).	Exposition establishing what the standard is and signaling active, immature governance.
MCP adoption evidence (97M+ monthly SDK downloads, 10,000+ active servers, first-class support across ChatGPT, Claude, Cursor, Gemini, Copilot, VS Code) and the claim that independent cross-vendor implementation, not any single count, is what makes an interface infrastructure.	Evidence for the unity's central empirical premise.
A2A description and adoption (v1.0, 150+ organizations, signed Agent Cards, GA in Copilot Studio/Azure AI Foundry/Bedrock AgentCore), plus the broader emerging stack (AGENTS.md, OpenTelemetry GenAI semantic conventions).	Extends the interface claim beyond MCP to a wider, still-forming standards stack.
The reuse argument: an MCP server should be engineered like a library or service (owners, versions, tests, upgrade policy) because the interface can outlast any given model or host.	First practical consequence drawn from the standardization claim.
The security-seam argument: MCP's authorization spec builds on OAuth 2.1/PKCE/audience-bound tokens, and behavioral annotations give hosts a policy vocabulary but must be treated as untrusted self-description.	Second practical consequence; also introduces the trust qualification that later becomes central.
Discovery and supply-chain risk: the MCP Registry (npm/PyPI-like, but preview-stage and package-distribution-agnostic) and the new supply-chain exposure of components holding live credentials.	Practical consequence plus explicit limitation (registry immaturity).
Testing benefits: schema-declared inputs/outputs let teams contract-test protocol behavior separately from model behavior; OpenTelemetry conventions extend this to runtime evidence.	Further practical benefit of standardization.
The turn: 'these benefits stop at the edge of what the interfaces describe' — the semantic gap (schema captures shape, not meaning) leads to a trust gap (a signature ties a claim to an identity, not to trustworthiness), and delegation across multi-hop agent chains has no common attenuation mechanism.	The essay's central qualification/limit — protocols carry an organization's trust decision through a system, they do not make it.
Closing recommendations: version-pin, keep protocol code behind thin adapters, budget for migration, give internal servers durable owners, and participate now in the still-young standards bodies while the rules are still being written; final restatement via the Ethernet/LSP analogy.	Synthesis and call to action.

Key terms

Interfaces (the arriving ones)
Standardized, neutrally governed, cross-vendor protocol contracts — MCP, A2A, and the emerging AGENTS.md/OTel conventions — that let AI systems and their tools/other agents interoperate without custom, one-off integration glue.
Semantic gap
The residual space between what a schema formally declares (a tool's argument shape) and what the tool actually means or when it is appropriate to use — something a JSON Schema cannot capture and a model must still interpret.
Trust gap
The further gap beyond the semantic one: a protocol (or a signed Agent Card) can carry a claim and bind it to an identity, but an organization still needs an independent basis for deciding whether that identity, publisher, or code deserves authority — the protocol transports the decision, it does not make it.
Neutral governance Cross-Vendor Protocol Standardization
Standards stewardship by a directed fund under a foundation (Linux Foundation) with multiple, competing corporate cofounders and backers, as distinct from a single vendor unilaterally controlling a spec.
Behavioral annotations
MCP's declared tool metadata (read-only, destructive, idempotent, open-world) that gives a host a policy vocabulary, but which the spec itself requires treating as untrusted unless attested by a trusted server.

Propositions

explicitcorroboratedAnthropic's donation of MCP and Google's earlier donation of A2A to the Linux-Foundation-based Agentic AI Foundation family makes this 'the most consequential AI news of the past year,' because companies that compete fiercely on models are now cooperating formally, under neutral governance, on the interfaces between them.conf: high
refinesAn Evolutionary Architecture Pattern for Managing AI's Pace of Change · p12 — Updates the earlier claim that 'no clear industry standard yet exists for agent-to-agent (A2A) protocols': by the time of this article, A2A had reached v1.0 with 150+ supporting organizations and GA in three major cloud platforms — though MCP's own five dated revisions in under two years shows the underlying instability that the older claim was describing persists.
supports ←Agent Tools & Interoperability · p1 — Both treat the donation of MCP and A2A to neutral, Linux-Foundation-based governance as the consequential standardization event that justifies building production architecture on top of these protocols.
explicitThe standardization now underway will influence what engineering teams ship over the next three years as much as further gains in model capability.conf: high
explicitA shared interface becomes infrastructure specifically when rival vendors implement it independently — cross-vendor implementation is the test that adoption counts alone cannot substitute for.conf: high
refinesThe Agentic P&L: Beyond the Empire of Headcount · p15 — Sharpens the earlier, undefended claim that 'an MCP-style protocol layer will become a de facto standard (the TCP/IP of the federated enterprise)' by naming the actual test for that claim — independent cross-vendor implementation, not adoption counts alone — and by treating MCP as one of several co-emerging protocols (plus A2A, AGENTS.md, OTel semconv) rather than a single settled substrate.
explicitAn MCP server should be engineered and owned like a library or service — with owners, versions, tests, and upgrade policies — because models and hosts will keep changing while the interface contract, implementation, and authorization wiring can endure.conf: high
explicitA shared protocol creates a recognizable security seam where identity, permissions, data flow, and audit controls can be specified once and applied across many tools and hosts, letting teams draw on years of OAuth deployment experience instead of rediscovering its failure modes inside a new protocol.conf: high
explicitBehavioral annotations (read-only, destructive, idempotent, open-world) give hosts a policy vocabulary, but must be treated as untrusted unless they come from a trusted server — self-description can inform a security decision but cannot establish the trust that decision rests on.conf: high
explicitBecause MCP now makes servers discoverable, an internal subregistry or allowlist is a sensible first control against the supply-chain risks (typosquatting, abandoned packages, malicious updates, uncertain provenance) that now apply to components holding live credentials and production access.conf: high
supportsFighting Tool Sprawl: The Case for AI Tool Registries · p7 — Both pieces converge on the same near-term control despite the public MCP Registry existing: cross-organization registry standardization is premature, so an internal, organization-scoped subregistry or allowlist is the practical response.
explicitA shared, schema-based contract separates two kinds of uncertainty that agent evaluations often conflate: whether an integration exchanged valid messages and enforced its contract (protocol testing) versus whether the agent chose the right tool and interpreted its result well (model evaluation).conf: high
explicitdevelopedA schema captures only the shape of a tool's arguments, not its meaning; it cannot tell an agent when a tool is appropriate, how its effects interact with other tools, or whether two similarly named operations are semantically equivalent — portability across hosts does not guarantee consistent behavior across models and contexts.conf: high
supportsArticle: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules · p9 — Same structural limit surfacing in a different domain: a schema or dependency-rule validator can prove structural conformance (a schema still parses; an import exists) but not semantic meaning or intent — here applied to MCP tool schemas, there to architectural fitness functions.
extends ←MCP Is Not Just Another API Standard · p6 — Gives a concrete before/after tool-description example and names the observed consequence (agents avoiding a well-schemaed but badly-described tool) for a claim the earlier piece states abstractly: that a schema captures shape but not meaning.
explicitThe semantic gap produces a trust gap: a protocol, or a signed A2A Agent Card, can carry a claim and bind it to an identity, but an organization still needs an independent basis for deciding which identities, publishers, code, and claims deserve authority — the protocol carries that decision through a system, it does not make it.conf: high
explicitPreventing token passthrough closes one authorization hole, but no common mechanism yet defines how authority should narrow (attenuate) as a request passes through an arbitrary chain of agent-to-agent-to-tool hops, so platforms currently solve delegation locally or leave too much authority in place.conf: high
extendsAWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale · p2 — Names the harder problem that Loom's RFC 8693 token-exchange mechanism only partially addresses: preserving a delegation chain across hops is necessary, but the article observes there is still no common mechanism for how authority should narrow at each hop.
explicitBecause the standards are still young (the registry is in preview, telemetry conventions are unstable, and MCP has produced five dated protocol revisions in under two years), engineering teams should version-pin, keep protocol code behind thin internal adapters, and budget for migrations rather than treat current implementations as settled.conf: high
supportsPresentation: From Copy-Paste to Composition: Building Agents Like Real Software · p12 — Independent evidence for treating MCP as immature, version-unstable infrastructure: a fully dynamic, unversioned tool schema breaks eval reliability the same way the article's own five-revisions-in-under-two-years cadence breaks integration stability.
implicitEngineering organizations with a real stake in agent infrastructure have a limited, closing window to influence what becomes portable, observable, and enforceable by participating directly in the still-young standards bodies, because the rules being written now will harden into assumptions embedded in future products.conf: medium
implicitThe correct posture toward AI protocol standardization is simultaneous confidence and caution: bet that the interfaces themselves will persist and are worth building on, while expecting their specific current forms to keep changing and insulating against that churn.conf: medium

Arguments

Engineering teams should treat internal MCP servers as durable, owned infrastructure assets — with owners, versions, tests, and upgrade policies — rather than as one-off integration glue. strength: medium

Explicit premises:

Standard interfaces change the economics of integration work that used to be custom glue for every agent/tool/host pairing.
Models and hosts will keep changing while the interface contract, server implementation, schemas, and authorization wiring can endure.
Language servers followed exactly this path: editors came and went around a stable interface.

Implicit premises:

Investment in an integration layer only pays off if that layer's useful life outlasts the churn of the systems built on top of it — the LSP analogy is being generalized into a lawlike expectation, not treated as a one-off historical coincidence.
Formal organizational ownership (named owners, versioning, tests, upgrade policy) is what actually captures durability once protocol stability exists — protocol maturity alone is not assumed sufficient.

Inferences:

If the interface layer is genuinely durable, the natural organizational response is to fund a small platform team that owns the shared MCP server surface the way platform-engineering teams already own other paved-road infrastructure — the essay's 'owners, versions, tests' language implies this without stating it.

Shared protocols cannot substitute for an organization's own judgment about which identities and code deserve authority — they only carry that judgment through a system once it has been made elsewhere. strength: high