104 - Frontier models, specialized models, and why enterprise AI uses both

Enterprise AI is almost never one model doing everything. A frontier model brings the reasoning and the world knowledge. A smaller specialized model runs alongside it for narrow jobs that happen at volume, not in place of it.

This lesson walks through the three families that dominate the frontier today, the three separate sources a frontier model can draw knowledge from, and why the common conflation of MCP with "retrieval" is worth correcting before you go further into the curriculum.

A frontier model is a large language model at or near the current limit of what is publicly available in terms of scale, training data, and capability. The label is relative and moves as the state of the art advances. A model that was frontier in 2023 may be a mid-tier model in 2026.

Three signals mark a model as frontier. First, scale: parameter counts and training compute measured in exaflops that only a handful of labs can afford. Second, capability: top scores on reasoning, coding, mathematics, and multimodal benchmarks. Third, steerability: reliable instruction-following, calibrated responses, and the interaction patterns enterprise deployments require, especially tool use and long-context reasoning.

As of 2026, three families dominate the conversation. Each is released in multiple tiers that trade capability against latency and cost, and each iterates on a roughly six-to-twelve month cadence.

Where does a frontier model's answer actually come from? There are three separate sources, and it is worth keeping them straight because they are solved by three different mechanisms. The training-cutoff question, the "can it see today's news" question, and the "can it see our data" question are not the same question.

The third column above is the one most easily misread. MCP sits at the column header, but MCP is not doing any searching. It is the protocol that tells the model a tool is available, describes what the tool does, and carries the invocation. The tool on the other end is the thing that actually retrieves anything. Retrieval, RAG, tool-use search: these are orthogonal concerns that happen to be how many MCP-exposed tools work, not what MCP is.

Enterprise data is never as simple as running inference on a raw schema. The hard part is never the SQL syntax. It is knowing what the data actually means in the context of the business: which metric the CFO cares about, which definition of "active customer" applies in this region, whether revenue is reported net or gross in this table, how the holiday calendar shifts week-over-week comparisons in retail.

This is where frontier models earn their keep even when none of your data was in their training. Trained on trillions of tokens of public web data, books, and code, they have absorbed the background world knowledge that a skilled data engineer or business analyst accumulates across decades of work. A frontier model already knows that a store located in Los Angeles has a larger addressable market than one in a small town. It already knows that "churn" means customers leaving, that Q4 skews heavily in retail, that "GAAP revenue" excludes certain adjustments, and that a column called "arr" is probably annualized recurring revenue.

Smaller and more specialized models do not have this breadth. They were not trained to know that Los Angeles is a large market. That kind of generalized common sense is the direct output of the massive, diverse pre-training corpora that only frontier labs can afford to assemble and train on.

A specialized model is trained or fine-tuned to do a specific task, not to hold a general conversation. The trade-off is exactly what you would expect: narrower scope, lower cost, lower latency, and often higher accuracy on the task it was built for. Common examples include embedding models that convert text into fixed-size vectors for similarity search, classifiers that tag content by category, named-entity extractors, and safety or moderation filters.

What specialized models lack is world knowledge. An embedding model produces a useful vector for any text it is given, but it will not reason about whether "sales" in a given query means gross revenue, net revenue, or unit count. A classifier labels content by the categories it was trained on and nothing else.

They are not chosen instead of a frontier model. They are chosen alongside one, for the narrow jobs that run thousands or millions of times per day where a frontier round trip would be wasteful.

A parallel ecosystem of open-weight models continues to close the gap with frontier labs on many tasks. Meta's Llama family, Mistral's models, and releases from DeepSeek and Qwen offer capable alternatives where self-hosting, on-premise deployment, or custom fine-tuning matters more than absolute benchmark leadership.

Local models are often smaller than frontier flagships, frequently specialized or fine-tuned, and typically run inside a customer's own infrastructure. They make sense when data residency rules forbid sending content to a third-party API, when latency budgets rule out a network round trip, when per-request cost at massive volume outweighs the capability gap, or when a specific domain has been fine-tuned into a smaller model that beats a general frontier model on that domain.

The honest trade-off is that local and smaller models trail frontier models on the tasks that benefit most from breadth: open-ended reasoning, ambiguity resolution, and drawing on world knowledge that was never in the schema. They can be excellent components in a larger system. They rarely replace a frontier model as the top-level reasoner for questions that require judgment.

Worth stating plainly because the framing is easy to get wrong: Plexara does not run the frontier model. Plexara is an MCP server. The customer chooses a frontier model and a client (Claude.ai, ChatGPT, Gemini, Claude Desktop, Cursor, or any other MCP-capable client) and connects that client to Plexara. The frontier model lives on the customer's side of that connection. Plexara lives on the other side.

Inside Plexara, narrow specialized models handle high-volume internal jobs. A small embedding model (Ollama serving nomic-embed-text) produces the 768-dimensional vectors that the Plexara memory and knowledge subsystems both depend on for semantic search. Ollama is not chosen because it is a better general model than the frontier. It is chosen because embeddings are a narrow internal job at a latency and volume that would be wasteful to send across a frontier round trip.

There is no single correct model and no single correct tier. Choice is driven by the workload and by constraints that have nothing to do with raw benchmark scores.

Eight terms cover the vocabulary you will see in model vendor documentation, architecture discussions, and Plexara reference material. Tool use and RAG in particular are worth pinning down now so the rest of the curriculum does not have to keep defining them.