AI Out · Pattern
The agents you ship as product
Your customers are wrapping your APIs into ad-hoc agents on behalf of their users. Your traffic profile is unrecognizable. Two surfaces to operate now: a developer-facing API and an agent-facing tool layer, with one backend underneath. Dome gives you the agent surface, with its own governance discipline.
Enterprise agents
Every customer is now an agent factory
The API surface designed for one developer per integration is now orchestrated by autonomous code on behalf of every customer. Rate limits and documentation do not help.
New customer workflows
Workflow tools wrap your APIs into ad-hoc agents. Single agent calls with 1:n tools, multiple agent calls each with their own tools, long-lived agent calls, spawning agent calls. The shapes your contract never anticipated.
Changing traffic profiles
Bursty, multi-step, cross-tenant, authored by non-developers. Hard to predict the number of agents, tool calls, or time to compute. Hard to predict the correctness or efficacy of individual solutions.
API gateways vs agent callers
API gateways were built for deterministic callers
An API contract assumes a deterministic caller: software you can reason about. Agentic callers are probabilistic. They will compose calls you didn't anticipate. They will retry on the wrong errors. They will pass user data into tool arguments in shapes your policy was never designed for.
| Dimension | API Gateway | Agents |
|---|---|---|
| Caller identity | API key per integration. One developer, one app. | One key fronts thousands of unique sessions |
| Authorization | Scope-based, static. Set at integration time. | Intent varies per call. Same scope, very different request. |
| Rate limiting | Per-key, per-second | Bursty, multi-step plans across many tool calls |
| Audit | Request logs. What was called. | “Why” is unanswerable without intent context |
| Response | Returned as-defined | Sensitive data leaks into agent context downstream |
The control points an API gateway gives you (auth, rate limits, schema validation) were designed for that older world. They control who can call what. They do not control what the caller is trying to do.
Agent provider
Shipping API and AI
APIs are not going away. What changes is that you operate two surfaces alongside each other: a developer-facing API surface, and an agent-facing tool surface. Same backend. Different governance discipline. The agent surface needs its own primitives.
| API surface | Agent surface | |
|---|---|---|
| Caller | Developer | Workflow runtime · Agent runtime |
| Contract | OpenAPI spec | MCP tool |
| Governance units | API key · Scope · Rate limit | Identity · Intent · Policy |
The agent surface is a first-class control point with its own identity model, policy language, and audit shape. Treating it as a thin wrapper over the API surface leaves most of the governance work undone.
With Dome
The agent surface, operated like infrastructure
Customer agents register against your tenant. Their tool calls flow through one gateway with policy, identity propagation, and audit at the boundary. The operational discipline you already have on the API side, applied to a surface that was never going to be served by the same primitives.
Connect
Customer agents and integration partners register against your tenant. Each one gets an identity. Each one becomes governable.
Secure
Every tool call is evaluated against policy. Intent is captured alongside the call. User identity propagates end-to-end so your backends know whose request this really is.
Operate
A queryable audit trail across every customer agent action. Policy versioned, testable, and rolled back through the same lifecycle as code.