What is an autonomous company? A founder's guide

An autonomous company is a repo: a naive.config.ts declaring the apps and the agent team, provisioned by naive up, run by a coordinator under per-agent budgets and approvals. Here is how one works.

What is an autonomous company?

The home page says it in six words: build your dream company with agents. This is the longer version. An autonomous company is a business whose operating work is done by a team of agents. Not one chatbot with a long prompt: a roster of agents with different roles, tools and budgets, coordinated by one of them, running on a schedule and on tasks, with a person approving the steps that need a person.

Three things make that a company rather than a demo.

First, it is declared, not improvised. Who the agents are, what they may call, what they may spend, and when they wake is written in one file and applied to the platform. Nothing an agent does mid-run can raise its own ceiling.

Second, it is bounded by money. Every agent carries a USD budget, and every model call and priced tool call is quoted against it before it runs. A company that cannot overspend is one you can leave running overnight.

Third, it is governed at the tool boundary. Each tool resolves to allow, ask, or deny. The actions that matter, sending mail, publishing a post, moving money, acting as an identity, can be made to wait for you.

On Naïve, all three come from the same place: a template.

A company is a repo

A template is a repository with a naive.config.ts in it. The repo holds the company's apps (a dashboard, sometimes a public site), the server behind them, and the config that declares the agent team. Clone it, bind the clone to your organization, and bring it up:

naive template ai-media-channel   # clone the template repo
naive claim --key sk_...          # bind the clone to your organization
naive up                          # provision the apps, the agents, their budgets

naive up reads the config and reconciles it against the platform, resource by resource: skills, identities, vaults, apps, then agents, in that order so an agent can reference the rest. The report lists every resource as created, updated, unchanged, deleted or refused. Re-running is always safe: every resource is keyed by its name in the config, and nothing is deleted by omission except a cron dropped from an agent's schedules. naive up --dry-run shows what an apply would do without writing anything.

What the config declares, per the CLI reference:

The config is the source of truth. A field edited by hand in the dashboard is drift, and the next naive up converges it back. That is what makes "an agent cannot raise its own budget" a fact rather than a hope: the only thing that changes the company is a person committing a change and applying it. If you would rather not open a terminal, the available templates on /templates deploy from Studio, which does the same thing in the browser.

What is in a template today

Agency templates run client work with a pipeline and deliverables; Media templates run a channel that produces and posts on a cadence.

• AI Media Channel: a writer, a producer and a channel manager. The writer scripts to the channel's hook library, the producer renders and voices each short, the channel manager keeps the calendar full and holds every post as pending until you approve it. This is the workload Social Bench measures.
• Clipping Channel: long-form in, clips out. A scout scores the moments worth cutting, an editor reframes and captions them, an account manager publishes on cadence behind a review queue.
• AI Automation Agency: five agents (sales, architect, builder, qa, account manager) behind a CRM dashboard and a public site whose enquiry form feeds the pipeline.
• SEO / GEO Agency: a crew provisioned per active client, re-auditing rankings and AI-answer citations on a schedule.

Every one of them ships with the same budget line: $10 per agent per day, $2 per task. Newsletter, Paid Ads Agency and Recruiting Agency are catalogued and coming.

The coordinator and its team

The team is a plain agent that has been given a roster. On the platform this is the multiagent object on an agent's configuration: type: "coordinator", an agents list of one to twenty members pinned by version, and optionally board: true. There is no separate team object; versioning, budgets, sessions and events apply unchanged.

The coordinator owns the top-level task and the top-level context. It coordinates the roster two ways:

• Delegation is point-to-point and one-shot. The coordinator calls send_to_agent with a member's name and a brief. The member runs in its own session, with only that brief as its opening context, and its answer folds back into the coordinator's transcript as a tool result. The coordinator can fan out several briefs, then park once on wait_for_agents until they finish.
• The board is broadcast and durable. Any thread on the team calls board_read and board_write. Cards have four fixed statuses, todo, doing, blocked, done, and they outlive every session that touched them. If the coordinator's session ends, the next one picks up from the board.

Delegation is one level deep: a member is never handed send_to_agent, so it cannot delegate and cannot be talked into it. And the reason to delegate is not speed but context and cost. A member starts fresh with only its brief, so every downstream model call carries far fewer tokens than the coordinator dragging its whole history through every turn. The team reference has the full mechanics; sub-agents is the short version.

Per-agent budgets

An agent is not creatable without a budget. It has three required fields: a period cap, a per-task ceiling, and the reset period (day, week, or month). On the wire these are integer micro-USD; the CLI's --budget-usd accepts a decimal and converts client-side.

Before every model call or priced tool call, the runtime computes a quote, an upper bound on what the call will cost at the session's completion window, and checks it against the organization balance, the agent's period cap, the task ceiling, and any session budget. If the quote would breach any of them, the call is refused, a budget.exceeded event is emitted, and the agent is told in-band so it can wrap up rather than crash.

In a team this composes. The coordinator's budget bounds the whole team, and every member's call is still quoted against the same organization balance and the coordinator's task ceiling, however many members fan out. Read Budgets for the reference and Context & budgets for how spend flows across a team.

Approvals where money or identity is touched

Every capability flows through one place, the tool call, and that is where policy is enforced:

allow is the wrong default for anything irreversible or externally visible. Sending mail, publishing a post, moving money, connecting a third-party account as a persona: set those to ask, or deny if the agent should never have the capability. That is what the templates do when they say a post is held as pending.

When an ask tool fires, the session goes idle with stop_reason: "awaiting_approval". A held tool consumes no budget while it waits, and because the loop is durable it can sit on a confirmation for hours at storage cost only. You answer with vetta session confirm, and the decision records who approved it on the event and the audit trail. A policy can bound the wait with ask_timeout_seconds and an on_timeout of deny (the default), allow, or escalate.

Identity is gated the same way. An identity is a named persona an agent acts as: verified domains, inboxes, phone numbers, third-party connections authorized over OAuth, and a vault of credentials injected at the network boundary so the agent uses secrets it can never read. Connections run under the same allow / ask / deny filter as any other tool. See Approvals, Vault, and the policies reference. We wrote up the approval loop in detail in how to add human approval to an AI agent.

What runs without you, and what does not

Runs without you: the schedules, which wake each agent, spend their own per-run budget, and go back to sleep. The intake message that starts a new agent working. Delegation and the board. Every budget check. Everything set to allow.

Waits for you: everything set to ask. Any edit to the company, which is a commit to naive.config.ts and a naive up. Authorizing a third-party connection over OAuth. Funding the organization balance that every quote is checked against.

We do not claim the company runs itself with no one watching. It runs within the caps you set and stops, cleanly, when it hits one. That is a different promise than hands-off, and it is the one we can keep.

The legal entity is a separate question from the operating company; we cover the US case in introducing formation.

Where to start

Pick the template on /templates closest to the company you want. Deploy it from Studio, or clone it and run the three commands. Watch the first intake session run. Then open naive.config.ts, change one thing (a budget, a schedule, a tool set to ask), run naive up, and read the report. That loop, edit, apply, observe, is how you run the company from then on.

If none of the templates fit, the same config works from zero: declare the agents you want, the tools they get, the budget they run under, and bring it up. For how the platforms in this space compare, see our top 10 platforms for autonomous companies.

An autonomous company is not a vision. It is a repository you can clone this afternoon, with a team already declared in it and a cap on what that team can spend. What it should do is still your call.