Frontier Models for Frontier Problems: how enterprises allocate intelligence

The enterprise AI market is developing a dangerous reflex. When an important problem appears, organizations reach for the largest model available. When a smaller model fails, they escalate. When the frontier model succeeds, they conclude that frontier intelligence should be the default. Each step looks rational. The destination is an architecture that is economically impossible to scale.

This essay develops an enterprise doctrine around Satya Nadella’s dictum, delivered in conversation with Reid Hoffman: do not use frontier models for non-frontier problems. He illustrates it with trade-promotion claims — a workflow full of messy documents and human error, but largely repetitive and deterministic. It needs intelligence. It may be far better served by a small specialized model, enterprise traces, explicit calculation and a controlled workflow than by invoking the most powerful general model for every claim.

The dictum is deceptively simple. Its implications are not. It suggests that enterprise AI strategy is not primarily about selecting the best model — it is about building the institutional capability to answer five questions.

1. 01What kind of problem is this?
2. 02What level of intelligence does it actually require?
3. 03Which parts require language-model reasoning at all?
4. 04How do we prove the selected system is sufficient?
5. 05How do we escalate only the cases that deserve greater intelligence?

That is the discipline of intelligence allocation, and the firm already knows how to do it everywhere else. It does not use its most expensive lawyer for every contract, its chief scientist for every laboratory test, its CEO for every customer complaint, or a supercomputer for every spreadsheet. It allocates scarce capability by complexity, consequence, uncertainty, value and scarcity. Machine intelligence should be managed the same way.

The alternative to frontier-by-default is emphatically not cheapest-by-default. A cheap model that fails frequently, needs repeated retries, generates human review and misses important exceptions may cost more than a frontier model. And a short question can conceal deep ambiguity, high consequence, missing context, novel reasoning or adversarial input. The correct answer is more demanding than either reflex.

A global company receives two million supplier invoices a year, arriving as PDFs, scanned images, spreadsheets, structured electronic formats and emails. It wants supplier identity, invoice number, currency, purchase order, amount, tax, payment terms and exception reason.

The AI team builds a proof of concept on its most capable frontier model. The prototype is impressive: it understands unusual layouts, resolves ambiguous labels, explains discrepancies. Executives approve expansion. Every document now goes through the frontier model.

Accuracy is high. So is the bill. And then the rest arrives:

• Latency becomes a problem during month-end processing
• Sensitive financial documents leave the preferred processing environment
• The model occasionally invents explanations when fields are missing
• Finance reviewers begin reading persuasive narratives instead of examining extraction confidence

A later review finds that the workload was never one problem. About 82% of invoices use layouts the company has seen many times, extractable with templates, document models, small specialized models and deterministic validation. Another 14% contain manageable variation that a smaller multimodal model handles. About 3% contain genuine ambiguity requiring a stronger general model. Under 1% involve conflicting contracts, possible fraud, unusual tax treatment or material commercial consequences — and those need both frontier reasoning and human expertise.

structured invoice        → direct parser
known layout              → specialized extraction model
moderate variation        → small multimodal model
ambiguous document        → frontier model
material financial or
legal uncertainty         → frontier model + qualified human

The company does not stop using frontier intelligence. It reserves frontier intelligence for the point at which it creates frontier value.

The original architecture asked: can the frontier model solve this? The redesign asks: what is the simplest reliable system that can solve each part?

That is the difference between an AI demonstration and an intelligence-allocation system.

Frontier model is widely used and inconsistently defined. It should never be treated as a permanent list of model names, because the frontier moves: a capability considered exceptional today may be inexpensive, local, standardized and embedded tomorrow.

Three qualifications matter more than the definition itself.

And frontier capability does not guarantee enterprise fitness. A model may be highly capable and still unsuitable because of privacy requirements, latency, availability, output variability, cost, hosting limitations, regulatory concerns or poor domain calibration.

The more important definition is the problem

A frontier problem is not merely complicated, high volume, strategically important, expensive, executive-sponsored, or described in unstructured language.

Frontier problems usually carry several of eight characteristics:

