The Principle of Least Intelligence: How Much AI Does the Work Need?

In the boardrooms where I discuss AI strategy, AI often means generative AIGlossaryGenerative AIAI capable of producing new content such as text, images, or code; positioned in the guide as an enabler that augments human capabilities rather than replacing jobs., and the conversation eventually arrives at a decision about which frontier modelGlossaryFrontier modelA model at the leading edge of AI capability, typically trained at the largest scale and governed under the tightest jurisdictional controls; availability can be withdrawn by regulation as well as by commercial choice. is best for the organisation. The discussion rarely turns to how large the model is, how much reasoning the work needs, where it is hosted, or on what terms. It is usually a choice between a handful of labs, and then a set of practical questions: who in the business should get access, how much will it cost, and how will we know when it is working. Those questions hide the assumption that one model, as capable as the budget allows, is the right answer for every task.

But what if all of that capability was not needed, or only some of it was? Much of what a business decides in software is a bounded choice, approve or refer, urgent or routine, and most of those decisions do not need the full capabilities of a comparatively expensive frontier model. Some need no model at all, and the rest usually need a model that is enough to get the job done. In July, in Not Everything Needs AI, I argued that the first question is whether a piece of work needs AI at all, and I stopped there intentionally. This article asks: when the work does need a model, how much capability does it need, and how much will the system be allowed to do on its own?

From monolith to ecosystem

Ask that of each piece of work and the answer is rarely one model but a mix of capabilities, each doing the work it is fit for. Ordinary code does the work where code is enough, and a task with one right answer does not need a model to find it. Specialist models take the narrow, repeated tasks, whether the boundary is a domain such as clinical imaging or an output such as a scored choice. Some models stay inside the organisation’s own environment because the data must not leave it. A frontier model is kept for work that needs breadth of knowledge, tolerance of ambiguity, or synthesis across many sources. Orchestration ties those parts together: it is the plumbing that decides which component handles which request, and it can be a few lines of deterministic software or an agent working it out as it goes.

A monolith is one model, one contract, and one route for every task, and it is easy to buy and relatively simple to adopt. An ecosystem is many models and code, each doing the job they are good at, with code or a small model taking the routine decisions and a frontier model taking the hard ones. It takes more effort to set up, but every task gets the least capability that does the job, so the organisation pays for and depends on no more than it uses. The decision changes too. Instead of asking which model to buy, the organisation asks what each task needs, and the frontier model becomes one answer among several.

The Board does not need to select any of those capabilities. It needs confidence that management has a disciplined way of matching capability to need, and can explain the match when asked. That is a different conversation from a choice between labs: it moves from choosing a model to governing a portfolio of capabilities. The organisation’s AI becomes something to steward rather than something to buy.

Least means sufficient

Stewarding a portfolio needs a rule for how much capability each piece of work gets, and that rule is this: apply no more intelligence than the outcome needs, with “needs” judged the way a Board judges anything about AI, across the Six Board Concerns together. Intelligence means the breadth of capability made available to the task, not the size or quality of the model. So a clinical imaging model that outperforms a frontier model on image scans satisfies the rule, precisely because it was focused on its narrow area of speciality. That is the Principle of Least Intelligence.

The principle takes its inspiration from two older rules. Security has the principle of least privilege, set out in a 1975 paper: give every part of a system no more access than its task needs. Web architecture has the rule of least power: use the least powerful language that does the job, because the less a tool can do, the easier it is to understand and check. Engineers have been writing about right-sizing models for years, and in June a web developer used the same thinking in his own work in a piece called The Principle of Least AIdev.toThe Principle of Least AI - DEV CommunityWhy AI Alternatives Matter AI is prone to problems affecting its output: hallucinations,… Tagged with ai, productivity, watercooler.Open link . None of those rules means weakest, and least does not mean dumber. Least means sufficient.

Why more capable is not better

The obvious objection is that frontier models are getting cheaper and more capable fast enough that a mix of smaller models may cost more in complexity than it saves in running costs. One capable model, well prompted, is simpler to assure than a dozen specialist ones, and a mix multiplies the things that can fail, the models that need checking, and the places where behaviour drifts between versions. Least also invites skimping: the model that was good enough on the benchmark fails on the edge case that matters, and the Board hears about it as an incident.

Sometimes the objection wins, and the principle allows for that. Proportionality is judged on the whole system: how much capability it has, and what it costs to run and to check. Count that cost and one frontier model is sometimes the least capable system that does the job, and the principle chooses it. What the principle refuses is the default, where the frontier model is used for every task because it was already there and nobody asked. The unit of proportionality is the system, not the model.

