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; the media blueprint hosts one post queue and carries three crews (faceless, longform, clipping) that fill it with different work. You choose the template; the blueprint is what the template needs to exist, and switching between the templates of one blueprint is an edit plus another apply — never a new app. 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.

​
Four questions, then a crew

A template asks at most four setup questions before anything is provisioned — a fifth 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. The cap is on what a person is asked before there is anything to look at, and it was three until optional bought the fourth slot. A question that may be left blank costs a glance rather than an answer, so a form of four one of whose questions need not be answered is still the short form the cap exists to protect — all three of the media blueprint’s shipped templates (faceless, longform, clipping) are exactly that shape, and all three ask the same four. A fifth is not, optional or otherwise. 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.

​
A question that may be left blank

A field marked optional: true may be left blank. Do that and its key is absent from the answers — not an empty string — which is the whole of what the flag buys: an unanswered key is simply not in the project context, so the crew reads the answers it was given rather than one more that says nothing. A key that is sent is validated like any other, so a blank string, an empty list or an unlisted option is still refused: an answer that was given is an answer that was meant. Ask this way when the answer would genuinely improve the work but does not gate it — a reference to imitate, a channel already running, a competitor to watch. Without the flag the only way to ask such a thing is to make it mandatory, which forces an answer out of a person who has none, and an invented answer is worse than an absent one because the crew cannot tell them apart.
help is the sentence under the label, on any field, optional or not. Both are the same QuestionField a parked agent asks with, so a form that renders one renders the other.

​
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. vetta skill catalog lists it (CLI). 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 § the platform catalogue. The media crews are taught from the video half of it: planning a piece against references somebody actually watched (reference-teardown, video-trend-brief, short-video-hooks, long-form-arc), cutting and captioning (clip-selection, caption-writing), joining separately rendered segments into one file (video-assembly), and the weekly note to the operator (channel-report).