Work goes to whatever AI happens to be open, and nothing decides that except availability. That default looks harmless until you follow it: the most expensive executor in the stack ends up with the tasks that need it least. A recurring monitoring check, a one-off file scan, a log lookup: none of them needs the model that was built for harder work. The constraint that ruled out the obvious answer was cost and the boundary between tools; letting the agentic model take whatever task appears is the posture that inflates the bill. So I stopped choosing executors by availability and made the task’s shape choose for me. The rule sits inside Reliable agent systems.
TL;DR
Route every task by its shape before starting, and keep monitoring and log work off the expensive path. Recurring and deterministic work belongs in a Script/Automation built once to run forever; only the work whose shape genuinely needs the agentic model should reach it. The decision costs nothing to apply, and it prevents the class of cost a default sends the wrong way.
Pick the executor from the task’s shape
The rule is a fixed decision tree, and I run it before a task starts, never after. Recurring and deterministic work becomes a Script/Automation, built once to run forever. Work that needs current, verified, web-sourced information goes to Ren. Work that touches code, files, or git goes to Claude Code. Work that needs cross-session memory or pattern detection goes to Hermes/Izuna. A task that fits none of those gets no AI at all, and monitoring and log work never goes to Claude Code, whatever it looks like at a glance.
Two alternatives were live, and I rejected each on a stated reason. The first was sending monitoring and log tasks to Claude Code; the cost penalty against an Izuna tool is what killed it, and that is the pathway this rule was written to close. The second was not deciding at all, leaving routing to the AI at hand; a guardrail that says which tool is wrong for which task class rejected that.
The tree decides which executor takes a task, not who may touch what. Separating spec, build and QA is that other axis: the write boundary and the hand-off chain, not the class of work.
The tree, at the level you could adopt it
Adopting the tree needs no new service: it is a short check you run before starting a task, and its answer is an executor you already have.
| Task shape | Executor |
|---|---|
| Recurring and deterministic | Build a Script/Automation (build once, run forever) |
| Needs current, verified, web-sourced information | Ren |
| Touches code, files, or git | Claude Code |
| Needs cross-session memory or pattern detection | Hermes/Izuna |
| Fits none of the above | No AI |
The value is in the left column. The task’s shape decides the executor, never brand preference or habit, and that is what keeps the tree a judgment rather than a default. Claude Code is named here as the tool the code branch uses, not as a preferred one; the same rule sends work away from it whenever the shape says so, and monitoring stays on Izuna tools.
The executor is only half of the routing question. Which model a chosen executor runs is its own decision, and where it runs, local or cloud, is another.
What the ad-hoc default cost
The failure lived in the default, not in any single task. With routing left to availability, the expensive executor absorbed the class it should never touch: monitoring and log work ran on Claude Code, and each of those tasks carried the 10–50× cost penalty of using it instead of an Izuna tool. Nothing about that work justified the capability it was paying for.
The rule does not make such tasks cheaper in the moment; it stops them from arriving at the tool that inflates them. The routing decision is the guard that keeps the monitoring class off Claude Code, and the rejected alternative is the pathway: the penalty is real, and leaving routing to habit is what lets it accumulate.
What the rule itself costs to run
Nothing beyond the moment of deciding. The heuristic adds no service and no model call: it is a decision applied before a task starts, not a step inside the pipeline. The 10–50× belongs to the task the rule diverts, not to the rule; it is the comparative penalty the tree avoids when it sends monitoring to an Izuna tool, never a running cost of the tree itself.
What the tree does not do
The tree routes; it does not check what comes back, and it does not secure the machine that runs the work.
Three layers sit outside it. Stopping an ungrounded line before it reaches a user is a deterministic output guard of its own. Confining an executor to the files it may touch is the operating-system boundary, a different register. Running a chosen automation every day without supervision is its own discipline, and the rendering contract that makes a model’s output deterministic is its own architecture.
The boundary that matters most is the tree’s last branch. The “otherwise no AI” floor is a boundary, not a destination: it marks work that should not go to a model at all, and it is not a claim that the rest should run unattended. A task whose shape is ambiguous still needs a judgment call between the branches, and the person making the route is the one who keeps the tree from becoming a promise about autonomy.
The trade-offs I accepted to run this stack are on the about page. If your team sends work to whatever AI is at hand and the bill shows it, let’s talk.