Solutions
Patterns of Agentic AI Applications
An Interactive Assistant. A Scheduled Job. A Developer Harness. An External Service. Many agent applications are one of these, and all four are built from the same resources.
Application pattern
Interactive Assistant
Hundreds of people, one agent. A chatbot, a support copilot, an internal Q&A service. One deployed agent that many people talk to, where each person expects answers scoped to what they personally can see.
What makes it hard
Permissions collapse to the union
One agent serving everyone reaches everything anyone can reach, unless the caller's identity travels with the call.
Sub-agent hops lose the person
A supervising agent that calls other agents usually drops the caller at the first hop.
A permitted call can still overshare
Authorization decides whether the call runs. It does not decide what comes back in the rows.
Cost is per conversation
One session can fan out into dozens of tool and model calls. Budgeting per request tells you nothing.
How Dome is configured
Callers. Point Dome at your identity provider. Every request carries a verified subject before it becomes an identity.
Agents. Register the assistant with acts-as required, so a request with no verified person is refused.
Gateways. Compose the tools and model pools it may reach into one Gateway, then grant that Gateway to the agent.
Rules. Write conditions on the caller, not only the agent. The verified email is available in the rule.
Guards. Redact on the response path, so a permitted call cannot return fields this caller should not see.
Quotas. Cap the agent over a window. One runaway conversation cannot drain the workspace.
The pattern, wired
Each person is verified before they become a Caller, and that identity travels with the call. A Rule can name Priya rather than only the Agent she is talking to, and the Audit record names both. Identity does not collapse at the sub-agent hop, so the billing Agent cannot reach anything Priya could not.
Application pattern
Scheduled Job
Nobody is watching at 3am. A nightly report, an inbox triage worker, a webhook handler. A schedule or an event wakes it, it runs to completion, and it exits with no person in the loop.
What makes it hard
There is nobody to ask
No confirmation prompt, no human to approve an edge case. Every decision has to be made in advance.
Failure is silent
A bad run at 3am is discovered when somebody notices the output is wrong, which may be days.
Standing credentials are a target
A long-lived identity with no person behind it is the most valuable thing in the estate to steal.
Retry loops burn budget
An agent that retries a failing call overnight can spend a month's allowance before anyone wakes up.
How Dome is configured
Agents. Register with a standing identity. The agent is the principal, and there is no acts-as to assert.
Gateways. Grant a read-only Gateway holding only what the job needs. Anything outside it is unreachable.
Rules. Permit the specific operations and nothing else. Simulate against the last day of traffic before deploying.
Quotas. Bind spend to the agent over a window. The refusal lands in audit like any other decision.
Webhooks. Subscribe to denials and failures, filtered to this agent, and point them at your on-call channel.
Audits. Reconstruct a run in order afterwards. The chain walks agent, tool, model and outcome.
The pattern, wired
Nothing here acts for a person, so the containment has to be structural. The Agent holds a standing identity with a read-only Gateway grant, and a Quota binds spend to that Agent rather than to an API key. Every denial leaves on a signed Webhook, so when a run misbehaves at 3am the record reaches you before anyone asks.
Application pattern
Developer Harness
Cursor and Claude Code, on your account. An engineer reaching internal tools and models from the editor they already work in. The person is present and signed in, and the work happens on their machine.
What makes it hard
The shared robot problem
One API key for the team means the audit trail names the key. It never names the engineer.
Credentials end up in dotfiles
Provider keys and tool tokens spread across laptops, where rotation is a message in a channel.
Every editor has its own config
Cursor, Claude Code and Codex each need setting up, and each drifts from the others.
Tool output becomes chat history
Whatever a tool returns lands in the model context, and from there into a transcript.
How Dome is configured
Callers. Turn on interactive access. People sign in with their own Dome account from the editor, and no agent key is issued.
Gateways. One Gateway per environment, granted to the engineering group rather than configured per person.
Rules. Scope on the signed-in person, so their reach from the editor matches their reach everywhere else.
Guards. Filter secrets and personal data out of tool responses before they enter the model context.
Audits. Every call attributes to the engineer. Two editors produce one record.
The pattern, wired
Nobody holds an agent API key. Alex is a Caller in his own right, signed in from whichever editor he is using, so provider credentials stay server-side and the Audit trail attributes every call to him rather than to a shared robot. Two editors, one Gateway grant, one record.
Application pattern
External Service
Other people's agents, calling yours. An MCP surface on your product, or agentic features your customers drive. Their agents call your APIs, and your tenancy boundary is the only thing between them.
What makes it hard
Callers stopped being deterministic
Rate limits and API keys assume software that behaves the same way twice. An agent decides what to call at runtime.
Isolation is the whole product
One scoping mistake is a cross-customer data incident rather than a bug report.
Call shapes are unpredictable
One agent with many tools, agents spawning agents, long-lived sessions. Your contract described none of it.
Billing needs attribution
You cannot charge for or contain what you cannot attribute to a tenant.
How Dome is configured
Agents. Each customer agent registers under its own tenant and receives its own credential.
Gateways. A Gateway per tenant, exposing only the tools that tenant is entitled to.
Rules. Write once at tenant scope. Per-customer exceptions go in as overrides rather than forks.
Guards. Constrain arguments on the request path, so a malformed or hostile call is stopped before it runs.
Quotas. Ceilings per tenant. One customer's runaway agent stays one customer's problem.
Webhooks. Push per-tenant usage and denial events into your own billing and support systems.
The pattern, wired
Each tenant's agent registers under its own credential and gets its own Gateway, so the tools Acme can reach and the tools Globex can reach are configuration rather than a code path. Guards constrain arguments before a call runs, and a Quota per tenant keeps one runaway agent one customer's problem. Per-tenant usage and denials leave on signed Webhooks, ready to bill from.
The agentic estate
Consistent architectural patterns for AI
Businesses are embracing AI as consumers of its capabilities and to transform the services they provide. Agentic applications can also be defined as patterns comprising common resources.
Next steps
Go deeper
See the resources in detail, or the same shapes wired out in full with the policy on every hop.