i would love a deterministic program that can confidently make plans for lower-cost models like deepseek. ofcourse the LLM part wont be deterministic, but its a lot easier to measure quality like this. you could argue an AGENTS.md is this, but from experience its not enough to make non-frontiers act have a high success rate.
Fair — AGENTS.md is prose the model has to re-interpret every session, and that reinterpretation is exactly where weaker models lose the thread. Here the plan is parsed and enforced as structured data: tasks with declared dependencies and one prompt each, so the per-step job is smaller and the plan isn't up for renegotiation. Nothing in that needs a frontier model
I just haven't benchmarked it against deepseek-class runners, and the runner is pluggable if you want to be the one who does.
What I kept hitting wasn't coding agents writing bad code. It was one agent trying to hold a whole change in its head. I'd give it a multi-step goal, it would start work, and its misreading of the first step only surfaced once the fourth one was on disk. The plan itself was never anywhere I could read it, so there was nothing to correct — only something to undo.
So I built Ordewell: the plan is a typed artifact here, not agent state. You describe a goal, a planner explores your repo read-only and comes back with an ordered list of tasks, each carrying its own runner, model, thinking effort and mode. You rewrite prompts, add or delete tasks, rewire dependencies, or swap the model on one task — before anything runs. Then each task runs as one real agent session, and the board holds the rest: done, running, blocked, left. Manual steps sit in the same list as checkboxes.
Four things that may be worth your time even if the tool isn't:
- One task, one session, one small context. The planner's sizing rule is explicit: each slice must fit one fresh session's context window, or it gets split. A task then starts clean and is handed only what it needs — its own prompt, a window of the plan marked "you are here", and a short tail of its direct dependencies' output. Nothing else from the run, and nothing from another task's transcript. A long session doesn't announce that it has lost the thread — it just keeps going, which is the part that costs you. Writing the plan down is what buys the alternative: no session has to carry it.
- The planner isn't asked not to write — it's prevented. Every research command is lexed the way a shell lexes it (quotes, backslashes, command substitution) and classified per segment into run / ask-once / refuse. The refuse tier returns before the approval seam is reached, so there is no prompt that unlocks it and no system-prompt wording that talks it into one. Anything reaching outside the workspace asks once. The read-only-planner / writing-runner split is the whole architecture.
- Completion is decided by evidence; the judgement calls are decided by you. Each task gets a unique marker, and it's done when that marker appears in the runner's output, with the exit code retained beside it as separate evidence. The model is never asked whether it thinks it succeeded — a clean exit without the marker fails loudly. The planner also classifies each task up front as autonomous or human-in-the-loop, and a human-in-the-loop task stops before the step you can't take back: it prints what it's about to do and why, and waits for approve or reject.
- There's no extra API key. Claude Code, Codex and OpenCode can each be the planner as well as the runner, on the subscription you already pay for. Enable more than one and the planner assigns a different one per task — the argument being that a security refactor and a README update do not deserve the same model. Other agents are a plugin manifest, not a code change.
What it is not: the planner is still an LLM and writes bad plans sometimes — the whole bet is that a bad plan is cheap when you can see and edit it, and expensive when it's hidden. The command classifier is a classifier, not a sandbox; container it if you want a hard boundary. The marker proves the agent finished and claimed the work, not that the code is correct — that's what your tests are for. TUI needs tmux; VS Code and the HTTP daemon don't. Node >= 20.
The second line is the VS Code panel; it carries its own core, nothing to install from npm.
Apache-2.0, no paid tier, nothing to sign up for. Docs and a demo at https://ordewell.ai
What I'd most like to hear: whether the per-task model assignment is real value or a knob nobody wants, and where the read-only planner boundary is too strict to be useful.
What I kept hitting wasn't coding agents writing bad code. It was one agent trying to hold a whole change in its head. I'd give it a multi-step goal, it would start work, and its misreading of the first step only surfaced once the fourth one was on disk. The plan itself was never anywhere I could read it, so there was nothing to correct — only something to undo.
So I built Ordewell: the plan is a typed artifact here, not agent state. You describe a goal, a planner explores your repo read-only and comes back with an ordered list of tasks, each carrying its own runner, model, thinking effort and mode. You rewrite prompts, add or delete tasks, rewire dependencies, or swap the model on one task — before anything runs. Then each task runs as one real agent session, and the board holds the rest: done, running, blocked, left. Manual steps sit in the same list as checkboxes.
Four things that may be worth your time even if the tool isn't:
- One task, one session, one small context. The planner's sizing rule is explicit: each slice must fit one fresh session's context window, or it gets split. A task then starts clean and is handed only what it needs — its own prompt, a window of the plan marked "you are here", and a short tail of its direct dependencies' output. Nothing else from the run, and nothing from another task's transcript. A long session doesn't announce that it has lost the thread — it just keeps going, which is the part that costs you. Writing the plan down is what buys the alternative: no session has to carry it.
- The planner isn't asked not to write — it's prevented. Every research command is lexed the way a shell lexes it (quotes, backslashes, command substitution) and classified per segment into run / ask-once / refuse. The refuse tier returns before the approval seam is reached, so there is no prompt that unlocks it and no system-prompt wording that talks it into one. Anything reaching outside the workspace asks once. The read-only-planner / writing-runner split is the whole architecture.
- Completion is decided by evidence; the judgement calls are decided by you. Each task gets a unique marker, and it's done when that marker appears in the runner's output, with the exit code retained beside it as separate evidence. The model is never asked whether it thinks it succeeded — a clean exit without the marker fails loudly. The planner also classifies each task up front as autonomous or human-in-the-loop, and a human-in-the-loop task stops before the step you can't take back: it prints what it's about to do and why, and waits for approve or reject.
- There's no extra API key. Claude Code, Codex and OpenCode can each be the planner as well as the runner, on the subscription you already pay for. Enable more than one and the planner assigns a different one per task — the argument being that a security refactor and a README update do not deserve the same model. Other agents are a plugin manifest, not a code change.
What it is not: the planner is still an LLM and writes bad plans sometimes — the whole bet is that a bad plan is cheap when you can see and edit it, and expensive when it's hidden. The command classifier is a classifier, not a sandbox; container it if you want a hard boundary. The marker proves the agent finished and claimed the work, not that the code is correct — that's what your tests are for. TUI needs tmux; VS Code and the HTTP daemon don't. Node >= 20.
The second line is the VS Code panel; it carries its own core, nothing to install from npm.Apache-2.0, no paid tier, nothing to sign up for. Docs and a demo at https://ordewell.ai
What I'd most like to hear: whether the per-task model assignment is real value or a knob nobody wants, and where the read-only planner boundary is too strict to be useful.