The AI Agent Protocol Stack: A Map of the Layers

From text generation to autonomous agents — and the emerging protocol stack that makes multi-agent engineering possible.

The AI Agent Protocol Stack: A Map of the Layers

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).

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×M problem: connecting N clients to M data sources requires writing N×M unique adapters. Five models and ten tools turn into fifty hand-coded connectors that nobody wants to maintain.

Vendors and open-source projects are proposing several protocol families. Several protocols now target different parts of agent integration — 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.

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.

How to Read the Stack: Four Reference Layers

A layer model makes the differences easier to track — much like a network model. Any agent stack has four reference tiers, and each protocol lives on its own:

  • Model & Tool Level — how the model binds context, calls functions, and executes code.
  • Agent / Process Level — how agent state, planning, and execution loops are managed.
  • Inter-Agent Level — how multiple agents communicate, orchestrate, and divide tasks.
  • Data & Governance — how security, semantics, knowledge graphs, and access gateways are enforced.

The sections below go from model/tool integration to governance.

Layer 1. Model & Tool Level: Model and Tool Integration

The lowest tier is where the LLM meets context, functions, and executable code.

MCP (Model Context Protocol) — Anthropic

Scope: Unified connection of context, files, and tools to an LLM. Architectural Layer: Integration / Data Fabric.

An open standard from Anthropic, designed to reduce the N×M adapter problem — 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: stdio for local processes and SSE for network. The server declares three basic primitives:

  • Prompts — ready-made interaction templates declared by the server.
  • Resources — passive data for context (files, logs, API responses) that the client reads.
  • Tools — active executable functions with side effects.

Among the items listed here, MCP is one of the more mature and widely deployed. When to use: 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.

FCP (Function Calling) — OpenAI

Scope: Schema-constrained invocation of external functions at the model decoding level. Architectural Layer: Model Interface Layer.

A function-calling mechanism built directly into the OpenAI API (Chat Completions and Responses API). A function is described via JSON Schema with strict: true and additionalProperties: false, after which the server infrastructure compiles the schema into a decoding grammar. This provides two useful properties:

  • Constrained Decoding — is intended to enforce schema-compliant JSON of the generated JSON with the specified types right at the token sampling level (grammar masking, logit bias). Invalid structures are blocked by constrained decoding rather than fixed after generation.
  • Parallel Function Calling — in a single response, the model can generate multiple calls for parallel execution on the client.

Strictly speaking, this is not a standalone "protocol standard" but an API-integrated mechanism — but it fits the model-interface layer in this map. When to use: when output structure validity is critical (no "the model sometimes returns broken JSON") and you want multiple parallel calls in a single turn.

TAP / ATP (Tool Agent Protocol → Agent Tool Protocol) — LangChain Ecosystem

Scope: Standardization of external tool description and invocation. Architectural Layer: Execution & Tooling.

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 — 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 — for instance, a V8 VM. This has two practical effects:

  • Substantial context window savings — schemas are not duplicated on every turn.
  • Parallel execution of tool chains and data filtering directly in the sandbox, before sending the result back to the LLM.

When to use: 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.

Layer 2. Agent / Process Level: Agent Runtime and State Management

At this layer, the concern shifts from a single request to long-running agent state.

AgentOS — Proprietary Runtime Architectures

Scope: Lifecycle and resource management for long-lived agents. Architectural Layer: Runtime / Infrastructure.

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:

  • Execution Throttling & Rate Limiting — managing API limits (TPM/RPM) and dynamic token allocation.
  • Process Control — launching, suspending, state dumping (checkpointing), and recovering an agent when a node crashes.
  • Memory Paging — managing operational context (short-term) and paging to vector/relational stores (long-term memory).

In practice, this means runtime services for state, scheduling, limits, and recovery. When to use: 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.

TDF (Task Definition Format) — Stanford

Scope: Declarative description of complex composite tasks and execution graph optimization. Architectural Layer: Specification / Graph Planning.

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: 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.

Layer 3. Inter-Agent Level: Inter-Agent Communication and Orchestration

This layer covers coordination between multiple agents.

ACP (Agent Communication Protocol) — IBM / BeeAI

