Ontologies are having a moment again. Latent Space covered the revival after UC Berkeley’s Frank Coyle argued at the AI Engineer World’s Fair that probabilistic models need logical guardrails, and Neo4j CEO Emil Eifrem pitched a shared semantic layer that thin agents could run on instead of each one being wired to its own data sources by hand. The vocabulary is familiar to anyone who was building for the web twenty years ago. RDF, OWL, Dublin Core, FOAF.
I was there the first time #
Before joining Microsoft in 1998 to work on semantic annotation, I did a PhD in natural language processing. The features we shipped into Office marked up ordinary text so software could tell what the entities in it actually were, primarily so it could offer you verbs attached to each one: email this person, add this date to your calendar, look up this stock. The Semantic Web was going to be the thing that organized the world’s information. The standards shipped. The tooling shipped. Most of it never made it into daily use.
That history matters right now, because the current revival is picking up the parts that worked and repeating the assumption that broke.
It didn’t fail on formalism #
The usual postmortem is that the Semantic Web was too academic, too complicated, too far from what working developers wanted. There is something to that. But the deeper problem was not that OWL could not express your business. OWL could express far more than most companies needed.
The problem was that an ontology is a description of a world that keeps moving. Someone has to add the new product line, retire the discontinued one, reconcile the two teams that use the same word for different things, and notice when a relationship that used to be one-to-one became one-to-many. That someone was a person, usually one person, usually with another job. The business changed faster than they could edit.
So the schema drifted from reality. And a schema that has drifted from reality is worse than no schema, because systems keep trusting it. Most of the ones I watched went stale within a year of whoever owned them moving to another team.
Microsoft tried it both ways at once, and I had a front-row seat. In 2001 it shipped two SharePoints. Portal Server, released to manufacturing that March, was the serious one. It organized documents by category and aimed squarely at the companies best equipped to do this properly: large enough to have a person, or a whole team, whose actual job was owning the taxonomy. Team Services was the other one. It was somewhere to put files and stand up a site, and it asked almost nothing of anybody.
Portal Server got the most favorable test the idea was ever going to get. The team site won. Microsoft kept both lines running and folded them under a single brand in 2010, and the model everyone actually builds on is the one that never asked you to own a taxonomy. Most deployments I have seen still organize by folders and search.
Two bets, same company, same year, and the market picked the one with no ontology in it.
This is the ordinary fate of any hand-maintained model of a company. It is also exactly what happens to the wiki nobody has updated since the person who wrote it left.
What’s actually different now #
The maintainer no longer has to be a human. Prasenjit Sarkar, quoted in the Latent Space piece, put it about as well as it can be put: when an agent maintains the ontology as part of its own operation, updating definitions when it hits edge cases, the maintenance problem changes character. It does not disappear. It changes from a job somebody has to remember to do into something that happens as a byproduct of the work.
It is the only difference that addresses what actually went wrong the first time. A revival that produces better-specified ontologies which humans still hand-maintain will fail the same way, on the same schedule, for the same reason.
Where we are, and where we aren’t #
This is the bet this+that is built around.
The brain holds operational knowledge today. Workflows write back to it as they run, so what an agent learns during a run is available to the next one rather than evaporating. None of that requires anyone to sit down and author a schema first.
The smallest working version of the argument is Contacts, and it is the part you can try today. Connect an account and the address book builds itself out of the people you actually correspond with. Someone who reaches you over email and over Slack resolves to one person instead of four half-people, and the edits you make by hand survive the next sync. Nobody imports a CSV and nobody fills in a form. It is a very small ontology, and what keeps it current is the message stream rather than a person with another job. It is deliberately not a system of record, which is the whole point. A snapshot you have to maintain is the failure mode, not the goal.
The part we have not finished is the part that matters most: the brain keeping itself current from everything the team already says to each other, with nobody assigned to tend it. Contacts is one narrow slice of that working. The general case is where we are headed.
A model that maintains itself needs a source that updates itself. Company knowledge sits in three layers. Systems of record hold structured facts about what happened, and the CRM and the billing system handle those well. Canonical knowledge is what somebody sat down and wrote, the pricing and the positioning, true for a year at a time, and the wiki handles that well enough. The third layer is what is going on right now: the launch that slipped, the partner who has gone quiet, the two people answering the same customer differently.
The first two are solved. The third goes stale the day after anyone writes it down, which is why nobody keeps it current, and it exists only in what people say to each other. That is also the raw material a language model reads best. We mapped those layers in the missing middle of company knowledge, and came at the communication half from the other direction in why a company’s world model is built from its communication.
What to ask if you’re evaluating this #
If a vendor or an internal team pitches you an ontology, a knowledge graph, or a semantic layer, the useful question is not how expressive it is. It is who keeps it current, and what happens when they stop. Ask what fills it. If the answer is an onboarding questionnaire or a workshop, you are buying a snapshot, and the clock starts the day you finish. Ask what updates it when the business changes. If the answer is a person, ask what happens when that person changes teams, because on the evidence of the last twenty years that is when the decay starts.
Guardrails are the easy pitch. Upkeep is the hard problem, and it is the one that killed this idea the first time around.