Use cases

Several models, one project.

Different agents are good at different steps. In Morion the agent is a property of the node, not of the project. Claude writes, Codex reviews, a cheaper agent takes the trivial tickets, and Mo decides between steps on a model of its own. You set it once per node and once per folder.

15 minClaude Code · Codex · pi · opencode · Auto-codetemplates: Code + code review · Code only · Plan + plan review + code + code review (all Mo-driven)

1Name the agent on each node

Every cli_agent node in a workflow names its agent: claude, codex, pi or opencode, and optionally the provider and model it runs on. pi and opencode go through OpenRouter by default or a local Ollama, so a node can run an open model such as Kimi, GLM or DeepSeek, or a model on your own machine. Add a fallback, and the runner uses it when that agent is not installed or fails to start. A fallback does not rerun a stage that finished with a bad result; that is the reviewer’s job. The five shipped templates differ by which stages exist, never by which agent fills them. You set the agent per node.

Open Project Settings → Workflows, copy a template, open the copy, and set Agent and Fallback on each cli_agent node. Then pick the copy for your folder in Folder Settings → Auto-code. Or ask your agent to do it over MCP: workflows_copy, then workflows_update, then workflows_validate.

you → Claude CodeIn Morion, copy the workflow “Code + code review · Mo-driven” in project habit-tracker. Put codex in the reviewer slot with claude as fallback, keep claude as the implementer with codex as fallback, and validate it.
a cli_agent node, in the workflow JSON { "id": "fix", "kind": "cli_agent", "agent": "claude", "fallbackAgent": "codex", "promptTemplate": "Implement the ticket in the work packet. Run the tests. Report." }, { "id": "review", "kind": "cli_agent", "agent": "codex", "fallbackAgent": "claude", "promptTemplate": "Review the diff against the acceptance criteria. Verdict: approve or request changes, with reasons." }

2Give each step a different agent

A split that works for most teams of one. Each line is one slot you fill once, and the runner uses it on every ticket after that.

Implementer: the agent you trust with your repo
The one whose worktree habits you know. It gets the work packet and writes the diff.
Reviewer: a different vendor
A second model disagrees in different places than a second run of the first. Codex writes the review, and a mo_stage reads it and decides where the ticket goes. For a third view, add a second review node with an open model such as Kimi, GLM or DeepSeek, paid per token.
Trivial tickets: a cheaper agent, no reviewer
A second folder with the "Code only" template and a lighter agent in the slot, such as opencode on an open model or a local model through Ollama. Typos, renames, dependency bumps.
Planner and plan reviewer: the strongest pair
For large or ambiguous tickets, the four-agent template adds a plan and a plan review before any code. The plan reviewer can send the planner back.
Mo: its own backend
Indexing, decisions between stages and Ask Mo run on the provider or subscription you set in Settings → Smart Indexing → Indexing Models. Mo’s decisions between stages have their own line there, Auto-code Mo stages, so you can pick their model separately from indexing.

3Pick a workflow per folder

Workflows belong to a project. Each folder picks one in Folder Settings → Auto-code. So the heavy folder runs “Plan + plan review + code + code review”, the everyday folder runs “Code + code review”, and the chores folder runs “Code only” with the cheap agent. A ticket’s folder decides its process.

Auto-code settings live on the folder, the project and the workspace. Agents can read and change them over MCP with the Workflows tools.

Project · habit-tracker · folders
FeaturesPlan + plan review + code + code review · claude, codex, claude, codex
FixesCode + code review · claude, codex
ChoresCode only · opencode
NotesAuto-code off · AI access on

4Route a ticket by moving it

Moving a ticket between folders changes who will work on it. Move it while no run is in flight; the next run in the new folder uses that folder’s workflow. A fix that turns out to be a rename goes to Chores, and the cheap agent takes it with no reviewer. A chore that grows into a feature goes to Features, and it gets a plan and a plan review before any code.

Nothing else changes. The ticket keeps its body, its comments and its history, and the next run reads them in the work packet.

5What you have now

Vendors stop being a choice you make once for the whole project. They are a choice per step and per folder, and the board shows which agent did what on every ticket. Swap one slot and the next run uses the new agent; the tickets, the work packets and the board stay the same.

Download