1. 01Epistemic novelty — the organization does not already know the answer or the method
2. 02Deep ambiguity — the objective or evidence is incomplete, conflicting or open to interpretation
3. 03Cross-domain synthesis — integration across fields not normally combined
4. 04Long reasoning horizons — many dependent steps
5. 05Sparse feedback — few historical examples
6. 06Weakly specified evaluation — no single correct output can be defined in advance
7. 07High option value — a superior answer may unlock a market, a discovery, a strategic shift
8. 08Marginal intelligence value — additional reasoning quality materially changes expected outcomes

The last is decisive. A problem may be genuinely difficult, but if a stronger model does not reliably improve the outcome, frontier use is not justified.

Three things that masquerade as frontier difficulty

Before using a frontier model, score the work across ten dimensions. The scoring is comparative, not absolute — and the point is that two tasks inside the same workflow can land in completely different places.

Total cost is the term most organizations get wrong. It includes model inference, reasoning tokens, latency, retries, human review, integration, security, failure recovery, provider dependence, energy and maintenance.

Most enterprise architectures contain two layers: a language model, and a human when it fails. The real stack has twelve.

There is no universally best enterprise model. The useful question is: which system meets the required outcome threshold for this task distribution at the best total economics and control profile?

OpenAI’s current enterprise scorecard argues the same: the lowest token price does not necessarily produce the lowest outcome cost, and the full calculation should include model price, compute used, likelihood of success, employee time, review, retries and rework.

This cuts both ways, which is what makes it a discipline rather than a slogan. A frontier model may be cheaper overall when it solves the task in one attempt, needs less prompt engineering, uses fewer retries and reduces human review — for a low-volume, high-value task, frontier use can have superior economics. And smaller models may dominate at scale: a 2026 enterprise-search study reported a fine-tuned small model matching or beating its teacher on human agreement while delivering 17× higher throughput and 19× better cost efficiency in the evaluated workflow. A separate 2026 contract-extraction study reported a domain-trained small model outperforming the tested frontier models on aggregate extraction metrics at substantially lower inference cost. These are individual studies, not universal results — which is precisely the point that enterprise-specific evaluation can overturn assumptions based on scale alone.

frontier value premium  =  E[value | frontier system] − E[value | next-best system]
frontier cost premium   =  total cost and risk of frontier − total cost and risk of next-best

justified when          →  value premium > cost premium

Every business workflow should have an intelligence budget defining acceptable cost, acceptable latency, reasoning effort, number of retries, escalation and human review.

Both directions have a cost. An agent can spend enormous inference exploring alternatives that do not improve the decision. A weak model produces wrong answers, shallow plans and costly human correction. So the budget must be adaptive: start on a lower-cost path, and increase intelligence when evidence indicates uncertainty, conflict, novelty, failed validation or high consequence.

A cascade attempts the task with a lower-cost system first and escalates when necessary. Cascades work because enterprise workloads have a long tail: most cases are routine, and a minority consume disproportionate reasoning.

The research is encouraging but bounded. FrugalGPT demonstrated that learned model cascades could, in the evaluated settings, match the best individual model at substantially lower cost or improve accuracy under the same budget. RouteLLM showed learned routers reducing model-call cost in tested benchmark settings while maintaining response quality, with some ability to transfer when the underlying strong and weak models changed. Neither guarantees the same savings in your workflow. What they establish is that routing can create a better cost-quality frontier than using one model universally.

Six ways to route

Language models can be confidently wrong. Self-reported confidence should never be the only escalation signal.

Stronger signals are available and mostly cheap: schema validation, source availability, deterministic checks, disagreement among models, novelty detection, retrieval quality, policy risk and historical outcome. Four patterns build on them — verifier-based routing (a verifier checks the output; failure escalates), consensus routing (several low-cost models answer; escalate on disagreement), retrieval-quality routing (escalate when authoritative evidence is missing or contradictory) and tool-failure routing (escalate when calculations fail, identities conflict or enterprise systems are unavailable). And employees should always be able to escalate on tacit context the system cannot see.

Escalating to a bigger model is the last of five options, not the first. Four cheaper moves come before it, and each one dissolves a surprising share of apparent frontier problems.

1 · Decomposition

A problem may appear to need frontier intelligence only because several distinct operations are bundled together. Using one frontier model for all of them is convenient. It is not optimal.

