What is AI agent infrastructure? The runtime and gateway layers

AI agent infrastructure is the runtime an agent loop runs on plus the gateway primitives it acts through, with policy enforced at every tool call. A map of the nine categories.

The problem the category exists to solve

Most teams find out they need agent infrastructure the same way. The demo loop works. Then the first real task needs a browser login, an inbox that receives replies, a card with a cap, a run that survives a restart, and a way to stop everything at 2 a.m. without redeploying.

A model API returns tokens. A general cloud serves request-response apps. Neither was built for a process that acts for hours, spends real money, holds credentials, and is stopped by policy rather than by a person watching a terminal.

AI agent infrastructure is the layer that fills that gap. It has two halves.

• The runtime: what the agent loop runs on, and how that run is metered.
• The gateway: the primitives the agent acts through, each one a tool call that policy can see.

The primitives catalogue is the same map, one card per primitive.

Model, harness, runtime: which layer you actually pick

Vetta ships several harnesses and pi is the default. Switching one agent's harness changes nothing about the durable loop, the budget gate or the policy layer under it. The three layers are described in How Vetta works.

The runtime layer

The runtime is the part you never configure and always pay for, so it is where efficiency is decided. The runtime category holds twelve primitives; the eight below are the ones you meet first.

Sessions. A session is one run of an agent, and the loop that drives it is an alarm, not a call stack: wake, take one bounded turn, commit the transcript to durable storage, sleep. A run that spans hours pays for storage between turns, not for a machine sitting hot. A crash loses one turn, never the run.

Computer. A session's computer is a disposable Linux micro-VM with a filesystem, a shell and an optional browser. It pauses when the session sleeps, so idle time meters disk rather than vCPU.

Completion window. One field with three settings: immediate, priority, loose. Same model, three tariffs. It defaults on the agent and overrides per session. If a model does not serve a window, the call is refused with window_unavailable rather than quietly moved to another lane.

Budgets. An agent cannot be created without one. Every model call and every priced tool call is quoted before it runs and checked, in order, against the organization balance, the agent's period cap, the per-task ceiling and any session budget. A call that would breach the cap is refused and a budget.exceeded event is emitted, so the agent can wrap up rather than crash.

vetta agent create --name Refunder \
  --model zai-org/GLM-5.2-FP8 --harness pi \
  --skill refund-policy \
  --budget-usd 50 --max-task-usd 5 --budget-period month \
  --window immediate --system "You process refunds."

Skills. Versioned playbooks the model reads on demand rather than carrying in every prompt. Pin a revision with slug@N.

Sub-agents. A coordinator with a version-pinned roster. The lead hands each member one brief; the member runs in its own session and only the result comes back. Delegation is capped at one level, and a shared board carries state that outlives any single session.

Deployments. Cron for agents. Each fire starts a fresh session under a per-run budget, runs to idle and stops. Scheduled work is the canonical loose window use case.

Webhooks. Signed events when a run goes idle or a job finishes. Each delivery carries an HMAC-SHA256 signature in a versioned header, and during a secret rotation the header carries both the old and the new signature so a verifier accepts either.

The rest of the category: structured outputs, a JSON schema the final answer must satisfy; files, organization-scoped storage that outlives the sandbox; model routing under all of it; and the audit log, every control-plane action attributed to a principal.

The gateway layer

Everything below is a tool call, so the same policy check and the same budget quote apply to a card as to bash.

Identity and legal

An agent that needs a person to lend it a login is supervised, not unattended. An identity is a named persona the agent acts as, with real endpoints: a domain, an inbox on it, a phone number with carrier registration. The relationship is many-to-many: one agent can hold a support persona and a sales persona; one billing@ persona can be shared by two agents. The Profile primitive is the persona object itself. When the work needs a company behind the name, KYC and LLC formation sit in the same category.

Money

Spend under caps the agent cannot raise. Cards are virtual cards with a hard limit. The onchain wallet pays per request in stablecoins. Trade connects a brokerage. Credits is the one prepaid balance every gateway call draws on.

Automation

