The Boring Layer Will Decide Whether AI Agents Actually Scale

AI Agents Need Standards Before Integration Becomes the Next Platform Tax

AI agents need interoperability standards before every enterprise ends up rebuilding the same integration layer. AGENTS.md, CLAUDE.md, MCP, and A2A are useful building blocks but the broader interoperability problem is still not solved.

That may sound like a narrow technical concern, but it is quickly becoming one of the most important questions in applied AI. The industry is moving from chat interfaces toward agents that can use tools, access systems, execute tasks, preserve context, and coordinate with other agents. That shift creates a new kind of infrastructure problem.

The issue is not whether agents will become more capable. They will. The issue is whether those capabilities will operate through shared contracts, or whether every company will have to build a custom bridge between every vendor, model, agent framework, tool interface, and context layer.

We have seen this pattern before.

In the early days of software platforms, fragmentation often looked manageable. A vendor-specific interface here. A custom connector there. A local convention that made perfect sense inside one ecosystem. Over time, those small differences compounded into real operational friction.

That is what made think about old “DLL hell”. The problem was not that libraries existed. The problem was version conflicts, implicit dependencies, incompatible assumptions, and unclear ownership of shared interfaces. The same risk now exists in the AI agent ecosystem.

Only this time, the dependency is not just a library. It is context, permissions, memory, tools, identity, task state, and delegation.

We are already seeing early signs of standardization. AGENTS.md is positioned as a simple, open format for giving coding agents predictable project-specific instructions essentially a README for agents. It gives agents a known place to find setup commands, conventions, tests, and other operational guidance. The official site says it is used by more than 60,000 open-source projects and is compatible with a growing ecosystem of coding tools.

CLAUDE.md serves a similar purpose inside Claude Code, but it is not the same thing. Anthropic’s documentation says Claude Code reads CLAUDE.md, not AGENTS.md, though a CLAUDE.md file can import AGENTS.md to avoid duplicating guidance. Anthropic also notes that CLAUDE.md content is treated as context, not enforced configuration, and is delivered after the system prompt rather than as part of it.

That distinction matters.

Files like AGENTS.md and CLAUDE.md are useful, but they are mostly instruction layers. They help an agent understand how to operate inside a codebase or environment. They are not, by themselves, a complete interoperability standard for agents operating across vendors, tools, systems, and boundaries.

MCP gets closer to the infrastructure layer. The Model Context Protocol defines an open protocol for connecting LLM applications to external data sources and tools. The official specification describes MCP as a standardized way for applications to share contextual information with language models, expose tools and capabilities, and build composable integrations.

That is a meaningful step. It reduces the need for every AI product to build a custom connector for every data source or tool. Anthropic’s original MCP announcement framed the problem clearly: without a common protocol, every new data source requires a custom implementation, making connected AI systems difficult to scale.

But MCP is still only part of the picture.

MCP is primarily about connecting AI systems to tools, data, and external capabilities. It helps answer the question: how does an agent access the resources it needs?

A2A addresses a different part of the problem. The Agent2Agent protocol is designed for communication and interoperability between independent agent systems, including agents built with different frameworks, languages, or vendors. Its specification includes discovery, modality negotiation, collaborative task management, and secure information exchange without requiring access to another agent’s internal state, memory, or tools.

That is much closer to the real interoperability challenge.

Still, the existence of standards does not mean the fragmentation problem is solved. It means the industry has started to define the right layers.

The deeper issue is that agents are not just APIs with natural language wrapped around them. An API call usually has a bounded contract: request, response, status code, authentication, schema. An agent interaction can involve ambiguous instructions, evolving state, intermediate reasoning, tool execution, partial results, memory, approvals, and delegation. That makes the contract harder to define.

A mature agent interoperability standard needs to answer practical questions.

Who is the agent acting on behalf of? What is it authorized to do? What context can it carry forward? What context must it drop? How does one agent know whether another agent is reliable for a task? How is task state represented? What counts as completion? What happens when two agents disagree? How are errors, retries, approvals, and audit trails handled?

Without common answers, every enterprise will build its own integration layer.

That layer will start small. A few adapters. A few prompt conventions. A routing service. A permissions wrapper. A custom memory policy. A logging layer. A vendor-specific bridge. Then another. Then another.

Eventually, the integration layer becomes the product tax.

This is where the “DLL hell” analogy becomes useful. The pain does not come from diversity. It comes from unmanaged diversity. Multiple vendors are fine. Multiple models are fine. Multiple agent frameworks are fine. The problem starts when every component brings its own hidden assumptions and every integration requires bespoke glue.

The pushback is obvious: standards are already emerging.

That is true. And it is good news. OpenAI, Anthropic, and Block helped launch the Agentic AI Foundation under the Linux Foundation, with contributions including AGENTS.md, MCP, and goose. OpenAI described the foundation as a neutral home for open, interoperable agentic infrastructure as agents move from experimentation into real-world production.

The Linux Foundation also describes MCP as a protocol for connecting AI models to tools, data, and applications, and AGENTS.md as a universal standard for giving coding agents project-specific guidance.

A2A is also moving through open governance. The Linux Foundation describes A2A as an open standard that enables agents to discover, communicate, and transact with each other across frameworks, vendors, and platforms. It also describes A2A and MCP as complementary: A2A defines how agents communicate and coordinate with each other, while MCP defines how agents connect to tools and data sources.

So the right argument is not “there are no standards.”

The right argument is that standards are emerging, but the enterprise interoperability problem is broader than any single file, connector, or protocol.

AGENTS.md helps with instruction discovery. CLAUDE.md helps Claude Code persist project guidance. MCP helps agents access tools and context. A2A helps agents communicate and coordinate. Those are all important. But the next layer is the durable operating contract: identity, permissions, provenance, state, observability, error handling, versioning, and governance.

That is the part that determines whether agents become reusable components or another round of vendor-specific infrastructure.

There is another reasonable objection: it may be too early to standardize.

That is partially true. The agent abstraction is still evolving. The industry should not prematurely freeze the way agents reason, plan, use memory, or delegate work. Bad standards can create lock-in just as easily as proprietary systems can.

But interoperability standards do not need to standardize intelligence. They need to standardize boundaries.

They do not need to define how an agent thinks. They need to define how an agent identifies itself, what capabilities it exposes, how it accepts a task, how it reports progress, how it returns artifacts, how it handles failure, and how another system can verify what happened.

That kind of standardization is not premature. It is infrastructure hygiene.

The agent ecosystem is moving quickly, and capability improvements will continue to get most of the attention. Bigger context windows, better tool use, stronger reasoning, and more autonomous execution all matter.

But the boring layer may decide how much of this actually scales.

Interoperability is not glamorous. Neither are schemas, version negotiation, permission models, audit logs, or lifecycle states. But those are the pieces that turn interesting demos into durable systems.

Without shared contracts, every enterprise will rebuild the same agent integration layer.

With shared contracts, agents can become portable, composable, and governable across systems.

That is the real unlock. Not one agent. Not one vendor. Not one model.

A standard that lets many of them work together without recreating DLL hell in a new form.