Your Agent Doesn't Need a Bigger Model. It Needs a Smaller Task.

The execution agent fails. Not catastrophically — it just does the wrong thing confidently, touches files it shouldn’t, and stops short of the part that mattered.

So you reach for a bigger model. It fails less often now, and costs several times more per run. You are still reviewing every diff by hand, still re-explaining the same constraints, still finding out at review time that the agent solved a different problem than the one you had.

At some point the bill arrives and the question sharpens: why does execution need the most expensive model I own?

It doesn’t. It needs a smaller task.

What you are actually paying for is ambiguity

A model’s reasoning budget goes to whatever is unresolved at the moment it starts. Hand an agent a vague instruction and it must first decide what you meant — infer the intent, guess the boundaries, reconstruct the constraints nobody wrote down, choose between three defensible interpretations. That inference is the expensive part. For most of what a backlog actually contains — wiring, refactors, integrations, bounded fixes — the code itself is comparatively trivial. Genuinely hard implementation exists, and it belongs on a frontier model. It is just rarer than your bill implies.

This is why bigger models feel like they help. They are better at inference. They’re better at guessing what you meant. But you’re paying frontier prices to have a machine reconstruct information you already had and simply never wrote down.

We’ve made the process version of this argument before: agents don’t remove process, they punish bad process. This is the economic version of the same claim. Ambiguity is not just a quality problem. It’s a line item.

The obvious objection: retiring ambiguity costs frontier tokens too. True — you don’t eliminate the inference, you relocate it. It pays because you do it once, against one spec, and then amortize it across every task underneath.

Which suggests a different way to build the pipeline. Instead of one powerful model doing everything, run a sequence of stages where each one removes a single ambiguity — and every ambiguity removed upstream is one less thing the next stage has to infer.

Each stage removes one ambiguity

Read the first six rows top to bottom and watch the ambiguity drain out. The last two put judgment back in, deliberately — more on that below. By the time you reach execution, there is very little left to decide. The stage everyone treats as the hard part is the stage with the least thinking left in it, if the stages above it did their jobs.

Those eight stages group into three — Decide, Execute, Verify — and the grouping is where the money is.

Decide

This is where the expensive reasoning belongs, and where it earns the most.

A spec turns a fuzzy intent into a fixed, arguable artifact. Its real value is that it is cheap to change your mind here. Rewriting a paragraph costs nothing. Rewriting a paragraph after twelve tasks have been executed against it costs twelve tasks.

A plan turns the spec into an approach: phases, sequence, dependencies, and — critically — the acceptance criteria each task will inherit. A plan without explicit success criteria hasn’t removed a single ambiguity. It has only reformatted it.

Tasks turn the plan into discrete units with explicit boundaries, state, and checklists. This is the stage that does the most economic work in the whole pipeline, and it’s the one most people skip.

Here is why it matters so much. A frontier model can usually recover from a coarse, underspecified task. A cheap model usually can’t — it infers too, it just infers badly, and its failures are quiet and confident rather than obvious. What it does reliably is follow. Give it an explicit boundary, an explicit acceptance criterion, and an explicit file to touch, and it produces a diff that passes the same gate for a fraction of the cost.

The whole argument fits in one line of task text. Here is the version most backlogs contain:

Fix auth.

And here is the same work, decomposed:

Update the OAuth callback validation in auth/callback.ts so expired state tokens are rejected. Do not touch the refresh flow. auth/__tests__/callback.spec.ts must pass.

Same intended change. Completely different demands on the model:

The second task isn’t better because it’s longer. It’s better because nothing is left to infer — and inference is precisely what you were paying frontier prices for.

Someone still had to know it was callback.ts, that the refresh flow was adjacent and risky, and that a spec file existed to point at. That knowledge isn’t free — it’s investigation, and investigation is expensive. The thinking didn’t disappear. It moved upstream — bought once, in spec and plan, instead of re-bought inside every task at execution time. The decomposed task is cheaper because the thinking already happened somewhere you could write it down.

So decomposition is not project-management hygiene. It’s cost engineering. Which gives you a rule worth keeping:

Size a task so that the cheapest model capable of doing it correctly is the one that runs it.

It cuts both ways: too coarse and you’re forced back up a tier, too fine and orchestration overhead eats the savings. Not “as small as possible” — “small enough to require no inference.”

One good decision here propagates into twenty tasks below it. That’s the leverage, and it’s why this stage is worth real money.

Execute

This is where the pipeline gets cheap, and where it parallelizes.

Staffing matches capability to work. A domain agent that already knows Cargo layout, ownership rules, and property-oriented testing brings context a generalist has to rediscover on every run. Staffing is not about intelligence — it’s about not paying twice for knowledge you’ve already encoded. Valdr ships a roster of domain and utility agents for exactly this reason.

Sprints answer the sequencing question: what runs now, what waits on what, and who reviews the output. This is the stage that makes parallelism safe rather than chaotic. Running five agents at once is easy. Running five agents at once without them colliding, duplicating work, or landing in an order that breaks the build is a scheduling problem, and scheduling problems want an explicit answer, not a hopeful one.

Execution is the stage everyone thinks is the main event. By now it’s close to mechanical. The task says what to do, the acceptance criteria say what done looks like, the agent has the domain context and the workspace to search. There’s no intent left to reconstruct.