Hands on a computer that is not the sandbox. The browser signs up and logs in on the agent's behalf, and credentials land in the vault, not the prompt. Mobile drives real apps on cloud devices. Connect is OAuth into the apps you already pay for, with tokens vaulted.

Content

Image, video, clips, audio, one media library and social publishing across platforms from one compose.

Intelligence

Live search with URL extraction and cited multi-step research, and Brain, company knowledge plus memory whose answers cite the source document.

Market data

Research instead of guessing: SEO, AEO for how a brand appears in AI answers, app store data, places, commerce, company data, people (off by default) and public social data.

Cloud

The slice of hosting an agent can provision itself: apps to a real URL, a managed Postgres database, storage, functions, auth, compute, queues and disposable sandboxes. Cloud is a category here, not the whole product; What is an AI-native cloud? covers it on its own.

Trust and ops

Why the rest is safe to run. Approvals freeze a risky call until a person decides. The vault holds credentials the agent uses and never reads. MCP sessions scope tool access per end user and are revocable. Jobs lists every async job in one place.

Policy at the tool boundary

The old way to govern an agent was to write rules into the system prompt and hope. The infrastructure way is to enforce them where every capability converges: the tool call.

On Vetta a policy is resolved from two layers, most specific wins: the organization sets a default every agent inherits, and each agent overrides it per tool. The resolved policy is evaluated on every tool call, connect attempt and primitive use, and each tool lands on one of three permissions.

const agent = await vetta.agents.create({
  name: "ops",
  model: "zai-org/GLM-5.2-FP8",
  harness: "pi",
  budget: { capMicroUsd: "50000000", maxTaskMicroUsd: "5000000", period: "month" }, // $50 / $5
  tools: {
    default_config: { permission: "allow" },
    configs: {
      bash:            { enabled: true, permission: "allow" },
      publish_file:    { enabled: true, permission: "allow" },
      "tracker.get_issue": { enabled: true, permission: "ask" },  // a connection/MCP tool, keyed `<connector>.<tool>`
    },
  },
});

A held ask call consumes no budget while it waits. The session goes idle with stop_reason: "awaiting_approval" and can sit there for hours at storage cost:

vetta session confirm --session $SID --tool-call $CALL_ID          # or
vetta session confirm --session $SID --tool-call $CALL_ID --reason "not this account"

The decision records who answered, on the event and on the audit trail. An ask does not have to wait forever: ask_timeout_seconds bounds it, and on_timeout says what happens next, deny by default.

Beyond individual tools, a policy scopes which external systems an agent may reach. Connections are gated by an allowlist, the mode to use for anything that runs unattended, and a call outside it is refused with a typed error before any external request is made. Some actions require approval out of the box: connecting a new third-party app, provisioning a phone number, purchasing a domain. An approval rule can also carry a spend threshold, so a primitive action whose quoted cost exceeds it forces a human decision even when the primitive is otherwise allowed.

This is why the identity layer above is safe to hand to an unattended agent. The persona, its inbox, its connections and its vault are all reached through tool calls, so what a persona may do is declared on the agent, not hoped for in the prompt. Combined with the budget gate, an agent left running overnight can neither exceed its spend nor touch a system it was not granted.

Configuration as code

A whole crew of agents, with their identities, vaults, skills and apps, is one file. A blueprint repository carries a naive.config.ts, and naive up reconciles every declared resource against the platform by name, reporting each as created, updated, unchanged, deleted or refused. naive up --dry-run plans without writing. Nothing is deleted by omission; only a name under removed deletes. The templates are published blueprints you clone and claim.

Where to start

Create an agent with a model, a prompt and a budget. Run it as a session and stream the events. Then add primitives as the work needs them: a browser for the first login, an inbox for the first reply, a card with a cap for the first purchase, ask on the first irreversible tool. The quickstart walks the same path, and Introducing Vetta explains why we built the runtime this way. If you are embedding agents inside your own product, Building AI agents into your SaaS covers the multi-tenant shape.

Agent infrastructure stops being optional the moment an agent leaves the chat window. Treat the runtime and the gateway as one surface, with policy at the tool boundary, rather than a pile of scripts around a model.