To do useful work, an agent must connect to a model, tools, remote agents, users, organization-specific instructions and knowledge, operational systems, and, for coding work, an IDE. Agents are becoming a primary unit of application development, and each of those connections is a boundary.
Vendors and working groups are converging on a different contract at each boundary. MCP, A2A, AG-UI, and ACP are communication protocols. Open Responses specifies a model API. OpenTelemetry GenAI defines semantic conventions. AGENTS.md, Agent Skills, and plugins use file and package formats. Together they make each connection more portable without forcing your whole agent system into one standard.
You can compose these contracts independently. Use MCP for tools without adopting A2A for remote agents or ACP for IDEs. Most teams start with model access and add contracts as their agent crosses new boundaries.
1. Open Responses: Calling Models
Your agent’s first connection is the model. Early integrations converged on the semantics of OpenAI’s Chat Completions API: messages, roles, multi-turn exchanges, streaming, and structured tool calls. Clients, gateways, and model providers adopted that request and response shape.
Agent runtimes now coordinate model actions across a run. OpenAI’s Responses API represents messages, tool calls, tool results, and other model actions as typed items, with semantic streaming events and state carried across turns. Open Responses takes that design and defines an open, multi-provider contract for calling models and composing agentic workflows.
OpenAI recommends Responses for new projects while continuing to support Chat Completions. Anthropic also provides an OpenAI SDK compatibility layer for core Chat Completions, although it positions the layer mainly for testing and comparison. That existing alignment makes Open Responses a credible neutral specification, but it is still emerging.
2. MCP: Connecting Tools
Once your agent can call a model, it can reason. To act on that reasoning it has to reach into its environment. A tool might read a document, query a database, operate a browser, invoke an internal service, or change an external system. The model API can describe a tool call, but the integration behind that call needs a reusable contract.
The Model Context Protocol uses JSON-RPC 2.0 and defines three roles: the host is the LLM application, a client inside that host connects to a server, and the server exposes capabilities. Alongside tools, resources and prompts let a server expose data and reusable interaction templates through the same connection.
MCP Apps extends that contract by letting a tool declare an interactive HTML resource for the host to fetch and render in a sandboxed iframe. Skills over MCP is still in development and explores how agents could discover and consume Agent Skills through the same protocol. Neither extension is part of basic MCP support.
Most clients, servers, and SDKs support MCP, which makes it the closest thing to a de facto standard in this map.
3. A2A: Delegating Work
The next boundary is delegation. Inside one process, a framework can coordinate agents with function calls or an internal message bus. Agents that someone else built and deployed need a shared external contract, and more so when another organization operates them.
A2A defines that contract. An Agent Card describes what an agent offers and how to reach it. Messages carry conversational content, Tasks represent stateful work, and Artifacts carry results. Streaming and push notifications let a client follow work that outlives a single request.
MCP gives your agent access to a capability. A2A lets it delegate an outcome to another autonomous participant, which can run its own model and MCP tools without exposing any of that to the caller.
A2A 1.0 is stable and comes with several protocol bindings and SDKs. The release is recent, but its published contract is ready to implement.
4. AG-UI and A2UI: Interacting with Users
Most agents also interact with people. Their applications need streamed text, visible tool activity, shared state, frontend actions, and a way to pause for an approval, credential, or choice.
AG-UI standardizes the event stream between an agent backend and a user-facing application. Its event model covers run lifecycle, messages, tool calls, and state without prescribing whether the client is a browser, mobile app, terminal, or chat surface. The unratified 1.0 draft also defines how one run requests outside input and a later run resumes with the answer.
A2UI: what the application renders
Some agents also need to tell the client what to render. A2UI uses declarative component descriptions drawn from a client-owned catalogue, so the client can render native widgets without running arbitrary code from the agent.
A2UI and AG-UI are separate specifications for adjacent parts of the same boundary. AG-UI carries the interaction, while A2UI describes the interface. An A2UI payload can travel over AG-UI, A2A, or another transport.
AG-UI has multiple framework integrations, but its 1.0 specification remains unratified. A2UI 0.9.1 is current, and 1.0 remains a candidate.
5. Instructions, Skills, and Plugins: Packaging Capabilities
Connections do not give your agent domain knowledge. You cannot encode repository rules, company procedures, examples, scripts, and task-specific references in the model.
The filesystem is the simplest delivery layer: people and agents inspect and version the same content. Several formats build on it.
AGENTS.md: project instructions
AGENTS.md gives coding agents a predictable place to find build commands, test instructions, style rules, security constraints, and other repository guidance. A file at the repository root establishes the general instructions, while nested files can narrow them for individual projects or directories.
AGENTS.md is a plain Markdown convention, so coding agents can support it without another runtime service.
Agent Skills: knowledge loaded on demand
An Agent Skill packages a procedure or body of knowledge in a directory with a required SKILL.md and optional scripts, references, and assets. For discovery, the agent loads only the skill’s name and description. When the skill activates, it reads the full instructions and pulls supporting files as needed.
Progressive disclosure keeps domain knowledge and operational logic from crowding the base prompt. Authoritative business rules, permissions, and irreversible decisions should still live in tested code and policy systems, but a Skill can teach the agent how to apply them.
Plugin packaging
At this layer you choose between two plugin formats, but they package different things. Claude Code plugins are product-specific and can include skills, agents, hooks, MCP servers, LSP servers, monitors, and other Claude Code components. The Agent Plugins specification defines a smaller portable package: a root plugin.json, Agent Skills, and MCP server configuration.
Skills carry instructions and knowledge; MCP servers expose tools. Claude Code plugins are an established product feature. Agent Plugins 1.0 is published and backed by multiple client implementers, but cross-client portability remains to be proved.
6. OpenTelemetry GenAI: Tracing Agent Activity
Once your agent crosses several boundaries, you need to observe its behavior across all of them. OpenTelemetry provides vendor-neutral APIs and data models for traces, metrics, and logs. The OpenTelemetry GenAI semantic conventions extend that vocabulary to model calls, agent and workflow invocations, planning, tool execution, and MCP activity.
With those conventions, one trace connects an agent run to its model calls, tool executions, and MCP activity. The conventions define names and attributes for telemetry; communication and storage sit outside their scope.
OpenTelemetry itself is mature, but the GenAI semantic conventions as a whole remain marked Development. Pin the semantic-convention version because names and attributes can still change.
7. ACP: Connecting Coding Agents to IDEs
The final boundary is your editor. An IDE and coding agent need to initialize a connection, create and resume sessions, exchange prompts and progress, mediate permissions, and cancel work. ACP v2 recommends that the client provide MCP servers for the tools that run on the client side.
The Agent Client Protocol standardizes that development-time relationship using JSON-RPC 2.0. Capability negotiation lets an IDE and coding agent use a common core while adding optional functions only when both sides support them.
LSP gave editors one contract for working with many language servers. ACP aims to do the same for coding agents, although an agent’s stateful work and authority make the interaction richer than language tooling.
ACP v1 remains the stable protocol. ACP v2 is still an experimental draft, and its wire protocol can change incompatibly. Implementations that explore v2 should negotiate the protocol version and keep v1 compatibility where they need it. ACP’s scope remains the IDE-to-coding-agent boundary, distinct from AG-UI’s user-facing application boundary and MCP’s tool boundary.
Choose the Interfaces You Need
Treat these standards as independent boundary contracts. Adopt one at the point where you need to replace what sits on the other side of that boundary without rewriting your agent, and leave the rest alone until you hit that point.
The table below has more than seven rows because the UI and capability layers each contain several specifications.
The protocols, APIs, and formats defining how agents connect to models, tools, users, other agents, and development environments.
Model interface
Open Responses: the open, multi-provider model API specification.
Tools and remote agents
Model Context Protocol: the core agent-to-tool protocol.
MCP Apps: the MCP extension for interactive HTML interfaces.
Skills over MCP: the developing bridge between MCP and Agent Skills.
Agent2Agent Protocol: the protocol for discovery, delegation, and collaboration between independent agents.
User interfaces
AG-UI: the event protocol between agent backends and user-facing applications.
A2UI: the declarative format for agent-generated interfaces.
Instructions, knowledge, and packaging
AGENTS.md: the repository instruction-file convention for coding agents.
Agent Skills: the on-demand instruction, knowledge, script, and asset format.
Claude Code plugins: Anthropic’s product-specific plugin format.
Agent Plugins: the portable package format for Agent Skills and MCP servers.
Operational tools and IDEs
OpenTelemetry GenAI semantic conventions: the shared telemetry vocabulary for models, agents, tools, and MCP.
Agent Client Protocol: the protocol between coding agents and IDEs.
Other Specifications to Watch
I left these out of the core map for two reasons: they either describe an agent rather than connect it to one of the seven systems, or their boundary is still emerging. Most of them cover agent schemas, packages, or configuration.
Agentic Resource Discovery: a proposal for federated discovery of agents, MCP servers, Skills, plugins, APIs, and workflows.
Open Agentic Schema Framework: AGNTCY’s schema framework for agent capabilities, interactions, metadata, and discovery.
Open Agent Specification: Oracle’s declarative format for portable agents and workflows.
Agent Format: a published 1.0 declarative YAML format for agent identity, interfaces, tool and agent dependencies, constraints, and execution policy, stored as
.agf.yaml; official framework adapters are still planned..agents Protocol: a draft global and workspace directory convention that collects MCP server configuration, model and prompt settings, instructions, skills, sub-agent profiles, recurring tasks, and memories under
.agents/.Agent Definition Language: version 0.3.0 is marked Posted and covers agent identity, capabilities, permissions, security, lifecycle, and runtime requirements in
.adl.jsonor.adldocuments.AAuth: an adjacent authorization layer for cryptographic agent identity and delegated HTTP resource access. Its protocol is an active individual Internet-Draft whose current version defines four resource-access modes. It is not an IETF-endorsed standard, so treat it as work in progress.
WebMCP: a W3C Web Machine Learning Community Group Draft for exposing typed website capabilities to agents; it is not a W3C Standard.
👋 Found this useful? Like and restack it for other software engineers.
Starting with model access and adding the rest later is good advice. My worry is that a small team picks MCP for tools and then finds its vendor built something of its own instead. How often does that happen now?
Excellent map — the seven-boundaries framing finally makes the protocol soup legible. One gap I'd flag for the next edition: the protocols tell an agent what it can touch (MCP for tools, A2A for agent-to-agent), but almost nobody is standardizing what an agent must *record*. Permissions are being spec'd; audit trails aren't. An agent ecosystem with standardized access and no standardized accountability is a breach with good plumbing. Would love to see the provenance/auditability boundary get its own protocol.