Scope: Enterprise-level inter-agent messaging. Architectural Layer: Application Layer (REST / Async HTTP).

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 (/agents, /runs, /sessions), and messages are transmitted as structured JSON packets with MIME-typed parts (text/plain, application/json, multimedia). Two notable features:

  • Async-First — support for long-lived tasks via SSE and pause/resume mechanisms (await_request).
  • Offline Discovery — discovering agent metadata and capabilities even with zero active pods (scale-to-zero).

When to use: 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.

A2A (Agent2Agent) — Google

Scope: Multi-agent cooperation, distributed orchestration, and role negotiation. Architectural Layer: Orchestration Layer.

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 — the protocol describes negotiation, task delegation, and role transfer. Key elements:

  • Role Capability Matrix — a formal description of an agent's competencies.
  • Shared Context Bus — end-to-end transfer of state and chains-of-thought with access segregation for private tokens.

A2A is widely discussed, but implementations and adoption should be checked case by case. When to use: when agents from different manufacturers need to coordinate roles, state, and subtasks across vendor boundaries — negotiate roles, delegate subtasks, and share common context.

OAP (Open Agent Protocol) — Open-Source Community

Scope: Decentralized agent discovery and routing. Architectural Layer: Network / Service Mesh.

A community standard for federated agent networks — federated agent networks. Two functions:

  • Agent Discovery — finding agents by their semantic profile through decentralized registries.
  • Inter-agent Routing — routing requests based on cost (cost-per-token), latency, and the target agent's reliability (SLA).

Treat OAP here as a category label unless referring to a specific implementation. When to use: 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.

Layer 4. Data & Governance: Data, Semantics, and Governance

The top tier is semantics, knowledge, and the perimeter. These concerns often appear only in production deployments.

RDF-Agent (Semantic Web) — W3C / Open Web

Scope: Knowledge graphs, semantic addressing, and logical inference. Architectural Layer: Knowledge Representation Layer.

An approach linking agent architectures to classic W3C standards — 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: 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.

AGP (Agent Gateways & Protocols) — Industry Standards

Scope: Security, transformations, authentication, and enterprise integration. Architectural Layer: Security & Enterprise Gateway.

An industrial class of protocols and gateways regulating the security perimeter when an agent exits into external corporate environments. Typical gateway functions include:

  • Identity & Access Management (IAM) — translating user tokens (OAuth2/OIDC) into restricted agent permissions (Delegated Authority).
  • Zero Trust Data Transformation — automatic masking of PII and secrets (API keys) in prompts before sending them to external LLM providers.
  • Policy Enforcement — real-time monitoring of agent actions with emergency process termination (Circuit Breaking) when the budget is exceeded or dangerous commands are detected.

This is not one protocol, but a class of gateways. When to use: when an agent exits the corporate perimeter — to translate user rights, keep secrets inside, and retain the ability to abort the process.

Summary Matrix

The table below groups the entries by layer:

Architectural Layer Protocols / Standards Core Task
Model & Tool Level MCP, FCP (OpenAI), TAP/ATP Context binding, function calling, code execution
Agent / Process Level AgentOS, TDF (Stanford) State management, planning, execution loops
Inter-Agent Level ACP (IBM), A2A (Google), OAP Communication, orchestration, task distribution
Data & Governance RDF-Agent, AGP (Industry) Security, semantics, knowledge graphs, access gateways

How to Use This in Practice

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:

  • Tool integration fails at the model interface — it duplicates schemas, consume too much context window, returns broken JSON. This is the Model & Tool Level: look at MCP (uniform tool access), FCP (strict output validity), TAP/ATP (sandboxed code execution).
  • The agent lives long and crashes — it loses state, hits limits, fails to recover after a crash. This is the Agent / Process Level: an AgentOS-class runtime, and for composite goals, declarative description in the spirit of TDF.
  • Multiple agents cannot coordinate reliably — they cannot negotiate, orchestration falls apart, role ownership is ambiguous. This is the Inter-Agent Level: ACP for HTTP linkage in the enterprise, A2A for negotiation and delegation between vendors, OAP for discovery and routing in a large network.
  • Data semantics and security controls — you need deterministic inference over an ontology or perimeter protection on exit. This is Data & Governance: RDF-Agent for knowledge graphs and precise queries, AGP for IAM, PII masking, and policy enforcement.

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?

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.

https://www.dobryakov.net/lead-magnets/ai-agent-protocol-stack.html?utm_source=None&utm_medium=None&utm_campaign=ai-agent-protocol-stack

Leave a Reply

Your email address will not be published. Required fields are marked *