What an app is
An app is a directory of content, kept in a repository and reviewed like source code. It holds workflow definitions, such as an orchestrator written as ordinary Python that the CLI compiles into alogic.code component; palettes, the
templates and settings the app picks from as it runs; a playground layout, the screen a person works the app through;
and manifests naming the workflows and schedulers it deploys into. Every definition, palette, layout and manifest is in
BlobHub’s own formats, so what the repository holds for each is exactly what the platform runs.
The platform has no notion of an app. Deploying one uses the CLI’s ordinary per-blob deploys,
blobhub workflow deploy and blobhub scheduler deploy, and the app carries an install
tool of its own that runs them in order and sets up the rest: the session the app lives in, the service accounts it
runs as, and its palettes. Running that tool again updates what it set up. The CLI has no single command that deploys
a whole app.
Missions
Missions delegates engineering work to coding agents. A mission is a graph of cells, each a bounded piece of work, wired bydepends_on edges from a cell to the cells it waits on, and a cell becomes ready only once every cell it
depends on is completed. A cell in draft or inactive is never picked up, so a mission can be shaped or paused
before anything in it runs.
Each cell runs a procedure, chosen from a palette of templates: a small graph of two kinds of step. A worker_task
step hands work to a coding agent, and an external_input step waits for a person’s answer. Each step’s outcome picks
the next one, so a procedure can loop, from a review back to the implementation, until it reaches its end.
An orchestrator advances every mission. It is a workflow written as logic.code, started once a minute by a recurring
schedule, and each run ticks every few seconds: it reads the missions and their cells, decides
what each active cell needs next, does it, and sleeps until the next tick. It keeps no position of its own between
ticks, so when a run crashes, the next one reads the same state and carries on from there.
A worker_task step reaches its agent through blobhub-worker. The orchestrator opens a
thread for the step that names its agent, Claude Code, Codex or Antigravity, and the cell’s workspace, a folder on the
worker’s machine that every step of the cell shares. In the Acme demo organization, one worker runs the missions’
Claude Code, Codex and Antigravity cells. The shipped agents run guarded, so each step’s agent answers to a
policy: the standard policy asks a person before a git push and refuses
force-pushes, hard resets and writes outside the work folder, and read_only, for reviewers, refuses writes. Like
every policy, these are a guardrail against mistakes, not a sandbox. The orchestrator and the worker each run as a
service account of their own, so a cell’s record shows which of them did what.
Mission Control
Mission Control is the screen Missions is worked through: a widget,app.missions.control, on the app’s
playground. The missions rail down the left lists every mission with its id, cell count and
status, and can be hidden. The board in the middle shows the selected mission as Graph, its cells and their
depends_on edges with each cell showing its status, or as Board, the same cells in status lanes with each
prerequisite shown as an ↳ after chip. New Mission and New Cell create an untitled record at once, named in
place.
Opening a cell brings up its dock on the right: its brief, its current step, its dependencies and its activity feed,
one entry per run outcome, decision, artifact and change of state, oldest first, styled by who produced it. A blocked
cell shows what it is waiting for, a step’s options or an agent’s question, and answering it there is how the cell
moves again. Mission Control writes only missions, cells, their dependencies and a person’s requests; dispatching work
and advancing a cell are the orchestrator’s alone.
The catalog
The same platform holds very different work, so apps are listed across domains, each with its status. Only Missions is built and running; each other row’s status says where it stands, and an example is an app a team could build from the same primitives. Deep Research is a public workflow in the Gallery today, without the sign-off its row names. Govern is the rule that matters while an app runs, and Audit the question someone will ask afterwards; outside Missions, both describe a design, not something that exists.
The Apps page on blobhub.io lists the same apps.