When Everyone Has Their Own Software, the Ontology Holds It Together
TL;DR:
As AI coding tools commoditize the application layer of enterprise software, the differentiating asset shifts down a layer. What doesn’t commoditize is shared data — agreeing on what a customer, an order, or an asset means across teams, applications, and AI agents acting on those records. The organizations that navigate this well will treat their organizational ontology as foundational infrastructure: owned by them, governed by them, and expressed in open portable standards.
There’s a trend here worth paying attention to. Not because SaaS is about to disappear overnight — it isn’t — but because the economics of software are shifting in ways that matter architecturally.
The immediate prompt was a recent Forbes piece in which a Palantir deployment strategist flatly declared that “SaaS is dead.” The author, a supply chain analyst, was appropriately skeptical of the claim in absolute terms, especially around whether AI-generated code can really absorb the complexity of enterprise workloads. That skepticism is fair. The more useful question is what the claim points to underneath.
The SaaS bargain and what’s changing
The case for SaaS was always economic. Custom software was too expensive, too slow, and too risky for most organizations, so shared applications won by spreading those costs across many customers. The tradeoff was standardization: the software was affordable precisely because it was built for the median customer, not for you.
Most organizations have always lived with that mismatch. They bought the suite, then rebuilt the missing pieces in spreadsheets, email chains, custom fields, and consulting-heavy implementations. That gap isn’t new. What’s changing is the cost of closing it.
AI coding tools are compressing the economics of custom software, even if not cleanly or uniformly. Market signals have already been sharp: early 2026 erased hundreds of billions from software-company valuations as investors reconsidered where this might lead, and major consultancies are now openly questioning the durability of the classic SaaS model.
The operational picture is more mixed. Google’s 2025 DORA research reframes AI as an amplifier — magnifying an organization’s existing strengths and weaknesses. Around 90% of developers now use AI daily. Individual output rises sharply (related telemetry shows 21% more tasks completed and 98% more pull requests merged), yet organizational delivery metrics stay flat. Throughput goes up, and so does instability — unless an organization’s control systems are mature enough to absorb the new pace. The headline finding: the greatest returns on AI come not from the tools themselves but from a strategic focus on the underlying organizational system.
So the interesting question isn’t whether SaaS disappears. It’s what becomes strategically scarce if custom application development gets much cheaper.
The application layer is becoming infrastructure
Infrastructure has a particular quality: it becomes invisible precisely because it works, and indispensable precisely because everything depends on it. Electrical grids, TCP/IP, the relational database. Nobody competes on having electricity. You compete on what you build with it.
The application layer of enterprise software is on this trajectory. When any team can spin up a custom workflow tool quickly, the workflow tool stops being a source of competitive advantage. It becomes table stakes — something you have, not something you win with.
SaaS vendors have always quietly conceded this point: if you run your business on a standard template, your capabilities aren’t differentiated from anyone else running on the same template. Every capability your vendor builds for you, they sell to your competitors too. That’s the strategic case for custom, not just the economic one.
The problem is what fragmentation exposes underneath.
The data layer doesn’t fragment as easily
Applications may be getting cheaper to build, but shared data isn’t getting cheaper to agree on.
When the sales team, the finance team, and the customer success team each have a different AI-configured interface for working with customer data, those interfaces still need to read from and write to something. The question of what “customer” means — which fields, which relationships, which history, which ownership — doesn’t get easier when the front end multiplies. It gets harder.
The cost of not solving this shows up in business terms, not just architectural ones. MIT CISR’s 2024 data monetization survey found that, on average, only 28% of employees regularly draw on reusable data assets in their own organizations, and that organizations with clear strategic guidance on data use generate 17% of revenue from data monetization versus 4% for those without. Agreeing on what things mean is a revenue problem as much as a technical one.
This is where the Palantir model gets interesting, and where it points to something more general. Their differentiating feature isn’t the custom application layer. It’s what they call the Palantir Ontology: an abstraction layer over existing systems that defines a canonical model of the organization’s real-world objects and logic. Customer orders, financial transactions, physical assets, products — defined once, in terms specific to that organization, and made available to every application and agent built on top.
Worth disclosing the personal angle here: I came up through symbolic AI — semantic networks, knowledge representation, expert systems, the semantic web, OWL, RDF — so when I look at where Palantir is taking the ontology question, it doesn’t feel like a new idea. It feels like an old one finally getting the substrate it needed.
The core symbolic insight was that machines need explicit models of entities, properties, and relationships when being correct matters. What failed wasn’t the need for formal structure. What failed was the hope that formal structure alone could carry the whole burden of intelligence.
LLMs changed the landscape by delivering extraordinary language capability without hand-built ontologies. But fluent language and reliable action on enterprise data are different problems. For the latter, the ontology layer is back — not as the basis of machine intelligence, but as the foundation for machine action.
If you track pendulum swings in the field, I’d expect symbolic AI to be on the ascendency again over the next several years. Different role than the first time around — probably hybridized with the neural side rather than competing with it — but the lessons from that era are about to be load-bearing again for the parts of the stack where being right matters more than being fluent.
And one of the most valuable technology companies in the world has made that ontology layer the centerpiece of its enterprise product strategy. They aren’t alone. Snowflake, Salesforce, and dbt Labs launched the Open Semantic Interchange in 2025 to standardize how semantic models move across tools. When competitors collaborate on a standard, it usually means the pressure is real.
One thing matters enormously here: who controls the ontology. Palantir builds and manages theirs for each client, which is useful but also means a core strategic asset sits inside a vendor-managed layer. The more durable architecture is probably different: your ontology expressed in open, portable standards, consumable by any tool that speaks those standards, but owned, governed, and controlled by you. If the ontology becomes a differentiator, it should travel with you.
Then there are the agents
So far this is a story about humans building and using more custom software. But the agent layer is forming at the same time.
AI agents — via MCP (Model Context Protocol), A2A, and a growing stack of integration standards — are being deployed across organizations with their own interfaces and their own logic for acting on company data. An agent routing purchase orders has its own model of what a vendor is, what an approval threshold means, and what constitutes a valid payment term. An agent scheduling deliveries has its own model of inventory, lead time, and carrier constraints.
OpenAI moved quickly to support MCP. In March 2025, Sam Altman announced that support was already available in the Agents SDK, with support for the ChatGPT desktop app and Responses API coming soon. That matters less because of OpenAI specifically than because it signals that interoperability standards are forming across major model vendors, not just inside one ecosystem.
What those standards don’t guarantee is that the agents using them operate on a consistent, shared understanding of what the underlying data means. MIT SMR and BCG’s 2025 study of 2,102 executives found that 52% of organizations with extensive agentic AI adoption already enable internal agent-to-agent interaction, versus 30% at the pilot stage, and 27% are ready for agents to interact externally with outside partners, versus 17% at pilot. Agents aren’t operating in isolation. They’re beginning to coordinate.
That makes the ontology question more acute, not less. When a human uses an application built on an inconsistent data model, the result is often a bad report or a confused process. When an agent operates on an inconsistent or ambiguous ontology, the result can be a wrong action taken autonomously: a payment routed to the wrong entity, inventory released that isn’t available, or a compliance exception triggered before anyone reviews it.
The fragmentation of the application layer is manageable. The fragmentation of the agent layer, acting autonomously on the same data, is a different order of problem.
The governance problem is not optional
This is where ontology and governance start to converge.
When every team can build what it needs, governance gaps widen. The issue isn’t just unauthorized software. It’s software and agents acting on production data without clear lineage, permissions, or alignment to a shared model of the business. An operations manager can wire up a custom tool or deploy an agent connected to real customer data in an afternoon; whether that tool has appropriate controls, auditability, or any coherent relationship to the company’s canonical data model is a separate question.
MIT CISR’s March 2026 framework argues for “minimum viable governance”: governance that’s agile enough not to drive AI use underground, but strong enough to maintain trust and control. In practice, that pushes architecture and governance closer together. If agents are going to act across enterprise systems, shared definitions, access controls, lineage, and auditability can’t live only in policy documents; they have to be reflected in the underlying data model too.
That’s why the ontology layer has to carry more weight than it did in the SaaS era. Before, much of the data model was embedded inside the vendor’s application — imperfect, but at least internally consistent. With proliferating custom applications and agents, the canonical model has to be explicit, shared, and machine-readable enough for applications, agents, and integrations to operate on reliably.
And it has to be auditable. When an agent acts, the organization needs to be able to answer basic questions: what version of the ontology was it operating on, what permissions did it have, what objects did it read and write, and did the action conform to the business rules? Enterprise-grade AI governance starts to look less like a review layer on top of systems and more like a property of the systems themselves.
The question worth asking now
None of this means the existing SaaS stack is obsolete or that every enterprise should rush to rebuild its software tomorrow. But the direction of travel is clear enough to be useful.
The question worth asking now — before the application layer fragments completely and before agents begin acting more autonomously across enterprise data — is: “What is our organizational ontology, and who controls it?”
Not what apps exist. Not even what data exists. The deeper question is whether there’s a shared, explicit, machine-readable definition of the things the business actually runs on — customers, orders, products, transactions, assets — in terms specific to how that organization operates.
The organizations that navigate this transition well won’t be the ones that moved fastest to replace SaaS tools or deploy the most agents. They’ll be the ones that treated the organizational ontology as foundational infrastructure: defined their canonical models clearly, governed them explicitly, adopted standards in ways that preserved portability and control, and built auditability into the architecture from the start.
MIT CISR’s late-2025 research on enterprise IT operating models reaches a parallel conclusion from a different direction: the highest-performing pattern combines high innovation velocity with strong enterprise IT leadership architected for modularity and reuse. The win isn’t centralization versus decentralization. It’s coherent shared infrastructure, governed well.
There’s a classic thread behind this too. Jeanne Ross’s Designed for Digital (2019) at MIT CISR argued the same architectural case under different vocabulary — that what separates digital winners is a coherent operational backbone of people, processes, data, and technology. The ontology argument foregrounds the data layer specifically, particularly under proliferating agents, but it’s the same load-bearing claim.
The application layer is becoming infrastructure. The ontology layer is becoming the moat.
