Foundation models vs task-specific models comes down to breadth against focus. A foundation model is trained on broad data so it can be adapted to many tasks. A task-specific model is trained to do one job, and most start life as a foundation model trained further on examples of that job. The foundation model is the better choice while the work is open-ended, changing or low in volume. The task-specific model wins once the same job runs at volume and its output can be checked, because it costs less per task and is easier to hold to a quality bar.
This guide covers what each kind of model is, when each wins, examples of task-specific models you can download today, and how they differ from domain-specific models. It closes on the view our lab works from: a business's work can be split across specialists, each trained for one job and composed by routing.
What is a foundation model?
A foundation model is a large model trained on broad data that can be adapted to a wide range of tasks. The term comes from a 2021 report by Rishi Bommasani and colleagues at Stanford's Center for Research on Foundation Models, "On the Opportunities and Risks of Foundation Models", which described models "trained on broad data at scale and are adaptable to a wide range of downstream tasks". The report's examples were BERT, DALL-E and GPT-3. Today the label covers the GPT, Claude and Gemini families and open-weight families such as Llama, Qwen and Gemma.
You adapt a foundation model in two ways: by prompting it, with instructions and examples in every request, or by training it further on your own data. The same report named the catch: "the defects of the foundation model are inherited by all the adapted models downstream." Every task-specific model built on a foundation model starts with its base's strengths and its flaws, which is why a specialist needs an evaluation of its own.
What is a task-specific model?
A task-specific model is a model trained to do one defined job, with a fixed kind of input and a fixed kind of output. Classifying a support ticket, extracting fields from an invoice, choosing which tool an agent should call, ranking search results and summarizing a meeting for a given question are each a task. Because the job is narrow, it has a test set: you can say what a correct answer looks like and measure how often the model gives one.
Most task-specific models today are built by training a foundation model further on examples of the task, through fine-tuning or distillation from a larger model. Size follows the task. The retrieval model in our QMSum study has 33M parameters, while a hard reasoning task can need a large model. The useful description is right-sized: the smallest model that holds the task's quality bar.
| Foundation model | Task-specific model | |
|---|---|---|
| Trained on | Broad data at scale | Examples of one task |
| Handles | Many tasks, steered by the prompt | One job with fixed inputs and outputs |
| Size | Usually large | Right-sized to the task |
| Prompt per request | Instructions and examples every time | Short, with the instructions trained in |
| Quality on the task | Strong without task training | Set by training, checked on held-out examples |
| Cost per task | Higher price per token, more tokens | Lower price per token, fewer tokens |
| Typical failure | Format drift and long answers | Inputs outside the task it learned |
| Best for | Open-ended, changing or low-volume work | Stable, repeated, checkable work |
Which AI system works only on a specific task?
A task-specific model, which older vocabulary calls narrow AI. IBM describes narrow AI as AI that "can be trained to perform a single or narrow task" and cannot work outside its defined task. IBM also counts every AI system in use today as narrow, chat assistants included, so the practical line sits at the model. A spam filter, a passage ranker or a content-safety classifier is built for one job and does only that job. The foundation model behind a chat assistant takes on whatever the prompt asks.
When does a task-specific model beat a foundation model?
When the same task runs at volume, its output can be checked, and the same instructions repeat in every prompt. Volume spreads the cost of building the model, checkable output gives you an evaluation to train against, and the repeated instructions are exactly what training removes from each request. Our published results show the pattern on one task.
Training on the task moved quality more than better inputs did. In our QMSum study (arXiv 2609.25028) on query-focused meeting summarization, we held one 1.2B base model fixed. Replacing the first 4,500 transcript words with 2,000 retrieved words added 1.55 ROUGE-1 on test and 0.29 on validation. Fine-tuning it on those same retrieved spans added 5.29 ROUGE-1, with a 95% interval of +4.02 to +6.56.
A smaller specialist held the bar. A 406M specialist trained the same way scored 36.33 ROUGE-1 against our 1.2B system's 35.41, a difference QMSum cannot statistically separate, while using under half the peak inference memory.
A specialist outscored hosted generalists on that benchmark's metric. Under one concise prompt and a reference-overlap scorer, a released 406M specialist scored at least 6.2 ROUGE-1 above each of the five proprietary hosted models tested. The paper limits that ordering: the hosted models produced verbose outputs, and no human or factuality evaluation was run. All of these conclusions are limited to QMSum and automatic metrics.
The spend sits on repeatable work. In OpenRouter's public data for the 30 days to 12 October 2026, classification, extraction and transformation took 20.8% of classified model spend, at 1.50 to 1.84 times the average price per token. Those are tasks with labels and records as outputs, which a specialist can be evaluated on precisely.
The cost case falls on two fronts. A task-specific model carries a lower price per token than the frontier model it replaces, and it needs fewer tokens per task, since the instructions and examples repeated in every prompt are trained into the model itself. How much the second front saves depends on how much of each prompt is repeated boilerplate, and prompt caching already discounts repeated context on frontier APIs, so measure it on your own traffic. The cost-per-task calculator runs both numbers for one workload.
Researchers at NVIDIA make the same argument for agents. In a 2025 position paper, "Small Language Models are the Future of Agentic AI", Peter Belcak and colleagues observe that in agentic applications, language models "perform a small number of specialized tasks repetitively and with little variation". They argue that small models are "sufficiently powerful, inherently more suitable, and necessarily more economical for many invocations in agentic systems."
When is a foundation model the better choice?
When the work is open-ended, still being defined, or too low in volume to repay training. Four situations favour it:
- A new task. Prompting is the fastest way to learn what the task needs.
- Requests that differ every time, such as research, drafting and open conversation.
- Low volume. A few thousand tasks a month seldom repays building a model.
- Broad or changing knowledge. A foundation model with retrieval covers facts that move.
The prompting period is also where the specialist's training data comes from. Log the prompts and outputs, correct the wrong ones, and keep a held-out set. Once the task stabilises, the logs become the training data and the held-out set becomes the bar the specialist has to pass. Our post on whether fine-tuning is dead draws the same line between prompting and training.
What are some examples of task-specific models?
Plenty of task-specific models are public. Five, each read from its model card or paper on 29 October 2026:
| Model | Task | Built from |
|---|---|---|
| BART-large-CNN | News summarization | BART, fine-tuned on CNN Daily Mail |
| ms-marco-MiniLM-L6-v2 | Ranking passages for a query | Cross-encoder trained on MS MARCO |
| Llama Guard 3-1B | Content safety classification | Llama 3.2 1B, fine-tuned |
| FunctionGemma | Function calling | Gemma 3 270M |
| QMSum locator and summarizer | Query-focused meeting summaries | Ertas research models |
BART-large-CNN is BART fine-tuned on CNN Daily Mail, "a large collection of text-summary pairs", and its card lists one intended use: text summarization.
ms-marco-MiniLM-L6-v2 takes a query and a passage and scores how well the passage answers it, so a search system can sort its results.
Llama Guard 3-1B is, in Meta's words, "a fine-tuned Llama-3.2-1B pretrained model for content safety classification". It labels a prompt or a response as safe or unsafe and lists the categories violated, and Meta designed it to lower the cost of running moderation.
FunctionGemma sits one step earlier. Google released it "as a foundation for creating your own specialized function calling models", built on Gemma 3 270M and "intended to be fine-tuned for your specific function-calling task". It is a specialist base, meant to be specialized again on your own tools.
Our QMSum system pairs two specialists. A 33M locator scores transcript windows against the question, and a summarizer writes the answer from the highest-scoring spans. Both are on Hugging Face under the ErtasAI account.
How is a task-specific model different from a domain-specific LLM?
A domain-specific LLM knows a field, and a task-specific model does a job. A domain model learns the vocabulary, facts and conventions of a field such as law, medicine or finance, and then serves many tasks inside it, from answering questions to drafting documents. A task-specific model is defined by one input and one output, such as pulling the parties and dates out of a contract, and that job could sit in any field. The two combine well: a domain-specific LLM can be the base a task model is trained from, so the specialist starts out knowing the field's language. Our guide to domain-specific LLMs covers how domain knowledge gets into a model.
Can a business's work be split across specialist models?
That is the view our lab works from, and it has an old precedent. In The Wealth of Nations, Book I, Chapter 1, Adam Smith described a pin workshop where making a pin was "divided into about eighteen distinct operations". Ten workers, some doing two or three operations each, could make "upwards of forty-eight thousand pins in a day", about 4,800 each. Working alone, Smith judged, "they certainly could not each of them have made twenty, perhaps not one pin in a day".
Applied to models, the division of labour looks like this. Take a support workflow. Handling a ticket breaks into steps: classify the request, pull the account details out of it, find the relevant policy, draft the reply, and check the draft against policy. Each step has its own input, its own output and its own test set, so each can have a specialist trained for that one job and right-sized to it. A router sends each step to its specialist, and anything outside what the specialists were trained on goes to a foundation model. Because the structure of the work decides the route, you always know which model answered and what it was trained to do.
Smith's workshop also shows that the split is a design decision, since some of his workers did two or three operations. A step too small to repay its own model shares one with its neighbour, and an open-ended step stays with the foundation model.
Our measured evidence so far covers single tasks, plus the two-model pipeline in the QMSum study. Whether a routed network of specialists matches a frontier generalist across a business's whole workload is the research question our lab is working on, and we will publish the results as they come in. The NVIDIA paper argues for the same architecture where agents also need general conversation: "heterogeneous agentic systems (i.e., agents invoking multiple different models)". For the routing mechanics, see LLM routing strategies and the model routing glossary entry.
How do you move a task from a foundation model to a specialist?
Start with one repeated step and keep the foundation model as the fallback.
- Pick the task. Choose the repeated step with the largest bill, measured as cost per task.
- Log it. Keep the foundation model's production prompts and outputs, and correct the wrong ones.
- Build the evaluation set. Hold out examples the specialist never trains on, with a pass mark agreed before training.
- Train and size it. Train a few model sizes on the logged examples and keep the smallest that passes.
- Route and watch. Run the specialist in shadow next to the foundation model, then move traffic over, with the foundation model handling out-of-scope requests.
Ertas runs this as the adaptive model endpoint: a specialist trained on your agents' task and served through an OpenAI-compatible API. New versions train on your agents' traffic in the background, are scored against your evaluations, and go live only with your sign-off. If a new version falls short, the current model stays in service. It runs Ertas-managed, in your own cloud or on-premise. The endpoint is currently invitation only, and we are developing a more streamlined version for wider access.
Frequently Asked Questions
Which AI is best for specific tasks?
A model trained for that task, picked by testing a few candidates on your own held-out examples. Public leaderboards rank general ability, and your task's evaluation set measures the thing you need. Start by prompting a foundation model, log the results, and train a specialist once the task is stable and repeated.
What are examples of task-specific small language models?
BART-large-CNN for news summarization, the ms-marco-MiniLM cross-encoders for ranking passages, Llama Guard 3-1B for content safety classification, and FunctionGemma, built on Gemma 3 270M, for function calling. Each is published with a model card describing its one job.
Are task-specific models always small?
They are usually smaller than a foundation model, and their size follows the task. A ranking or retrieval step can run on tens of millions of parameters, and a hard reasoning task can need a large model. The rule is the smallest model that holds the task's quality bar on held-out examples.
Is a fine-tuned model still a foundation model?
A fine-tuned model is an adapted foundation model. Once it is trained for one job it behaves as a task-specific model, and it keeps whatever its base got wrong: the Stanford report warned that a foundation model's defects are "inherited by all the adapted models downstream". Evaluate it on its own task.
What happens when a task-specific model gets a request outside its task?
Its answers degrade, because it never learned that kind of input. Two defences work together: train it on examples it should decline, and route out-of-scope requests to a foundation model before they reach it.
The Short Version
Use a foundation model while the work is new, open-ended or low in volume. Train a task-specific model when the same job repeats at volume with output you can check: it costs less per task on price and on token count, and its quality can be held to a bar. Split a workflow into steps, give the repeated steps their own specialists, and let a router send the rest to a foundation model. If the money question comes first, start with cost per task.
Sources, read 29 October 2026: Bommasani et al., "On the Opportunities and Risks of Foundation Models" (Stanford CRFM, 2021); Belcak et al., "Small Language Models are the Future of Agentic AI" (NVIDIA, 2025); IBM, "Types of Artificial Intelligence"; Adam Smith, The Wealth of Nations, Book I, Chapter 1 (Project Gutenberg); model cards for BART-large-CNN, ms-marco-MiniLM-L6-v2, Llama Guard 3-1B and FunctionGemma. Our research: the QMSum study and the OpenRouter structured-task report.