I've been thinking about a strange mismatch in how we're approaching enterprise AI.
We're building models capable of extraordinary reasoning, and then asking them to perform remarkably ordinary work. A model that can write sophisticated software, work through advanced mathematics, or reason about scientific problems might spend much of its day checking invoices, updating customer records, or preparing purchase orders.
There's nothing inherently wrong with this. General intelligence is useful, especially when we don't understand a problem very well. But once a company has performed the same operation ten thousand times, I wonder why it should continue paying for all that generality.
And there's another question that interests me even more. If a model is capable of doing almost anything, why should it be allowed to do more than the particular job it was given?
I suspect these two questions, one about intelligence and the other about authority, will become increasingly important as AI moves from answering questions to actually running parts of businesses.
Consider a manufacturing company.
Its purchasing department deals with suppliers, purchase orders, invoices, receiving records, inventory, payment approvals, and a collection of software systems that may or may not talk to each other. Much of this work follows established rules. But anyone who has operated a business knows the rules rarely tell the whole story.
A supplier sends the wrong invoice. Parts arrive in two shipments. Someone updates a purchase order but forgets to notify accounting. A customer needs something urgently, so an employee works around a process that was designed for normal circumstances.
This is exactly where a capable general model can be useful. It can investigate the situation, read different records, recognize inconsistencies, ask questions, and figure out what needs to happen next.
Initially, the model needs broad reasoning ability because the work itself hasn't been reduced to a predictable sequence.
But imagine observing that same purchasing operation over several months.
You might discover that most invoices are rather uninteresting. They come from known suppliers, match existing purchase orders, correspond to goods already received, and fall within established limits. The same checks happen again and again.
At some point, an interesting possibility appears: perhaps the general model has learned enough about this operation that a much smaller model could now perform most of it.
The general model was useful for understanding the job. It may not be necessary for doing that job indefinitely.
This reminds me of what happens in software with just-in-time compilation. A system begins with a general way of executing instructions, observes which paths are used repeatedly, and replaces those paths with more efficient implementations.
What if something similar happened with intelligence?
A general model works through an unfamiliar business process. As the work becomes familiar, another system recognizes the recurring structure and produces a specialist. The specialist doesn't need to know everything its teacher knows. It only needs to know enough to perform that particular operation reliably.
There is something almost counterintuitive about this direction. We usually think of progress in AI as moving toward larger, more capable models. But inside an enterprise, progress might sometimes mean moving in the opposite direction: from general intelligence toward increasingly narrow intelligence.
Perhaps the ultimate role of a frontier model in some workflows is to help create its own cheaper replacement.
Of course, replacing a general model with a smaller one isn't the same as compiling software. A compiled program is expected to preserve its intended behavior. A trained neural network offers no such guarantee.
Which brings us to the harder problem.
How do we know the replacement is actually good enough?
An ordinary benchmark won't answer that question. A model might score extremely well on general reasoning tests and still make an expensive mistake in a company's purchasing system. Another model might be mediocre on broad benchmarks but nearly perfect at one narrow operational task.
The only meaningful way to compare them is against the actual work.
And this is where I think the distinction between historical data and executable environments becomes important.
Most companies have considerable operational history: invoices, approvals, support tickets, CRM updates, tool calls, and records of transactions that succeeded or failed. These are useful sources of training examples.
But history mostly tells us what happened. It says much less about what could have happened.
Suppose we train a model using ten thousand successful invoice transactions. It learns the common patterns and reproduces them accurately.
What happens when a supplier changes its bank details the day before payment? Or when two agents try to use the same remaining purchase-order balance? Or when a payment API processes a transaction successfully but times out before returning a confirmation?
The model may have never seen those situations.
Worse, it might confidently treat them as ordinary cases.
This has led me to think about a different way of preparing specialized models: not just training them on records of past work, but allowing them to operate inside an executable copy of the business.
I don't mean a dashboard showing how processes connect. I mean an environment in which the AI can actually create a purchase order, receive goods, approve an invoice, change inventory, initiate a simulated payment, and experience the consequences.
If it pays the same invoice twice, the simulated bank balance changes twice. If it orders inventory that already exists, the excess stock appears. If it approves something outside company policy, the violation becomes visible in the resulting business state.
Then we reset the environment and try again.
We can introduce a supplier that doesn't exist, a payment that partially fails, a document containing malicious instructions, or a situation in which the correct decision is to do nothing.
The distinction matters because an agent's explanation can sound perfectly reasonable while its actions produce a disastrous result.
A transcript might say, "Invoice approved successfully."
The underlying system might reveal that the company just overpaid a supplier by $40,000.
A replay that judges the response may miss what an executable environment discovers.
That doesn't mean a simulation is automatically faithful to reality. A poorly constructed business environment can give us misleading confidence. Its rules can be incomplete, its edge cases artificial, and its assumptions wrong. We have to test the environment too.
But if built carefully, it offers something historical records alone cannot: a controlled way to investigate the consequences of decisions before those decisions affect the real company.
I think this is especially valuable for deciding where a specialist's competence ends.
Imagine a small model that performs invoice matching very well. We test it against normal transactions, unusual suppliers, incomplete records, failed API calls, and unfamiliar situations.
Eventually we may be able to say something precise about its capabilities.
It works reliably for purchase-order-backed invoices, in US dollars, from approved suppliers, within a defined transaction range. It has not demonstrated the same reliability for new supplier creation, foreign currencies, or changes to banking information.
That is a much more useful statement than saying the model achieved 97% accuracy.
The percentage tells us how often it succeeded on a particular collection of tests. It doesn't necessarily tell us which situations are safe to entrust to it.
What we really want is a map of where the model has demonstrated competence, where it hasn't, and what should happen when it encounters something unfamiliar.
In some cases, the correct behavior isn't an answer. It's an escalation.
A specialist that handles ninety-nine familiar cases correctly but confidently invents a solution to the hundredth may be less useful than one that handles ninety-seven and knows when to ask for help.
This raises a question that deserves more attention in model evaluations: can we train an AI not just to perform a task, but to recognize when it is no longer the right intelligence for that task?
I don't think we can assume the answer is yes. We need experiments that distinguish familiar cases, difficult boundary cases, and genuinely novel situations that neither the teacher nor the specialist encountered during training.
If a smaller model can reliably identify its own limits, a rather interesting architecture becomes possible.
Routine work goes to specialists. Unfamiliar work returns to a frontier model or a human. As new patterns become understood, more of the work can be specialized.
The general model remains important, but it stops being the default executor of every action.
There is, however, a second problem that model training cannot solve.
Let's suppose we've proved that a specialist can correctly handle invoices up to $25,000.
Should it therefore be allowed to approve $25,000 payments?
Not necessarily.
The company might only permit it to reconcile invoices up to $10,000. It might require a manager's approval for anything larger. It might prohibit the AI from executing payments altogether.
The distinction seems obvious when talking about employees. A talented accountant doesn't automatically gain access to the company's bank account simply because they're good at accounting.
Yet we often blur that distinction with AI.
We give an agent access to tools, tell it what it should and shouldn't do, and expect the model to respect those instructions.
This is a fragile arrangement.
A model can misunderstand an instruction. A document can contain an adversarial instruction. A software update can change behavior. A retrained model may develop abilities its predecessor never had.
A system's competence cannot be the source of its permission.
I keep returning to a simple principle: capability is something we can measure; authority is something someone must grant.
The two should remain independent.
A specialized model can propose an action. A separate authorization system should determine whether that exact action is permitted for that exact actor, company, resource, amount, and moment.
If the action is outside the approved limits, it should not happen, regardless of what the model believes.
And the decision should leave evidence that another party can verify.
This becomes even more important as AI systems begin training and replacing their own specialized models.
Imagine an invoice agent is running version three today. It has a known set of evaluated capabilities and an explicit set of permissions.
Next week, the company deploys version four.
It might perform better. It might use different tools. It might make fewer mistakes. But the evidence supporting version three doesn't automatically establish what version four can do. Nor should version four silently inherit permission to perform actions it was never explicitly authorized to take.
A new model should be treated as a new actor, even when it descends from an older one.
The evaluation has to apply to the exact version being deployed, and the permission to act has to be established separately.
This creates an interesting constraint on autonomous AI development: a machine may become more capable without automatically becoming more powerful.
I think that distinction will matter far beyond invoice processing. It applies to agents deploying software, managing cloud infrastructure, approving refunds, purchasing equipment, or eventually operating physical machinery.
There is also an economic argument for all this, although I think it needs more skepticism than it usually receives.
A small model can be dramatically cheaper per inference than a frontier model. But inference cost isn't the same as the cost of completing a business operation.
A cheap model that requires frequent human correction may cost more than an expensive model that gets the work right. A specialist that needs constant retraining might never recover the expense of maintaining it. And a task that only occurs a few times a month may not justify specialization at all.
The meaningful comparison is cost per successfully completed task, including inference, infrastructure, evaluation, escalation, supervision, maintenance, and the expected consequences of errors.
I suspect some enterprise operations will show extraordinary savings from specialization. Others will not.
We should be prepared for either result.
In fact, sometimes the smallest sufficient intelligence may not be a neural model at all. It might be a deterministic program that a general model helped us discover.
If a company's invoice-matching rules can be expressed reliably in a few hundred lines of software, why insist on a neural network?
The goal isn't to create more models. It's to use less computation and less unnecessary complexity wherever we can, without sacrificing reliability.
This is part of what we're exploring with EnterpriseWorld and Delegus.
EnterpriseWorld is intended to provide executable business environments in which models can be tested against consequences rather than judged solely by their responses. We want to investigate whether those environments can produce better specialists and, just as importantly, stronger evidence about where they work.
The Compiler asks how little intelligence a particular operation actually requires.
Delegus Check addresses the separate problem of authority: what the company has permitted that intelligence to do, and whether a particular action is authorized at the moment it is attempted.
The training itself doesn't need to happen on our infrastructure. A company should be able to use its own cloud, its preferred model, or an external training provider. The important thing is being able to evaluate the resulting model, establish its limits, and independently govern its actions.
These are ideas we still have to test. We haven't demonstrated that training inside an executable business world consistently produces better specialists than training on historical trajectories. It may turn out that the benefit is substantial for unfamiliar situations, modest for routine ones, or highly dependent on the quality of the environment.
That uncertainty is precisely why the experiment interests me.
If the approach works, I think it suggests a different future for enterprise AI.
Instead of one enormously capable model operating across the entire company, there may be many smaller systems, each responsible for a well-understood part of the business. Some will be models. Some will be conventional software. Some work will still require frontier intelligence, and some decisions will remain with people.
These systems will need to know what they are competent to do, when to hand work off, and what they have been authorized to do.
The frontier model doesn't disappear. It becomes the explorer, the teacher, the investigator of unfamiliar problems, and perhaps the architect of increasingly specialized replacements.
In a sense, the better general intelligence becomes, the more opportunities it may discover to use less of itself.
That is a rather different picture from the assumption that every business problem ultimately needs the most powerful model available.
And it leaves us with two questions that I think enterprises will increasingly need to ask.
How much intelligence does this particular job really require?
And once we have that intelligence, how much power should we give it?
The first is a question we can answer with evidence. The second must remain a question of authority.
Getting both right may matter much more than simply building a smarter model.