Workflows

A workflow is a reusable process inside a project. It turns a substantial job into a directed acyclic graph (DAG) of small, inspectable units, then runs everything whose dependencies are satisfied in parallel.

Use a workflow when the shape of the work matters: implementation followed by review and revision, several independent changes converging on one merge, or a long process you want to pause, inspect, and rerun. A session remains the better fit for one continuous conversation.

The graph

A workflow is built from four pieces:

Edges — not slice order — decide what can run. Two nodes in different slices can run together when neither depends on the other; two nodes in the same slice can still be ordered by a dependency.

The graph marks each node’s kind, status, upstream nodes it waits for, and downstream nodes it blocks. During a run it also shows current, queued, and blocked signals plus the latest attempt metadata.

For every node kind and its execution behavior, see Workflow execution.

Opening the Workflows tab

Open a workspace and select Workflows. Workflows belong to projects, so the project picker at the top chooses which project’s list you are viewing.

The left rail stays visible while the selected workflow’s detail scrolls on the right. A list row shows the workflow title, state, root worktree, update time, and whether a run is active.

Workflow states are:

• Draft — an authored shell that has not been promoted to an executable graph.
• Graph ready — task-breakdown authoring produced a valid executable graph.
• Archived — retained but set aside.

The validation panel, not the state badge by itself, determines whether Start Run is blocked.

Creating and authoring

There are two entry points:

• In an empty Workflows tab, select Create your first workflow. Brisal creates and selects an untitled draft.
• Ask an agent with Read workflows and Write workflows enabled to create one from your conversation. The agent can create the draft, inspect it, write its spec, and apply a task breakdown. Authoring never starts a run by itself.

The Graph editor lets you add and edit slices and nodes directly. A slice has a title, layout order, and optional worktree override. A node has a kind, slice, prompt, agent-pool and thinking overrides, timeout and retry overrides, declared inputs, instructions, parameters, and a disabled state.

Edit a node’s Dependencies to choose every predecessor it must wait for. The selector groups candidates by slice and marks cross-slice dependencies. Self-dependencies and cycles are invalid. Validation separates blocking errors from warnings; blocking errors disable Start Run.

The manual editor does not currently expose slice or node deletion because it cannot confirm the necessary run-history state. Disable a node instead so the definition and its evidence remain intelligible. An agent applying a task breakdown can reconcile removed structure through the history-aware authoring path.

Binding worktrees

Before the first run, choose and save a root worktree in Run setup. You can select an existing worktree or create one from the same surface.

A slice normally inherits the root. Give a slice its own worktree when you want its changes isolated. Brisal adds a Merge node back toward the root; that merge still obeys explicit graph dependencies and never runs merely because the slice finished.

Runs do not coordinate writes with other runs. If another active workflow uses the same worktree, Brisal warns you, but it does not block either run. You own the concurrent-write risk.

Starting and watching a run

A run is one execution of the workflow. Start Run becomes available after the root worktree is saved and validation has no blocking errors.

The run viewer separates:

• the current node;
• graph-ready nodes waiting for capacity;
• blocked nodes;
• every attempt, including its state, agent, provider, thinking level, and terminal reason.

An attempt is one try to execute one node. Agent-backed attempts create ordinary workflow sessions, shown below the run and grouped by worktree. Open any row to inspect its complete transcript. Workflow sessions stay out of the normal session list by default, keeping the sidebar focused on conversations you started.

Approval nodes appear under Approval gates. Approve completes the gate and lets dependents advance; Reject blocks it.

Run controls, rerun semantics, snapshots, scheduling, retries, recovery, and all lifecycle states are defined in Workflow execution.

Editing after a run starts

You may keep editing the workflow while a run is active, but the active run uses the graph and execution policy it captured at start.

Agent configuration is the deliberate exception: a run freezes agent ids and pool order, then resolves each agent’s current configuration when an attempt starts. Editing, disabling, or deleting an agent can therefore affect a later attempt in an active run.

What to read next

• Workflow execution — node kinds, policy, scheduling, lifecycle, reruns, review/revision, and recovery.
• Worktrees — the branches workflow nodes act on and how merge conflicts are resolved.
• Sessions — the transcript behind every agent-backed attempt.
• Agents — agent tool policy, models, thinking, and behavior.