A Bigger Model Does Not Shrink the Factory

The headline number on a sparse model describes what the system can hold, not what every request uses. A routing mechanism selects part of the network for each token. That distinction matters because it separates stored capacity from active computation. The machine can be broad without paying the full compute cost on every step.

That is a real architectural advantage. It can put more specialized behavior behind one interface and change the economics of serving capable models. But the advantage arrives with a new dependency: the router. If the system chooses which internal experts handle the work, then the quality of that choice becomes part of the result even though the buyer never sees it.

Software leaders should recognize the pattern. You already have more possible work than you should activate at once. The useful question is not how much capacity exists. It is which capacity gets routed to this change, under which constraints, and who is allowed to say the result is finished.

A giant pool of capability does not organize itself around your outcome. Something still has to decide whether a request needs repository history, interface work, a migration plan, a security review, or a production check. Sending every task through every possible path would waste money and create noise. Sending it down the wrong path creates polished failure.

A software factory needs an explicit router above the model. The request should enter with a decided outcome and known boundaries. The factory should select the smallest capable workflow, grant only the permissions that workflow needs, and preserve the context required to judge its work. A routine dependency update and a change to access control should not receive the same route just because both end in a pull request.

This is where many agent deployments collapse into a prompt box. They give one model broad context and broad authority, then hope intelligence will discover the right process. It might discover a plausible process. That is not the same as operating the process your business approved.

When a system selects specialized internal capacity, the output can improve without making the reasoning easier to inspect. You receive the answer, not a trustworthy account of why that particular route produced it. Asking the same system to explain itself does not close the gap. It gives you another output from the machinery under review.

Move acceptance outside the builder. Test behavior the agent did not see while implementing. Run checks in an environment it cannot reshape. Compare the result with the original consequence, not with the story the model tells about its work. Keep release authority separate from generation authority. A stronger model may pass more often, but it should not get to lower the bar because it looks more impressive while doing it.

The model is allowed to be complicated. The acceptance contract cannot be mysterious. You need to know what evidence permits motion, what failure stops the line, and where an undecided consequence returns to a person. Otherwise hidden specialization becomes hidden authority.

If sparse architectures make strong capability cheaper to activate, the first reaction should not be to spend the savings on longer conversations. Use the change to move more repeatable work into governed machinery. Run more independent checks. Try competing implementations when the decision is reversible. Reserve expensive routes for work that earns them and send ordinary work through narrower ones.

That requires accounting at the work level. Track the cost of an accepted change, including failed attempts, verification, review, and production fallout. A low token price can still produce an expensive result if the route generates rework. A costly model can be the cheaper choice when it clears a difficult gate in one bounded attempt. Model price is an ingredient. Factory economics belong to the finished outcome.

Our prediction is that model routing and work routing will converge. Factories will select capability the way a disciplined production system selects tools: by consequence, risk, evidence, and cost. Teams that keep assigning one assistant to one person will miss that shift because their unit of management is still the user, not the work.

A new model can improve overnight. Your competitor can reach it at roughly the same time you do. The durable advantage is everything the release cannot download: the shape of your requests, the routes that match your risks, the permissions around each action, the evidence that accepts a change, and the production failures that became permanent controls.

That machinery also survives model replacement. When a better engine arrives, you should be able to place it behind the same boundaries, run it against the same proof, and compare accepted outcomes. If changing models requires rebuilding the operating process, you did not have a factory. You had a collection of habits attached to a vendor.

Large sparse models make the engine room more interesting. They may make capable inference much more practical. Take that seriously, then keep building the part that decides where the engine may go. Capacity creates options. Routing turns options into work. Independent proof turns work into software you can operate.