Karp is right about tokenmaxxing. Here’s what comes next.
Alex Karp does not do polite. In a recent interview [LINK HERE], the Palantir CEO attacked what he calls “tokenmaxxing”: the tendency of frontier AI providers to equate greater model consumption with greater enterprise value.
Strip away the theatre and he’s making three points worth sitting with.
First: pay for outcomes, not activity. Today’s AI economics can resemble a taxi meter: the customer pays for the journey whether or not it reaches the destination. More prompts, larger context, more retries — consumption goes up without a guaranteed connection to business value.
Second: don’t hand over your alpha. Every enterprise has its own proprietary operating logic — its entities, relationships, rules, and institutional understanding of how the business actually works. The ontology of how a business actually works is a competitive advantage. Enterprises should be careful about renting it out by the token and making it permanently dependent on infrastructure they don’t actually control.
Third: sovereignty is no longer optional. Governments, regulated institutions, and sophisticated enterprises want control over their data, models, and critical operating systems. That’s not paranoia. It’s prudent architecture.
Palantir’s answer is powerful: use an ontology to connect enterprise data, decisions, and actions, while keeping more control over your IP.
Occam starts from the same first principle — the ontology of the enterprise is an asset — but applies it at a different point in the stack.
Palantir uses ontology to make existing enterprise data operational. Occam makes the ontology itself operational, by compiling it into the transactional system the business runs on. Define a business entity once — its identity, attributes, relationships, and constraints — and Occam generates the system beneath it: schema, procedures, APIs, interfaces, pipelines. The ontology doesn’t just describe the system. It produces it.
That matters because most enterprise AI asks probabilistic models to reconstruct business context from fragmented data and prompts, over and over, on every request. Occam takes the opposite approach: where a requirement can be expressed precisely, it’s captured in the ontology and compiled into software once. From there it runs the way software has always run — fast, inspectable, and identical every time, because the database, procedures, APIs, and interfaces are all generated from the same source.
This doesn’t eliminate the need for frontier models, and it shouldn’t. Models earn their keep where interpretation, judgment, and discovery are required. They shouldn’t be forced to rediscover settled business logic every time a process runs. The right architecture puts probabilistic intelligence where ambiguity actually exists, and deterministic software where the answer is already known — with the ontology and everything generated from it staying inside the enterprise, not on loan from someone else’s inference pipeline.
This isn’t theoretical. The compiler has been running in production since 2010 — fifteen years, no platform rewrite — and today governs several million records across more than a thousand production tables for industrial and logistics operators.
Occam isn’t an alternative to Karp’s direction. It’s the next step in it: not just using the ontology to make fragmented data operational, but using it to generate the operational system itself, so problems never have the chance to form downstream in the first place.
That’s Occam. Define the business once. Compile the system. Keep the alpha.
If this resonates with how you’re thinking about your own data architecture, We’d welcome the conversation — comment below or send me a message.
