The Cheaper Tokens Get, the More Ontology Is Worth

At the end of the previous piece, I left a question.

I was able to use first principles to cut the joints of GEO correctly, once. But that "joint map" lives in my head. The next person who comes along, or the machine I want to run this repeatedly — do they have to re-derive everything from scratch every time?

This piece answers that question.

Taking joints that one person cut correctly once, fixing them in place, turning them into a structure that every person and every machine can rely on — that has a name: ontology.

In other words: ontology is first principles that have been institutionalized and fixed in place. It is the map someone leaves behind after cutting a domain's joints correctly once, so that everyone who comes after — human or machine — does not have to re-derive from scratch every time.

The word sounds philosophical. But in the age of AI, it is becoming one of the least philosophical things imaginable — infrastructure.

A judgment the whole industry believes — that is only half right

To explain why ontology matters today, I need to start with a judgment that nearly everyone believes.

Richard Sutton wrote a widely cited essay, The Bitter Lesson. Its conclusion is hard: throughout the history of AI, approaches that tried to hand-engineer human domain knowledge into systems have, in the long run, almost always lost to a dumber method — general-purpose methods plus ever-increasing compute, letting the model learn on its own.

This judgment shaped the entire industry's instinct: don't bother building structure — just make the model big enough. Dirty data, messy data — doesn't matter. Feed enough of it in, make the model strong enough, and understanding will emerge on its own.

This judgment is not wrong. But it is only half right.

In 2025, MIT published a widely cited and widely debated study. The exact numbers have been questioned, but the fact it points to is hard to refute: roughly 95% of enterprise generative AI pilots produced no measurable P&L impact; and the researchers attributed the root cause to flawed integration approaches, not to models being insufficiently powerful.

What truly blocks landing is not the model's IQ. It is the chasm between a beautiful demo and a system that actually runs inside real legacy infrastructure, real workflows, real compliance requirements — that dirty, heavy gap in between.

Interestingly, even Sutton himself later added the other half of the picture — the "Big World Hypothesis." The gist: the real world is too vast and too idiosyncratic to be pre-packaged inside any single model. An agent cannot navigate the world on knowledge installed at the factory. It must adapt online, continuously, to the specifics of every concrete client it faces.

Put these things together, and I arrive at the hardest sentence in this essay:

Cheaper compute, cheaper tokens — none of it eliminates structure. It just moves structure's address: from inside the model's weights, out to the real world the model must operate on. And in that world, someone always has to build structure anew.

This is the flip side of The Bitter Lesson for the agent era. The more general and powerful the model, the more the world it operates on needs a clear, reliable, reality-fitted structure. That is why ontology is going from a philosophy term to a piece of infrastructure.

Data is not files, and ontology is not philosophy

When we say "data," what comes to mind is usually files, spreadsheets, logs, or a pile of vectors.

But to an agent, these things are nearly inoperable. A heap of disconnected tables, a field of semantically ambiguous columns — the agent can read the bytes but cannot reach the meaning.

Data that an agent can reliably use is not raw bytes. It is a mapping of reality that has been organized, defined, and given relationships and semantics.

That is what ontology does. It answers a few questions that look basic yet decide whether anything works at all:

• What actually exists in this world? (What entities, what objects)
• What are the relationships between them?
• What does a concept actually mean in this system? ("Customer" — someone who placed an order, someone who registered, or someone who paid?)
• How should an agent understand and operate on these objects?

Without this layer, even the strongest model is flying blind: it can talk, but it cannot see or touch your real business. It can demo, but it cannot land.

So ontology stops being a philosophy term here. It becomes the work of translating a messy reality into a foundation an agent can depend on and execute against.

Someone has already turned this into a moat

This is not speculation. One company has already built a deep, hard-to-replicate moat on top of it — Palantir.

One judgment of theirs that many engineers remember: plugging a large model directly into a pile of disconnected databases is dangerous. Their real moat was never the model — it was their Ontology: distilling how an organization actually operates into a semantic model, from raw data to business objects to executable actions.

And the most powerful thing about this system is that it compounds. The more data and processes get mapped into the ontology, the more valuable and harder to replace it becomes. Palantir's reported net revenue retention rate is roughly 139% — clients not only stay, they go deeper.

By contrast, the model layer is commoditizing at full speed. GPT, Claude, Gemini are neck-and-neck on every benchmark; whoever leads cannot hold the lead for more than a few months. Having access to a frontier model is, by itself, no longer a barrier. What hasn't been commoditized is harder to copy: the work of mapping a specific reality into a structure an agent can reliably operate on.

Palantir gave the people who do this work a name: Forward Deployed Engineer — FDE.

Note that an FDE is a person, a role — not a piece of software, not a platform.

The logic is the exact reverse of a traditional software company. Traditional software: build a general product first, then wait for customers to adapt to it. FDE: drill directly into the customer's real world, understand their messy data, real workflows, unique semantics, and shape the system to fit that reality.

