Capability is no longer the bottleneck. Governance is.

I've spent much of my career building developer platforms and API products. At Shutterstock I helped evaluate several API gateways before we chose Apigee. The decision looked like an infrastructure choice. It turned out to be a business one.

Internal traffic was the entry point

What stood out about Apigee was that managing internal API traffic was only where you started. The larger opportunity was helping business and platform teams turn capabilities into products: packaging them, controlling who could call them, measuring usage, and supporting commercial models the company had not tried before.

Internal governance came first, and it mattered. Every team that exposed something through the gateway got the same identity, the same policy, the same metering, the same record. That discipline is what made the next step possible.

The next step was opening those governed APIs to other companies' developers. The business and Platform Solutions teams did the hard work of building, selling, and operating those products. The API offerings we ran through the gateway grew from more than $10 million in annualized revenue in the first year to more than $100 million within three years.

The gateway did not create that demand. It gave the teams a controlled way to operate and scale it. That is the sentence I keep coming back to.

Agents are not APIs

That experience shapes how I think about agents, and the first thing it tells me is that the analogy only goes so far.

An API exposes a predefined capability through a fixed contract. You know what it does before you call it.

An agent interprets intent, makes decisions, selects tools, keeps state, and acts with delegated authority. It may reach through HTTP, MCP, a browser, another agent, a payment system, or production infrastructure. You know what it was asked to do. You find out what it did afterward.

That difference is why the gateway category is splitting into layers rather than producing one winner.

Four layers, four boundaries

• Agent gateway How an agent is invoked and how it reaches models, tools, systems, and other agents. Carries identity, authority, and policy across the call and leaves a receipt.
• MCP gateway Tool layer. Which tools an agent can discover and use, with what credentials, and a record of every tool call.
• LLM gateway Model layer. Access, providers, reliability, guardrails, token budgets, and cost for each model call.
• Model router One endpoint for many models and providers. Which model serves this request, at what price.

stateful, long-lived workflowsstateless request and response

A model router, such as OpenRouter, gives developers one way to reach many models and providers. It answers "which model serves this request, at what price."

An LLM gateway manages model calls: access, providers, reliability, and guardrails. It sits between an application and the model.

An MCP gateway governs access to tools exposed through MCP. It sits between an agent and the things it can use.

An agent gateway sits at a different boundary. It governs how an agent is invoked and how its interactions cross into models, tools, systems, and other agents. It does not need to own the agent runtime or store the agent's memory. It does need to carry identity, authority, and policy across the interaction, and leave a receipt that someone else can verify.

The questions it has to answer are concrete:

• Who is the agent acting for?
• What authority was it given?
• Does the proposed action match that authority?
• What can it access?
• What happened, and what did it cost?
• Can the interaction be verified afterward, by someone who was not there?

The last one is the one the other layers do not ask. Logs say what the operator claims happened. A receipt is something the other party can check.

The immediate value is operational

For most teams the first value is unglamorous and real: inventory, ownership, controlled access, credential isolation, policy, reliability, and usage across the agents they already run. Different teams already use different agents, in different tools, with credentials that live in too many places. Putting one governed path in front of that traffic is the same move as putting an API gateway in front of internal services. It is where you start.

That same layer then gives business and platform teams what they need to decide which agents are ready for broader use, who may invoke them, how outcomes are measured, and which capabilities can be offered to partners. That is the second rung, and it is the one that started to matter commercially at Shutterstock.

Where this is headed

Here is where it gets interesting, and where the Apigee analogy earns its keep.

The way companies do business is going to change shape. Specialized knowledge and value are going to be exchanged from one governed agent to another, the way they moved from one company's governed APIs to another company's developers a decade ago. The consuming party will not be a developer reading documentation. It will be an agent, acting for a company, with its own authority and its own budget.

On the offering side, a company's agent will assemble the right mix of what the company has inside. Some of that is symbolic: rules, contracts, and policy that must hold exactly. Some of it is deterministic: services and data with fixed behavior. Some of it is neural: models that interpret, draft, and decide under uncertainty. The agent's job is to compose those into the right resource for the agent on the other side, under terms both companies can enforce, with a receipt both can verify.

That is the difference from the API era, and it is also the continuity with it. Internal governance was necessary at Shutterstock, but it was not what grew the business. Opening governed capabilities to outside consumers was. The same sequence is about to run again, with agents on both ends of the call.

Internal governance is the ticket in. Agent-to-agent commerce is the reason to buy it.

The thesis behind Zerker

That is the thesis behind Zerker Gateway: govern agents for your workforce first, then partners, then customers and their agents, with a provable receipt for every call built into the core. Capability is no longer the bottleneck in agentic AI. Governance is.

Model routers route inference.
LLM gateways govern model calls.
MCP gateways govern tool access.
Agent gateways govern agency.