Most conversations about AI-assisted development still revolve around models: which model writes better code, which CLI is faster, and which agent has the best benchmark.
But the interesting shift is happening one layer below the model.
We are building systems in which agents use tools, delegate work to other agents, operate inside editors, interact with applications, and coordinate across services. Once those systems leave a demo and become software, integrations need contracts.
That is where protocols and conventions such as MCP, A2A, ANP, ACP, AG-UI, Agent Skills, and AGENTS.md enter the picture.
They are not competing names for the same thing. Each describes a different boundary in an agentic system.
First, the mental model
Think of an agentic application as a set of connected boundaries:
- A model or agent runtime reasons about a task.
- Tool protocols expose capabilities and data to that runtime.
- Agent protocols let independent agents delegate and collaborate.
- Client protocols connect coding agents to editors.
- UI protocols connect agent runtimes to product interfaces.
- Repository instructions and skills provide reusable context and workflows.
- Evaluation and tracing help us verify that the whole system behaves reliably.
A useful rule: don’t choose a protocol because it is trending; choose it because you can identify the boundary it standardizes.
1. MCP — Model Context Protocol
Problem: Every AI application was integrating tools and data sources in a slightly different way.
MCP standardizes how an AI application connects a model or agent to external capabilities. An MCP server can expose three important primitives:
- Tools: actions the model can invoke, such as querying a database or creating an issue.
- Resources: data the host can load into the model’s context, such as files or records.
- Prompts: reusable prompt templates exposed by the server.
For example, imagine a coding agent that needs to inspect a database, read GitHub issues, and check deployment logs. Instead of writing a bespoke integration for every agent, those capabilities can be exposed through MCP servers.
MCP is primarily about the agent-to-tool and agent-to-context boundary. It does not, by itself, define how two independent agents delegate a multi-step task to each other.
2. A2A — Agent2Agent Protocol
Problem: Tool calling is not the same as agent collaboration.
An agent may be excellent at planning but not have the domain knowledge or permissions needed to complete a specialist task. A2A defines a common way for independent agent systems to discover capabilities, exchange messages, and collaborate on tasks.
A practical example:
- A product-planning agent receives a request to add billing.
- It delegates a security review to a security agent.
- It delegates API design to a backend agent.
- Each specialist works within its own runtime and returns a result.
- The planning agent combines the results and coordinates the next step.
The important part is that the caller does not need to know the internal prompts, memory, tools, or framework used by the remote agent. It needs a standard interaction contract.
A2A is about the agent-to-agent boundary. It complements MCP: an agent can use MCP to access tools while using A2A to collaborate with another agent.
3. ANP — Agent Network Protocol
Problem: How do agents find and connect to other agents across an open network?
ANP (Agent Network Protocol) takes the idea of agent interoperability toward an open, internet-scale agent network. Its work covers agent identity, authentication, descriptions, discovery, messaging, and application-level collaboration.
The distinction from A2A is useful:
- A2A standardizes interaction and task collaboration between independent agent systems.
- ANP puts additional emphasis on open-network identity, discovery, and connectivity—how agents can identify one another and find services across domains.
ANP is an evolving protocol suite, so check the status of individual specifications before depending on a particular feature. For example, its current project documentation distinguishes released specifications from drafts.
Do not treat ANP and A2A as interchangeable names. They address overlapping parts of the broader interoperability problem from different design directions.
4. ACP — know which ACP someone means
ACP is a particularly confusing acronym because it is used by more than one project.
Agent Client Protocol
In AI coding tools, ACP commonly means Agent Client Protocol, developed by Zed and grown with the editor and agent ecosystem.
It standardizes communication between a code editor and a coding agent. The goal is simple: use different compatible agents from different compatible editors without building a custom integration for every editor-agent pair.
Think of it as the editor-agent equivalent of what the Language Server Protocol did for editor-language-server integrations.
For example, an ACP-compatible editor can launch or connect to an ACP-compatible coding agent and exchange session prompts, updates, and other interaction events through a shared contract.
This is especially relevant if you are building a coding agent and want it to work in more than one IDE.
Agent Communication Protocol
There is also an Agent Communication Protocol associated with IBM’s BeeAI work. It was designed for lightweight, HTTP-native communication between agents.
Important status update: IBM’s project documentation says this ACP has become part of A2A under the Linux Foundation, with migration guidance available. It should not be presented as an unrelated, actively competing protocol without that qualification.
When someone says ACP, ask whether they mean Agent Client Protocol (editor ↔ coding agent) or the older Agent Communication Protocol (agent ↔ agent).
5. AG-UI — Agent ↔ User Interaction Protocol
Problem: A chat transcript is not enough to represent a real agentic application.
An agent might need to stream a response, show tool activity, update shared state, request user input, or render an interactive experience. AG-UI standardizes the event-based connection between an agent runtime and a user-facing application.
Picture a project-management app:
- The user asks an agent to prepare a release.
- The backend streams progress and tool activity.
- The frontend updates the task list as work completes.
- The agent asks the user to approve a risky action.
- The UI sends that decision back to the runtime.
AG-UI is the agent-to-application interaction boundary. It is not a component library and does not decide which UI framework you must use.
6. A2UI — a related but different idea
A2UI is about how an agent can describe a user interface in a structured, renderable form. AG-UI, by contrast, standardizes the interaction and event flow between an agent and an application.
A simple way to remember the distinction:
- AG-UI: how the agent and frontend communicate.
- A2UI: how an agent can describe UI that a client can render.
They can work together, but they solve different problems.
7. Agent Skills and AGENTS.md — make expertise reusable
Not every important part of agentic development is a network protocol.
Two conventions are becoming important in coding-agent workflows:
Agent Skills package a repeatable capability as instructions, and optionally supporting references or scripts. A skill might explain how to review a pull request, investigate a production incident, or generate a migration safely. The agent can load the workflow when it is relevant instead of carrying every instruction in its base prompt.
AGENTS.md is a repository-level instruction file used by coding agents. It can explain the project structure, coding conventions, test commands, architectural constraints, and rules an agent should follow while working in that repository.
A useful separation:
- Put durable project rules in
AGENTS.md. - Put reusable, task-specific procedures in skills.
- Keep application behavior and business logic in code.
- Keep credentials and authorization in the actual security boundary—not in a prompt.
These conventions help an agent work consistently, but they are not substitutes for permissions, tests, or code review.
8. Tool calling, handoffs, traces, and evals
You will also hear several terms that are important but are not all protocols:
- Tool / function calling: the model requests a structured action that the runtime can execute. MCP can standardize how tools are exposed across applications.
- Handoff: control moves from one agent or specialist to another inside an orchestration runtime. A handoff is a workflow concept; it is not automatically an A2A exchange.
- Orchestration: the logic that decides which agent runs, what context it receives, what happens next, and when a human must approve.
- Guardrails: input, output, and action checks that constrain what the system can do.
- Tracing: records of model calls, tool invocations, handoffs, latency, and outcomes that help developers debug an execution.
- Evals: repeatable tests that measure whether an agent completes tasks correctly and safely across representative scenarios.
A system can implement all of these without adopting every protocol mentioned in this article.
How the pieces fit together
Here is one possible architecture for an agentic developer platform. It is illustrative, not a requirement that every application use every protocol.
flowchart TD
U[Developer / User] --> IDE[IDE or Product UI]
IDE <-->|ACP| AGENT[Coding Agent Runtime]
IDE <-->|AG-UI in a product UI| APP[Agent-enabled Frontend]
APP <--> ORCH[Orchestrator]
AGENT <--> ORCH
ORCH -->|MCP| TOOLS[Tools and Data Sources]
ORCH -->|A2A| SPECIALIST[Remote Specialist Agents]
ANP[ANP Identity and Discovery] -.->|Find / identify agents| SPECIALIST
SKILLS[Agent Skills + AGENTS.md] -.-> AGENT
SKILLS -.-> ORCH
ORCH --> OBS[Traces, Evals and Guardrails]
AGENT --> OBS
The architecture has distinct responsibilities:
| Boundary | Useful standard or concept | What it answers |
|---|---|---|
| Agent ↔ tools and data | MCP | What can this agent access or invoke? |
| Agent ↔ agent | A2A | How can independent agents collaborate? |
| Open agent network | ANP | How can agents identify and discover one another? |
| Editor ↔ coding agent | Agent Client Protocol (ACP) | How can an agent work across compatible editors? |
| Agent ↔ frontend | AG-UI | How does the app receive agent events and send user interaction? |
| Agent ↔ rendered UI description | A2UI | How can an agent describe UI in a structured way? |
| Agent ↔ project workflow | Skills, AGENTS.md |
What reusable expertise and repository rules should it follow? |
| Runtime quality | Tracing and evals | Did the system behave correctly? |
What should a developer learn first?
If you are building agentic software today, I would learn these in this order:
- Tool calling and MCP — build an agent that can safely use real capabilities.
- Orchestration and handoffs — understand state, delegation, retries, and human approval.
- A2A — connect independently deployed agents when a real interoperability boundary exists.
- AG-UI — build a product experience that exposes agent state and user control.
- ACP (Agent Client Protocol) — make a coding agent usable from compatible editors.
- ANP — explore open-network identity and discovery as your use case requires.
- Skills, AGENTS.md, traces, and evals — make the development workflow repeatable and measurable.
You do not need all of them for your first agent. A single agent with a few well-designed MCP tools, clear permissions, durable state, and a solid evaluation set can be more useful than a distributed system of agents connected by every protocol available.
The bigger shift
The interesting development is not that we have more acronyms.
It is that agentic software is moving from isolated model integrations toward a composable ecosystem. Tools need contracts. Agents need ways to collaborate. Editors need a common interface to agents. Frontends need structured interaction. Teams need reusable instructions and ways to measure reliability.
The model is only one component in that system.
The next generation of agentic developers will need to understand not just how to prompt an agent, but how to engineer the boundaries around it.