The agent protocol stack is real

For the past year, the agent ecosystem had a plumbing problem. Every framework invented its own way for agents to call tools, talk to each other, and understand codebases. If you built on LangChain, your tools didn't work in CrewAI. If you trained an agent on your repo's conventions, that knowledge didn't transfer to a different agent. It was the pre-HTTP internet: brilliant nodes that couldn't interoperate.

That era is ending. Three protocols (MCP, A2A, and AGENTS.md) have emerged as the de facto infrastructure layer for agentic AI. In December 2025, all three were donated to the Linux Foundation's Agentic AI Foundation (AAIF), co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block. The industry is converging on a shared stack, and if you're building agents, you need to understand it.

The stack at a glance

The analogy that keeps circulating is "the TCP/IP moment for AI agents." The framing originated with Micheal Lanham in February 2026: "Two competing visions stopped competing and started merging. If that sounds familiar, it should. That is exactly how TCP/IP won."

The analogy is imperfect. TCP/IP evolved over decades, not months. But the structural parallel is real. Just as the internet needed a layered protocol stack (IP for routing, TCP for reliable delivery, HTTP for applications), agents need a layered stack for tool access, coordination, and context.

Layer 1: MCP, the tool layer

The Model Context Protocol, created by Anthropic and open-sourced in late 2024, gives agents a universal interface to tools, data sources, and APIs. Think of it as USB for AI: one standardised connector that works with any tool and any model.

Before MCP, every agent framework had its own tool-calling convention. If you built a Slack integration for one framework, you rebuilt it from scratch for another. MCP eliminates this by defining four primitives:

The adoption numbers speak for themselves. MCP has reached 97 million monthly SDK downloads across its TypeScript and Python SDKs, as reported by Anthropic. Over 8,600 public MCP servers exist across registries, up from roughly 425 in mid-2025.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import { z } from "zod";

const server = new McpServer({

name: "pricing-service",

version: "1.0.0",

});

// Expose a tool with typed schema

server.tool(

"get_competitor_pricing",

"Fetch current pricing for a competitor product",

{

  competitor: z.string().describe("Company name"),

  product: z.string().describe("Product identifier"),

  currency: z.enum(["USD", "EUR", "GBP"]).default("USD"),

},

async ({ competitor, product, currency }) => {

  const data = await pricingDb.query({ competitor, product, currency });

  return {

    content: [{

      type: "text",

      text: JSON.stringify(data, null, 2),

    }],

  };

}

);

// Expose a resource for read-only access

server.resource(

"pricing-history",

"pricing://history/{competitor}",

async (uri) => {

  const competitor = uri.pathname.split("/").pop();

  const history = await pricingDb.getHistory(competitor);

  return {

    contents: [{

      uri: uri.href,

      mimeType: "application/json",

      text: JSON.stringify(history),

    }],

  };

}

);

Layer 2: A2A, the coordination layer

MCP solves tool access. It does not solve agent-to-agent communication. If you have a research agent that needs to hand off findings to a writing agent, MCP has nothing to say about how that handoff works. That's what A2A is for.

The Agent2Agent Protocol, introduced by Google in April 2025, defines how agents discover each other, negotiate capabilities, and exchange tasks. The lifecycle is simple:

1. Discovery: agents publish Agent Cards, which are JSON documents describing their capabilities, input schemas, and endpoint URLs. Other agents can query a well-known path to find available collaborators.

2. Task submission: one agent sends a structured task to another. The task has a defined schema, constraints, and a deadline.

3. Status updates: the receiving agent streams status updates as it works. Accepted, working, input-needed, complete, or failed.

4. Result delivery: the final output is returned as a structured artifact with metadata (confidence, warnings, partial results).

{

"name": "compliance-reviewer",

"description": "Reviews content against regulatory compliance rules",

"url": "https://agents.viziums.com/compliance",

"version": "2.1.0",

"capabilities": {

  "streaming": true,

  "pushNotifications": false

},

"skills": [

  {

    "id": "review-content",

    "name": "Content compliance review",

    "description": "Checks text against SOC2, GDPR, and HIPAA rules",

    "inputSchema": {

      "type": "object",

      "properties": {

        "content": { "type": "string" },

        "rules": {

          "type": "array",

          "items": { "enum": ["soc2", "gdpr", "hipaa"] }

        }

      },

      "required": ["content", "rules"]

    }

  }

]

}