This is the inversion worth sitting with: if your execution stage needs a frontier model, that is not a model problem. It’s a diagnostic. It’s telling you that ambiguity leaked downstream and something has to resolve it at the most expensive possible moment — during execution, in parallel, across every task at once.

Verify

And here the cost goes back up, on purpose.

Most of review does decompose, and should: types, tests, lint, coverage, and secret scanning are mechanical, and most of them need no model at all. What’s left over is the one question no check can ask — does this diff do what the spec meant, or only what it said? That residue is small, and it is the expensive part. Structured review with explicit scoring dimensions makes that judgment repeatable and comparable across runs; it does not make it cheap, and you shouldn’t want it to.

Close-out is the stage almost nobody runs, and it’s the one that turns a checklist into a pipeline. An audit doesn’t grade the code — review already did that. It grades the run. Was the spec sufficient? Did the plan decompose cleanly, or did one task quietly absorb three others? Was the agent staffed correctly? Did the cheap tier actually hold, or did it thrash and get escalated?

Those answers are inputs to the next spec. Which is what makes this a loop rather than a line.

The cost curve is a U

Plot cost against stage and the pipeline has a shape — expensive at both ends, cheap through the middle:

And the middle is where nearly all the volume lives. One spec, one plan, then a dozen tasks executed a tier or two down, then one gate.

Most people run that line flat at the frontier price — one expensive model for every stage, from first idea to final merge. That’s the configuration that feels safest and costs the most, and it’s the one that produces the least structure, because a single long-running session never has to write anything down.

Everything lives in the context window, and a context window is not an artifact.

The session closes and the reasoning goes with it.

The U-shape costs less and leaves artifacts behind — and of those two, the second is what actually matters.

The savings are real but bounded, and model prices fall on their own anyway. The artifacts compound. A spec you can argue with, a plan you can re-run, a task another model can pick up cold, a review score you can compare against last sprint’s — none of that exists inside a transcript. Cheap execution is the visible win. The durable artifacts are the real one.

Routing should be configuration, not discipline

None of this works if “use the cheap model for execution” is something you have to remember at 2am.

In Valdr it isn’t. A launcher preset is a named, reusable record of provider and model: providerType picks the backend — Claude, Codex, Gemini, OpenAI, Anthropic, or a local Ollama runtime — and config pins the model and permission mode. Sessions launch against a preset key, not an ad-hoc choice.

So the U-curve becomes three presets:

planner-frontier   → frontier model, spec and plan work
executor-standard  → cheap or open-weight model, task execution
reviewer-judgment  → frontier model, review and audit gates

Attach the preset to the stage and the routing happens whether or not you’re paying attention. That local Ollama option matters more than it looks: for tasks that have been decomposed until they require no inference, an open-weight model running on your own hardware is often sufficient — and its marginal cost is electricity.

There’s a second half to this, and it’s the part that makes the cheap tier actually hold. Routing a task down-tier only works if the instructions that arrive there are written for a down-tier model, and open-weight models vary widely in how literally they follow loose phrasing. Model targeting lets a single pack adapt its prompt content to whichever model is running, so the cheap tier gets the explicit version without you maintaining a forked set of prompts. What doesn’t adapt is the governance — capability IDs, scoring rules, and charter identity stay fixed across tiers. The wording flexes; the standard doesn’t.

Local-first: Valdr runs on your machine. Presets, plans, tasks, sessions, and review records live in your local workspace and stay there until you delete them.

The loop closes

Run this once and it’s a process. Run it repeatedly and something better happens: the close-out audit starts improving the stage furthest from it. Signal from the end of one run lands at the start of the next.

An audit that says “three tasks in this sprint all had to be escalated to a frontier model” is not a complaint about the model. It’s a measurement of your decomposition. It tells you the plan stage produced tasks that still contained ambiguity — and it tells you before you write the next plan, not after you’ve paid for another sprint.

That feedback has nowhere to land in a prompt-driven workflow. There’s no artifact to attach it to, no stage to correct, no record that the escalation happened. The session ends, the lesson evaporates, and the next sprint makes the same mistake at the same price.

You are already doing all eight stages

This is the part worth being honest about, because the pipeline looks like heavy process and the objection is fair on its face.

But you already do all of this. You decide what you’re building. You break it into pieces and work out what has to land first. You do the work. You review it. You form an opinion about whether it came out right.

You just do most of it implicitly, inconsistently, and inside your own head — which means none of it is reusable, none of it is inspectable, and none of it can be handed to a cheaper model. The pipeline doesn’t add eight steps. It makes eight steps you already perform explicit enough that something other than you can run them.

That’s the trade, and it isn’t free. Writing down a decision you could have held in your head is a real cost, paid before anything runs. You pay it once per decision instead of once per session.

And in exchange, the expensive thinking stops being something you re-purchase on every single run.

Fix the stage that feeds the one that’s failing

If your execution is flaky, don’t upgrade the model. Look at the task.

Take a task that went badly and ask what the agent had to guess. Then write that down in the task — as an acceptance criterion, a boundary, an explicit file, a constraint. Re-run it on a smaller model than the one that failed. If it works, you’ve just found the real problem, and it wasn’t the model.

Do that a few times and the pattern becomes structural: the clarity moves upstream, the cost moves downstream, and the pipeline starts holding its shape without you carrying it.

Valdr is a control plane for engineers who use AI agents in real work. Every stage in this post — spec through close-out — becomes a durable artifact in your local workspace instead of a message in a transcript that ends. See how the pipeline fits together →