Decomposition buys lower cost, clearer testing, a smaller blast radius, easier audit, component reuse and better routing. It also has a limit: over-decomposition creates excessive orchestration, brittle interfaces, latency and loss of holistic reasoning. The architecture must preserve enough context for the problem to remain solvable.

2 · Determinism

Enterprise AI teams often treat rules and calculations as old technology. This is a mistake. For arithmetic, eligibility, thresholds, financial posting and safety constraints, predictability is a feature. A model can decide calculate the promotion P&L; a governed engine should calculate revenue, discount, trade spend, cost and contribution. Exact systems should then verify totals, currencies, dates, permissions, IDs and balance conditions.

3 · Retrieval

A weak answer often reflects missing context rather than insufficient intelligence: the wrong document, a stale policy, missing customer data, an unclear hierarchy, or too much irrelevant context. Bigger models cannot invent authoritative enterprise truth — they compensate plausibly, which makes the risk worse. Before escalating models, test source authority, retrieval recall, retrieval precision, entity resolution and context assembly. A smaller model with correct facts, a clear schema and a narrow objective may outperform a frontier model given poor context. Retrieval cannot, however, replace reasoning: for genuinely novel synthesis, frontier capability may still be required.

4 · Specialization

A general model learns broad patterns. A specialized model can be optimized for one vocabulary, one document type, one decision, one output schema — through fine-tuning, distillation, adapters, constrained decoding, domain pretraining, specialist retrieval or tool scaffolding. Google’s “distilling step-by-step” research showed how rationales produced by larger models help smaller task-specific models learn more efficiently.

The risk is brittleness: a narrow model may fail when the input distribution changes, a new customer format appears, policy changes or the task expands. Specialization therefore requires drift detection, fallback and periodic retraining — otherwise it is just deferred failure.

This may be the most valuable enterprise pattern in the essay. Frontier models can teach systems (generate taxonomies, label examples, write tests, propose rules, create synthetic edge cases, explain expert decisions, build smaller models), teach humans (explanations, simulations, counterarguments, practice cases) and teach agents (policies, plans, specialist prompts, tool descriptions).

The teacher must itself be evaluated: frontier-generated labels can contain errors, bias and unsupported reasoning, so expert sampling and validation are not optional. But the economic shift is the point. Instead of paying the frontier model on every production transaction, the company pays it to improve the cheaper system handling millions of transactions.

The frontier model becomes a capability factory rather than the permanent processor of every case.

That said, some problems genuinely deserve maximum available capability, and a doctrine of restraint is worthless if it cannot say where restraint ends.

Frontier capability is valuable precisely because some work remains genuinely difficult.

A problem may require frontier intelligence and still require human authority. The two questions are independent, and conflating them is one of the most expensive errors in enterprise AI.

Stronger intelligence can increase required governance. A more capable agent may access more tools, act over longer horizons and produce more persuasive outputs. The blast radius grows with the capability.

Organizations often assume the strongest model is the safest because it makes fewer mistakes. That is one term of five. For certain actions the safest design is deterministic rules, a limited model role and strong human authority — a simpler architecture, not a stronger model.

Privacy and sovereignty

Smaller or open-weight models can run inside the enterprise, on private infrastructure, at the edge or on devices — reducing data movement, giving predictable deployment, offline operation, lower provider dependence and lower latency. The trade-offs are real: internal security burden, maintenance, weaker general capability, hardware requirements and model-update responsibility. So sovereignty should be selective, prioritizing workloads involving sensitive data, operational continuity, strategic knowledge and high volume. A multi-model architecture also protects bargaining power, continuity and learning ownership — the argument the previous essay made at length.

Latency

A correct answer that arrives too late has no value. Latency comes from model size, reasoning effort, generated tokens, tool calls, sequential cascades, network and human review — and OpenAI’s latency guidance notes that response time is materially influenced by the selected model and the number of generated tokens.

Agents can run specialist tasks in parallel, but parallel calls increase cost, coordination and synthesis burden. Parallelism buys latency with money.

Energy

