Architecture

Dome governs how AI agents access tools and models. The following components decide what happens to each request. For a high-level platform overview, start with What is Dome?.

​

High-level overview

Dome architecture separates into three kinds of concept: the components you define, the controls you apply to them, and the audit that records what happened. The control plane is where you configure those components and controls and sync that configuration. The data plane is where requests are enforced on the hot path. Components are what you define in the control plane:

• Agents identify the applications and automated processes making requests.
• Resources are the tools, model connections, and model pools exposed through Dome.
• Gateways group resources behind named endpoints and control which agents can reach them.

Controls are what you apply to components to govern traffic:

• Rules authorize what an agent may do after reaching a Gateway.
• Guards inspect request and response content before it reaches its destination.
• Quotas cap what an agent can spend on model calls over a window.

Audit events record every request’s outcome across control-plane changes and data-plane decisions, so you can review or investigate it later. Within a workspace, these concepts have the following relationships: An agent reaches a Gateway through an access grant, then reaches the tools, model pools, and model connections behind it through membership. On every call that passes through the data plane, Rules, Guards, and Quotas govern the traffic, and Audit logs the outcome. The access grant, membership, and rule are three separate checks, and all three must allow the request:

​

Agents

An agent is an identity in Dome. It represents the application, assistant, or automated process making a request. Dome does not run the agent. An agent authenticates each request with an API key or a short-lived agent token. The credential identifies the agent, but it does not contain the agent’s permissions and is not bound to a specific Gateway. Each agent can have one or more API keys. Because identity is independent from the endpoint, you can use the same agent credentials with multiple Gateways, as long as the agent has access to each Gateway. Refer to Agents concept for how identity works across Gateways.

​

Resources

A resource is something an agent can call through Dome. Dome supports three resource types:

1. Tools are MCP servers, local processes over stdio, or catalog-backed tool integrations.
2. Model connections point to LLM providers such as Anthropic, OpenAI, Google, or a self-hosted runtime.
3. Pools group model connections and add routing, weighting, and failover.

Refer to Resources concept for how backends are modeled, and Tools concept, Models concept, and Pools concept for each type.

​

Gateways

A Gateway is a named logical access surface in Dome. Each Gateway packages a selected set of resources behind an endpoint and defines which agents may use it. A Gateway is not a separately deployed data-plane process. A Gateway can contain many resources, and the same resource can belong to more than one Gateway. A registered resource that belongs to no Gateway is Unreachable. A Gateway exposes both tools and models through different protocol endpoints:

• Tools use /gateways/<id>/mcp
• Models and model pools use /gateways/<id>/v1/...

For a model call, the request can target a direct model connection or a model pool. Configured routing can also select a matching or default pool. A direct model connection must be a member of the Gateway. When a pool is selected, Dome chooses one of its model connections. Tools and models do not have to share a Gateway. You can use different Gateways for different jobs, as long as each Gateway grants that agent access and Rules permit each request. An access grant gives an agent permission to use a Gateway. A Gateway can also grant access to every agent in its workspace.

​

Rules

An access grant and membership get the request to the resource. A rule then controls what the agent may do once it’s there, deciding tool calls and model calls the same way. Cedar, the default rule engine, evaluates the agent, requested action, resource, and request context, and denies the request by default when no rule matches. Dome combines rules from organization, tenant, workspace, and agent scopes. Rules can permit access to one tool while forbidding another, even when both belong to the same Gateway. Dome fails closed if it can’t verify current policy, rather than falling back to a stale or default configuration.

​

Guards

Guards inspect content in both directions. Request Guards inspect prompts or tool arguments before Dome calls the resource. Response Guards inspect model output or tool results before content returns to the agent. Guards use ordered, connection-specific Filters. A Filter can redact, omit, or block matching content. Dome fails closed when an assigned Filter cannot be evaluated, rather than forwarding uninspected traffic. Refer to Guards concept for the model and Configure Guards for configuration.

​

Quotas

Quotas cap spend on model calls. Each Quota sets a budget over a window at a chosen scope: workspace, agent, Gateway, pool, model, or verified end user. Dome checks applicable Quotas before it authorizes the call. An exhausted total cap rejects the request. An exhausted per-model budget can spill to another member of the pool. Refer to Quotas concept for the model and Set Usage Limits for configuration.

​

How requests move through Dome

Every request passes through Dome before it reaches a tool or model. Dome identifies the agent, enforces access and authorization, applies request Guards, calls the resource with protected backend credentials, and applies response Guards before returning content. Tool discovery follows the same core model. Tools blocked by Rules are omitted from the catalog. Other access or operational failures can return an empty catalog or deny the request. If a model produces a tool call, the model does not invoke the tool itself. The agent runtime receives the tool request and makes a second call through the Gateway’s MCP endpoint. The model call and tool call are separate requests governed with the same agent identity.

​

Workspaces and isolation

An organization is a company’s top-level account. It contains one or more tenants, hard isolation boundaries usually drawn around a business unit or product line, such as a Commerce tenant kept separate from a Support tenant. Each tenant holds workspaces that scope day-to-day work, such as separate production and staging workspaces for the same team. Agents, resources, Gateways, Rules, Guards, Quotas, and audit events all live inside a workspace. Dome enforces tenant and workspace boundaries on every configuration and runtime request, so nothing scoped to one workspace leaks into another.

​

Next steps

With the component and request-path model in mind, continue with:

• Scopes concept for organization, tenant, and workspace isolation
• Agents concept, Resources concept, and Gateways concept for the components you define
• Rules concept, Guards concept, and Quotas concept for the controls on each request
• Audit events concept for the evidence trail
• Data plane concept for fail-closed runtime placement