When a smaller capability would have done, using the frontier model anyway has costs that rarely appear in the business case. It spends money and time on reasoning the task never needed. It makes every task in the organisation depend on one supplier, which is comfortable until the terms or the availability change. And it uses capability that adds nothing to the result, which is a question of proportion that belongs with the other questions a Board asks about how resources are used. Researchers at NVIDIA published a paper in 2025 arguing that small language modelsGlossarySmall Language ModelA compact, often domain-specific AI model offering faster inference, lower cost, easier deployment, and reduced energy footprint, trading broad capability for higher accuracy within defined domains. are enough for many of the tasks agents do, and that large models should be used by exception rather than by habit. NVIDIA sells the chips those small models would run on, so the argument is not disinterested, but it is still a supplier at the centre of the industry saying that the large model should be the exception.

At home I run a version of this on a small desktop AI server, an NVIDIA DGX Spark, with a 120-billion-parameter open-weightGlossaryOpen-weightFoundation models whose weights are available for organisations to build on and align themselves, the practical basis for building rather than buying, though pre-training priors persist underneath. model. It is a mixture of experts, a design that uses only a small part of the model for each word: enough to read server logs and write a plain account of what it finds, and well short of a frontier model. A Mac Mini orchestrates the task. It watches a network that spans two countries, the devices on it, my websites’ traffic logs, and my home energy consumption, and when one of its jobs fails and recovers, it works out why.

Where the question has a computable answer, such as what caused a reboot, code works it out from the system’s own logs and writes the account itself, and no model is called. Where it does not, the Mac Mini gathers the evidence around the failure and sends the model that and nothing else. The model says what happened, quotes the log line each fact rests on, and says what the evidence cannot settle, and code then checks every quotation against the evidence. The task needs a model, because log lines are prose and the combinations change too much for fixed code, and it does not need a frontier one. A frontier model did this job at first, and the model on the Spark replaced it. What that model is held to is a set of past incidents whose cause is already known, and that bar says nothing about size.

The result is a root cause analysis email in my inbox whenever something goes wrong on my home network or my website, or when energy use spikes without an explanation.

The models that do less on purpose

On 18 September a start-up called Cua releasedgithub.comGitHub - trycua/cua: Scale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation. · GitHubScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation. - trycua/cuaOpen link a model of around 706,000 parameters that does one job, filling in forms for software agents that operate a computer screen, a task the industry had been giving to frontier vision models many thousands of times larger. A newer class goes further and does not write text at all. A decision modelGlossaryDecision modelA model that does not write text. Given a fixed set of options, it returns a calibrated probability for each, so software can act on the answer without a person reading it; it is built for routing, classification, prioritisation, verification, and workflow control. It cannot return an option it was not given, but it can still return the wrong one, so for a Board the question is the threshold: above what probability does the organisation act without a human, who set it, and what happens below it. takes a fixed set of options and returns a probability for each, calibrated so that, over many decisions, when it says ninety per cent it is right about nine times in ten, and software acts on the answer directly.

TypeSafe AI shipped Jev on 15 September, the day it came out of stealth, and calls the class System One modelsGlossarySystem One ModelTypeSafe AI’s name for a decision model, also used by Cua: a model that returns a typed, probabilistic decision rather than text. The name is Daniel Kahneman’s, from Thinking, Fast and Slow, and names one side of a two-way split, fast and intuitive System 1 against slow and deliberate System 2. There is no System Two product; reasoning models are the implied counterpart. after Kahneman’s name for fast, intuitive thinking; its documentationdocs.typesafe.aiSystem One - TypeSafe AISystem One models make fast, structured decisions for software. Jev is TypeSafe’s flagship model and the first System One model.Open link says these models “do not write replies, produce code, or generate explanations of their reasoning”. A decision model cannot return an option it was not given, but it can still return the wrong one, and TypeSafe’s own documentationdocs.typesafe.aiJev 1.13 jaggedness - TypeSafe AIJev isn’t perfect. Here are some jagged edges we are aware of with jev-1.13. Many of these will be fixed in later versions.Open link says where its model is unreliable: it “does not count reliably”, it “is not a calculator”, and it “reads dates as text, not as ordered quantities”.

