Your App Gets Smarter Just By Existing Here

By The Chiri Team

Palantir’s CTO, Shyam Sankar, put it more bluntly than most vendors would dare on an earnings call. “The ontology is the body to the AI brains,” he told analysts in May. “You cannot actually interact with the enterprise or affect the world. Your agents can go nowhere without ontology.”

He was talking about Palantir’s own product. He could just as easily have been describing the bet Chiri made a year earlier.

The model stopped being the hard part

The industry has mostly made peace with the idea that frontier models are commoditizing fast. A new open-weight release lands every quarter, and last month’s frontier capability is this month’s cheap default. What that leaves unresolved is the actual argument everyone is now having in public: if the model isn’t the differentiator anymore, what is.

Box CEO Aaron Levie gave one answer directly to reporters last September. “I think we’re in the era of context within AI,” he said. “What AI models and agents need is context, and the context that they need to work off is sitting inside your unstructured data.” A16z made the same case in a research note the following spring, arguing that most enterprise AI failures trace back to a lack of business context, not a lack of model capability, and pointed to MIT’s own 2025 research on the subject.

That MIT research is worth sitting with. Researchers at MIT’s Project NANDA studied enterprise generative AI deployments and found that despite $30 to $40 billion in enterprise AI investment, 95 percent of generative AI pilots showed no measurable return. The minority that worked shared one trait: they were built around integrated, context-aware workflows, not generic access to a model.

Context, in other words, is where the actual product gets built. The question is where that context lives, and whether it compounds or sits still.

Two ways in, one system that learns

Here is the part that is easy to miss if you only think about Chiri as a chat interface. Chiri’s ontology, its living map of how a business actually works, learns two ways.

The first is obvious: every time your team uses Chiri directly, the system captures what happened and gets a little sharper about your business.

The second is the one that matters more. When Chiri builds and hosts a custom application for a client, that application runs on the same foundation and feeds the same ontology, even though nobody using that app ever opens Chiri’s own interface. A support tool your team built on Chiri, a client portal, an internal ops dashboard, whatever it is, every action inside it becomes context the ontology can draw on later. The system gets smarter from work it never directly touched.

Most enterprise software cannot make this claim honestly. A tool gets better when you use that specific tool. Chiri gets better when your business does anything on the foundation, whether or not that thing looks like Chiri at all.

The comparison that actually holds up

Palantir is the clearest real-world precedent for this argument, and not because the branding overlaps. Palantir’s own documentation describes its Ontology as representing “the decisions in an enterprise, not simply the data,” built from four layers: data, logic, action, and security. The company’s public materials describe an “end-to-end decision lineage” that becomes, in their words, contextual fuel for improving the performance of both humans and agents over time.

CEO Alex Karp has described the same idea more plainly: “We use Ontology to manage large language models and Foundry to reconcile data.” The mechanism is the same shape as Chiri’s, even if the target customer and price point are not. Palantir sells this to the Fortune 50 and the Department of Defense, at a scale and cost most mid-market companies will never touch. Chiri exists because that same underlying idea, decisions and context accumulating in a structured layer the model can actually use, does not have to cost that much or take a defense contract to access.

There is independent evidence this general pattern is real outside of any one company’s marketing. GitHub has published research showing that Copilot’s suggestion-acceptance rate rises measurably over months of continued use, and the effect had not plateaued even after six months of observation. That is a real product getting measurably better from accumulated usage data, documented in academic research rather than a press release.

The honest counterargument

Not everyone buys the “data compounds into a moat” story, and the skepticism deserves a real answer rather than silence.

Analyst Benedict Evans argued last November that large language models actually undermine traditional data-network effects, because a new competitor can now “rent the cold start” by calling a general-purpose model’s API instead of needing years of accumulated usage data to bootstrap something useful. A former Gartner vice president made a related point in the spring, warning that the industry was about to spend a year re-litigating “context graphs” and “knowledge graphs,” concepts that have circled the enterprise software world for decades without consistently delivering on their promise.

Both critiques are aimed at the right target, and both actually support the distinction this article is making rather than undercut it. Evans’s point is that renting a model is not a moat. That is Chiri’s own argument about tokenomics and model routing, stated from the other direction: the model was never supposed to be where the advantage lived. The skepticism about knowledge graphs is fair too, and it is exactly why the second learning path matters. A knowledge graph that only updates when someone manually feeds it data does stagnate. An ontology that keeps accumulating context from real, hosted, in-production applications, whether or not anyone thinks about it as “using the ontology,” does not have the same failure mode.

What this actually means

The practical version of this argument is simple. If you build a custom internal tool on Chiri’s foundation, you are not just getting an app. You are adding another sensor to a system that keeps getting better at understanding how your business actually runs, and that improvement shows up the next time any part of the business needs it, not just inside the app where it happened.

This lands differently depending on where you sit:

The CTO is the one deciding whether a new internal tool should be a one-off build or another input into a system that compounds.
The CEO is the one who has to explain, a year from now, why one part of the business is dramatically more AI-literate than another that built the same kind of tool somewhere else.
The CFO is the one who has to price this correctly: a tool that makes the next five tools cheaper to build is not the same purchase as five separate tools.
The COO is the one who will notice first when a workflow gets faster for reasons nobody remembers explaining to anyone.

If every app your company builds this year taught the next one nothing, what did you actually build?

Sources cited

Shyam Sankar, Palantir Q1 2026 earnings call, May 4, 2026. Transcript via The Motley Fool.
Alex Karp, on the Palantir-SAP partnership, SAP Sapphire, May 20-21, 2025. Via Sahm Capital / Benzinga syndication.
Palantir, “Why create an Ontology?” and “The Ontology system,” Palantir Foundry documentation, palantir.com/docs.
Aaron Levie (CEO, Box), interview with TechCrunch, September 11, 2025.
a16z, “Fruits of the Walled Garden,” by Marc Andrusko and Alex Rampell, October 9, 2025.
a16z, “Your Data Agents Need Context,” by Jason Cui and Jennifer Li, March 10, 2026.
MIT Project NANDA, “The GenAI Divide: State of AI in Business 2025,” July 2025. Cited via Fortune, August 18, 2025.
Benedict Evans, “AI, networks and Mechanical Turks,” ben-evans.com, November 23, 2025.
Sanjeev Mohan, “Dispatches from the Gartner Data & Analytics Summit 2026,” March 16, 2026.
GitHub, “Updates to GitHub Copilot interaction data usage policy,” GitHub Blog, effective April 24, 2026.