Pick the model last

Most companies did not choose an AI strategy. They chose a model, and the strategy grew up around it.

A piece on Towards AI this week, The Durable Asset is the Control Plane, not the Frontier Model, puts that habit on trial. The author’s evidence is Cursor, the coding tool that became one of Anthropic’s largest customers while Anthropic’s own coding agent increasingly competed with it at the application layer. Cursor meanwhile built upward: its own models, its own agent runtime, and in July a router that decides which model sees each request. The article’s conclusion is blunt: the durable asset is the control plane above the model, the layer that holds policy, spend, identity, and evaluation so no single vendor can hold them for you. The model itself is replaceable.

At Modular Technology Group we agree, and we would push it one step further for the companies we work with. That layer is where “your data, your rules” has to live, because the rules do not survive anywhere else.

The layer nobody bought

The article describes four layers. Models are the specialists. A router decides which specialist sees which request. A harness is the runtime around the model: tools, files, memory, permissions, the loop that turns tokens into actions. And a meta-harness sits above all of that so harnesses and models can be swapped without rewriting anything. Databricks has open-sourced one, and its hosted version is in beta as of this month.

The author’s analogy is a hospital. Nobody sends every patient to the most expensive specialist. Primary care handles the predictable cases, triage decides who goes where, and the hospital system supplies identity, budgets, records, and oversight across all of it. Then comes the line worth taping to a monitor: most companies bought a specialist and never built a hospital.

Picture a forty-person firm. Someone signed up for a frontier chat tool two years ago. It worked, so more people used it. Prompts now carry client matters and payroll data. Nobody can say what it costs per month across the seats, which model version answered a given question, or what happens to the account when the vendor ships a product that competes with the firm’s own service. There is no router, since there is only one model, and the policy is whatever the vendor’s terms of service say this quarter. The firm has an excellent specialist and no hospital.

Routing is a governance decision wearing an engineering hat

It is tempting to read the article as advice for platform teams at large companies, since the examples are Cursor, Snowflake, Microsoft, and NVIDIA. The routing products those companies ship are real, and the article is careful about their fine print: some routers require a specific model to be enabled, and curating a model list can shrink your effective context window to the smallest model in the set. The author’s advice is to ask every routing vendor which models are mandatory before assuming the layer is provider-neutral.

But strip the vendor names away and routing is a question a small firm can answer today. Which of our work is routine and easy to check? Which of it is novel, or high enough stakes that a person should sign off? The first bucket can run on a validated open-weight model on hardware you control, at a fixed cost, with the data never leaving the building. The second bucket earns the frontier model. The third bucket, the high-stakes one, gets verification and a human approval regardless of which model answered.

Odds are your firm has never measured its own split. That measurement is where a governance engagement should start, and the point of doing it first is that nobody buys anything until the split is on paper. The article’s phrase for the payoff is refusing to spend frontier dollars on work a cheaper, validated model already handles. Read that as a policy statement rather than a cost tip, because once the routing rule enforces it, the policy holds without anyone re-reading a memo.

Your data, your rules, and that includes the AI working on it. Your AI, your rules. The router is where the second half of that gets enforced.

What to own, and what to rent

The article closes with a list of what the durable asset actually contains: models that can change without a rewrite, routing that can learn, harnesses that can be substituted, policies that follow the workload, identity and budgets that stay centralized, and evals that prove the system is improving. It also notes that only operationally mature teams pull this off, because you need evals that say which work is safe to route cheaper, and policy that is not a prompt.

For a small or mid-sized firm, that list is a buy-versus-own map. Rent the specialists. As the article says, models will keep changing and prices will keep moving, so there is no reason to be loyal to one. Own the hospital. The gateway that every request passes through, the budget that caps a runaway agent, the log that says which model answered which question with whose data, and the routing rule that keeps client records on infrastructure you control. Those are small pieces of software. They are also the only pieces you cannot afford to have a vendor hold for you. When the vendor’s incentives shift, that layer is what lets you leave on your own terms.

You do not need Databricks or a platform team to get there. You need someone accountable for the question, a private environment where routine work can run, a gateway in front of everything else, and the discipline to measure cost per finished task rather than cost per token. That is the stack we design for firms that are too small for an enterprise AI program and too regulated to keep improvising, and the order of operations is the whole method. Policy first. Then routing. Then, and only then, the model.

So here is the question for your own shop. If your frontier vendor announced tomorrow that it now sells what you sell, which parts of your AI setup would you keep, and which would you be renting back? Tell me what that inventory looks like at your firm.