Every inference uses physical infrastructure. The IEA reported in 2026 that energy consumption per AI task has been declining rapidly even as aggregate demand grows, because usage and capability are expanding faster; it projects continued substantial growth in data-centre electricity demand, with uncertainty shaped by efficiency, adoption and model capability. Using a frontier model unnecessarily consumes more compute, energy and infrastructure capacity.

Portfolio risk needs active monitoring: one-provider concentration, correlated infrastructure, model retirement, capability gaps, duplicated models and unmaintained local deployments.

A model gateway separates business workflows from model providers, taking responsibility for authentication, routing, policy, model selection, logging, cost, privacy, fallback and version control. It buys portability, consistent governance, centralized cost control and faster model testing. It also carries its own risk: the gateway can become a bottleneck, a single point of failure, or a hidden decision-maker. It requires resilience and evaluation like any other critical system.

Without evaluations, model allocation is opinion. Enterprise evals define required quality, prohibited failures, acceptable cost, acceptable latency and escalation conditions. OpenAI’s enterprise eval guidance frames the process as Specify → Measure → Improve: translating fuzzy business goals into concrete workflow expectations and examples.

For each task distribution, plot capability against cost and success. One curve shows a large improvement from rules to a small model, a smaller one from small to medium, and almost nothing from medium to frontier — in which case default frontier use is simply wasteful. Another shows routine cases solved by a small model and a sharp frontier advantage on ambiguous ones — which is the empirical case for routing. The optimal system usually sits near the knee, where additional spend starts producing diminishing quality. And do not optimize average accuracy alone: weight errors by financial consequence, safety, customer impact and recoverability.

The unit of decision is not the workflow. It is the stage. The same process will correctly use six different kinds of system.

High-scale enterprises may establish an Intelligence Allocation Council spanning business, AI, IT, finance, security, risk, procurement and sustainability, owning the model portfolio, frontier-use policy, routing standards, eval standards, cost thresholds, sovereign workloads and environmental measurement. Its remit is reusable standards, high-impact exceptions and capital allocation — not approving individual model calls. A council that approves model calls has become the bottleneck it was created to remove.

Frontier models are not merely software products. They depend on capital, compute, energy, specialized talent and infrastructure, and the most capable ones may be controlled by a small number of providers. Default frontier use shifts margins, learning and bargaining power upstream. Countries that consume frontier models without building local expertise, evaluation, context and infrastructure may gain productivity while remaining strategically dependent. Used selectively, frontier models preserve budget, portability, provider choice and internal capability — restraint is a sovereignty instrument.

There is also an internal divide. Large firms may afford frontier reasoning for every employee while smaller ones rely on cheaper systems — but efficient model portfolios narrow that gap by combining open models, specialization, routing and domain knowledge.

The corrective is model minimalism — which does not mean choosing the smallest model. It means using no more model, context, reasoning and output than the outcome requires: reduce unnecessary context, reduce unnecessary output, avoid redundant calls, reuse cached context, batch work, use tools, and stop reasoning when the answer is sufficient. The smallest system is often a composition — a rules engine plus a small model may be more capable than one medium model — and minimalism improves economics, latency, privacy, resilience and auditability at once.

A global FMCG company processes retailer trade claims: 500,000 claims a year, €2.4 billion of claimed value, 60 retailers, 25 markets, thousands of contract formats.

The initial architecture sends every claim through one frontier model, which reads the claim, finds the agreement, calculates the entitlement, recommends a settlement and drafts a response. The result: high cost, slow peak processing, calculation errors, inconsistent customer handling, difficult audit and cross-customer context risk.

Decomposition maps each operation to its proper layer:

After redesign the company measures cost per validated claim, frontier escalation rate, false-negative escalation, human-review time, settlement accuracy and recovery value. And frontier-resolved cases become candidates for a new taxonomy, a new deterministic rule, a new training example, a small-model improvement and an evaluation case.

Today’s frontier exception should become tomorrow’s specialized routine whenever the organization learns enough to codify it.

The goal is not to keep every difficult case at the frontier forever. It is to move repeatable knowledge down the intelligence stack. That is how token capital compounds.

Self-optimizing does not mean unsupervised. The enterprise remains responsible for the allocation policy.