In August 2025, IBM announced that its Agent Communication Protocol (ACP) would officially merge with A2A under the Linux Foundation's LF AI & Data umbrella. This was significant because ACP and A2A had overlapping goals. The merge eliminated the last serious protocol fragmentation risk. Kate Blair joined the A2A Technical Steering Committee on behalf of IBM, alongside representatives from Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow, and SAP.

Layer 3: AGENTS.md, the context layer

MCP gives agents tools. A2A lets agents coordinate. But neither tells an agent what a codebase does or how to work within it. That's the gap AGENTS.md fills.

AGENTS.md is a Markdown file that lives in the root of a repository. A README for AI agents. It was originated by Sourcegraph and rapidly adopted by OpenAI Codex, Google Jules, Cursor, GitHub Copilot, and others. GitHub analysed over 2,500 public repositories with AGENTS.md files and published a guide to writing effective ones.

The format is deliberately simple. No JSON schema, no formal specification. Just structured Markdown with conventional sections:

# AGENTS.md

## Project overview

E-commerce platform built with Next.js 15, TypeScript, and Postgres.

Monorepo with three packages: web, api, shared.

## Architecture decisions

- Server Components by default; "use client" only for interactivity

- All database access through Drizzle ORM (no raw SQL)

- Feature flags via LaunchDarkly; never hard-code conditionals

## Code conventions

- Prefer named exports over default exports

- Use Zod for all external input validation

- Tests live next to source files (*.test.ts, not __tests__/)

## Commands

- `pnpm dev` starts the dev server

- `pnpm test` runs vitest

- `pnpm lint` runs eslint + prettier check

- `pnpm db:migrate` runs pending migrations

## Sensitive areas

- /packages/api/src/auth/ contains authentication logic, changes need security review

- /packages/shared/src/billing/ contains billing calculations, require two approvals

The brilliance is in the positioning. AGENTS.md doesn't try to be a formal protocol. It's a social convention, like .gitignore or .editorconfig, that works because it's simple enough for every team to adopt and every agent to parse.

“

AGENTS.md is the most underrated part of the stack. MCP and A2A handle the infrastructure. AGENTS.md handles the culture. Without it, agents can use your tools but don't understand your project.

How the layers compose

The real power is in the composition. A production agent system doesn't use one protocol. It uses all three, each at the layer where it belongs.

What the stack doesn't solve

The protocol stack is infrastructure, not intelligence. It solves interoperability (the right tool reaches the right agent at the right time). It does not solve:

• Reliability: a ten-step workflow at 85% per-step accuracy still fails 80% of the time, regardless of how clean the protocol layer is. You still need checkpointing, validation gates, and the architectural patterns we covered in the previous post.

• Trust: MCP servers can return anything. A2A agents can misrepresent their capabilities. AGENTS.md can be outdated. The protocols define the wire format, not the trustworthiness of what travels on it.

• Evaluation: knowing that your agents can talk to each other tells you nothing about whether they produce good results. You need an eval layer on top of the protocol layer.

Building on the stack today

The stack is production-ready for well-scoped use cases. Here's where to start:

MCP: deploy MCP servers for your internal tools. If your agents call a Postgres database, a Slack workspace, or an internal API, wrap each in an MCP server. The SDKs (TypeScript, Python) are stable. The protocol handles transport (stdio for local, SSE for remote).

A2A: define Agent Cards for any agent you want to be discoverable. Even if you're not building multi-agent systems yet, having a formal capability description forces you to think about your agent's boundaries. What it can do, what it can't, and what inputs it needs.

AGENTS.md: add one to every repository your agents touch. Start with project overview, code conventions, and commands. Iterate as you learn what your agents actually need. GitHub's analysis of 2,500 repositories found that the most effective AGENTS.md files are specific and opinionated, not generic.

“

The protocol stack won't make your agents smarter. It will make them composable. And composability, the ability to assemble reliable systems from independent parts, is how every successful infrastructure layer has won.

MCP, A2A, and AGENTS.md are not the final answer. They're version one of a stack that will evolve for years. But they're the first version that matters. The one where the industry stopped fragmenting and started converging. Build on them now, and your agent infrastructure will compound in value. Wait, and you'll be rewriting integration code that the protocols were designed to eliminate.