Skip to main content
Naïve is runtime-agnostic. An agent profile’s tools work wherever the agent runs — governance is at the tool-call boundary, not in the runtime, so self-hosting does not give up spend caps, approvals, audit, or revoke.

​
Bring your own runtime (the lead path)

The lowest-friction adoption: keep your existing agent (Vercel Eve, AWS Bedrock AgentCore, LangGraph, CrewAI, or your own loop) and just inject the agent profile’s governed tools. 
import { Naive } from "@usenaive-sdk/server";
const naive = new Naive({ apiKey: process.env.NAIVE_SECRET_KEY! });

const op = await naive.forUser(agentId).provision("support", { idempotencyKey: `op:${agentId}` });
const naiveTools = await op.tools();      // the agent profile's governed tools (discover-then-run)

await theirAgent.run({
  tools: [...theirInternalTools, ...naiveTools],
  task: "Resolve ticket #492. Refund if policy allows.",
});
A refund still hits the Naïve gateway — capped, approval-routed above threshold, audited, instantly revocable.

​
Naïve-hosted (optional)

Declare a runtime.pool in naive.config.ts, then start agents on microVMs: 
await naive.runtime("pool").start(op.id, { goal: "Triage support email." });

// Multi-agent system by NAME — Naïve provisions the root + members from the
// `systems` block in naive.config.ts (shared budget) and starts them:
await naive.runtime("pool").startSystem({ system: "content", goal: "Ship this week's posts." });

// …or pass already-provisioned agent profile ids explicitly:
await naive.runtime("pool").startSystem({
  root: parent.id,
  members: [researcher.id, writer.id, publisher.id],
  topology: "manager → researcher → writer → publisher",
});
Pools declared under runtime in naive.config.ts (and registered by naive up) are validated on start() — an unknown pool name returns a clear error listing the declared pools. Inside a hosted agent, use @usenaive-sdk/runtime — credentials are injected at boot (never on the agent’s filesystem): 
import { agentProfile } from "@usenaive-sdk/runtime";
const tools = agentProfile.tools();
await runAgentLoop({ tools, goal: "Resolve tickets. Refunds over $50 route to a human." });
Hosted runtime is enabled per deployment. When it is configured (the orchestration cluster is set), start() claims an isolated agent container for the agent profile — sealed to a per-agent profile scoped key, never your company key — and dispatches the run; startSystem({ system }) is a standing team — it provisions the system’s root + member profiles once (reused on later calls, not re-spawned) under the root’s shared budget, then dispatches the run. When it is not enabled, start() returns a clear error directing you to the BYO-runtime path. Either way, governance is identical: every action the agent takes flows back through the gateway under the agent profile’s policy.
We do not build a Firecracker fleet; the runtime module wraps the existing managed compute orchestration behind a stable interface, so it stays swappable.

​
Billing

A claimed hosted-runtime container is duration-metered in credits (runtime_usage): 2 credits/vCPU-hour + 0.25 credits/GB-hour, so a default 1 vCPU / 2 GB agent costs ≈ 2.5 credits/hour while its container is up — busy or idle. revoke() releases the slot immediately and stops the meter. Bring-your-own-runtime incurs no runtime_usage (you pay only for the API primitives the agent calls). The shared warm pool that keeps start-up fast is platform overhead and is never billed to you. See Credits.