The Expensive Model Belongs at the Narrowest Gate

For a while, waiting for the next model looked like a sensible operating plan. New releases arrived with enough capability to cover weak prompts, thin context, and rough workflows. The easiest move was to send the work to the best model available and let the market erase yesterday's mistakes.

That stops working when the strongest option carries a meaningfully different bill, a different data policy, or access you cannot count on. Then the question changes. You are no longer asking which model is best in the abstract. You are asking which parts of the work deserve scarce capability, which parts need a cheaper engine, and what evidence lets either one proceed.

This is a familiar transition in engineering. When one resource stops feeling unlimited, architecture becomes visible. The system has to decide what work goes where. In an agent-run software factory, that decision belongs in the machinery, not in a developer's model picker.

A task label is a poor router. Two changes called bug fixes can carry completely different consequences. One may update a bounded presentation rule with strong tests. The other may touch identity, money, permissions, or data movement. Sending both through the same route because they share a ticket type hides the decision the business actually cares about.

Route on consequence instead. Ask how ambiguous the requirement is, how wide the allowed change surface is, what authority the agent needs, how expensive failure would be, and whether independent proof already exists. A narrow, repeatable change with a complete specification can go to a less capable model because the factory supplies the missing structure. An architectural decision with unclear tradeoffs may earn the strongest model before any code is written.

The expensive model should spend its capability where uncertainty is dense. It can interrogate intent, challenge a design, or resolve a failure that cheaper attempts could not explain. Once that uncertainty has been turned into a precise brief and executable checks, routine implementation can move down a cheaper route.

A weaker model with the right contract can outperform a stronger model that has to reconstruct the job from scraps. Give it the relevant code, the boundary it may change, the behavior that must hold, the commands that prove it, and the conditions that stop the run. You have reduced the amount of judgment the model must improvise.

That context cannot be a heroic prompt somebody rebuilds for every task. It has to be assembled by the factory from durable sources: the current specification, repository rules, architecture boundaries, known failure cases, and evidence from prior runs. When a defect escapes, the reproduction test joins the route. When an agent crosses a boundary, the permission rule tightens. The next model receives the lesson automatically.

This is how routing compounds. You are not merely substituting a cheaper token stream. You are moving intelligence out of a rented component and into machinery the organization owns. Models will keep changing. A route that retains its context, controls, and proof can change with them without forgetting how the work gets done.

Price is only one constraint. Where a model runs, what traces it retains, which tools it can reach, and whether its availability can be throttled all change the route. A model can be technically excellent and still be the wrong destination for a task whose context cannot cross that boundary.

Treat those conditions as mechanical policy. Classify the context before dispatch. Give each route an explicit set of permitted models, credentials, tools, and retention rules. If the work cannot be completed inside those limits, the factory should narrow the context, choose another route, or escalate the decision. It should not let an agent quietly trade governance for convenience.

That makes model choice an authority boundary. The router is deciding not just who can generate an answer, but where company knowledge can travel and which actions can follow. A dropdown and a warning banner cannot carry that responsibility at factory scale.

A router is only useful if it can be corrected. Record why a route was chosen, what it cost, which evidence passed, where the work came back, and whether escalation changed the outcome. Do not reduce that record to model preference or benchmark rank. The useful measure is how much acceptable work survived the entire route.

Then promote and demote models like replaceable factory parts. A cheaper model that repeatedly clears a bounded route has earned more work there. A premium model that produces polished changes which fail independent proof has earned less. The standard stays fixed while the components compete against the same consequences.

Our position is that this routing layer will become a basic control in software factories. The strongest model will not disappear, and the cheapest model will not win everything. The factory will reserve expensive judgment for the narrow points where it changes the result, then push repeatable execution through routes that scale. That is how you turn a volatile model market into an operating advantage instead of a monthly surprise.