> ## Documentation Index
> Fetch the complete documentation index at: https://vetta.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Naive and Vetta
> Vetta is the autonomous-company infrastructure; Naive is the blueprints, templates and studio on top of it. Which surface you use for what.
**Vetta** is the autonomous-company infrastructure: the harness, the managed agent runtime, sessions, budgets, identities and tools. **Naive** is the layer on top of it — the blueprints and templates a whole company is installed from, the catalogue that publishes them, and the studio you run them in.
These pages are the **Vetta** reference. Every page below documents the infrastructure, which is why the prose, the CLI and the API all say `vetta`.
Naive is not a second platform. A blueprint has no runtime of its own: everything it installs is an ordinary Vetta resource, created through the same API you could call yourself.
## Where the line sits
[Agents](/docs/capabilities/agent), [sessions](/docs/concepts/sessions), the [durable runtime](/docs/concepts/runtime), [harnesses](/docs/concepts/harnesses), the [completion window](/docs/concepts/completion-window), [budgets](/docs/concepts/budgets) and the ledger, [computers](/docs/capabilities/computer), [files](/docs/capabilities/files), [skills](/docs/capabilities/skills), [identities](/docs/capabilities/identity) and vaults, [deployments](/docs/capabilities/deployments) and [webhooks](/docs/capabilities/webhooks) — reached over one REST API, one SDK and one CLI.
Blueprints and their templates: a company as a repository — its dashboard, its crew, its personas and its timers — plus the published catalogue of those pairs and the studio that installs and operates them.
## The four surfaces
| Surface | What it is | What you do there |
| -------------------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| [`usenaive.ai`](https://usenaive.ai) | The public site | Read about the product; browse the [catalogue of companies](https://usenaive.ai/templates) you can install |
| [`app.usenaive.ai`](https://app.usenaive.ai) | The studio | Install a blueprint, answer its setup questions, then run everything: agents, sessions, computers, identities, files, credits, keys |
| `api.vetta.sh` | The [API](/docs/api/overview) | Every resource, directly — the studio and the CLI are both clients of it |
| `vetta` / `naive` | The [CLI](/docs/cli/overview) and the [SDK](/docs/sdk/typescript) | The same arc from a terminal or your own code, plus `naive up` from a cloned blueprint |
## What a blueprint actually installs
A blueprint is a public repository with a `naive.config.ts` in it — `naive template agency` clones `usenaive/agency-blueprint`, `naive template media` clones `usenaive/media-blueprint`. A **template** is data inside that repository: the crew and its prompts, the tool allow-lists, the schedules, and the words its screens print. One repository carries every template its blueprint has.
| Blueprint | Templates | Default |
| --------- | ---------------------- | ---------------------- |
| `agency` | `blank`, `seo-geo` | `blank` |
| `media` | `faceless`, `clipping` | none — you must choose |
Applying that config — `naive up` in the clone, or the studio's install flow — reconciles your organization against it. Every row it writes is a Vetta resource you could have created yourself:
| Declared in `naive.config.ts` | Created on Vetta |
| ----------------------------- | ------------------------------------------------------------------------------------------------- |
| `skills[]` | A versioned [skill](/docs/capabilities/skills), pushed by slug and content-addressed |
| `identities[]` | A [persona](/docs/identity/personas) the agents and schedules act as |
| `vaults[]` | A [vault](/docs/identity/vault) and its credentials, held by a declared identity |
| `apps[]` | A hosted [app](/docs/api/apps) — its file-map deployment, its secrets, and an optional `/mcp` endpoint |
| `agents[]` | An [agent](/docs/capabilities/agent): model, system prompt, tools, skills, budget |
| `agents[].schedules[]` | Cron [deployments](/docs/capabilities/deployments), owned as a complete set per agent |
| `agents[].intake` | One [session](/docs/concepts/sessions), opened once, on the apply that creates the agent |
The report names each one `created`, `updated`, `unchanged`, `deleted` or `refused`. It is idempotent — every resource is keyed by its config name — and nothing is deleted by omission. The full config surface is in the [`naive` CLI reference](/docs/cli/naive).
## Which one am I touching?
* **Standing up or switching a whole company** — Naive. Install from the studio, or clone the blueprint and run `naive up`. Switching template is an edit plus another `naive up`; the app, its URL and its data stay where they are.
* **Changing an agent a blueprint installed** — the resource is Vetta's, but the config is the source of truth: edit `naive.config.ts` and re-run `naive up`, because the next apply converges a field edited by hand back to what the config declares.
* **Anything not from a blueprint** — Vetta only. An agent you create by hand, a session, a computer, a key: nothing about blueprints is required to use the platform, and the [quickstart](/docs/quickstart) never mentions one.
* **Watching work happen** — sessions, [events](/docs/concepts/events-and-streaming), files and cost read the same whether the agent came from a blueprint or from `POST /v1/agents`.
`vetta` and `naive` are two binaries pointing at the same bundle from `@usenaive-sdk/vetta-cli`; the name selects nothing. `naive up` is `vetta naive up`.
Create an agent, run it, and read the meter in under five minutes.
`claim`, `up`, `template`, `catalog`, `installs` — and the whole config surface.