Why I stopped choosing one coding agent — and route each task to the one that fits

Ordewell — Wed, 05 Aug 2026 23:31:19 +0000

Disclosure up front: I built the tool described here. Free and Apache-2.0;
the point of this post is the design thinking, not a purchase.

Most agent tooling assumes you've picked a vendor. You're a Claude Code shop or
a Codex shop or a Cursor shop, and everything you run is that one thing. But
that assumption was never true for me — Codex is better at some tasks, Claude
Code at others, and I wanted a single plan that could use both without me
shepherding each step by hand.

This post is about the design decision behind letting one plan hand work to
different agents — and what it takes to make that safe.

A plan as a portfolio decision

The tool starts the same way each time: a goal in, a planner reads the repo
read-only, and an ordered list of tasks comes back. What's different is that
each task carries its own runner, model, thinking effort, and mode. The planner
makes one portfolio decision across the whole plan — a security refactor and a
README update should not get the same model, let alone the same agent — and
shows you every assignment before anything runs. You can change any of it.

That's the part worth dwelling on: per-task routing as a first-class feature,
decided in the open, rather than "pick one agent and hope."

Adding an agent is a plugin manifest, not a fork

The barrier that usually stops multi-agent setups is that wiring in a second
agent means invasive code. Here, adding an agent is a small plugin manifest, not
a code change. Claude Code, Codex, and OpenCode ship built-in; Aider or your own
CLI is just another manifest. The planner reads each runner's catalog, so a
task's mode and model re-derive from what that runner can actually spawn — you
can't configure a task into a runner that can't run it.

The safety boundary that makes mixed plans viable

Routing work across agents raises an obvious question: what stops the planner
from doing damage in your repo? Two answers, both deliberate.

First, the planner can't write. Research commands are lexed the way a shell
would lex them and classified per segment; the write tier returns refused before
any approval prompt exists, so there's no "allow once" to click through.
Mutation belongs to the runners.

Second, completion is evidence-based. A task is done only when its unique
completion marker appears in the runner's output, exit code retained separately.
No agent grades its own work — the marker and the exit code agree, or it fails.

Honest limits

The planner is an LLM and occasionally produces a bad plan — the argument for
this design is that you see the bad plan before a single execution token is
spent. Also, mixing runners means you hold the subscriptions for whatever you
mix: it rides the Claude subscription you already have for Claude Code, the
Codex subscription for Codex. No extra API key, but also no free ride for a
runner you don't already pay for. And the TUI needs tmux (WSL on Windows); the
CLI and VS Code extension don't.

Try it

npm install -g ordewell && ordewell

GitHub: github.com/ordewell/ordewell
Apache-2.0, free.

One question I'd genuinely like input on: is per-task model routing useful, or a
knob nobody touches? Curious what multi-agent people think.

How I stopped my coding agents from writing files before I could see the plan

Ordewell — Wed, 05 Aug 2026 23:04:43 +0000

Disclosure up front: I built the tool this article walks through. It's
free and Apache-2.0, so my interest is "people find this useful" more than
"people pay me."

The failure that sent me down this path is probably familiar. I give an agent a
multi-step goal: refactor this module, update the README, add tests. Everything
goes fine until step 4 — where I discover it misread step 1 back at the start.
By then files are written. There's no plan to correct, because the plan lived in
the model's head. There's only something to undo.

That's the core problem: the plan is a side effect of the session, not an
artifact you can inspect and edit. This post is about the design decision I
landed on to fix it — make the plan the thing you approve, not the thing you
hope for.

The plan is a typed artifact

The tool reads your repo read-only, then hands back an ordered list of tasks.
Each task carries four pieces of metadata: the runner (Claude Code, Codex, or
OpenCode), the model, the thinking effort, and the mode. That's not decoration —
those four are what the task actually runs as. You can rewrite any prompt, add
or delete a task, rewire dependencies (task 4 depends on task 2), or change
the model on a single task. Completed work stays done. Nothing round-trips the
AI while you edit.

Why a separate planner

The natural question is "why not just use plan mode?" Two reasons.

First, plan mode plans inside the session that then executes — the plan is
advisory and the model can drift from it. Here, the plan is produced by a
separate process that physically cannot write to your repo. Its exploration is
strictly read-only; commands that would write are refused before an approval
prompt even exists, so there's no "allow once" to click through. Mutation
belongs to the runners, not the planner.

Second, per-task assignment. A security refactor and a README update do not
deserve the same model. The planner makes that portfolio decision across the
whole plan, in the open, before you spend a single execution token — and you can
override any of it.

Verdicts from evidence, not opinion

The part I care most about happened later. Agents are bad at grading themselves
— and worse, they'll announce success on a build that doesn't compile. So a task
here is marked done only when its unique completion marker appears in the
runner's output, with the exit code retained beside it as separate evidence. The
model is never the tie-breaker. If the session finished and claimed the work
without the marker, it fails loudly.

If you've watched an agent say "done" and then open a file that's still broken,
that's the whole motivation.

Honest limits

The planner is still an LLM and writes bad plans sometimes. The argument isn't
that it's always right — it's that a bad plan you can see and edit costs a
minute, and one you can't costs an afternoon. The completion marker proves the
session finished and claimed the work, not that the code is correct.

Also: the TUI needs tmux on every platform (on Windows, that means WSL). The CLI
and the VS Code extension run natively without it.

Try it

npm install -g ordewell && ordewell

Point it at a repo you know well and read the plan it hands back. That first
plan is the whole argument.

GitHub: github.com/ordewell/ordewell
Apache-2.0, free, no paid tier.

Happy to answer anything, including "why not just do X."

DEV Community: Ordewell

Why I stopped choosing one coding agent — and route each task to the one that fits

A plan as a portfolio decision

Adding an agent is a plugin manifest, not a fork

The safety boundary that makes mixed plans viable

Honest limits

Try it

How I stopped my coding agents from writing files before I could see the plan

The plan is a typed artifact

Why a separate planner

Verdicts from evidence, not opinion

Honest limits

Try it