Skip to main content
A blueprint is the machine: the repository, the apps it hosts and the routes they serve. A template is data inside it — which agents make up the crew, what each is told on its first day, what it has been taught, what it may reach and when it runs. One blueprint ships several templates: the web blueprint hosts a site and the publisher template staffs it with an editor and a traffic analyst. You choose the template; the blueprint is what the template needs to exist. Applying a template provisions the crew into your organization and starts it working. Everything below is about making that first apply an honest transaction: what you are asked, what you pay for on day one, what you can leave out, and what the crew remembers afterwards.

​
Three questions, then a crew

A template asks at most three setup questions before anything is provisioned — a fourth belongs to the crew’s first conversation, not to a form. The questions are the same text and choice fields an agent asks with when it parks on a question (awaiting-answer loop), so an answer is a string or, for a multiple choice, a list of strings. A template that declares more is refused when it is defined, not when it is published. Every answer to a declared question is consumable: it is stored on the install and read back as project context. A key the template does not declare is refused.

​
Day one and the days after

A template’s first day is a set of tasks — cards on the organization’s shared board, one per piece of work the crew starts with: a title, a body, an agent as assignee, and the other tasks it waits on as blocked_by. The board belongs to the organization’s standing orchestrator; the apply creates that owner (as CEO) when there is none, seats the crew on its roster, and writes the cards blockers first. Nothing is started by the apply itself. A card with an assignee and nothing open in front of it is picked up on the platform’s next tick, which starts that agent on that card — and when it hands the card back done or blocked, the owner is the one who reads the digest. That is what makes the first day durable: who is on what, what waits on what, and what is stuck are on the board, not in N private conversations. Each card is keyed by its project and task, so applying the same template again finds the same cards and reports them unchanged — a second apply never doubles the board and never moves a card the crew has already moved. An agent may instead carry an intake — the first thing it reads, once, on the apply that creates it. It is the legacy first day: a private session per agent rather than a card the whole crew can see. It keeps working, and a template may declare both, but a template written today declares tasks. Intake is priced as day one: the sum of the selected agents’ intake budgets, each falling back to its agent’s per-task cap. It is shown beside — never folded into — the per-fire ceiling of the template’s timers, because they are two kinds of spend: the intakes happen once, on an apply a person is watching; the timers happen every day for as long as they are armed.

​
Selection

A template’s crew is a crew a person chooses from, not a count of resources. An apply may carry a selection: { agents, apps } naming which of the declared agents and apps it provisions; omitted, it provisions everything. An agent left out is not created, its schedules are not armed and its intake does not open. One that already exists is left running — narrowing a selection is not a removal — and the report names it under deselected, apart from skipped, because a choice is not a failure. A template marks the resources it cannot do without as required: the coordinator it is built around, the app every agent’s tools reach through. A selection that leaves one out is refused before anything is written, and the refusal names every missing one:
From the command line, naive up --only editor,site and naive up --without analyst are the same selection (CLI); from the SDK it is apps.installs.apply({ selection }).

​
Project context

The answers you gave are not a form that is filed away. They are the project context: the answers with the questions they answer, the apps with the URL each is served at and the agents with the role each was declared with, derived from the project’s latest applied install.
Every agent a template creates reads it through the built-in project_context tool: read-only, no arguments, offered only to an agent whose project has an applied install — an agent outside a template never sees it. You read and edit the same object with apps.installs.context and apps.installs.update, or naive installs context [--set key=value] (CLI). An edit rewrites the answers and nothing else: the install’s revision does not move, nothing is re-provisioned and no agent is briefed again. The crew simply reads the new answer the next time it looks.

​
The skill catalogue

A template that says what an agent has been taught must name something that exists before your organization does. That is the skill catalogue: skills the platform ships, versioned and immutable, readable by anyone authenticated and written by nobody’s push. A skill reference in a template is naive/slug (the newest catalogue version, resolved once at session start) or naive/slug@N (frozen); a bare slug or slug@N is one of your organization’s own skills. The catalogue’s routes are in Skills § catalog.