Minimum Viable Model: Structured Model Selection Criteria For Agents
I have been saying that the SLM or LLM is the smallest part of the agent, but models are still critical. That means I must address model selection as part of the Harness, Loop, and Graph series.
The Frontier Lab Strategy & Its Gaps
Frontier labs are built on the premise that more capable models are the most efficient path to more capable agents. The model will do 90% of the work with minimal support from components like harnesses, loops, and graphs. People from OpenAI and Anthropic have taken to social media urging users to delete their MD file repository with each new release. They claim that most of that context is no longer necessary.
So far, that strategy hasn’t panned out for multiple reasons. The models are undoubtedly more capable, but a model alone hasn’t achieved the consistency, reliability, or customization required to support enterprise workflows. Frontier models, even open-weight options, are still prohibitively expensive for our current workflow.
Let me start out by providing evidence for those claims, so you can see this is more than just personal experience talking. I will explain my approach to model selection, but I’m going to revisit this claim. It is only true if the business has solved enough of the context and verification problems.
As it turns out, the model selection you build today is also a bridge to how the business will manage model selection in the future. That transformation has multiple drivers.
How much of the context, verification, and (by extension) learning problems you have solved for the workflow. The better defined the workflow, context, and verification, the smaller the model that’s required. As it turns out, information flywheels iteratively bring down the cost of agents.
How frontier AI helps solve the context and validation problems. I will explain this in greater depth in just a minute, but frontier AI has a place in your overall AI strategy. Just not the places most people have it in today.
How rapidly small model capabilities are improving.
The ‘One-Shot’ Approach To Completing A Workflow Isn’t Viable, Even With Frontier AI
The math here is extremely straightforward. If an agent’s per-step reliability is p, a workflow of H dependent steps succeeds at roughly p^H. At 98% per-step accuracy, a 100-step workflow completes 13% of the time. At 85% per-step, which is generous for an unassisted model on a real enterprise task, 10 steps get you to about 20%. This is the math of compounding errors and cascading systems failure.
METR’s time-horizon work shows frontier models near 100% success on tasks that take a human under 4 minutes, and below 10% on tasks that take a human more than 4 hours. More steps without context and verification to keep things on track lead to failure in even frontier AI. However, models are improving in ways that most benchmarks fail to capture.
METR’s 50%-success time horizon has been doubling every 7 months, but that appears to be dropping to every 4 months. By this time next year, the doubling rate might be even faster. That progress rate curve tells us where on the workflow complexity scale that frontier AI’s one-shot stops working. This isn’t enough to support a complete enterprise workflow, but it is enough to enable individual steps. That’s really important, and I’ll explain why in a bit.
The paper ‘The Illusion of Diminishing Returns’ isolated execution from reasoning by handing models the full plan and the required knowledge/information/context, then measuring how many steps they could execute. They found that per-step accuracy degrades as the context fills with the model’s own prior mistakes. This is the context problem from my article on harnesses.
You cannot buy your way out of the context or verifier problem on long workflows with frontier AI, and small models are not up to the job over many steps, even with context, unless you solve the verifier problem as well. The verifier problem prevents the context window from filling because you only pass forward what the model needs to fix for the next iteration in the loop.
Spinning Up Multiple Agents In Unconstrained Loops Has Not Worked Either
The best evidence here is MAST, Berkeley’s multi-agent failure taxonomy. They annotated more than 1,600 execution traces across 7 popular multi-agent frameworks and sorted the failures into 14 modes in 3 families:
Specification issues caused 41.8% of failures.
Inter-agent misalignment caused 36.9% of failures.
Task verification caused 21.3% of failures.
Roughly a third of observed failures are inter-agent misalignment. You can’t solve the context problem by adding agents.
Cognition found that actions carry implicit decisions, and conflicting decisions carry bad results. Two sub-agents each make reasonable local choices, and the merge produces something incoherent. The authors’ conclusion is that most of these failures stem from system design, not model capability. Better orchestration fixes them. Bigger models do not.
‘Multi-agent doesn’t work’ is too broad, and I want to clarify a key distinction so you don’t think I’m saying that multi-agent systems don’t work across the board. Anthropic published a multi-agent research system that outperformed a single agent by 90.2% on their internal research evaluation. It also burned about 15x the tokens of a normal chat interaction, and they found token usage alone caused 80% of the performance improvement.
Their guidance is that it works for problems that split into genuinely parallel strands, and works poorly for tightly interdependent work like coding. The failure mode is not agents working together or the number of agents. It is the unconstrained collection of agents thrown together without solving the context and verifier problems.
The strongest proof of the ‘multi-agent + context and verifier’ argument comes from Cognizant AI Lab. They completed a 1,048,575-step task with zero errors by decomposing (defining) the workflow to the point of absurdity. They provided context and created verifier mechanisms to support the agents at every micro-step.
Reliability comes from information and architecture, not the model’s complexity or the number of agents that are deployed. Multi-agent systems work, but adding agents still doesn’t overcome the context or verifier problems.
The Cost Gap Is A Multiple That Undermines Or Enables Margins
As of July 2026, Claude Opus 5 costs $5 per million input tokens and $25 per million output tokens. GPT-5.4 costs $2.50/$15. Claude Sonnet 4.6 is $3/$15.
Llama 4 Scout on Together AI costs $0.18/$0.59, DeepSeek V3.2 costs $0.14/$0.28, and Mistral Nemo costs $0.15/$0.15. That is a 25x to 40x spread on output tokens. Smaller models make agents’ unit economics work for more workflows.
Microsoft’s Azure numbers give us a workflow-level comparison. On a workload processing 50 million tokens per month, the difference between routing to a frontier-class model and routing to Phi-4-mini is roughly $5,000 versus $125. That is the difference between an economically viable workflow and a demo that the feasibility assessment recommends shelving.
This is especially true for workflows that only convert to value in a low percentage of cases. Agentic commerce is a good example. Only a small percentage of searches convert to sales. At $5K per day, the unit economics of those searches is questionable for small to medium-sized retailers. At $125 per day, returns scale faster than costs on much lower volumes and average margins per transaction.
Agentic workflows are not one call, so either the costs or the savings compound with each iteration and loop. Most of the model calls are for doing something with low complexity (for an SLM or LLM) like parsing, routing, formatting, checking, and extracting. Paying frontier rates for simple steps is the single most common cost sink I see in client architectures.
Here comes the “but.” Low complexity calls are only low complexity if we have solved most of the workflow’s context and verification problems. If we have a good understanding of what to parse and how, a very small model can get the job done. If we have a good understanding of what a high-quality parsing result looks like, a very small model can loop its way to success.
If neither of those is true, we must look at frontier models as a potential bridge. Their capabilities can help fill in some of the gaps to make an agent reliable enough for early adopters to use. As I explained in the other articles in this series, usage kicks off information flywheels. Essentially, frontier AI can give us the foot in the door to begin solving the context and verifier problems. As we build both answer keys, we can reduce the size and cost of the model used.
A New Approach: Minimum Viable Model
There’s a new approach to model selection that rejects the frontier AI strategy unless it is absolutely necessary. Companies like Microsoft and Thinking Machines have proven it works, so again, this isn’t just my opinion and experience. Microsoft saw significant optimization in its engineering workflows using what I call the Minimum Viable Model (MVM). It starts with a question.