The last of those, no explanation of their reasoning, is the one a Board should notice. A model that gives no reasons cannot be asked why it approved a claim or refused one, and someone will ask: a customer, a regulator, an auditor. It is tempting to answer that a frontier model can explain itself and a decision model cannot, but the first half is not true either. Anthropic reportedanthropic.comReasoning models don't always say what they think \ AnthropicResearch from Anthropic on the faithfulness of AI models’ Chain-of-ThoughtOpen link in 2025 that when its own reasoning model was given a hint and used it, the written reasoning mentioned the hint about a quarter of the time. The explanation a model writes for its answer is a plausible account, not a record of what happened inside it. What can be explained is the system: what the model was asked, which options it was given, the probability it returned, the threshold that turned that probability into an action, and who set it. A decision model makes that record easy to keep, because every part of it is a number or a rule, and that is the explanation a Board can stand behind.

On 9 October Microsoft followedcommandline.microsoft.comMicrosoft-Decision-1: Our model for fast decision-makingOur new decision-scoring model delivers top performance in latency and quality on structured decision tasks to outperform both LLMs and other decision models.Open link with a model of the same kind, built for routing, classification, prioritisation, verification, and workflow control, and its announcement said that “it’s increasingly important to choose the right model for the right job”. A supplier saying so is welcome, and the question for a Board is the one the supplier cannot answer: whether its own organisation has a method for the choosing, rather than a catalogue to choose from. The pattern is an industry removing open-ended output where it adds no value, not an industry building smaller minds, and that is why these are the models that do less on purpose.

Consider a health system whose rule is that patient data cannot be sent to a model hosted by a third party. The usual objection to AI in that setting assumes that AI means doing exactly that. Google’s MedGemma is an open clinical model of four billion parameters, built for medical images and text rather than for everything, and small enough to run inside a health system’s own environment. A model of that kind changes what is possible before anything else changes. It does not make local AI acceptable on its own, and the information governance questions remain, but it moves the Board’s question from whether to how, because architecture changes the governance question.

Two decisions, not one

There are two decisions to make about any AI system, and they are different decisions. The first is how much capability the work gets, which is what the principle governs. The second is how much the system is allowed to do without a person checking. It is easy to assume the second follows from the first, that a cleverer model means more risk, but the two do not move together. A frontier model that only drafts a paper for someone to read can do little on its own, however capable it is, because a person decides what happens next. A small specialist model that is allowed to approve thousands of routine claims a day with nobody checking can do a great deal. That exposure follows the permission to act, not the capability, which is why there are two decisions, not one.

Decision models show the second decision in its simplest form. The probability they return, with a threshold the organisation sets, is where the permission is set: above the threshold the software acts, and below it the case goes to a person or to a more capable model. For any system that acts on its own, the Board’s questions follow from that: what is the threshold, who set it, what happens below it, and what record is kept so a decision can be explained afterwards. Routing is not permission to act: a small model that reads a request and chooses which larger model should handle it is the principle enforced in software, and it says nothing about how much the system is then allowed to do on its own.

What the Board stewards

The Board does not pick the models and does not set the thresholds. Management does both, and the Board’s job is to know that the two decisions are being made on purpose, by someone, for a reason that can be explained. That is the same division of responsibility that runs through the rest of Remake: the Board stewards, management decides, and the evidence of both is kept where a regulator or a successor can find it.

The simplest way I have found to show both decisions on one page is a chart: how much capability a system has along one side, and how far the work has been handed to the machine along the other. Every AI system an organisation runs sits somewhere on it. A frontier model that drafts reports has a lot of capability and little permission. A decision model that approves routine claims has little capability and a lot of permission. A small model that routes requests has little of either. An agent that acts on a frontier model’s judgement has the most of both. No place on the chart is the right one, because each is a different pair of decisions. The chart, with a worked version for a sample organisation, is in the Least Intelligence Diagnostic.

Five questions follow from the chart, and a Board can ask them of any AI system without knowing anything about the model inside it. What does this work need, and how was that decided? What is the least capability that does it, and did we start there or arrive there? Where does it act without a person, and who set that threshold? What happens below the threshold? And what do we check it against, so we know the match still holds when the model or the work changes? None of those is a technical question. Together they are what the Board stewards.

The industry is moving towards smaller, narrower models that run closer to the work, and the next two articles follow that movement: first into the agents that string those models together, then into the case for running them on premises the organisation controls. The principle stays the same wherever the model runs. The mature AI strategy is the one that knows how much AI the work needs, not the one that uses the most.

The Questions Considered