Work in Motriz
Flows
Run built-in multi-agent pipelines or create custom sequential, parallel, and review-loop flows.
Flows coordinate multiple agents when one model should not own every stage. They are optional: a direct single-agent run remains the default and does not require a flow wrapper.
Built-in flows
| Flow | Pipeline | Use it when |
|---|---|---|
| Claude Code | Claude Coder | You want one Claude Code run saved as a reusable flow choice. |
| Codex | Codex Coder at medium effort | You want one Codex run with the seeded defaults. |
| Ollama Cloud | Ollama Coder with repo tools | You want an Ollama Cloud coding run with local tools. |
| Plan → Build | Claude Planner → Ollama plan executor | The implementation benefits from a checked plan executed step by step. |
| Heavy Plan → Build | Claude Heavy Planner → Ollama plan executor | Architecture fit, blast radius, edge cases, and guarded steps matter. |
| Plan → Execute → Review | Claude Planner → Ollama Coder → Codex Reviewer | You want implementation followed by a review loop until approval or the loop limit. |
| Ollama Plan → Codex Build | Ollama Planner → Codex Coder | You want to invert the usual planning and implementation providers. |
Ventures also use internal founder fan-out flows for market and pain analysis and for validation synthesis. The co-founder invokes these behind the venture experience.
Create a custom flow
- Open Flows.
Choose New flow or select an existing flow to edit.
- Name the outcome.
Use a clear name and description that explain when the flow should be selected.
- Add the first step.
Choose a template or start with a single step, then set its execution mode, role, model, effort, Fast tier, and instructions.
- Add orchestration only where needed.
Reorder steps, add parallel branches, or configure a review loop.
- Save and test it on bounded work.
Every step and fan-out branch must use a model. Motriz prevents deleting flows while active runs still depend on them.
Step execution modes
| Mode | Behavior |
|---|---|
| Single | Runs one configured agent, then passes its transcript and output to the next step. |
| Plan executor | Consumes a prior structured plan and executes its steps with completion checks. |
| Fan-out | Runs several independent branches and preserves their separate findings before continuing. |
| Loop | Evaluates an approval phrase and returns to an earlier step when the reviewer has requested changes. |
Configure a step
- Name should describe the activity shown in the run timeline.
- Role supplies the full task behavior. Extra instructions should add flow-specific context rather than repeat the role.
- Model can come from any configured provider. A flow may mix providers freely.
- Effort is reconciled to what the chosen provider and model support.
- Fast selects the provider's priority tier where available.
Run parallel branches
A fan-out step is useful for independent investigations: for example, architecture, testing, and security reviews that should not influence one another before synthesis. Each branch must have its own name, model, role, effort, and optional instructions.
Flow fan-out coordinates branches inside one run. Dashboard parallel tasks isolate independent code changes into Git worktrees. Choose the mechanism based on whether you are parallelizing analysis or parallelizing repository mutations.
Configure a review loop
Enable a loop on the review step, choose the earlier step to repeat, define the approval marker, and set a maximum number of loops. The built-in review flow uses APPROVE and can return to the implementation step when specific fixes remain.
Keep the maximum bounded. A loop is a safety net for concrete review findings, not a substitute for a clear acceptance criterion.
Provider readiness
Before a flow can run, every provider used by every step and branch must be configured. If the composer marks the flow unavailable, either configure the missing providers in Settings → Providers or edit the flow to use ready models.