Work in Motriz
Flows
Run the built-in flows or create your own with Single run, Plan executor, and Fan-out steps, plus per-step review loops.
A flow is a saved recipe for a run, made of one or more steps. Each step picks its own provider, model, role, and reasoning effort — the Flows page puts it plainly: "Each step picks its own provider, model and reasoning effort — mix them freely." A flow is one of two ways a run executes; the other — the default — is a single agent.
Flows are optional
Single-agent runs are first-class. A thread with no flow runs one agent with the provider, model, effort, and role set in the composer, and that is often the best choice: one strong model with a clear prompt has no handoffs to lose context across. Reach for a flow when the work has stages — a plan worth writing before implementation, a review gate, or several independent angles on one question.
In a Build thread the composer carries a two-button mode toggle, "Single agent" and "Flow". In flow mode the model, effort, and role pills are replaced by a flow picker (placeholder "Select flow"). Chat, Product design, and co-founder threads never show flow controls.
Run the smallest useful version of the work with a single agent first. Add a flow only when you can name the stage that a second configuration would do better.
Built-in flows
Motriz seeds a set of built-in flows, marked with a "built-in" badge on the Flows page. Their descriptions, verbatim:
| Flow | Description |
|---|---|
| Claude Code | "A single Claude Code agent (Coder), end to end." |
| Codex | "A single Codex agent (Coder, medium effort)." |
| Ollama Cloud | "A single Ollama Cloud agent (Coder) with repo tools." |
| Plan → Build | "Claude plans, then Ollama implements each plan step with fresh context and completion checks." |
| Heavy Plan → Build | "Claude writes an exhaustive, guarded plan (architecture fit, blast radius, edge cases), then Ollama executes it step by step — the plan is written so a smaller model can follow it safely." |
| Plan → Execute → Review | "Claude plans, Ollama implements, Codex reviews — looping back to the coder until approved." |
| Ollama Plan → Codex Build | "An example with the providers flipped: Ollama plans (fast), Codex implements." |
The co-founder may coordinate specialist work internally, but that orchestration is presented as co-founder activity rather than as named roles or editable Founder flows. The Flows page is a Build surface and lists Build flows only.
Built-ins you edit are kept as your version; built-ins you delete stay deleted; unedited built-ins refresh when Motriz updates their definitions.
The journey's build handoff assigns "Plan → Build" to every task it seeds. If you deleted that flow, the handoff refuses to run: "The Plan → Build flow is unavailable. Restore it before starting the build handoff."
Create a flow
- Open the Flows page.
Use the "Flows" button in the sidebar footer, or "Manage flows…" in the composer's flow menu. Escape navigates back.
- Start a flow.
Click "New flow", then give it a name and a description of what it is for.
- Add and configure steps.
Each step gets its own execution mode, role, model, effort, and instructions. The read-only Pipeline strip shows the step chips joined by →, adding "with review loop" when any step loops.
- Save.
"Create flow" or "Save changes". Validation is strict: "Name is required", "Add at least one step", "Every step needs a model".
Deleting a flow asks for confirmation and is refused while runs are active ("Stop active runs before deleting flows.").
Configure a step
- Name — what the step's row will say in the activity stream, e.g. "Planner".
- Execution — exactly one of "Single run", "Plan executor", or "Fan-out" (see below).
- Role — any of the build roles, or "Custom". With a role selected, the text area is "Extra instructions (optional)" and layers on top of the role's prompt; with "Custom", the field becomes "Instructions" and your text is the entire system prompt.
- Model and effort — any model from any configured provider; effort offers "Default" plus that provider's levels. Roles are provider-neutral: the same role prompt is adapted to whichever provider runs the step, so a flow can mix providers freely.
- Fast tier — a switch that appears only for models that support the provider's fast service tier.
- Max iterations — 1–100; new steps default to 14.
Execution modes
| Mode | Behavior |
|---|---|
| Single run | One provider invocation for the step. The default, and right for most steps. |
| Plan executor | Takes the previous step's structured plan and executes it item by item, each item with a fresh provider invocation, then runs completion-check passes until the checker is satisfied — capped by the step's "Completion passes" field (1–50, default 10). |
| Fan-out | Runs several branch configurations at once as real child runs, and joins their results before the next step. |
A fan-out step has a "Parallel branches" section with an "Add branch" button. Each branch carries its own name, model, effort, role, and instructions; branches always execute as plain single runs and cannot loop. Validation: "Fan-out steps need at least one branch" and "Every fan-out branch needs a model".
The review loop
Any step can gate the flow with the per-step switch "Loop back to an earlier step until approved". You choose "Loop to" (the step to repeat from), "Approve when" (an approval token, default APPROVE), and "Max loops" (default 2). When the gating step finishes, Motriz checks whether its output ends with the token; if not, the flow returns to the target step, until approval or the loop limit. Re-entered steps show a "pass N" badge. The seeded Reviewer template is written for this contract: it ends with a standalone APPROVE, or REVISE followed by a numbered fix list.
Agent templates
The step list ends with an "Insert from template…" select, which adds a step from a saved agent template — a named bundle of model, effort, role, instructions, and iteration limit. Only templates whose role fits the flow are offered. Motriz seeds one starter template per role; templates are also the named agents that delegated sub-agents can reference.
Running a flow
Next to the composer's flow picker, a chain of provider pills (for example Claude → Ollama → Codex) summarizes the providers the flow uses. If any is unconfigured, the pill warns "{Provider} not set up": "This flow uses providers that aren't configured. Set them up in Settings → Providers, or edit the flow to use different providers." The flow stays selectable, but the run is refused until every provider is ready in Settings → Providers.
In the activity stream, a multi-step flow run's turn row carries a "flow" badge and reads "step X of Y" while it runs; a single-step flow presents like a single-agent run. Steps render as numbered rows: pending steps show "queued", skipped steps show "skipped". A plan-executor step reports "{done} of {items} items", gives each plan item its own numbered row titled with the item, and shows its verification passes as "Completion check (pass N)" rows. A fan-out step adds a "fan-out ×N" badge, with each branch a "delegated" child row — collapsed by default, even while running. When the run settles, the turn folds into a one-line receipt with its token, cost, and duration totals.
Choosing a shape
Single agent, no flow
The default. Bounded work, one clear prompt, one capable model.
Plan, then execute
A planner step feeding a plan-executor step, so each plan item gets fresh context — the shape of "Plan → Build".
Add a review loop
When correctness is worth extra passes, gate with a reviewer that loops back until it approves.
Fan out
Several independent angles on one question, run at once and joined for the next step.
Fan-out parallelizes branches inside one run. Durable tasks in Build's queue each run their own flow or single agent, and tasks staged in parallel are isolated in their own Git worktrees. Use fan-out for analysis within a run; use parallel tasks for independent code changes.