Since 2022, systems built on large language models have moved from "generate a paragraph" to autonomous agents. In production, an AI agent usually wraps an LLM with tool calls, state, and orchestration. It is an autonomous module that combines three capabilities: planning (breaking a goal into steps), memory (short-term in context, long-term in external stores), and execution (calling APIs, writing files, triggering other services).<\/p>\n
In production deployments, teams run into interface fragmentation. The model lives in one place, the tools in another, other agents elsewhere, and the corporate security perimeter somewhere else entirely. All of these must be wired together. The classic formulation of this pain is the N\u00d7M problem: connecting N clients to M data sources requires writing N\u00d7M unique adapters. Five models and ten tools turn into fifty hand-coded connectors that nobody wants to maintain.<\/p>\n
Vendors and open-source projects are proposing several protocol families. Several protocols now target different parts of agent integration \u2014 specifications that each take over a specific piece of the wiring: how the model reaches a tool, how an agent lives in time, how two agents negotiate, how data safely crosses the perimeter. Below is a breakdown of ten such protocols and standards, grouped by architectural layer.<\/p>\n
<\/p>\n
Caveat: these entries are not equally mature. Not all ten entries are equally mature. Some are real, widely discussed, and already deployed standards (MCP, A2A, ACP, OpenAI function calling). Others are umbrella terms for a class of problems rather than a single ratified protocol (AgentOS, TDF, OAP, AGP). That matters because some names below refer to deployed APIs, while others describe categories, and knowing what sits where is more useful than pretending we have ten finished specifications.<\/p>\n
A layer model makes the differences easier to track \u2014 much like a network model. Any agent stack has four reference tiers, and each protocol lives on its own:<\/p>\n
The sections below go from model\/tool integration to governance.<\/p>\n
The lowest tier is where the LLM meets context, functions, and executable code.<\/p>\n
Scope:<\/strong> Unified connection of context, files, and tools to an LLM. Architectural Layer:<\/strong> Integration \/ Data Fabric.<\/p>\n An open standard from Anthropic, designed to reduce the N\u00d7M adapter problem \u2014 so you do not write a unique adapter for every data source. Architecturally, it is a client-server model over JSON-RPC 2.0 with two transports: Among the items listed here, MCP is one of the more mature and widely deployed. When to use:<\/strong> when you need to uniformly connect many heterogeneous sources and tools to the model without writing separate one-off integrations. MCP gives you one contract instead of dozens of adapters.<\/p>\n Scope:<\/strong> Schema-constrained invocation of external functions at the model decoding level. Architectural Layer:<\/strong> Model Interface Layer.<\/p>\n A function-calling mechanism built directly into the OpenAI API (Chat Completions and Responses API). A function is described via JSON Schema with Strictly speaking, this is not a standalone "protocol standard" but an API-integrated mechanism \u2014 but it fits the model-interface layer in this map. When to use:<\/strong> when output structure validity is critical (no "the model sometimes returns broken JSON") and you want multiple parallel calls in a single turn.<\/p>\n Scope:<\/strong> Standardization of external tool description and invocation. Architectural Layer:<\/strong> Execution & Tooling.<\/p>\n A protocol for agent interaction with tools and execution environments. In the LangChain\/LangGraph ecosystem, it standardizes the abstractions of Runs, Threads, and Store, and is evolving into ATP \u2014 a protocol for secure code execution. The goal is to reduce token usage from repeated tool schemas: instead of re-injecting JSON schemas for every function into the context on every turn, TAP\/ATP translates tool metadata and lets the agent generate strict executable code (TypeScript\/Python) inside an isolated sandbox \u2014 for instance, a V8 VM. This has two practical effects:<\/p>\n When to use:<\/strong> when there are many tools, their schemas consume too much context window, and part of the logic (filtering, aggregation) is cheaper to execute as code in a sandbox rather than routing through the model.<\/p>\n At this layer, the concern shifts from a single request to long-running agent state.<\/p>\n Scope:<\/strong> Lifecycle and resource management for long-lived agents. Architectural Layer:<\/strong> Runtime \/ Infrastructure.<\/p>\n The term AgentOS does not denote a single standard, but a class of specialized execution environments (usually inside enterprise platform products) that abstract hardware and software for agent systems. The functional stack here is infrastructural:<\/p>\n In practice, this means runtime services for state, scheduling, limits, and recovery. When to use:<\/strong> when the agent runs for a long time and must survive failures. The runtime must define recovery behavior if a node drops in the middle of a three-hour task while the token budget is running out.<\/p>\n Scope:<\/strong> Declarative description of complex composite tasks and execution graph optimization. Architectural Layer:<\/strong> Specification \/ Graph Planning.<\/p>\n A specification that grew out of research on agent graphs and planning. It defines a strict declarative format (usually YAML or JSON-LD) for describing the target system state, input\/output contracts, and the dependency graph (DAG). The point is to compile a high-level goal into an optimized execution graph: distributing subtasks among specialized agents and minimizing the total number of LLM calls. This is currently closer to a research format than an industry standard. When to use:<\/strong> when a task is composite and multi-step, and it is cheaper to describe it declaratively (what the outcome should be and in what order) and let an engine compile the optimal plan, rather than hardcoding the call chain by hand.<\/p>\n This layer covers coordination between multiple agents.<\/p>\n Scope:<\/strong> Enterprise-level inter-agent messaging. Architectural Layer:<\/strong> Application Layer (REST \/ Async HTTP).<\/p>\n Developed under the BeeAI initiative under the auspices of the Linux Foundation. It provides a vendor-neutral HTTP interface for linking agents written in different languages and frameworks (LangChain, CrewAI, custom environments). Mechanics: an agent is abstracted into a set of REST endpoints ( When to use:<\/strong> when you need to link heterogeneous agents over plain HTTP within an enterprise, with long-lived tasks and the ability to discover agents even when they are not spun up.<\/p>\n Scope:<\/strong> Multi-agent cooperation, distributed orchestration, and role negotiation. Architectural Layer:<\/strong> Orchestration Layer.<\/p>\n An open protocol for horizontal interaction between autonomous systems from different vendors. Its distinguishing feature is the semantics of task delegation: agents exchange not just text, but declarative expectations about the work to be done \u2014 the protocol describes negotiation, task delegation, and role transfer. Key elements:<\/p>\n A2A is widely discussed, but implementations and adoption should be checked case by case. When to use:<\/strong> when agents from different manufacturers need to coordinate roles, state, and subtasks across vendor boundaries \u2014 negotiate roles, delegate subtasks, and share common context.<\/p>\n Scope:<\/strong> Decentralized agent discovery and routing. Architectural Layer:<\/strong> Network \/ Service Mesh.<\/p>\n A community standard for federated agent networks \u2014 federated agent networks. Two functions:<\/p>\n Treat OAP here as a category label unless referring to a specific implementation. When to use:<\/strong> when there are many agents on the network and you need a mechanism that finds the right one and routes the request based on price, latency, and reliability.<\/p>\n The top tier is semantics, knowledge, and the perimeter. These concerns often appear only in production deployments.<\/p>\n Scope:<\/strong> Knowledge graphs, semantic addressing, and logical inference. Architectural Layer:<\/strong> Knowledge Representation Layer.<\/p>\n An approach linking agent architectures to classic W3C standards \u2014 RDF, OWL, SPARQL. Data and agent capabilities are described as a Linked Data graph, and the agent uses SPARQL for precise, deterministic queries to enterprise knowledge graphs. The main benefit is reducing unsupported relationship inference by using explicit ontologies: logical inference relies on strict ontologies rather than the model's statistical guesswork. When to use:<\/strong> in financial, legal, and medical contexts, where unsupported links between facts can create legal, financial, or clinical risk, and deterministic, verifiable inference over an ontology is required.<\/p>\n Scope:<\/strong> Security, transformations, authentication, and enterprise integration. Architectural Layer:<\/strong> Security & Enterprise Gateway.<\/p>\n An industrial class of protocols and gateways regulating the security perimeter when an agent exits into external corporate environments. Typical gateway functions include:<\/p>\n This is not one protocol, but a class of gateways. When to use:<\/strong> when an agent exits the corporate perimeter \u2014 to translate user rights, keep secrets inside, and retain the ability to abort the process.<\/p>\n The table below groups the entries by layer:<\/p>\n Use the map to identify the layer where a problem belongs. It is being able to quickly locate the right layer and protocol for a specific engineering problem. A practical heuristic: determine the layer first, then the protocol:<\/p>\n A symptom visible in model behavior may originate in runtime, orchestration, or governance. So the first question to ask when designing or debugging an agent system is: which layer owns this failure mode?<\/p>\n The stack is still evolving. But its outline is already visible, and the ability to map any agent task across these four tiers is a useful way to avoid ad hoc adapter work and design the integration boundary deliberately.<\/p>\n https:\/\/www.dobryakov.net\/lead-magnets\/ai-agent-protocol-stack.html?utm_source=None&utm_medium=None&utm_campaign=ai-agent-protocol-stack<\/p>\n","protected":false},"excerpt":{"rendered":" From text generation to autonomous agents \u2014 and the emerging protocol stack that makes multi-agent engineering possible.<\/p>\n","protected":false},"author":0,"featured_media":124,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[113,114],"tags":[116,26,117,118,27,115],"class_list":["post-125","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-architecture","category-engineering","tag-a2a","tag-ai-agents","tag-architecture","tag-enterprise-ai","tag-mcp","tag-protocols"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tstdio<\/code> for local processes and SSE for network. The server declares three basic primitives:<\/p>\n\n
FCP (Function Calling) \u2014 OpenAI<\/h3>\n
strict: true<\/code> and additionalProperties: false<\/code>, after which the server infrastructure compiles the schema into a decoding grammar. This provides two useful properties:<\/p>\n\n
TAP \/ ATP (Tool Agent Protocol \u2192 Agent Tool Protocol) \u2014 LangChain Ecosystem<\/h3>\n
\n
Layer 2. Agent \/ Process Level: Agent Runtime and State Management<\/h2>\n
AgentOS \u2014 Proprietary Runtime Architectures<\/h3>\n
\n
TDF (Task Definition Format) \u2014 Stanford<\/h3>\n
Layer 3. Inter-Agent Level: Inter-Agent Communication and Orchestration<\/h2>\n
ACP (Agent Communication Protocol) \u2014 IBM \/ BeeAI<\/h3>\n
\/agents<\/code>, \/runs<\/code>, \/sessions<\/code>), and messages are transmitted as structured JSON packets with MIME-typed parts (text\/plain<\/code>, application\/json<\/code>, multimedia). Two notable features:<\/p>\n\n
await_request<\/code>).<\/li>\nA2A (Agent2Agent) \u2014 Google<\/h3>\n
\n
OAP (Open Agent Protocol) \u2014 Open-Source Community<\/h3>\n
\n
Layer 4. Data & Governance: Data, Semantics, and Governance<\/h2>\n
RDF-Agent (Semantic Web) \u2014 W3C \/ Open Web<\/h3>\n
AGP (Agent Gateways & Protocols) \u2014 Industry Standards<\/h3>\n
\n
Summary Matrix<\/h2>\n
\n\n
\n \nArchitectural Layer<\/th>\n Protocols \/ Standards<\/th>\n Core Task<\/th>\n<\/tr>\n<\/thead>\n \n Model & Tool Level<\/td>\n MCP, FCP (OpenAI), TAP\/ATP<\/td>\n Context binding, function calling, code execution<\/td>\n<\/tr>\n \n Agent \/ Process Level<\/td>\n AgentOS, TDF (Stanford)<\/td>\n State management, planning, execution loops<\/td>\n<\/tr>\n \n Inter-Agent Level<\/td>\n ACP (IBM), A2A (Google), OAP<\/td>\n Communication, orchestration, task distribution<\/td>\n<\/tr>\n \n Data & Governance<\/td>\n RDF-Agent, AGP (Industry)<\/td>\n Security, semantics, knowledge graphs, access gateways<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n How to Use This in Practice<\/h2>\n
\n