The Race for AI's Decision Layer
Why the next platform giant won't be built by adding AI to existing systems, but by capturing the context that makes decisions possible.
The enterprise software landscape is about to experience its most significant disruption in decades, and it won't come from the incumbents. While Salesforce, SAP, and Workday rush to add AI features to their existing platforms, a new category of infrastructure is emerging. A category that will fundamentally reshape where value accrues in the enterprise stack.
This new layer, built around context graphs and decision traces, represents a rare opportunity: the chance to build a trillion-dollar platform from scratch. But the window is narrow, the technical challenges are real, and the competitive dynamics favor a specific type of player.
Why Incumbents Are Structurally Disadvantaged
The legacy enterprise vendors are not standing still. They're acquiring AI startups, building agent features, and restricting API access to protect their moat. On paper, they have every advantage: existing customer relationships, comprehensive data models, and the resources to out-invest any startup.
Yet they face a structural problem that acquisitions and defensive tactics cannot solve.
The Execution Path Problem
Capturing decision traces requires being in the execution path at the precise moment decisions are committed. This isn't about observability after the fact or governance bolted on top. It's about instrumenting the decision itself and capturing the complete context as the agent queries multiple systems, synthesizes information, applies judgment, and commits the result.
Incumbents own deep data about customers, opportunities, and pipelines. But the decisions that matter increasingly span multiple systems. A sales exception might depend on data from Salesforce (customer history), NetSuite (financial health), Gong (recent call sentiment), and Slack (internal communications about churn risk). Any one of these incumbents only sees one piece of this picture. They cannot capture the cross-system synthesis that justifies the decision without fundamentally changing their position in the stack.
The incumbents could try to become the orchestration layer where these decisions happen. But this requires them to effectively demote themselves from system of record to middleware. This is a business model transformation that large public companies rarely execute successfully.
Consider what this would actually require for a company like Salesforce. Their entire business model is built around owning customer data, charging per-seat licenses, creating switching cost lock-in, and expanding within their domain. To become an effective orchestration layer, they would need to open APIs freely, enable data to flow easily to competitors, charge for coordination rather than storage, and accept that their value comes from connecting systems rather than replacing them.
These are fundamentally opposed business models. Wall Street values Salesforce based on annual recurring revenue from seat licenses and expects growth through expanding Salesforce's footprint. The moment Salesforce becomes a coordination layer that helps customers use competitors more effectively, an analyst asks: "Your revenue per customer is declining because customers are using Salesforce for less. Why should we value you as a high-growth SaaS company?" The CEO has no good answer. The business model transformation would damage their valuation before the new model proves itself.
We've seen this pattern before. IBM owned the mainframe—the central system of record for enterprise computing. When the market needed distributed computing across many systems, IBM should have embraced being a coordination layer in a multi-vendor world. Instead, they tried to protect mainframe revenue while half-heartedly building distributed solutions. They had the technical capability to lead but lost platform leadership to Microsoft and Oracle because the business model transformation was too threatening to their core revenue.
This structural challenge is precisely why the decision orchestration layer is more likely to emerge from startups with no legacy revenue to protect, native multi-system design from day one, and investor expectations aligned with disrupting incumbents rather than protecting them. Their incentive is to keep AI features within their walled gardens, even though the most valuable decisions require breaking down those walls.
The API Restriction Trap
When threatened, incumbents predictably restrict API access, impose rate limits, and favor their own AI features. We've seen this playbook before. But in trying to protect their existing business, they make it harder to build the cross-system context graphs that enterprises actually need.
This creates an opening. Enterprises will choose platforms that can see across systems over platforms that try to own everything. The vendor that sits between AI agents and multiple systems of record (capturing context from all of them) becomes more strategically valuable than any single system of record, no matter how comprehensive.
Why Data Platforms Aren't Positioned to Win
If incumbents struggle with the execution path problem, what about data platforms? Snowflake, Databricks, and the modern data stack companies already aggregate information across systems. They sit on comprehensive data. Why can't they capture decision traces?
The Write Path vs. Read Path Problem
Data warehouses and lakehouses operate in the read path. They're optimized for analytical queries after data has been written to source systems. They're extraordinary at aggregation, transformation, and analysis. But decision traces must be captured at commit time, in the write path, at the speed of transaction processing.
When an AI agent approves a purchase order, the context that justified that decision must be captured in real-time, before the state of the world changes. By the time that data flows into a data warehouse (hours or days later, after ETL processes run) the moment has passed. You can reconstruct what data existed, but you cannot perfectly preserve the temporal snapshot and cross-system relationships that made the decision appropriate.
Data platforms could try to move upstream into the operational/transactional layer. But this requires different technical architecture, different performance characteristics, and different go-to-market motions.
Consider the fundamental architectural divide. Data warehouses are built for columnar storage optimized for scanning millions of rows, batch processing with eventual consistency, and high latency tolerance where queries can take seconds or minutes. Operational systems require row-oriented storage for fast individual record updates, real-time consistency, and millisecond latency where users are actively waiting. These aren't different configurations, they're fundamentally different architectures.
The performance requirements are equally incompatible. When an AI agent approves a purchase order, the entire workflow (querying vendor status, checking budget availability, validating policy, capturing decision context, and committing the approval) must complete in tens of milliseconds. The user is waiting. If this takes five seconds instead of 40 milliseconds, the experience is broken and the agent cannot function in production workflows. Data platforms excel at queries that scan 500,000 rows and take 13 seconds to return dashboard results, which is perfectly acceptable for analytics but catastrophic for operational decisions.
This matters critically for context graphs because capturing decision traces must happen at transaction speed, not analytical speed. By the time data flows through ETL pipelines into a warehouse hours later, the moment has passed. Customer tiers may have changed, budgets updated, policies revised. You cannot reconstruct the exact state of the world at decision time from analytical data that arrives after the fact.
The go-to-market challenge is equally significant. Data platforms sell to Chief Data Officers and analytics teams with a value proposition around strategic insights, six to twelve month buying cycles, and success metrics like reports created and query performance. Operational platforms sell to CIOs and line of business leaders with a value proposition around daily execution, three to six month cycles, and success metrics like transaction throughput and uptime. These are different buyers, different conversations, different implementation partners, and different value propositions entirely.
A platform built for analytics would face immediate credibility questions from operations leaders: "Why should we trust our operational systems to a platform built for analytics? What happens when analytical queries slow down our transactional performance?" This is why Amazon built DynamoDB and Redshift as separate products with separate architectures rather than trying to make Redshift handle real-time transactions. It's not where their core competency lies.
Pathways for a Startup
This leaves a genuine opening for startups, but the path to a trillion-dollar outcome is not obvious. We're seeing two distinct approaches emerge, and the winner may be neither, or a hybrid we haven't seen yet.
Path One: Replace Systems of Record
The most direct approach is to rebuild CRMs, ERPs, and other systems of record from the ground up with agentic execution and context capture as core design principles. Instead of a CRM that stores customer data and bolts on AI features, imagine a system where AI agents are first-class users, decisions are captured as core entities, and context graphs are native infrastructure.
This approach has the virtue of clarity. You own the data, control the execution path, and can design the perfect architecture for context capture without legacy constraints. Companies taking this path are essentially saying: "Incumbent-X had 25 years to build the right architecture for AI. They didn't. We will."
The challenge is obvious: you're competing with entrenched vendors on their home turf while simultaneously trying to introduce a new technical paradigm. You need to be 10x better on the AI/context dimensions while also achieving feature parity on the traditional dimensions. The switching costs are enormous, and most enterprises aren't ready to rip out and replace core systems, even for significantly better AI capabilities.
Path Two: Build the Orchestration Layer
The alternative is to sit between AI agents and existing systems of record. Don't replace Salesforce or Snowflake, orchestrate on top of it. When agents need to make decisions that span CRM, ERP, support, and financial systems, your platform becomes the execution layer. You query the systems of record, capture the decision context, commit the results back, and maintain the context graph that makes future decisions smarter.
This approach sidesteps the replacement problem. Enterprises can adopt your platform without ripping out existing infrastructure. You provide immediate value (better AI decisions) without requiring enterprise-wide transformation. You accumulate context graphs that become more valuable over time, creating a moat that's orthogonal to the data moats of traditional vendors.
The challenge here is that you don't own the underlying data. You're dependent on APIs that can be restricted. You're building on top of systems that weren't designed for this use case. And you need to be so valuable that enterprises choose you even when incumbents offer "good enough" agent features bundled into existing contracts.
The Emerging Category
The winning approach will likely be something that defies existing categories. Not quite observability (though it requires instrumentation). Not quite a data warehouse (though it captures cross-system context). Not quite a CRM or ERP (though it sits at the center of business operations).
Think of it as a "decision fabric".
An infrastructure that captures, stores, and makes queryable the complete context of business decisions across an organization. It needs real-time performance for the write path, sophisticated graph capabilities for modeling relationships, temporal consistency for audit and learning, and cross-system reach that no incumbent naturally possesses.
The companies building this category today (like Moltin) are placing a bold bet: that in five years, the most valuable enterprise platform won't be the one that stores the most customer records or the biggest data lake, but the one that has the richest, most complete record of how decisions are actually made.
The Strategic Stakes
If this thesis is correct (and the early evidence is compelling) we're witnessing the emergence of a new control point in enterprise architecture. The platform that captures decision context becomes the source of truth for AI autonomy, the system of record for institutional judgment, and the layer that incumbents must integrate with even as they compete.
This is why context graphs represent a trillion-dollar opportunity. Not because they'll generate a trillion dollars in revenue (though they might), but because they'll fundamentally restructure where value and power reside in the enterprise stack.
For incumbents, the challenge is existential: adapt to a world where they're not at the center, or watch a new generation of platforms capture the most strategically valuable layer of the stack.
For startups, the opportunity is generational: build the infrastructure that makes AI autonomy possible, and you don't just build a successful company, you build the next platform that everything else is built on top of.
The race has started. The technical challenges are significant. The competitive dynamics are complex. But the prize for getting it right has rarely been larger.