What an ACP is not

An Agentic Control Plane occupies a distinct layer in the AI stack. It complements — not replaces — your existing infrastructure.

Not an LLM routing gateway

Tools like Portkey, LiteLLM, and OpenRouter focus on model selection and load balancing — routing prompts to the cheapest or fastest LLM provider.

An ACP doesn't choose which model to use. It sits between the LLM and your backend to enforce who can use it, what they're allowed to do, and whether the request complies with your policies. LLM gateways optimize cost and latency. An ACP enforces trust and control.

Use both: Route through your LLM gateway for model selection, then through your ACP for identity, policy, and audit.

Not an agent framework

LangChain, CrewAI, AutoGen, and similar frameworks help you build agents — defining tool chains, memory, reasoning loops, and orchestration.

An ACP doesn't build agents. It governs them. When your LangChain agent calls a tool, the ACP verifies the user's identity, checks authorization policies, enforces rate limits, and logs the action. The agent framework decides what to do. The ACP decides whether it's allowed.

Use both: Build your agent with any framework. Route its tool calls through your ACP for control.

Not a traditional API gateway

Kong, Apigee, and AWS API Gateway handle HTTP traffic management — routing, rate limiting, TLS termination, and basic auth.

Traditional API gateways don't understand the three-party problem. They can verify a token, but they can't bind LLM-forwarded requests to the originating user. They can rate-limit by IP, but not by verified user identity. They can log requests, but not attribute AI actions to specific people with policy context.

Use both: Your API gateway handles TLS, global rate limits, and routing. Your ACP handles identity binding, per-user policies, and AI-specific control.

Not a sandbox

Sandboxes — Docker and gVisor, micro-VMs, cloud execution environments, and the sandboxes built into coding harnesses — contain where agent code runs: an OS boundary around files, processes, and network on one host.

A sandbox has no opinion about actions made with valid credentials through legitimate channels. The agent that merges the wrong PR, emails the wrong customer, or deletes cloud resources with your own key does all of it through channels the sandbox correctly lets through. An ACP sits at the tool-call and model-call seam and decides each action by policy — allow, ask, or deny — with the decision logged and the cost metered.

Use both: the sandbox bounds the unauthorized — exploits, runaway code, filesystem blast radius. The ACP decides the authorized. Run the agent inside whatever sandbox you like, with the control plane in its call path. Why they compose →

Control that works across every model

Some platforms bundle control into a single model provider's ecosystem — identity, policy, and audit that only work with their models.

An ACP gives you one control layer for all of them — OpenAI, Anthropic, Google, Mistral, open-source, or your own fine-tune. Same identity binding, same policies, same audit trails, regardless of which model is behind the agent. Deploy in minutes, not months, with no vendor-specific deployment team required.

Why it matters: Your team already uses multiple models. Your control shouldn't break when you add another one.

DIY OAuth vs. purpose-built control plane

You can build identity and control yourself. Here's what that looks like compared to using your IdP's built-in features or adopting an Agentic Control Plane.

Feature comparison

See the reference implementation

GatewayStack implements the Agentic Control Plane as six composable npm modules. Open source, MIT licensed.