What is an AI-native cloud? The hosting slice an agent operates

An AI-native cloud is the hosting and data slice an agent can provision by API: apps, Postgres, storage, functions, auth, compute, queues and sandboxes, gated by allow / ask / deny policies and a USD budget.

Search for AI cloud and the results are a mess: GPU marketplaces, "AI platforms", and every hyperscaler's landing page with a chatbot bolted on. If you build agents, the useful definition is narrower, and it is a slice of AI agent infrastructure, not the whole stack.

An AI-native cloud is cloud infrastructure whose primary operator can be an agent. The agent creates the app, ships the build, provisions the database, queues the work and tears it all down again, through the same API surface and under the same policy and budget as every other action it takes. A person is still in the loop, but at the approval boundary, not in a console clicking through wizards.

This post absorbs our older launch posts for apps, backend, compute and queue. They described the same idea in a vocabulary we have since retired; this is the current version.

AI cloud vs. AI-native cloud

If the operator is still a human in a console, you have cloud near AI. If the operator can be an agent calling one API without long-lived provider keys in its context, you have an agent-shaped cloud surface.

What has to be true

Four properties separate an AI-native cloud from a normal one with an SDK.

1. Provisioning is a tool call. Creating an app, running a migration or pushing a deployment is something the agent does mid-session, not something a person does before the session starts.
2. Policy is enforced at the tool boundary. Every capability resolves to allow, ask or deny before it runs. The model can attempt anything; the runtime decides what actually executes.
3. Money is structural. A budget in USD is a constructor argument on the agent, and calls are priced before they are made. Overspend is refused, not discovered on an invoice.
4. Secrets are write-only. The agent uses a database connection string, an API key or an OAuth token without any route ever returning the value to it.

On Naïve these are not features of the cloud primitives specifically. They are how policies, budgets and the vault work for every primitive an agent holds. The cloud slice just inherits them.

The eight cloud primitives

The Cloud category on /primitives is the hosting and data slice. Eight primitives, plus the computer every session already runs in.

Apps. A hosted web application on a real URL. An app is an organization-level resource: it does not belong to an agent, it outlives any session, and by default every agent in the organization can operate it (narrow that per agent with the apps tool's allowed_apps). Two types: frontend_only, which is active at birth, and fullstack, which is provisioning until its managed database is ready and then has the connection string pushed into its environment automatically. Creation is idempotent on the name. A deployment is one request carrying a map of file paths to contents; the build advances queued to building to ready on read. Full detail in the Apps API.

Database. The managed Postgres behind a fullstack app. The agent runs SQL against it through the app's own db/query route, so schema, CRUD and migrations all happen against the database the app already uses, with no second connection to manage.

Storage. File buckets on the app the agent deployed. This is distinct from Files, the organization-scoped store where a session's own artifacts land when the agent calls publish_file. Scratch work stays in the sandbox; deliverables go to Files; app assets go to Storage.

Functions. Backend logic at the edge, for the parts of an app that need to run server-side without standing up a second platform.

Auth. Sign-in for the apps the agent builds, with email, Google and GitHub. The agent ships a product with users, not a static page.

Compute. Containers and long-running workers that scale on demand, including GPU workloads, for the jobs that do not fit inside a request.

Queue. Durable message queues for agent pipelines: work handed off durably rather than held in a process that has to stay running.

Sandbox. A disposable code sandbox the agent can run, checkpoint, fork and throw away. It is the same machine as the computer below, created on demand for a task: a snapshot checkpoints it without stopping it, and a fork boots a new computer from that checkpoint, billed like any fresh create. We wrote about it in introducing the computer.

The computer underneath

Every session on Vetta already runs inside a computer: a real Linux micro-VM with a filesystem, a shell and an optional browser scoped to an allowlist of domains. It defaults to 2 vCPU and 4 GiB of memory and can be sized up to 16 vCPU, 64 GiB and a 100 GiB disk. It pauses when the agent sleeps and resumes on the next turn, so idle time meters storage, not compute. That is what makes the cloud slice affordable to operate from an agent: the operator costs nothing while it waits for a build or an approval. Details in Computer and the sandbox lifecycle reference.

Apps get their tools back

The part of this that is genuinely new, and that the old launch posts could not describe, is that a shipped app can hand tools back to the agents that operate it. A fullstack app that serves an MCP endpoint declares the path once:

const app = await vetta.apps.create({ name: "storefront", type: "fullstack", mcp: "/mcp" });

Setting mcp mints an opaque bearer token and pushes it into the app as the write-only secret VETTA_MCP_TOKEN. From then on, every turn of every agent that can access the app is offered the endpoint's tools as <app-name>.<tool>, for example storefront.list_orders, under the agent's normal allow / ask / deny policy. The platform injects the bearer server-side; the token never reaches the sandbox or the transcript. An unreachable endpoint contributes no tools that turn and never fails the run.

That closes the loop an AI-native cloud is supposed to close. The agent ships the app; the app becomes part of the agent's toolset; the same policy governs both. See Tools from your apps.

Governance: allow, ask, deny, budget

Handing an agent a raw cloud IAM role fails in familiar ways: keys leak into logs and prompts, always-on resources dominate the bill, and revoke means chasing roles by hand. The fix is not a better prompt. It is enforcement the model cannot reach.

Policies. Every tool an agent holds, including the cloud primitives and the <app-name>.<tool> tools above, resolves to one of three permissions. allow runs without confirmation. ask emits a tool.confirm event and pauses the tool; the session goes idle with stop_reason: "awaiting_approval" until a person confirms or rejects it, and the decision records who answered. deny means the tool is not offered to the model at all. Policies resolve from an organization default with a per-agent, per-tool override, and a held tool consumes no budget while it waits.

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" },
      "storefront.refund_order": { enabled: true, permission: "ask" },
    },
  },
});

