Alex Karp Is Right About Where Enterprise AI Creates Value

Alex Karp did not hold back in his recent CNBC interview:

Enterprises are livid, paying for tokens that create no value, while these models steal the alpha of their business.

His argument is that the winners in enterprise AI will not be the companies with exclusive access to the best models. They will be the companies that own the application layer and the ontology underneath it.

He is right. The models are becoming broadly available, but the context that makes them useful inside a specific business is not.

That distinction explains why so much enterprise AI spending has produced polished demos and disappointing results. Companies keep giving better models access to more systems, then wonder why the answers still cannot be trusted.

The model does not understand your business

Every company runs on a collection of systems that describe different parts of the business. The CRM knows the opportunity, billing knows what is being invoiced, support knows what is broken, product analytics knows what is being used, and customer success knows what is happening in the relationship.

Even the customer has a different identity in each system. Salesforce calls it an account, Stripe uses a customer ID, Zendesk has an organization, and the product database has a tenant.

Pointing a powerful model at those systems does not create a shared understanding of the customer. It gives the model several disconnected records and asks it to reconstruct the relationships each time someone asks a question.

The model may produce a plausible answer, but plausibility is not enough when the answer affects a forecast, renewal, or customer relationship.

This is the problem Karp is describing. The model is not where the company's operational knowledge lives. That knowledge exists in the identities, relationships, definitions, and history spread across the company's systems.

The application layer needs an ontology

Karp uses the word ontology because the application layer needs more than access to data. It needs a structured understanding of what exists in the business and how those things relate.

An account has opportunities, renewals, invoices, product tenants, support tickets, contacts, and owners. A support escalation may affect a product used by several customers. An engineering delay may put multiple committed deals at risk. A departing champion may weaken both an active opportunity and an upcoming renewal.

Those relationships are what turn isolated facts into business context.

Without them, an AI agent can retrieve an opportunity record or summarize a support ticket. It cannot reliably explain how the ticket changes the revenue outlook unless it knows that the ticket, account, product, opportunity, and renewal are connected.

That is why the application layer matters. It gives the model something coherent to reason over.

This is especially important in RevOps

Karp talks about preserving a company's operational advantage, or its alpha. In revenue operations, much of that advantage lives in the ability to recognize change before it reaches the forecast.

A deal can remain in Commit while product usage falls, support tickets accumulate, an invoice becomes overdue, and the customer's champion leaves. The CRM is not necessarily wrong because nothing changed in the opportunity record. The risk developed elsewhere.

Revenue teams compensate for this by assembling context manually. They open several dashboards, message account owners, compare exports, and rely on the people who remember how everything fits together.

An AI agent can make that process faster, but only if it begins with the relationships already resolved. Otherwise, it repeats the same manual reconciliation through tool calls and produces an answer that may still be based on the wrong customer, the wrong revenue figure, or stale ownership.

The real opportunity for enterprise AI is not generating a more polished forecast summary. It is revealing the revenue risk the CRM cannot see alone.

The ontology has to stay current

This is where I would extend Karp's argument.

Having an ontology is not enough. It needs to reflect the business as it exists now.

A hand-maintained model begins drifting as soon as it is written. Accounts change owners, teams reorganize, contracts change, products are renamed, and customers adopt new domains. An ontology that requires people to update it manually becomes another catalog that everyone eventually stops trusting.

The operational model needs to derive from the systems where the business is already changing. When ownership changes in Salesforce, the graph should reflect it. When an escalation opens in Zendesk, the relationship to the customer and renewal should already exist. When billing changes in Stripe, the new amount should appear alongside the contracted value without overwriting it.

The goal is not to manufacture one perfect source of truth. Different systems can make different, valid claims about the same customer. Contracted ARR and billed recurring revenue may differ because something commercially meaningful happened. A health score can remain green even though a new P1 escalation creates immediate risk.

A useful ontology preserves those observations, their sources, and when they were true. It gives the model enough context to understand the disagreement instead of hiding it.

This is what we are building with SixDegree

SixDegree is the application and ontology layer Karp is describing, applied first to revenue.

We resolve records from CRM, billing, support, product, conversations, customer success, and engineering into shared operational entities and relationships. Each source keeps owning what it knows, while SixDegree preserves the evidence and connects it to the accounts, opportunities, renewals, owners, and ARR it can affect.

That produces a live operational graph that authorized teams and agents can query. Instead of asking a model to reconstruct the customer on every run, the model begins with the customer, evidence, and relationships already resolved.

A revenue team can ask which committed deals carry risk outside the CRM, which renewals have deteriorated since the last review, where contracted ARR disagrees with billing, or which opportunities depend on engineering work that slipped.

The answer is not generated from one system or guessed from a pile of retrieved text. It is assembled from current, source-backed observations connected through the graph.

Karp identified the real moat

The model is not the durable advantage. Models will continue to improve, prices will fall, and companies will switch between providers.

The durable value is the operational map of the business: which customers exist, how records relate, what changed, which claims conflict, and what those changes mean for the decisions the company needs to make.

That is the application layer. That is the ontology. It is also where enterprise AI stops sounding intelligent and starts producing useful work.

Karp is right that companies should protect and own this layer. The model can be replaced. The live map of how your business actually works cannot.