A recruiter’s ad showed up for me on LinkedIn in October: Director of Ontology & Knowledge, remote, US. The client is a large healthcare organization building “a brand-new Ontology & Knowledge Products function that will serve as the semantic foundation for enterprise AI, knowledge graph, and agent-based technology initiatives.” It asks for 14 years in data or knowledge work, eight of them with ontologies or knowledge graphs, and five leading teams. Eighty-two people had applied when I looked.

So do you need one? For most companies, not yet. The job exists because agents fail when nobody has agreed what the company’s words mean, and that problem is real. But the first version of the fix costs far less than a director. It’s typed files that one person owns, added to every time an agent gets something wrong, with a check on any field that has drifted before. The hire starts to make sense when several systems disagree about what a customer or an order is, when a regulator needs definitions you can defend, or when different teams keep building agents on conflicting vocabulary.

What does an ontologist do?

An ontologist decides what the things in your business are, what’s true about each of them, and how they relate, then writes that down in a form software can check. The ad lists the work as “enterprise ontologies, semantic models, taxonomies, entity relationships, business definitions, and metadata standards”. In plainer words, they own the company’s vocabulary and make it precise enough that a machine can’t misread it.

Four terms get used as if they were the same, and they aren’t. A taxonomy is a tree of categories: invoices sit under finance documents, which sit under documents. An ontology adds types, properties and the relationships allowed between them. So a customer has accounts, an account has a billing contact who is a person, and nobody can be their own manager. A knowledge graph is your real facts stored in that shape, thousands or millions of specific customers and accounts joined by those relationships. A semantic layer is narrower and far more common: one agreed definition of each business number, so “revenue” or “active customer” comes out the same in every dashboard and every agent query.

Microsoft now ships an ontology item in its Fabric data platform, still in preview. Its docs call it “a shared, machine-understandable representation of your business”, which is as good a one-line definition as any.

Why is this suddenly a job title? Because of agents. Simon Willison wrote about the new name for the skill, context engineering, quoting Tobi Lutke’s definition: “the art of providing all the context for the task to be plausibly solvable by the LLM.” An ontology is one way to do that for a whole company at once. Ananth Packkildurai made the same point from the data side in August, in a piece on what agents need: “An ontology for AI agents is not a single file or graph. It is a system”.

If the distinctions above are new, I’ve written about knowledge graphs versus vector search and why a semantic model is not a report. Under most of it sits a plainer problem I’ve also covered, two systems calling one thing by different names.

Ontology hiring so far

The ads are real, and they’re at serious employers. Capital One posted a Manager, Ontology & Data Modeling on 31 August 2026. Novartis has two Associate Director openings in semantic and knowledge engineering that name agentic AI in the description. Lockheed Martin posted an AI Ontology Engineer in September. And there’s the ad I saw, which the recruiter, Harnham, also runs on its own site, where the client is described only as working in a highly regulated industry.

What I couldn’t find is a count. Nobody I could find publishes how many US job ads ask for ontology work, so any claim that the job is booming rests on a handful of listings. The one steady series I found is UK-only. IT Jobs Watch counted 43 permanent ads citing ontologies in the six months to 29 October 2026, against 24 and 17 in the same stretch of 2025 and 2024. As a share of all UK permanent ads that’s 0.035%, down from 0.048% a year earlier but up from 0.025% the year before. Ads for the work grew, and the rest of the job market grew faster.

So the reading is narrow. Large, regulated companies with a lot of data are hiring for this. That isn’t the same as every company needing it. It’s also a different hire from the one most firms should make first, an AI lead who can run the whole program.

Does an ontology make agents more accurate?

Sometimes, on questions over structured data, and the record on upkeep is poor.

The best-known result is a 2023 benchmark where GPT-4, answering business questions straight off SQL tables, scored 16%. The same questions posed over a knowledge graph scored 54%. A 2024 follow-up by the same group got to 72%, counting answers where the model said it didn’t know. The authors were at data.world, now part of ServiceNow, which sells this kind of tooling.