1. 01What percentage of AI usage goes to frontier models?
2. 02How much of that use has demonstrated a frontier performance premium?
3. 03Which workflows use language models for deterministic work?
4. 04What is our cost per successful outcome?
5. 05Which tasks could move to smaller or local models?
6. 06Which tasks genuinely deserve extended reasoning?
7. 07Do we evaluate complete systems, or only models?
8. 08Which frontier-dependent workflows lack fallback?
9. 09What happens if frontier pricing or access changes?
10. 10How much human review does each model architecture create?
11. 11Which model-use decisions are driven by convenience rather than evidence?
12. 12What is our frontier escalation rate?
13. 13Which difficult cases are being converted into reusable token capital?
14. 14Where could specialization outperform generality?
15. 15Which tasks require human authority regardless of model capability?
16. 16How are energy and environmental effects measured?
17. 17Who owns the model-routing policy?
18. 18Can the router be audited?
19. 19Are we buying intelligence, or building capability?
20. 20Where does one additional unit of reasoning create the greatest value?

Problem:
Business outcome:                 Frequency:
Value per successful case:        Novelty:
Ambiguity:                        Decomposability:
Deterministic components:         Verification availability:
Consequence of error:             Reversibility:
Latency requirement:              Required human authority:
Measured frontier lift:
Recommended system:

Workflow:
System A:            System B:            System C:

Task success:                     High-impact error rate:
Cost per attempt:                 Cost per success:
Latency:                          Human review:
Privacy:                          Portability:
Energy proxy:                     Business value:
Decision:

Task class:                       Default system:
Validation:                       Escalation trigger:
Frontier model:                   Human trigger:
Maximum reasoning budget:         Maximum retries:
Fail behaviour:                   Fallback:
Owner:

Case:                             Current system:
Failure or uncertainty:           Evidence missing:
Risk:                             Expected frontier value:
Frontier cost:                    Human review required:
Escalation approved:              Outcome:
Learning captured:

Workflow:                         Value per case:
Monthly volume:                   Cost ceiling:
Latency ceiling:                  Frontier allocation:
Retry budget:                     Human-review budget:
Escalation threshold:             Current cost per success:
Target:

Frontier case:
Why frontier was required:        Resolution:
Reusable pattern:                 New rule:
New tool:                         Training example:
Evaluation case:
Can future cases move down-stack?:
Owner:

Model or system:                  Provider:
Capability class:                 Approved tasks:
Prohibited tasks:                 Cost profile:
Latency:                          Hosting:
Privacy:                          Fallback:
Evaluation status:                Retirement risk:
Owner:

What is a frontier model?

A model operating near the leading edge of broadly available capability in areas such as reasoning, coding, multimodal understanding, scientific work, planning or agentic operation.

What is a frontier problem?

One for which established rules, specialized systems and routine procedures are insufficient, and where stronger general reasoning materially improves expected outcomes.

Does this mean enterprises should avoid frontier models?

No. It means frontier capability should be deployed where its additional value justifies its total cost and risk. Frontier models commonly require greater inference resources, but total outcome cost depends on success rate, retries, latency and human review — so a frontier model can absolutely be cheaper overall when it solves a difficult task in one attempt that a weaker system repeatedly fails.

Are small models always less capable?

Generally they have less breadth, but specialized small models can match or outperform larger general models on narrowly defined tasks.

Can the model route itself?

It can contribute a routing signal, but self-reported confidence should not be the only control.

Should every workflow use multiple models?

No. Multi-model complexity is justified only where it improves quality, cost, resilience, privacy or control. The risk of the opposite — one-model architecture — is unnecessary cost, provider dependence, poor task fit and weak fallback.

How should high-risk tasks be handled?

With suitable intelligence, deterministic validation, bounded authority and qualified human oversight. A stronger model does not eliminate governance.

Does more reasoning always improve accuracy?

No. Benefits vary by task, and additional generated reasoning can produce diminishing or negative returns.

What should the enterprise own?

It should strongly control task definitions, routing policy, private evaluations, context, tools, outcome data and learning.

What is frontier utilization?

The share of work or spend allocated to frontier systems. The metric is meaningful only when paired with measured frontier value.

