The Ontology Gap
Why generic AI fails in vertical markets — and what domain-fluent teams ship instead.
Abstract
Frontier models are extraordinary general reasoners and mediocre vertical specialists. The bottleneck is no longer model capability; it is the gap between a model's pre-trained world and the specific ontology of a customer's business. This essay argues that the next decade of AI value capture will be decided by who can close that gap fastest — and that the people who can are the ones worth hiring.
The thesis in one paragraph
AI deployments fail or succeed on a single axis: how well the system's internal representation of the domain matches the customer's actual ontology — the entities, relationships, processes, edge cases, and implicit constraints that define how work really gets done. A model with a state-of-the-art base capability but the wrong ontology will lose every time to a weaker model wrapped in the right one.
Why this is an industry-shaping problem
For the first wave of LLM products, the model itself was the moat. Whoever had access to GPT-4 in 2023 had a market-defining advantage. That advantage has evaporated. As of mid-2026, half a dozen open and closed models cluster within a few percentage points of each other on every meaningful benchmark.
What separates a thriving AI product from a stalled pilot is no longer the model. It is whether the team around the model understands the customer's domain well enough to translate it into prompts, tools, retrieval indices, evaluation criteria, guardrails, and feedback loops.
What an ontology actually is (in deployment terms)
Ontology, in the AI deployment sense, is the working model of how a particular business reasons about its own work. It is rarely written down. It lives in:
- The vocabulary an expert uses to describe a normal day.
- The implicit hierarchy of which problems are urgent vs. background.
- The way the same entity (a 'customer', an 'account', a 'case') is referred to differently across departments.
- The exceptions that experienced staff handle without thinking — and that any new system will get wrong.
- The judgement calls that aren't in any SOP but that everyone in the building agrees on.
A model with no exposure to this ontology will produce outputs that look plausible to an outsider and obviously wrong to an insider. This is the single most common reason pilots stall.
The data is unambiguous
Across the AI deployments we observe through StarPlan, the strongest predictor of a successful production rollout is not model choice, prompt sophistication, retrieval architecture, or even compute budget. It is whether the team building the feature spent meaningful time inside the customer's workflow before writing the first line of code.
The fastest way to ship a useful AI product is to spend the first two weeks not building one.
Why the frontier labs underestimate this
Research labs are organized to push capability frontiers, which means their default measure of progress is general-purpose benchmark performance. That instinct is exactly wrong for vertical deployment, where the work is to deliberately narrow the model's distribution to match a customer's ontology rather than broaden it.
This is why the most valuable AI engineers today are not the ones training models, but the ones translating domains into prompts, tools, evals, and feedback loops. The skill is closer to systems analysis than to ML research — and the market has not fully priced this in yet.
How to hire for ontology fluency
Three signals reliably predict whether an engineer can close the ontology gap inside an unfamiliar domain:
- Demonstrated curiosity about a domain they didn't grow up in — a portfolio piece where they obviously got smarter about an industry by building for it.
- An ability to explain why a previous AI feature failed in terms of the domain, not the model.
- Comfort sitting next to a non-technical expert for two weeks before writing meaningful code.
These are not the same signals as classical software engineering — and they are not what most hiring loops currently optimise for. The teams that update their loop fastest will win the next wave of deployments.
What this means for the StarPlan marketplace
We organise the StarPlan AI engineer marketplace around roles, skills, and industry experience — not just generic 'AI engineer' labels — precisely because ontology fluency is industry-specific. A forward deployed engineer who has shipped three healthcare agents is, for a healthcare team, worth ten generalists with stronger ML CVs.
The marketplace exposes that signal directly: filter by industry experience, screen for shipped work in the domain, then reach out. The right ontology is almost always already in the room — you just have to be willing to look for it.