LinkedIn built a knowledge graph from its own metadata, query logs, wikis and code for an internal data chatbot. Expert review found 53% of its responses correct or close to correct. Useful, and still a long way from something you’d let act alone.

The evidence on the other side is mixed too. A 2025 study notes that “recent studies report that GraphRAG frequently underperforms vanilla RAG on many real-world tasks”, meaning graph-based retrieval often loses to plain document search. Its own tests found the graph level with plain search on simple fact lookups and ahead on complex and creative tasks. And the write-up of the most interesting internal build I’ve read about mentions neither an ontology nor a knowledge graph. OpenAI’s data agent works over 600 petabytes of data. The Decoder’s account describes six layers of context, including descriptions from domain experts of what the data means and canonical metric definitions. That’s a semantic layer in all but name.

The older problem is keeping it all true. Cory Doctorow wrote in 2001, in his essay on metadata, that “A world of exhaustive, reliable metadata would be a utopia. It’s also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities.” Clay Shirky argued four years later that ontology is overrated for most of the web, because fixed categories don’t fit things people label in their own ways. And by 2003 Harvard Business Review was already running a piece on how to fix knowledge management. Companies had spent heavily on software that promised to get people sharing what they knew.

I found a small case of this in Tallyfy’s own files in October. tallyfy.com keeps an inventory of every image on the site, then 1,919 rows, each with a risk level. 1,792 rows said LOW and 106 said low, all from one batch added in January. Nothing read that column, so nothing noticed, and anything filtering on LOW would have skipped those 106. Nobody designed that drift. It’s what a field with no owner and no check does, so I fixed the rows and added a check that refuses anything but LOW, MEDIUM or HIGH.

Keep typed files and grow them from failures

Tallyfy has never had an ontologist, and a fair amount of its knowledge already sits in typed files that software reads. The comparison pages on tallyfy.com come from 74 vendor files that all share one schema. An entity map of 292 named entities, 270 of them marked verified and 104 tied to Wikidata ids, feeds the site’s structured data. One file, capabilities.json, was written for agents. The site’s in-browser tools read it when an agent asks about pricing, integrations or compliance, including the certifications Tallyfy doesn’t hold.

And outside the website, Tallyfy’s SOC 2 risks live in YAML, the policies in markdown, and the cap table in a JSON file. None of it is called an ontology. All of it is someone deciding what the things are and writing them down where software can check them.

The cheap way to grow this is to write down only what an agent got wrong. A March 2026 paper ran that loop on an incident management agent in a made-up but realistic retail setting. Nine cycles of fixing what the agent failed on produced a knowledge base of 46 entities. The same authors say “top-down efforts produce bloated, untested knowledge bases”.

Give each file one named owner, a person who updates it, because nothing keeps itself current. Keep it in Git so every change has a date and a reason. And put a check on any field the moment it drifts once, the way that risk column now has one.

The files have to describe something real underneath. Vercel’s team, writing about cutting most of their internal agent’s tools, put it bluntly: “If your data layer is a mess of legacy naming conventions and undocumented joins, giving Claude raw file access won’t save you. You’ll just get faster bad queries.” Andrej Karpathy put the human side of it in one line, in a note on letting an LLM keep a wiki: “Humans abandon wikis because the maintenance burden grows faster than the value.” His answer is to hand that bookkeeping to a model, which still leaves a person checking what it wrote.

More context isn’t free either. A 2026 study of the context files coding agents read found that providing them “does not generally improve task success rates, while increasing inference cost by over 20% on average.” Keep each file small and about one thing.

This is close to what I’ve argued about processes. Tribal knowledge stalls AI adoption because the decision logic lives in people’s heads. And writing a process for an agent forces you to spell out what a person would have guessed. The same instruction-file discipline shows up in how I layer CLAUDE.md files.

When does the director make sense? When the typed files stop agreeing with each other, or a regulator wants each definition defended line by line. At that point the vocabulary is a full-time job, and the person in that ad is the right hire. Until then, pick the one question your agents get wrong most often this week, write the answer into a typed file, and put a named owner and a last-checked date on it.