Can the frontier move?

Yes. Today’s frontier capability may become tomorrow’s commodity model, edge model or deterministic service. Routing policy should be reviewed whenever models change, prices change, the task distribution changes, evaluations change, or incidents occur.

Where should a company begin?

Select one high-volume workflow currently using a frontier model. Decompose it into rules, retrieval, calculations, routine interpretation, genuine ambiguity and human decisions. Then evaluate alternative architectures.

The most powerful model is an extraordinary resource. It can understand unfamiliar problems, synthesize across domains, reason through ambiguity, operate tools, explore possibilities and help humans move beyond established methods. That capability should be celebrated. It should not be wasted.

The first phase of enterprise AI rewarded access. The second rewarded adoption. The next will reward allocation. The winning organization will not ask how to put its strongest model into every process. It will ask where stronger intelligence genuinely changes the outcome.

That question requires humility, because many apparent AI problems are actually data problems, process problems, policy problems, integration problems or management problems. A larger model may temporarily work around them. It may also make them harder to see.

The mature enterprise learns to separate:

• Language from calculation
• Judgment from policy
• Novelty from volume
• Importance from ambiguity
• Model capability from system reliability
• Intelligence access from intelligence ownership

And it understands that:

• Rules are not inferior to reasoning
• Small models are not inferior when the task is small
• Frontier models are not excessive when the problem is truly frontier
• Humans are not fallback systems for poorly designed automation

The correct enterprise architecture is not a pyramid in which everything moves upward toward the largest model.

Routine work moves through rules, tools and specialized models. Difficult work escalates. Frontier work receives frontier intelligence. Humanly consequential work receives human authority. And then learning flows back down — resolved cases becoming rules, tools, evaluations and smaller models. This downward movement is as important as the escalation, and it is the half that almost nobody builds. When the company learns from a frontier case, the same problem should not remain frontier forever.

The frontier model is therefore not only a solver. It is an explorer, a teacher, a capability builder and an exception resolver. Its highest enterprise value may come not from answering every question, but from helping the organization reduce the number of questions that require it.

The agentic firm should not maximize intelligence consumption. It should maximize useful, reliable, responsible outcomes per unit of intelligence.

That is token efficiency. That is strategic sovereignty. That is intelligent allocation.

And that is how enterprises reserve their most powerful machines for the problems powerful enough to deserve them.

The source conversation.This article begins from Satya Nadella’s dictum that enterprises should not use frontier models for non-frontier problems, and his example of trade-promotion claims as repeatable workflows suited to specialized models, enterprise traces and efficient learning systems.

Cost per successful task.OpenAI’s 2026 enterprise scorecard argues that AI economics should be measured through useful work, dependability and full cost per successful task rather than token price alone.

Evaluation of complete systems.OpenAI’s 2026 evaluation guidance emphasizes that frontier and agentic performance depends on the tested model, reasoning budget, tools, harness, safeguards, retries, time and cost.

Enterprise evals.OpenAI’s enterprise evaluation framework recommends specifying concrete quality requirements, measuring them under realistic workflow conditions, and improving systems through observed failures.

Model routing and cascades. FrugalGPT and RouteLLM provide research evidence that learned cascades and routers can improve the cost-quality trade-off relative to using one model universally, although results remain workload dependent.

Specialized small models. Recent enterprise-search and contract-extraction studies demonstrate that fine-tuned or domain-specialized small models can match or outperform larger models on some narrow tasks while improving throughput and cost.

Distillation and specialization. Google Research has demonstrated approaches for transferring useful reasoning signals from larger models into smaller task-specific systems, and for extracting efficient task-specific subnetworks.

Inference-time reasoning.Research on inference-time scaling shows that additional computation can improve difficult reasoning, but that the benefits vary across tasks and cannot be reduced to “more tokens equals more accuracy.”

Energy and efficiency.The IEA’s 2026 analysis notes that energy consumption per AI task is improving rapidly while total data-centre electricity demand continues to rise as usage and capabilities expand.

Risk management.NIST’s AI RMF emphasizes lifecycle testing, evaluation, verification, validation, continuous monitoring, and consideration of economic and environmental impacts when selecting and managing AI systems.