AI agents are coming for enterprise software and terminal values have re-rated as a result. Even Systems of Record, the stalwarts of software stability, are now being questioned. Will computer-use agents relegate these SoRs to mere dumb databases? Will enterprises one-shot their own CRM in Claude Code? Is per-seat pricing dead as companies right size their workforce for the AI era?
The answer is nuanced and below I try to outline some heuristics I’ve found helpful. While undoubtedly some SoR are genuinely existentially threatened, I believe others will prove durable. The difference has almost nothing to do with the quality of the software, the size of the customer base, or how many integrations the platform has built. The answer lies in why the data ended up there in the first place.
Bret Taylor put his finger on this in a recent Cheeky Pint episode. He drew the distinction between SoR that function as a
- Reference Ledger where the data matters to auditors and external parties
- Aggregation Ledger where utility is the convenience of putting data in one place
He argued Reference Ledgers are durable, while Aggregation Ledgers are under real pressure as agents reduce the friction underpinning their value. Let’s dig in
The Reference Ledger
The Reference Ledger is a SoR whose authority comes from outside the company. Regulators require it and auditors depend on it. The data it stores is there because the world outside treats it as the canonical version of the truth, creating regulatory and liability anchors supporting durability. Examples include SAP and Oracle Financials for corporate accounts. Epic, Cerner, EMIS for clinical records.
ERP’s claim to being the system of record does not depend on having the richest, most current, or most operationally useful data. It depends on holding the legally authoritative version of the data. That distinction carries legal and financial weight that no amount of AI capability dissolves. A legacy schema may limit analytical flexibility or operational visibility, but it does not eliminate the ERP’s core function so long as the records it holds remain the recognised basis for control, compliance, and financial reporting. Regulators don’t care that Slack messages contain richer procurement intelligence than the purchase order in SAP. They care that the purchase order in SAP is auditable. The Reference Ledger can be operationally stale and still be institutionally indispensable.
Birmingham City Council is a useful illustration of just why inertia exists in replacing such systems. The council has run on SAP since 1999. In 2019, it decided to migrate to Oracle Cloud, a project budgeted at £19m and expected to complete by 2021. Oracle went live in April 2022 and immediately failed: the system posted transactions incorrectly, the council could not produce auditable accounts, and basic financial management for an organisation with a £3bn+ annual budget broke down entirely. The project is still on going and now £90m over budget …
I concede that competence of the UK public sector is a key confounding factor, but what’s interesting is why it failed. The council originally committed to an “adopt not adapt” principle aiming to retrofit its processes to Oracle out of the box as part of the ‘transformation’. However, this decision was soon reversed due to pushback and the Oracle system was customised to mirror Birmingham’s existing SAP-era business processes. This meant essentially replicating 23 years of accumulated institutional logic in a new system. Critical risk information was buried in supporting documents and a culture where “bad news was not welcome” meant concerns went unheard until after the failed launch. The point is a Reference Ledger accumulates encoded institutional process, custom fields, pricing rules, approval logic, decades of exception handling. And change management is both human and brutal.
Enterprises don’t want to rip out a Reference Ledger, but as technology evolves its schema staleness does create workflow problems. People work around it, build shadow systems, export to spreadsheets cc. Tessera, Axiamatic, Conduct. Opportunities exist if you can build a new interface and intelligence layer that sits above the existing ledger, making it more programmable and accessible, without requiring the underlying record to move at all. In that world Reference Ledgers become more valuable not less, as decades of trapped data become accessible without migration.
The Network Ledger
The Network Ledgers durability comes from a coordination dynamic rather than its technical merit. Value is not derived from their schema or UI quality, but because every participant in a network has independently converged on the same standard, and displacing it now requires every single one of them to move simultaneously. Leaving Salesforce is a procurement decision one firm makes independently. Leaving SWIFT requires every bank in 200 countries to agree on an alternative and migrate at the same time
The credit rating agencies are a good illustration. Moody’s and S&P scores are embedded in bond docs, investment mandates, and regulatory capital rules globally. Their data is written into contracts between parties who never coordinated with each other to adopt it. Each party independently chose the same reference because not doing so was too costly.
Travis May’s concept of the data currency describes the commercial mechanism underlying this. A data currency is a dataset so embedded in the contracts and workflows between third parties that the controlling entity can tax every transaction it touches. The FICO score is a data currency, lenders and borrowers both reference it, and now the score is baked into loan agreements, credit policies, and regulatory capital calculations simultaneously. The DUNS number. The Datavant key in healthcare. Nielsen’s TV viewership panel, which is written into the contracts between advertisers and broadcasters. These data assets become toll roads.
Such Network Ledgers aren’t quite winner-takes-all (Visa and Mastercard, Moody’s and S&P, Experian and Equifax tend toward duopolies) but they’re close, and the returns to being first to tip a vertical are extraordinary. Unsurprisingly such power has resulted in some becoming mutual utilities instead, owned by the participants themselves (SWIFT, DTCC). No single entity extracts economics from them because the network owns the infrastructure collectively. With no profit motive to betray the participants and no extractive pricing to arbitrage against they are extremely durable.
The main credible structural threat to an established network ledger is a technology that lets participants coordinate without a central record-keeper. It hasn’t happened at scale for predictable reasons (governance, latency, regulatory), but the logic is sound. In any vertical where the Network Ledger is owned by a private party that extracts aggressively, there’s a latent coalition of participants who would prefer a neutral shared infrastructure. Perhaps agents won’t be so fond of Visa rails.
The Aggregation Ledger
Aggregation Ledgers exist to solve two hard problems:
- (1) querying across heterogeneous data sources was expensive, joining customer data from five different places required real engineering effort, so you standardised everything into one schema.
- (2) building software on top of data required a stable API surface. With everything into one place, one schema and one API the aggregation SoR solved this and created a flywheel on top. More integrations → more data → harder to leave → more software built on top.
But why did people put data there in the first place? and does that reason survive agents?
Workday is more defensible than Asana because payroll has a compliance anchor, the audit trail and liability gives it quasi-Reference Ledger status. ServiceNow is more defensible than HubSpot because IT change management has regulatory weight in most SOC 2 frameworks and IT controls are increasingly important to financial auditors.
As agents begin to dissolve the problems Aggregation Ledgers were predicated on, there are two survival strategies emerging:
- (a) migrate toward Reference Ledger status by finding the regulatory or liability anchor that makes your data the canonical version external parties require, or
- (b) become the Process Ledger before a new entrant does
The clearest example of what the disruptors are actually building is Rox, a next-generation CRM that Packy McCormick of Not Boring laid out in detail. The thesis is simple, Salesforce was built for a world of structured, static pipeline data (deals, stages, contacts). But the signals that actually predict revenue today are overwhelmingly unstructured: Gong call recordings, support tickets, product usage logs, email threads. They estimate 40% of all data in modern enterprise data warehouses is now customer data, and it lives nowhere near Salesforce. Rox’s play is to build a new system of record, capturing unstructured and dynamic data upstream and using that position to train agents that progressively take over the revenue team’s functions. The Aggregation Ledger survives if it can make the same migration, hence Salesforce Agentforce.
For the Aggregation Ledger, the response to schema staleness is existential. Its only claim to SoR status was being the best place to centralise data. If better, more dynamic data lives elsewhere and agents can read it directly, its reason to exist disappears.
The Process Ledger
This is the new category and perhaps where value will be created over the next decade. Bret Taylor alluded to it in the same conversation, describing agents as themselves a new kind of SoR. They don’t require a database of state, but a Record of Action regarding what was done, by whom, when, with what inputs, and with what outcome.
Existing ledgers are all fundamentally about storing things as they are. The Reference Ledger stores the authoritative current state of accounts. The Network Ledger stores the shared standard that all parties use. The Aggregation Ledger stores a unified view of customer or operational data. None of them are designed to record the process. The sequence of decisions, the chain of reasoning, the audit trail of autonomous action, the verification of outcome.
At Sierra, Taylor describes building their own Process Ledger to record every customer service resolution. What the agent understood, what options it considered, what it did, what the outcome was. In this world, a contract review agent leaves behind an audit trail of every clause examined and every risk flagged. A medical AI diagnosing from imaging creates a chain of reasoning that, in a regulated context, becomes the evidentiary record of clinical decision-making and is then linked to outcomes.
The Process Ledger matters for three reasons:
- Explainability & Auditability: as agents make more consequential decisions, the need for explainability and auditability increases. Regulators will require process records for the same reason they require financial ledgers, e.g. Newton’s Tree for post deployment monitoring in healthcare
- Reward Signals: The Process Ledger creates a training data flywheel. Whoever owns the record of how good decisions were made in a domain owns the data asset that makes the next generation of models better. Especially important as AI seeks to expand beyond the most functionally verifiable domains like coding.
- Data Currency: In many verticals, the Process Ledger may tip toward Network Ledger status. When two parties both rely on a validated process record to complete a transaction, you have a data currency. A credit rating for your agent?
The SaaSpocalypse is real, but it’s selective. The businesses that were always Reference Ledgers or Network Ledgers have better near term defensibility and may even be more valuable as the volume of agentic activity that depends on them grows. As an early stage VC the interesting money, is on identifying those building the Process Ledgers of the future and the systems integrators fueling the transitions. I’m on jamie@triplepoint.vc