Cheap by planning: the biggest lever
The largest cost control in agent development is not the model price list. It is where in the process a defect gets discovered, and the method is arranged around that.
If you read one page in this section as a budget holder, read this one.
The model price list is not the biggest lever on what agent development costs. It is the most visible one, and it is the one every vendor comparison is about, but the spread it covers is small next to the spread between a defect caught while the work is being specified and the same defect caught after it has been built, reviewed and verified.
The most expensive place to discover a defect is downstream of it. Everything below is the same idea applied at a different stage.
The plan gate is the highest-leverage dollar in the system
A flawed plan rejected at the plan gate costs a plan.
The same flaw discovered mid-implementation costs an implementation run, a review round, a verification pass, and a re-dispatch — and it costs the human attention to notice it, which is the resource that never appears in a ledger.
⇒ The plan gate is not process overhead. It is the point in the sequence where a dollar buys the most, and it is placed there deliberately.
Buy the diagnosis before the repair
When the cause of a problem is not known, the order buys a diagnosis first: read-only, cheap, and gated — then the targeted fix is ordered afterwards, against evidence.
⛔ Ordering a fix before a diagnosis is buying a lottery ticket. It sometimes wins, and the times it does not are paid for at implementation prices, twice, because the second attempt still has no diagnosis behind it.
A test plan that cannot fail measures nothing
Every guarded behaviour in an order names two things: the test that guards it, and the mutation that must turn that test red.
The second half is the one usually missing, and it is the one that saves money. A test that cannot detect the failure it claims to guard is a defect of the plan — and it is found at order-writing price rather than after it has silently passed for a month.
Review sits where errors are cheapest to stop
The independent, adversarial review happens after implementation and before anything merges. Its verdict is a recorded recommendation; a human decides on it.
⚠ "Green is not correctness" is a standing rule here. Proof is the artifact itself, not the suite's own report about it — which is exactly the discipline that catches the expensive class of defect: the one that passes its own tests.
Separating the plan from the tests makes both cheaper
The plan and the test plan are emitted as separate artifacts. That split has two effects at once:
- Test authoring for single-file classes can route to a zero-cost or electricity-cost tier behind a deterministic check.
- The test author does not see the implementation plan — so the tests are written against the requirement rather than against the intended solution.
⇒ Cheaper and more adversarial from the same change. That combination is rare enough to be worth noticing.
Lessons ratchet; they are never bought twice
When a class of failure is measured once, it enters the standard definition of done that rides in every subsequent order. It does not have to be rediscovered by the next person, on the next stream, at the next price.
Paying for a lesson once is tuition. Paying for it twice is a process defect, and the method treats it as one.
And the claim itself is measured
A method that claims to save money and cannot show it is marketing. So every prediction-and-actual pair is recorded with a pass class:
| Pass class | What it records |
|---|---|
first-pass | Delivered on the first attempt |
rework | A second pass after a defect — the cost this method exists to prevent |
refusal | Near-zero: a guardrail worked |
manual-seam | Human minutes eaten by a mechanism that does not exist yet |
The metric that matters is the share of rework and manual-seam in a stream's cost, tracked as a trend on real rows.
⛔ Savings are never counted against a hypothetical world in which the method was not used. That is fortune-telling, and it is the standard way this kind of claim is inflated. What is counted is the trend of the pass classes in the actual books — which means if the claim on this page were false, these books would be the first thing to say so.
What is not built
- ⚠ The pass-class metric is not a product surface yet. The classes are recorded, but the rework-and-manual-seam share is compiled by hand from the record rather than drawn by the console.
Next
- Worked examples — the whole sequence as commands.
- What a ledger row knows — where the pairs and the pass classes are kept.
Matching the model to the task
Model choice is an economic decision, so the product refuses to make it for you. The ladder of actors, what earns each rung, and how predictions get calibrated from your own record.
Worked examples
The commands, in the order the money actually moves: price it, check capacity, compose it, then read what it cost — and two refusals that cost nothing.