Programs
A program is a long-running, goal-driven body of work — a CVE-remediation drive, a front-end refresh, a quarterly reporting cycle. You split it into ordered phases, put activities in each phase, and assign every activity to a workflow, an agent, a team or a person. The platform runs the activities, tracks what each run produced, checks the work against your acceptance criteria, and stops to ask a person when something needs a decision.
Open Build → Programs in the left navigation to see every program in the current project.
Program (goal, context, knowledge, documents, access rules)
├─ Phase 1 (sequential | parallel, completion mode, optional checkpoint)
│ ├─ Activity → Workflow ─┐
│ ├─ Activity → Agent ├─ each run is recorded as a mission
│ ├─ Activity → Team ─┘
│ └─ Activity → Person (marked complete by hand)
├─ Phase 2
└─ …
How programs relate to other entities
| Entity | Relationship |
|---|---|
| Workflows | An activity can be assigned to a workflow. Each run of that activity starts the workflow with the attribute values you set on the activity. |
| Missions | Every activity run — workflow, agent or team — is recorded as a mission of type program activity. A workflow run opens in the mission execution canvas, which links back to the program. |
| Agents and Teams | An activity can be assigned to an agent or a team. The run happens headlessly and is saved as a chat transcript you can open while it works or afterwards. |
| Knowledge bases | Knowledge bases attached to the program, and to individual activities, are given to every run. |
| The Program Manager agent | An ordinary agent that designs and edits programs with you through the Program Assistant chat. See The Program Assistant. |
Program fields
| Field | What it does |
|---|---|
| Name | Required. The editor won't create a program still named "Untitled Program". |
| Brief | The goal. It is included in the context sent with every run. |
| Tags | Free-form labels. The Programs list search matches name, brief and tags. |
| Program manager agent | Records which agent manages the program; shown as Manager in the program header. Leave it on Use platform default to use your organisation's default. |
| Access | Which agents, teams and workflows this program may assign work to. See Access. |
| Knowledge | Knowledge bases given to every run in the program. |
| Program knowledge | An accumulating log of notes — added by people, by the Program Assistant, and by activities — that is included in the context sent with every run. See Knowledge and documents. |
| Documents | Reference documents stored on the program. Pinned or injected documents are summarised into every run's context. |
Program status and health
A program's status is one of draft, active, paused or archived. Programs you finish in the editor are active. A program that is a draft, paused or archived dispatches no work at all.
Each program also shows one health value, worked out from everything inside it. The first rule that matches wins:
| Health | When |
|---|---|
| Archived | The program is archived. Hidden from the list unless you turn on Show archived. |
| Draft | The program is a draft, or it has never run and at least one phase has no activities. |
| Needs you | Something is waiting on a person: a checkpoint to approve, a question to answer, a failed run, or a run that failed verification. |
| Stalled | The only open problems are runs the platform has lost contact with. |
| Running | At least one run is queued or running. |
| Paused | The program is paused. |
| Completed | All the work is done. |
| In progress | Some work is done and more remains. |
| Not started | Nothing has run yet. |
Phases
A phase is an ordered stage of the program. Phases have their own status — pending, active, completed (and repeating or skipped when set through the API). A phase becomes active as soon as any of its work starts, or when the phase before it advances.
| Setting | Options | Effect |
|---|---|---|
| Phase name | — | Required. |
| Description | — | What the phase is for. |
| Activities run | Sequentially (default), In parallel | Sequential runs one activity at a time, in order. Parallel starts every ready activity at once. |
| Completion mode | Manual (default), Auto, Checkpoint | What happens when every activity in the phase has finished. See below. |
Completion modes:
- Manual — the platform records that all activities are complete. You move on with Advance to next phase.
- Auto — the phase is marked completed and the next phase becomes active automatically.
- Checkpoint — the phase's checkpoint is raised and the phase waits for a person to approve or reject it. See Checkpoints.
Advancing (by hand, automatically, or by approving a checkpoint) makes the next phase active but does not start it — you start it with Run phase.
Pausing a phase
Pause this phase stops the phase from starting anything new. Runs already in progress keep going. Resume this phase lifts the pause; nothing restarts until the phase is run again. Activities you paused individually stay paused.
Activities
An activity is one unit of work. Its Owner type decides who carries it out:
| Owner type | What happens when it runs |
|---|---|
| Workflow | Starts the chosen workflow with the attribute values set on the activity. Opens in the mission execution canvas. |
| Agent | Runs the chosen agent headlessly on the activity's prompt, with the program context appended. Produces a transcript, a summary and a list of artifacts. |
| Team | As for an agent, but runs the chosen team. |
| Person | Never dispatched. The assigned project member does the work and selects Mark complete. |
New activities default to the Workflow owner type.
What an agent or team is sent
The message an agent or team receives is the activity's Prompt (or, if that is blank, its description, then its name), followed by a Program context section made up of the program brief, the program knowledge, and the summaries of any pinned or injected documents. The context section is capped at 6,000 characters. Use Preview what the assignee receives in the activity editor to see the exact text.
Agent runs also get three tools for managing the activity they are running: one to report live progress (shown on the board), one to add a durable note, and one to raise a block — stop and ask a person a question. Workflow runs receive the same program context as a program_context attribute value.
Run policy
Run policy (shown as When a phase run may run this) controls whether Run phase picks the activity up again:
| Option | Behaviour |
|---|---|
| Once — skip it after it succeeds | Default. Run phase skips it once it has succeeded. |
| Always — run every time the phase runs | Run phase runs it every time. |
| Until success — retry while its latest run keeps failing | Run phase runs it unless its latest run succeeded. |
Running a single activity yourself (Run now, Re-run, Retry) ignores the run policy. It never overrides a hold: a paused or blocked activity, a paused phase, an unresolved checkpoint, or a program that isn't active.
Dependencies
Depends on lists the activities this one waits for. They can be in any phase of the program. An activity with no explicit dependencies follows its phase's setting: in a sequential phase it waits for the activity before it; in a parallel phase it waits for nothing. A dependency is satisfied only when that activity succeeds — a failed, cancelled or unanswered activity keeps everything behind it waiting. Circular dependencies are refused.
If every remaining activity in a phase run is waiting on something that failed, the platform records Sequence halted in the activity log and the phase does not complete.
Acceptance criteria and verification
Done when — acceptance criteria says what a successful run must produce. Deliverable — expected artifact types (for example pull_request) lists the kinds of artifact a run must report.
When a run finishes:
- A deterministic pre-check fails the run if it reported no summary, or none of the expected artifact types.
- If the activity has acceptance criteria, a judge model scores the run's summary and artifacts against them and records passed or failed with a score from 0 to 1 and notes.
An activity with no criteria and no expected artifacts stays Not verified — that is not a failing grade. A run that completes but fails verification shows as Verification failed and counts as a failure for dependencies. You can Re-verify, or Accept anyway with a note explaining why.
Activity states
The activities table groups activities by state:
| Group | States |
|---|---|
| Needs you | Failed, Verification failed, Needs answer (an agent raised a block), Needs approval (a checkpoint holds the phase), Lost contact |
| Running | Running, Queued |
| Ready | Ready — can run now |
| Waiting | Waiting — queued behind a dependency |
| Done | Done |
| Paused | Paused |
| Skipped / Cancelled | Skipped, Cancelled (collapsed by default) |
A run is marked Lost contact when it stops sending heartbeats for 5 minutes, or when its last heartbeat is more than 15 minutes old.
For what each state means and the recovery actions available, see Working with program activities.
Checkpoints
A checkpoint is an approval gate on a phase. When a phase whose completion mode is Checkpoint finishes its activities, its checkpoint is raised and the phase holds: nothing more in the phase — or in any later phase — can be dispatched, and Advance to next phase is refused until someone decides.
- Approve (note optional) — if the phase's work is finished, the phase completes and the next phase becomes active. If work was still queued behind the checkpoint, that work is released and dispatched.
- Reject (note required) — the phase is paused. Resume it when the objection has been dealt with.
A checkpoint has a name and, optionally, a description, required approvers and a timeout in hours. A timeout never approves anything: a checkpoint that times out is marked expired and keeps holding the phase until a person decides.
Setting Completion mode to Checkpoint in the editor does not by itself create the checkpoint. The checkpoint is defined by the Program Assistant, or through the API or MCP server (create_phase_checkpoint). Programs built with create_program_from_plan get a checkpoint on every phase except the last. If a phase has no checkpoint defined, nothing holds it.
The Required approvers list is recorded and shown, but is not enforced: anyone who can edit the program can approve or reject.
Knowledge and documents
Program knowledge is an append-only log. Each entry is labelled with its source — the person who added it, the assistant, or the activity that produced it — and appears on the program's Knowledge tab. Entries are capped at 4,000 characters each; once the whole log passes 32,000 characters the oldest entries are dropped. Because the knowledge log is part of every run's context, keep entries short and factual.
Documents are stored on the program with a title, a type (brief, spec, runbook, research, reference, report, meeting_notes, okr, strategy or other), a summary, content and an optional source URL. A document that is Pinned or has Inject into runs turned on is added to every run's context — its summary if it has one, otherwise the first 500 characters of its content.
An activity can also be set (through the API) to send its result to the program automatically: its run summary and artifact list are appended to the program knowledge, or saved as a new research document.
Access
Access limits which executors a program may use. For each of agents, teams and workflows you choose All, None or Only these. The platform enforces this whether the change comes from the editor, the Program Assistant, the API or MCP: an activity can't be assigned to an executor outside the program's access, and an activity whose executor falls out of scope can't run.
Usage and cost
The program header shows what the program's runs have cost so far — cost, then tokens, number of runs and total run time. When a model has no price configured, the header shows cost not metered rather than a misleading $0.00. The API also returns the same figures broken down by phase and by activity. For organisation-wide reporting see Usage and billing.
Activity log
Every significant change is recorded as a program event — programs created or changed status, phases started, advanced, paused or completed, checkpoints created, resolved or expired, runs started, completed, failed, cancelled or lost, verification verdicts, blocks and answers, activities paused, stopped or marked complete, and knowledge added. The Activity log tab lists them newest first, with who did it.
Working with programs outside the app
Everything in a program is available through the Platform API and the Platform MCP server, which has tools for programs, phases, activities, checkpoints, documents, knowledge and the Program Manager agent. The MCP server's create_program_from_plan tool turns a structured plan into a complete program in one step — see The Program Assistant.