You're paying a model to work as an if statement
There's a cheap question almost nobody asks before adding an agent to a workflow: of everything I'm about to hand it, how much is a decision and how much is a rule?
Picking the next task off a list based on its prerequisites isn't a decision — it's a rule. Marking that task complete and recalculating the counters isn't one either. Those were the two things I was asking a model to do when I built my agent orchestrator, and both left the agent three days in.
What I wrote down in the commits at the time: around $0.25 and 40 seconds per run on selection, around $0.30 and 20 seconds on closing. Sounds like nothing. Four months and 2,095 tasks later, those two scripts add up to more than a thousand dollars and more than thirty hours never spent.
And the point that matters if you're building something similar: the saving didn't come from picking a cheaper model or writing better prompts. It came from shrinking the surface the model gets to touch at all.
The first two days were all interface
I started on April 7th, 2026, and the first thing I built was none of that: it was a screen. A server managing several projects at once, with a dashboard in the middle showing which stage everything was in. Looking back at that first week's history, it's almost funny. The width of the sidebar. Tooltips showing full dates on hover. "In progress" badges on each stage. Colours per pipeline stage, so they'd be distinguishable at a glance.
There's a pair of consecutive commits I particularly like as a portrait of that moment. The first sets an emoji as the icon for the loop button. The second replaces it with a Unicode character, because the emoji ignored the colour I was setting in CSS and always looked the same, regardless of state.
I don't bring this up to mock myself. I bring it up because it's exactly what a project looks like when you don't yet know what the problem is. I was polishing the system's surface very carefully because the surface was the only thing in front of me. The underlying question — which parts of this flow need a model to decide, and which don't — hadn't even occurred to me.
Two steps that became scripts
By then the pipeline had taken shape: a chain of steps where an agent picked the next pending task, implemented it, and then marked it complete. All three steps ran through the model, because all three were written as instructions inside the skills I handed it.
The uncomfortable question came from looking at the first of the three. There's an index of items, each with a status and a list of prerequisites, and the whole rule is: take the first one that's pending with all prerequisites met, mark it in progress, and record the change.
That day I turned it into a deterministic script. It parses the index, finds the first pending item with its prerequisites in order, marks it in progress and commits the change. It also handles resuming an item that was already underway, which was the only part with any subtlety to it.
The same day I did the same at the other end of the chain. The step that closes a task — updating the status, recalculating the summary counters, deleting the spec file and committing — also stopped going through the model. It's a sequence of operations over files and state. There's nothing to interpret.
The numbers I wrote down at the time
What keeps this from being an anecdote is that I measured before and after, and left it written in those commit messages.
Automatic picking cost roughly 0.25 dollars and 40 seconds every time it ran. Completion, roughly 0.30 dollars and 20 seconds. As a script, picking became step zero of the pipeline: instant and free, running before any agent was spun up.
A little under sixty cents and a minute per task. Seen one at a time, it's negligible. That's precisely the problem with this kind of waste: it never hurts enough for you to look at it.
Four months on, the system has completed 2,095 features and fixes. At that rate, those two scripts add up to more than a thousand dollars and over thirty hours of waiting that were never paid. And not because the model was doing its job badly — it was doing it well. It was simply doing a job that didn't require a model.
You pay for the model where there's ambiguity
The conclusion I drew from those two days is still the criterion I apply to every new step I add to the pipeline. A model earns its keep where something has to be interpreted: understanding a spec written in prose, deciding how to structure a change, judging whether a result is acceptable. Where the rule can be written down, the rule wins.
And it doesn't win on price alone. It wins for three reasons that weigh more heavily as the system grows:
- It's cheaper, which is the obvious point and the least important one.
- It's faster: a script takes milliseconds where an agent takes tens of seconds, and that gap multiplies across every task in the backlog.
- It's deterministic, which is what actually matters. A pipeline that has to run unattended can't have steps that sometimes do one thing and sometimes another. Every point where a model intervenes is a point where the outcome can vary, and that variance compounds along the chain.
Put differently: every deterministic step you take away from the agent isn't just savings, it's a source of uncertainty you remove from the system.
Telemetry is what made it visible
There's a detail without which none of this would have happened: to claim a step cost twenty-five cents, I first had to measure it.
That instrumentation — recording cost and duration for every single step — was among the first things I built, and today the system holds 5,698 skill runs and 9,109 recorded steps, each with what it cost and how long it took. It's the foundation under nearly every decision I'll describe in this series.
Without those numbers, the reasoning of that April 10th would have been one more intuition, of the same kind as the ones that later turned out to be wrong. With the numbers, it was a ten-minute decision.
Where yours are
The exercise requires building nothing: list the steps in your flow and mark the ones with a single correct answer given the input. Picking the next item, moving a state, recalculating a counter, checking whether the prerequisites are met. Every one of those a model resolves today you're paying for twice — in tokens and in variance — to get something a conditional returns identically every time.
With the deterministic steps out of the way the pipeline started producing at a good pace, and the opposite problem showed up, the one that occupied me for the next four months: the agent would finish, report that it had implemented what was asked, and the only criterion for believing it was that the step hadn't returned an error. That's what the next entry is about.