Approving from the CLI is one command:

vetta session confirm --session $SID --tool-call $CALL_ID

An ask does not hold forever. ask_timeout_seconds bounds the wait and on_timeout decides what happens when it elapses; the default is deny. For the full pattern read how to add human approval to an AI agent.

Budgets. An agent cannot be created without one. Before every model call or priced tool call, a pre-flight gate quotes an upper bound and checks it against the organization balance, the agent's period cap, the per-task ceiling and any session budget, in that order. A call that would breach any of them is refused and a budget.exceeded event is emitted so the agent can wrap up cleanly. One honest caveat: compute is metered from what actually ran and booked afterwards, so a period can finish slightly past its cap. It is on the ledger either way. See budgets.

Secrets. App secrets are write-only environment variables: the value goes to the app's runtime and never comes back on any read, and the list returns names and timestamps only. Vault credentials behave the same way. Neither an app secret nor a vault credential is returned by any route once written, which is the property that makes it safe to let an agent set them.

Declaring the cloud instead of clicking it

Cloud resources on Naïve are declared in a naive.config.ts and reconciled with naive up. An apps entry names the app, its type, the directory to ship and the environment it needs, with secret values read from your shell at apply time so they never sit in the file:

apps: [
  {
    name: "dashboard",
    type: "fullstack",
    deploy_dir: "dist",
    mcp: "/mcp",
    env: { PUBLIC_URL: "https://dashboard.example", API_KEY: { from_env: "NAIVE_API_KEY" } },
  },
],

naive up upserts every declared resource by name and reports each as created, updated, unchanged, deleted or refused. Re-running is always safe: the deploy directory is hashed and an unchanged tree is not uploaded, and nothing is deleted by omission. Every app records the project that created it, and an apply that touches an app owned by another project stops rather than overwrites. The full reference is the naive CLI.

Bottom line

An AI-native cloud is not a synonym for "we bought GPUs", and it is not the whole of Naïve. It is the hosting and data slice whose primary user can be an agent: provisioned by tool call, metered against a budget the agent cannot raise, governed by allow / ask / deny at the boundary, and fed secrets it uses but never reads. Start with one app, one small budget and ask on anything destructive. Widen from there.