The four identity surfaces
Passport
The business identity you write.
Genome
A structural fingerprint of the steps, generated automatically.
Manifest
What the mission technically needs to run.
Blueprint
A portable, secret-free export of the whole mission.
Passport — the business identity
The Passport is the part you fill in: what this mission is, in business terms. It captures the mission’s domain, its use case, the industry, the outcome it promises, its risk level, and its sharing policy. It’s the human-readable “who and why” that gives the rest of Build its meaning. It’s editable at any time.Genome — the structural fingerprint
The Genome is generated for you from the steps. It describes the shape of the flow, not its content: the pattern (for example agent → wait_poll → human), an archetype, a complexity measure, and the automation ratio (how much runs without a person). Two missions with the same Genome work the same way even if they do different jobs.Manifest — what it needs to run
The Manifest is the mission’s requirements list: the agent roles it uses, the systems and connections it touches, the data it reads, and the permissions it needs — plus whether it needs human approval, makes external calls, or runs on a schedule. It’s the fastest way to answer “what does this mission depend on?” before you rely on it.Blueprint — the portable export
The Blueprint is a secret-free JSON export of the entire mission — its steps, contracts, and settings, with credentials stripped out. Preview and Export JSON let you copy, review, or archive a mission’s design safely. (Publishing and installing blueprints into other workspaces is not yet available.)Variables
Variables are the named values your steps reuse via{{vars.key}} — either static values or references to a connection (secrets stay hidden). Each variable tracks which steps use it, so you can see the impact before you change one. This is the other half of the templating you set up in the flow.
Versions
Versions is the mission’s configuration history — a safety net for changing a live mission.
Publishing a change captures the current version first, so you can always compare or roll back. See Triggers & Drafts for the full draft-and-publish flow.
Test — pre-flight before you run
Test runs a pre-flight validation: a read-only readiness check with no side effects and no agent runs. It confirms the mission is fit to run and reports a readiness result. It checks that:- the mission is active;
- every agent step has an assigned, active agent;
- every human step has an approver;
- any webhook trigger has a secret;
- there are enough credits;
- and it does a mocked happy-path walk that proves the steps are ordered correctly — without running anything.
Pre-flight is the cheap way to catch a broken mission before it costs a credit. Run it after any edit to the flow, agents, or triggers.
SOP — the auto-written runbook
SOP is a Standard Operating Procedure document generated from the current flow — purpose, scope, responsibilities, the process step by step, approvals, and audit rules. It’s a plain-language runbook you can hand to a colleague so a mission isn’t a black box.From an AI client, these surfaces map to
mission_validate (pre-flight), mission_compare_versions, and the mission read tools. See the Missions API reference and Mission Recipes.