---
title: "The Principle of Least Intelligence"
date: 2026-10-11
description: The Principle of Least Intelligence: apply no more capability than the outcome needs, and treat permission to act as a separate decision for Boards to steward.
author: Mario Thomas
canonical: https://mariothomas.com/blog/the-principle-of-least-intelligence/
---

In the boardrooms where I discuss AI strategy, AI often means generative AI, and the conversation eventually arrives at a decision about which frontier model 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](/blog/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](/blog/board-ai-governance-priorities/) 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](https://web.mit.edu/Saltzer/www/publications/protection/): give every part of a system no more access than its task needs. Web architecture has the [rule of least power](https://www.w3.org/2001/tag/doc/leastPower.html): 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 AI](https://dev.to/ingosteinke/the-principle-of-least-ai-4jc0). 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](https://arxiv.org/html/2506.02153) published a paper in 2025 arguing that small language models 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-weight 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 [released](https://github.com/trycua/cua) 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 model 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 models after Kahneman's name for fast, intuitive thinking; its [documentation](https://docs.typesafe.ai/concepts/system-one) 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 [documentation](https://docs.typesafe.ai/model-jaggedness/jev-1.13) 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 reported](https://www.anthropic.com/research/reasoning-models-dont-say-think) 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 [followed](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/) 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](https://developers.google.com/health-ai-developer-foundations/medgemma/model-card) 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](/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](https://my.mariothomas.com/remake/diagnostics/least-intelligence/).

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 {#questions-considered}

### How do we decide how much AI capability a piece of work needs?

Apply the Principle of Least Intelligence: no more intelligence than the outcome needs, with need judged 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 specialist clinical imaging model that outperforms a frontier model on scans satisfies the rule. Least means sufficient, not weakest, drawing on security's principle of least privilege and the web's rule of least power.

### Should we buy one frontier model for every task in the organisation?

Usually not. Much of what software decides is a bounded choice that does not need frontier capability, and some tasks need no model at all. An ecosystem gives each task the least capability that does the job, with code or small models taking routine decisions and a frontier model kept for breadth, ambiguity, or synthesis. The Board's conversation moves from choosing a model to governing a portfolio of capabilities.

### When is a single frontier model the right choice?

When the whole system is counted. Proportionality is judged on how much capability the system has and what it costs to run and to check, and a mix of smaller models may cost more in complexity than it saves in running costs. One frontier model is sometimes the least capable system that does the job, and the principle chooses it. The principle refuses the default, where the frontier model handles everything because it was already there and nobody asked.

### Does a more capable model always mean more risk?

No. There are two decisions: how much capability the work gets, and how much the system may do without a person checking, and they do not move together. A frontier model that only drafts a paper for someone to read can do little on its own, while a small model allowed to approve thousands of routine claims a day unchecked can do a great deal. Exposure follows the permission to act, not the capability.

### How do we explain a decision made by a model that gives no reasons?

Not by asking the model. A decision model returns a probability and no explanation, and the reasoning a frontier model writes out is not a reliable record either: Anthropic found in 2025 that its own reasoning model mentioned a hint it had used a quarter of the time. What can be explained is the system: what the model was asked, the options it was given, the probability it returned, the threshold that acted on it, and who set it.

### What should our Board ask about any AI system?

Five questions that need no knowledge of the model inside: what does the 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 it; and what is it checked against so the match holds when the model or the work changes. Management picks models and sets thresholds; the Board stewards both decisions.

### Is the industry moving towards smaller models?

Yes, towards smaller, narrower models that run closer to the work. Researchers at NVIDIA argued in a 2025 paper that small language models are enough for many agent tasks, though NVIDIA sells the chips those models would run on, so the argument is not disinterested. TypeSafe AI and Microsoft have shipped decision models that return calibrated probabilities over fixed options rather than text. The pattern is an industry removing open-ended output where it adds no value, not building smaller minds.