# What is an Agentic Data Plane? An agentic data plane is the execution layer for AI agents — LLM routing, tool execution, context, and orchestration. Distinct from the agentic control plane. # What Is an Agentic Data Plane? An **agentic data plane** is the execution layer for AI agents. It's everything that actually does the work an agent is asked to do: routing prompts to models, executing tool calls, reading from databases, writing to APIs, and streaming results back. It's distinct from the [agentic control plane](/what-is-an-agentic-control-plane), which decides *whether* an action is allowed and records *what happened*. In production AI infrastructure, you need both.
AGENTIC DATA PLANE Execution layer What actually does the work LLM routing OpenAI · Anthropic · local Tool execution MCP · fn calls · APIs Context management RAG · memory · history Streaming SSE · incremental tokens Orchestration multi-step flows · supervisor/worker · handoffs Typical products LangChain · LangGraph · CrewAI · LiteLLM · MCP servers every call crosses boundary AGENTIC CONTROL PLANE Control layer What decides whether work is allowed Identity JWT · OIDC · delegation chain Policy 3-axis ABAC · audit-only by default Content safety PII · secrets · injection scan Budget per-user · per-agent caps Audit structured · identity-attributed · compliance-ready Typical products ACP · agent gateways · NHI platforms
Two planes, distinct responsibilities. Every data-plane action crosses the boundary for control-plane evaluation.
--- ## The Short Version In classical networking and cloud infrastructure, the "data plane" moves packets, processes queries, and handles real-time traffic. The "control plane" configures policy, distributes routing tables, and coordinates state. Both planes exist in every serious system because they're load-bearing in different ways. AI agent infrastructure is evolving into the same split: - **Agentic data plane** → *executes* actions. LLM calls, tool invocations, context management, streaming responses, orchestration between agents. - **[Agentic control plane](/what-is-an-agentic-control-plane)** → *controls* actions. Identity verification, policy enforcement, content safety, budget caps, audit emission. If you've ever wondered why your "simple" agent deployment feels fragile — why control is hard to enforce, why audit trails are incomplete, why different agents have inconsistent security — the reason is almost always that you've built both planes in the same codebase, tangled together. --- ## What a Data Plane Does (Concretely) The agentic data plane is responsible for: **LLM routing and model selection.** Choosing which provider gets the prompt (OpenAI, Anthropic, Google, a local model), handling failover, optimizing for cost or latency, applying prompt templates. This is the work of products like [LiteLLM, Portkey, OpenRouter, and LLM gateways](/blog/why-api-gateways-dont-solve-ai-governance). **Tool execution.** When the model emits a `tool_use` block, something has to actually run the tool — make the HTTP request, execute the database query, read the file. MCP servers, agent frameworks (LangChain, LangGraph, CrewAI, AutoGen), and custom tool dispatchers all live here. **Context management.** Building the prompt, retrieving relevant documents (RAG), maintaining conversation history, managing memory across turns. Vector databases, retrievers, and memory systems are data-plane components. **Response streaming.** Delivering the model's tokens to the end user or to the next agent in a chain, without buffering the full response. **Orchestration and workflow.** Multi-step agent flows, chain-of-thought, sub-agent coordination, handoffs. A LangGraph supervisor-and-workers pattern, a CrewAI crew, an OpenAI Agents SDK handoff — these are all data-plane orchestration patterns. What the data plane does *not* decide: whether the action should be allowed, who's responsible, whether the data crossing it is sensitive, or whether the right user's identity is attached. Those are control-plane questions. --- ## Why the Split Matters Three reasons. **1. Control gets enforced inconsistently if every data-plane product owns its own policy.** If your LangChain deployment has its own allow-list, your MCP server has another one, and your custom workflow tool has a third, then you have three places to keep in sync. The moment an engineer adds a new integration, that integration either re-implements policy or skips it. That's how production AI systems end up with "the Claude instance has audit but the Cursor instance doesn't." A dedicated control plane solves this by living at the trust boundary between the data plane and your real backend systems. Every data-plane execution path — whether it's LangGraph, CrewAI, Claude Desktop, or a hand-rolled Python script — flows through the same control pipeline. **2. Audit evidence is useless if it's per-tool and per-framework.** SOC 2 auditors, HIPAA compliance reviewers, and EU AI Act Article 14 assessors don't want to log into five different observability tools. They want one evidence trail per user action, showing who did what, with what authorization, when, and whether any policy layer denied anything. A data-plane-only architecture produces fragmented audit. A control-plane architecture produces unified [AI agent audit trails](/blog/ai-agent-audit-trails). **3. Agent-to-agent delegation requires both planes to coordinate.** When agent A delegates to agent B, the data plane handles the transport (the MCP call, the handoff, the A2A protocol exchange). But "can agent B actually do this on behalf of the human who started agent A?" is a control-plane question — and a hard one. It requires [delegation chain](/what-is-an-agent-delegation-chain) primitives with scope intersection, budget propagation, and cycle detection. See [agent-to-agent governance](/agent-to-agent) for the ACP approach. --- ## The Agentic Data Plane Ecosystem
AGENTIC DATA PLANE ECOSYSTEM LLM gateways routing · failover · caching LiteLLM · Portkey · OpenRouter Agent frameworks orchestration · tool loops LangChain · LangGraph · CrewAI Agent SDKs skills · handoffs · guardrails OpenAI Agents · Claude Agent SDK Orchestration runtimes stateful workflows Temporal · Airflow · custom MCP clients user-facing tool execution Claude Desktop · Cursor · Cline MCP servers expose tools to agents filesystem · GitHub · Slack · custom Coding agent CLIs terminal-driven agents Claude Code · Codex Vector DBs · RAG context retrieval Pinecone · Weaviate · pgvector TRUST BOUNDARY — every data-plane call must pass through identity verification · policy enforcement · content safety · audit emission AGENTIC CONTROL PLANE one control layer for every data-plane product in your stack
Every data-plane category is complementary to the control plane. Control is consistent regardless of which data-plane products you use.
## Common Agentic Data Plane Products | Category | Examples | |---|---| | LLM gateways | LiteLLM, Portkey, OpenRouter, Kong AI Gateway | | Agent frameworks | LangChain, [LangGraph](/integrations/langgraph), [CrewAI](/integrations/crewai), [OpenAI Agents SDK](/integrations/openai-agents-sdk), [Anthropic Agent SDK](/integrations/anthropic-agent-sdk), AutoGen | | MCP servers / clients | [Claude Desktop](/integrations/claude-desktop), [Cursor](/integrations/cursor), [Claude Code](/integrations/claude-code), [Cline](/integrations/cline), [Codex CLI](/integrations/codex), custom MCP servers | | Vector DBs / retrievers | Pinecone, Weaviate, Chroma, pgvector | | Orchestration runtimes | Temporal, Airflow, custom state machines | These are all valuable — and all data-plane. None of them is a substitute for control-plane policy. [Agentic Control Plane](/what-is-an-agentic-control-plane) is designed to control any data plane without replacing it. --- ## How the Two Planes Interact
DATA PLANE Agent framework CONTROL PLANE ACP control pipeline BACKEND Salesforce · GitHub · DB 1 Agent emits tool_use database.query · salesforce.update · github.pr POST /govern/tool-use 2 7-layer pipeline runs ✓ identity verified ✓ policy evaluated ✓ PII scanned ✓ budget checked { decision: allow | deny, reason } 3 if allowed → execute 4
Every tool call is round-tripped through the control plane before execution. Audit is emitted whether allowed or denied.
Every action in a production AI system crosses the boundary between the two planes twice: 1. **Data plane decides to do something** — e.g., the agent emits `tool_use: { name: "database.query", input: { sql: "..." } }`. 2. **Control plane evaluates** — is the caller identified? Is this tool in scope? Is the SQL within policy? Is the user within budget? Does any PII need to be redacted? 3. **Control plane returns allow/deny/transform** — with a reason. 4. **Data plane executes** (if allowed) or surfaces the denial (if not). 5. **Control plane emits audit** — the record of what happened, with full identity and policy context. Think of the control plane as the clerk at the bank counter. The data plane is the parrot with the account number. The parrot repeats what it heard; the clerk verifies *who actually asked* before letting anything move. See the [Three-Party Problem explainer](/what-is-an-agentic-control-plane#the-three-party-problem) for why this pattern is foundational. --- ## Data Plane vs Control Plane — Side by Side | | Agentic Data Plane | [Agentic Control Plane](/what-is-an-agentic-control-plane) | |---|---|---| | Primary job | Execute actions | Control actions | | Owns | Model calls, tool execution, streaming, orchestration | Identity, policy, audit, budget, safety | | Examples | LangChain, CrewAI, Portkey, MCP servers | ACP, Astrix, Aembit-style NHI platforms | | Failure mode if missing | Nothing happens | Everything happens unsafely | | Auditable | Usually per-product | Unified across all data planes | | Scales via | Horizontal replicas, caching, model-routing | Central policy + distributed enforcement | --- ## When You Need a Dedicated Data Plane Most teams start with an implicit data plane — whatever framework they picked. That's fine for prototypes. The signals that you need to start treating the data plane as a first-class layer: - You're running more than one LLM provider and need failover or cost routing - You have more than one MCP server or agent framework in production - You need to swap models without code changes - You want centralized observability across multiple orchestration products - You need to scale the tool-execution layer independently of the control layer If any two of those apply, consider a dedicated LLM gateway or MCP proxy for the data plane. Then put a [control plane](/what-is-an-agentic-control-plane) in front of it so the control layer is consistent regardless of which data-plane product you use. --- ## Related Reading - [Agentic Data Plane vs Agentic Control Plane](/blog/agentic-data-plane-vs-agentic-control-plane) — the deeper comparison - [Why API Gateways Don't Solve AI Governance](/blog/why-api-gateways-dont-solve-ai-governance) — why a traditional data-plane tool isn't enough - [MCP Gateway Comparison](/blog/mcp-gateway-comparison) — the MCP-specific data-plane landscape - [What is an Agentic Control Plane?](/what-is-an-agentic-control-plane) — the control counterpart - [Reference Architecture](/reference-architecture) — how the hook and gateway sit at the data-plane/control-plane boundary --- ## FAQ **Is an agentic data plane the same as an LLM gateway?** Close but not identical. An LLM gateway is one *component* of the agentic data plane — the part that routes and manages model calls. The data plane also includes tool execution, context management, and orchestration, none of which an LLM gateway typically handles. **Can I have a control plane without a data plane?** No. The data plane is where execution happens. A control plane alone has nothing to control. What you can have is the data plane tangled into application code (most startups) vs a dedicated data-plane product (most scaled teams). **Is MCP a data plane or a control plane?** MCP is a protocol specification that describes how clients and servers expose and invoke tools. Most MCP deployments are data-plane components — they execute tool calls. A control plane can sit in front of MCP servers (see [MCP control plane](/what-is-an-mcp-control-plane) and [MCP audit gap](/blog/mcp-audit-gap)) to enforce policy. **Is CrewAI a data plane?** Yes. [CrewAI](/integrations/crewai) is an agent framework — it orchestrates LLM calls, tool invocations, and multi-agent handoffs. It's a data-plane component. [Control layers on top](/integrations/crewai) via the control plane. **Does my team need both planes from day one?** No. Early-stage projects usually conflate them — the agent framework plays both roles. The moment you hit production scale, regulated industries, multi-framework deployments, or need for agent-to-agent control, splitting them out becomes high-leverage. **What's the difference between an agentic data plane and an AI gateway?** "AI gateway" is a marketing term that usually refers to an LLM-routing product (Portkey, Kong AI Gateway, NeuralTrust, LiteLLM). AI gateways are a *subset* of data-plane capability — they handle model routing and some safety features, but don't typically handle tool execution, agent orchestration, or agent-to-agent delegation. They also don't handle identity attribution or delegation-chain control. **How does this relate to the Forrester Agent Control Plane market evaluation?** Forrester's upcoming market evaluation is focused on the **agent control plane** — the control layer, not the execution layer. Agentic data plane products (frameworks, LLM gateways, MCP runtimes) may be adjacent but aren't the same category.