Workflow builder

A workflow is a process you author once and reuse: the ordered steps a recurring job takes, laid out as a graph instead of re-explained to an agent every time. Where a single task is one piece of work, a workflow is the shape that work follows whenever it runs: gather, draft, check, approve. The builder is where you draw that shape, and it is the first step in turning a proven process into something repeatable.

You draw a workflow as a graph of steps

A workflow is a definition: a named graph of steps connected by edges, owned by a workspace and usually scoped to a project. You open the builder from the Workflows page, which lists the definitions in your workspace and links each one to its graph, or by searching for the workflow in the command center. The builder renders the graph top to bottom. Each root becomes its own vertical chain, branch steps anchor in that chain before fanning out into horizontal route columns, and each route continues downward in its own local chain. You create and edit steps in the shared step modal, insert new steps from the connector menus between cards, and reorder linear runs vertically. If a branch fans out wide enough to need more space, only the graph canvas scrolls horizontally.

The builder also gives you a quick read on the current draft before you scan the full graph. A compact overview shows the workflow's effective lifecycle and step count. Rich step cards surface the configuration that matters for each step. Scalar settings such as agent, autonomy ceiling, verifier, and approval recipient render as semantic label and value detail rows, the same pattern Task Machine uses in workflow run details. Prose fields still read as prose, branch routes stay as ordered route descriptions, and document outputs stay as structured file lists. Members who can read workflows but cannot manage them can still reach the page, but they see a no-permission state that asks them to get workflow management access before changing the draft. Layout is the builder's concern. The definition itself stores the steps, the edges between them, and the configuration each step carries, not where they sit on screen.

Every step has a step type that decides what it does:

• Agent steps run an agent against a prompt and a set of context references — the documents, files, memories, or tasks the agent should read before it works.
• Branch steps split the path. Each outgoing route carries a natural-language branch condition, evaluated in order, so the same workflow can take different paths depending on what it finds.
• Human approval steps are a deliberate pause. The step routes a request to a chosen member or role and holds until a person decides — the gate where your judgment enters a run. Give the step a single route and a rejection fails the run. Give it two and the first is its approved path and the second its rejected path, so a rejection can branch into rework instead of stopping.
• Document steps name the outputs the workflow is expected to produce, each with a title, a path, and a prompt describing what belongs there.

You assign the agent, optional autonomy ceilings for the work and verification, and an optional verifier as you configure a step, so the graph carries the choices that are specific to this process rather than leaving them to be decided later.

Branch conditions route by meaning, not by code

A branch step chooses its path by reading conditions written in plain language. Each route out of a branch carries a condition, a sentence describing when that route should be taken, and the conditions are ordered by a sort value. When the branch is reached, an evaluator agent reads the conditions in that order and the first one that passes wins, so routing stays deterministic even though the conditions are natural language. You write the conditions and order them. You do not write rules or expressions.

Standard retries bound transient failures

Retries are part of the run behavior rather than something you configure on each step. If agent work fails or times out, Task Machine retries it with a standard bounded backoff before failing the run. If a verifier rejects a result or a document step does not produce what it promised, the run gives that step one bounded rework attempt and then fails if the problem remains. Budgets and retries covers how those bounds fit the larger control story.

Validation checks the graph before you rely on it

The builder validates a graph against deterministic topology rules so a broken process is caught while you are still drawing it. A valid graph has exactly one start step, keeps every edge within the definition, gives each outgoing route a distinct order, and routes deterministically: one route out of a plain step, the conditional routes out of a branch, and an approved-and-rejected pair out of a human approval. It also avoids cycles, since loops are out of scope. Validation is read-only and returns a complete list of problems with the step or edge each one points at, so you can fix the graph rather than guess. You save a definition as a draft while you are still shaping it. Validating it is how you confirm the graph hangs together.

Publishing freezes a draft into an immutable active version

When a draft is ready, you use Publish version, and that is what turns a graph you are editing into one a run can follow. Publishing first validates the source graph, then copies the whole definition, including its steps, edges, and branch conditions, into a new active version with its own identity and a published timestamp. The current workflow stays editable as the draft you were already working in, and that draft records a link to the version it produced so the next publish chains to the one before it.

The sidebar keeps that history visible while you work. Version history shows the Current draft first, then lists immutable published versions newest first below it. Open one of those published entries and the builder switches into a read-only historical view with Viewing version N at the top and Back to current to return to the editable draft.

This copy-on-save design is what makes a published version immutable: a run always executes against the exact version it started from, and editing the draft afterward never reaches back and changes a graph a run already followed. Changes always happen in the draft you publish next. You keep refining that draft and publish again when the next version is ready. Each published version is a frozen snapshot, and the link chain is the history of how the process changed. Scheduling stays on the same workflow identity, so future schedule firings keep resolving the latest published version even as you keep editing the draft. Only an active published version can be started. See workflow execution for how a run of one proceeds.

Workspace workflow playbooks use the same graph shape but sit outside the normal runnable list. When one appears in the command center, duplicating it creates a fresh draft with the playbook's retry policies, steps, edges, and branch conditions copied in, so you can adapt the graph before publishing it.

An agent can propose a workflow

An agent authors workflows as well as runs them, but its profile can gate workflow creation behind your approval. When it is gated, the agent proposes the definition instead of saving an ordinary draft: the graph is created in a held state with the agent's rationale attached, and it waits in your inbox and on the Proposed tab of the Workflows page, beside the active and archived definitions. From there you open the proposal to preview the graph it drew: its steps and the order they run in. You can then approve it into the workspace or reject it with a reason. A process an agent suggests becomes a runnable definition only once you have seen the graph and approved it, the same draft-and-approve pattern that governs autonomy throughout Task Machine.

From here, workflow execution describes how a run of a published workflow advances and what it records.