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 nodes

A workflow is a definition: a named graph of nodes 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, and you add, edit, reorder, and connect nodes directly on the canvas. Layout is the builder's concern; the definition itself stores the nodes, the edges between them, and the configuration each node carries, not where they sit on screen.

Each node is one step, and its node type decides what that step does:

• Agent nodes run an agent against a prompt and a set of context references — the documents, artifacts, files, memories, or tasks the agent should read before it works.
• Branch nodes 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 nodes 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 node 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.
• Artifact nodes 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, the runtime, and an optional verifier as you configure a node, 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 node 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 node. 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 an artifact 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 node, keeps every edge within the definition, gives each outgoing route a distinct order, 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 — and avoids cycles, since loops are out of scope. Validation is read-only and returns a complete list of problems with the node 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 publish it, 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 — its nodes, edges, and branch conditions — into a new active version with its own identity and a published timestamp. The draft you were editing stays a draft and records a link to the version it produced, so the next publish chains to the one before it.

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. You keep refining the 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. Only an active published version can be started — see workflow execution for how a run of one proceeds.

Workspace workflow templates 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 template's retry policies, nodes, 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 nodes and the order they run in — and 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.