Workstreams and phases

A Decision Value Loop says what a class of decisions requires. This page covers the machinery that actually does the work: the unit of agent-led execution, where its output accumulates, how phases are structured, and what a gate checks before a cycle moves on.

Workstreams: definition and execution

A workstream definition is a reusable template for a type of human-and-agent collaboration — an assessment, a synthesis, an analysis, a review. It holds the agent roster for that kind of work, the default runtime image, and the playbooks the work consults. Definitions move through draft → approved → active → deprecated → retired; a definition stays active across many runs, and deprecating it stops new runs without disturbing the historical ones.

A workstream execution is one run of that definition pursuing one specific objective. It carries the concrete state: when it started, who is participating, what is being pursued, which agents were built, which sessions are open. Executions move through pending → active → paused → completed, failed, or cancelled.

Each execution records the version of the definition it was built from. That is what lets you explain a run from a year ago without having frozen the definition in the meantime.

Where the work lands: playbook and workbench

Two repositories sit on either side of an execution, and confusing them is the most common early mistake.

	Playbook	Workbench
What it holds	Process definitions, standard operating procedures, domain reference material, decision criteria, and the order in which phases and agents take up the work	The work products agents and people actually produce: analysis, drafts, materials, intermediate artifacts
Access during a run	Read-only	The write surface — the only one
Scope	Per definition, versioned independently	One repository per workstream, one branch per execution

The playbook is the read-only process definition. Because it is read-only during execution, every run of a given workflow consults the same canonical procedures rather than knowledge embedded in an agent’s prompt. It has its own version lifecycle: draft → published → deprecated.

The workbench is the mutable, version-controlled workspace. It is one repository per workstream, with each execution owning its own branch created at start. Work is committed as the phases proceed, and the branch persists afterward as the execution’s durable, inspectable record — there is no separate archiving step, and nothing an agent produced is ephemeral.

Carrying work forward between runs is a branch fork: a new execution’s branch can start from a prior execution’s branch, inheriting its accumulated work and its full revision history, or from the repository baseline for a clean start. Which of the two happens is a property of the definition, so “does this workflow build on the last run or start fresh” is configuration rather than a decision someone makes by hand each time.

Phases

A cycle progresses through five phases — Sense, Analyze, Decide, Act, Learn — with gates between them. Every phase follows the same rhythm:

Read what earlier phases left, scoped to this cycle.
Work: run definitions, derive, author.
Freeze the phase’s outputs, with their purpose and context stamped on them.
Designate the ones that constitute the phase’s evidence.
Ask the platform to advance.

Which kind of work happens in which phase is configured at design time, as part of the Decision Pack: a binding maps each phase to the workstream definitions that run in it. Sensing may call for a retrieval workstream, analysis for a synthesis workstream, the decision itself for a human-review workstream. When a cycle enters a phase, the binding is what tells the platform which work to start.

A phase execution is one phase of one cycle. It exists because a single phase may involve several parallel spans of work — an agent gathering data, an agent producing analysis, a person reviewing a recommendation — and the phase execution is what binds the phase to that concrete work. It is also what makes per-phase cost and progress observable rather than only per-cycle. Phase executions move through pending → active → completed, failed, or skipped.

The relationship between cycles and executions is deliberately loose. A cycle may be completed by one execution or composed from several, including more than one within a single phase. The cycle is the accounting and evidence boundary; how the work is organized underneath is a matter of what the decision needs.

What a phase costs

Each phase records model spend, human time, elapsed time, agent invocations, and tool calls. These aggregate up to the cycle and across cycles, which is what makes cost per decision — rather than cost per platform — a reportable number.

Phase objectives and phase gates

A phase does not end when an agent believes it is finished. It ends when its phase objectives are satisfied and a gate permits the advance.

A phase objective is a stated obligation the phase must discharge before it can close. Each declares the roles it expects its evidence to fill. Satisfying an objective means binding a Decision Material — a frozen record, explicitly designated — to it.

A phase gate is the transition itself, and where human approval is required, it is the structural moment that approval happens. What the gate captures is the whole event: the material that was put in front of a person, who approved it, when, and under what conditions if any.

Three properties of gate evaluation are worth an evaluator’s attention.

Evidence is read, never accepted. A gate reads records that are already resident in the platform. Nothing is conveyed to a gate: where an advance request carries anything at all, it may only be a reference to a persisted record. Checks verify artifacts and state, never assertions that work was done. An agent cannot talk its way past a gate.

Deterministic checks are visible before the approval, not after. A gate can carry automated acceptance checks — the deterministic conditions a playbook declares alongside its process. Their latest results appear above the approve control in one of three honest states: passing, failing, or never run. “Never run” is shown as itself rather than presented as passing.

Approving over a failing check is possible, and it is recorded as what it is. A blocking check that is red or has never run does not silently prevent the advance; it requires an explicit, reasoned, audited override to proceed. The platform’s posture is that judgment sometimes outranks a check, and that when it does, the record should say so plainly.

Where a phase requires several approvals, each approved material is designated to the role it fills, and the gate validates them together — right approver, authority actually held, roles matching what the phase declared. It advances only if all of them pass.

How this fits together

Workstream definition  ──instantiates──>  Workstream execution
        │                                        │
   playbooks (read-only)                    workbench branch
        │                                        │
        └──── consulted during ────────> phases of a DVL Cycle
                                                 │
                                    phase objectives satisfied by
                                    designated Decision Materials
                                                 │
                                            phase gate
                                                 │
                                            next phase

Where to go next

Data products and plugins — how the evidence a gate reads is produced, frozen, and designated.
Agents and runtimes — who is doing the work inside a phase, and under what authority.
Tour of one decision cycle — a single cycle followed from sensing to a measured outcome.

Documentation