A widely repeated line: the moat is not the software — it is the last mile. From "we have a set of tools" to "this set of tools is actually driving the customer's daily operations" — that hardest, least-automatable distance. When a forward-deployed team spends months embedding an AI system deep into a customer's internal data, workflows, and compliance architecture, the system itself becomes load-bearing infrastructure — the customer could not swap it out even if they wanted to.

And this is no longer Palantir's niche playbook. The entire AI industry is copying it:

OpenAI assembled its own FDE team in early 2025, sending engineers to write code directly on customer systems. By 2026, it went further and founded The Deployment Company, dispatching forward-deployed engineers to embed inside client organizations and land AI systems and workflows — a structural bet backed by over $4 billion in funding. Anthropic formed a roughly $1.5 billion joint venture around the same time, dedicated to enterprise AI deployment.

The two most valuable AI companies, within weeks of each other, bet on the same thing: models are strong enough; the real bottleneck is the last mile.

What makes the people who can do this so scarce

So the question is: what kind of person does it take to do this work — translating reality into a structure an agent can operate on?

Palantir's own description of the FDE role is telling: the responsibilities are closer to a hands-on, do-everything AI startup CTO.

I break it into two kinds of "sense" that are very hard to find in one person:

One is model sense. You need to know, clearly, where the boundaries of today's models lie; how to evaluate whether a model is doing a task well; which jobs should go to which model, and which jobs the model simply cannot do yet and must be left to deterministic code or a human. Without this sense, you overestimate the model and shove a pile of tasks at it that it is guaranteed to botch.

The other is user sense. You need to genuinely know how users will use this thing in real scenarios; what their workflows look like; where a solution will get stuck when it lands in a real system. Without this sense, you build something that looks stunning in a demo and falls apart the moment it hits a customer site.

The vast majority of people have only one of these. Either a researcher who understands models but not deployment, or a domain expert who understands the business but not models. FDE work demands that both senses live in the same person.

What I do sits exactly at that intersection.

I turned this into a vertical plugin

Back to my own GEO.

In the previous piece I explained how I used first principles to break GEO into four gates: crawled, understood, chosen, tracked. But breaking it down is only cognition. To make it actually run at a client site, what I did is, in essence, FDE work — fixing the joint map of the GEO domain into a structure an agent can execute.

It landed in three specific places:

First, where data comes from. I did not make clients log into a new webpage and export data to feed me — that is the same old playbook of "build a generic product and wait for the client to adapt." I went the other way: I plugged the plugin directly into the office tools clients already use — Feishu, various CLIs. Those tools already hold the client's real data and the scaffolding an agent needs to move. This is the integration work an FDE does — I do not ask the client to adapt to me; I drill into the client's reality.

Second, how humans and agents collaborate. This system is a copilot, not a replacement. It does not pretend it can do the job fully automatically. It presents analysis results in HTML for humans to review and exports structured data as JSON for humans to use. Critical judgments and decisions stay in human hands. This fits the reality: in complex business, agents are here to augment humans, not to replace them.

Third, how humans and agents divide labor. We are the vertical domain experts — responsible for cutting the joints of the GEO domain correctly, packaging workflows, prompts, and tools into a reliable set of skills. The client is the business expert — responsible for contributing the firsthand insight about their own business that no model can ever fabricate.

This loops back to the hard gate from the previous piece: at the content-production step, if the business expert's insight briefing is not filled in, the agent refuses to execute.

Now you should be able to see what that gate really is. It is fixing the boundary between human and agent labor — that joint — into code, at the ontological level. Which tasks the agent handles, which one thing must be supplied by a human — this is not a slogan. It is an unyielding structure inside the system.

Our vertical plugin empowers agents, turning them into AI employees that can genuinely work inside an enterprise.

As a side note, Palantir itself is already building "AI FDEs": an interactive agent that can operate Foundry through conversational commands — performing data transformations, managing codebases, even constructing and maintaining the ontology itself. Letting an agent participate in building the very structure it will depend on — that is the same road I am on.

Only structure can act

Read these two pieces together, and you will see that first principles and ontology are really the same capability, deployed at two different scales.

First principles is one person, in the middle of chaos, finding the joint that truly bears weight — by hand.

Ontology is fixing that joint structure in place, so that a system, in a complex world, gains a reality foundation it can depend on and execute against.

One is a one-time cognitive act; the other is long-running infrastructure. One happens in the moment of confronting chaos; the other sustains day-after-day execution. But they point at the same thing — refusing to be fooled by surface appearances, reaching for the structure that truly bears weight.

And this has never been more critical than it is today.

Because language is becoming cheap: models can generate endless text that all looks right. Demos are becoming cheap: anyone can build a beautiful demonstration.

When surface-level things are nearly free, the scarce things — the things that decide who wins — are left as structure itself: whether a person can find the real fulcrum in the chaos; whether a system has a model of the real world it can depend on.

Surface is cheap. Structure is scarce.

That gap — between surface and structure — is where the work is now. And almost no one is doing it.