Systems of Record Evolution in the AI Era
The Last Trillion-Dollar Cycle: Object Records
Defining characteristic: Own the canonical data of a domain
- Salesforce – Customer data. Own customer relationships, own workflow, own lock-in.
- Workday – Employee data. Own HR, payroll, talent management.
- SAP – Operations data. Own procurement, supply chain, manufacturing.
Business model:
- Data is the core asset
- API access is managed (not free)
- Switching costs are high (data migration is expensive)
- Vendor lock-in is designed in
Market outcome: Trillion-dollar ecosystems built on owned data domains.
The Emerging Question: Do Systems of Record Survive the Agent Era?
The “Agents Kill Everything” Narrative
Some argue agents will disintermediate systems of record:
- Agents work across systems seamlessly
- Single source of truth becomes less important
- Workflow interface separates from data plane
- Systems of record become commoditized
The Evolution Narrative (More Likely)
Systems of record don’t disappear—they get harder.
Jamin Ball’s framing:
- Agents are cross-system and action-oriented
- UX separates from data plane
- Agents become the interface
- But something still has to be canonical underneath
Requirements go up:
- Need better data accessibility
- Need semantic contracts (shared definitions)
- Need explicit rules about which definition wins
- Need governance for multi-system access
The Missing Half: Decision Records
Ball’s analysis assumes the data agents need already lives somewhere, and agents just need better access plus governance.
That’s half the picture. The other half is:
The decision traces – the exceptions, overrides, precedents, and cross-system context that currently live in:
- Slack threads
- Deal desk conversations
- Escalation calls
- People’s heads
- Email chains
- Spreadsheets
Rules vs Decision Traces (Revisited)
Rules are defined before decisions happen:
- “Official ARR definition is X”
- “Discount cap is 10%”
- “Approval authority is Y”
Decision traces record what actually happened:
- “We used X definition, under policy v3.2, with VP exception”
- “Approved 20% discount because customer is strategic reference account”
- “Finance approved because of prior precedent Z”
Why Both Matter
Agents need rules to know general guidelines.
But agents need decision traces to navigate exceptions.
Current systems of record capture the rules (policies, definitions, approval authorities). They don’t capture the traces (why was that rule bent in that case?).
The Evolution: Two Tracks
Track 1: Traditional Systems Evolve (Partial Solution)
Incumbents will improve their systems of record:
- Better cross-system APIs
- Clearer semantic definitions
- More granular permissions
- Better governance
- Improved data accessibility
Result: Better systems of record for objects.
Problem: They still can’t capture decision traces because they don’t sit in the execution path of decisions.
Track 2: New Systems of Record Emerge (Full Solution)
Orchestration startups will create entirely new systems of record:
- Purpose-built for decisions, not objects
- Capture decision traces at execution time
- Record precedent, exceptions, approvals, rationale
- Enable agents to query “why was this allowed?”
- Compound value over time as more decisions get recorded
What this means:
-
Salesforce records customer objects
-
New platform records customer decisions (discount approvals, renewal terms, risk assessments)
-
SAP records operational objects
-
New platform records operational decisions (procurement exceptions, delivery exceptions, quality overrides)
The Architectural Shift
Current State (Object-Centric)
Traditional Systems of Record (Salesforce, Workday, SAP)
↓
Agent Orchestration (Accesses these systems)
↓
Agents make decisions
↓
Decisions get recorded...nowhere systematically
Future State (Decision-Centric)
Traditional Systems of Record (keep existing data)
↓
Agent Orchestration Layer
↓
Decision Record Layer (NEW)
- Records decision traces
- Stores precedent
- Captures "why"
- Enables future decisions
The new layer doesn’t replace existing systems. It sits alongside them and adds value by systematizing what enterprises never captured before: decision lineage.
Why Incumbents Can’t Build This
Problem 1: Architecture Path Dependency
Systems are built on current state storage:
- Salesforce: “Here’s the customer NOW”
- Workday: “Here’s the employee NOW”
- SAP: “Here’s the operation NOW”
To capture decision traces, you need:
- Historical snapshots (what did the state look like when decision was made?)
- Decision events (approval moments, override events)
- Cross-system lineage (what inputs from other systems influenced this?)
Retrofitting this into current-state systems is like trying to bolt a data warehouse onto a OLTP database.
Problem 2: Siloed Viewpoint
Operational incumbents only see their domain:
- Salesforce only sees CRM
- ServiceNow only sees ticketing
- Workday only sees HR
Decision context is always cross-functional:
- Support escalation: CRM tier + billing SLA + infrastructure outages + slack discussions
- Deal pricing: ARR calculation + customer health + market conditions + regulatory constraints
- Hiring decision: compensation + market rates + retention history + org goals
Incumbents can see only their silo. The decision traces live in the connections between silos.
Problem 3: Not in the Write Path
Salesforce, ServiceNow, Workday are write paths for their domain. But they’re not write paths for decisions.
When a decision happens:
- Agent gathers context from multiple systems
- Evaluates policies
- Routes for approval (maybe)
- Executes (changes state in multiple systems)
- Needs to record decision trace
Operational systems see step 4 (the state change in their system), not steps 1-3 (the decision context and reasoning).
They can see the result, not the logic.
The Competitive Dynamic
Incumbent Playbook (Will Try)
- Acquisitions – Buy orchestration startups to bolt on capabilities
- API lock-down – Make data extraction expensive (egress fees)
- Own ecosystem – “Keep everything in our platform”
- Agent frameworks – Build agents to stay within platform
Why This Doesn’t Work
- Can make extraction harder
- Can’t insert themselves into orchestration layer they weren’t part of
- Can’t retroactively be in the execution path
- Can’t systematically capture decision traces because they don’t see decisions
Startup Playbook (Wins)
- Insert at orchestration – Be the layer where agents coordinate
- Capture traces naturally – Decision traces emerge as byproduct of orchestration
- Build lock-in differently – Lock-in through precedent (harder to leave once decisions are encoded)
- Expand by vertical – Dominate specific decision domains
The Trillion-Dollar Transition
What Gets Disrupted
Not the data, but the lock-in mechanism:
Old lock-in: “Your customer data lives in our system”
New lock-in: “Your decision precedent lives in our system”
The data can move. The decision history compounds over time and becomes expensive to move.
What Gets Created
Entirely new categories of systems of record:
| Domain | Object Record | Decision Record |
|---|---|---|
| Sales/RevOps | Salesforce | Decision platform for: pricing, discounts, terms, exceptions |
| Support | Zendesk | Decision platform for: escalations, routing, resolutions, precedent |
| HR | Workday | Decision platform for: compensation, approvals, exceptions, promotions |
| Operations | SAP | Decision platform for: procurement exceptions, supply alternatives |
| Engineering | GitHub | Decision platform for: deployment approvals, incident decisions, on-call routing |
Each represents a new trillion-dollar opportunity.
Key Strategic Principle
The next generation of enterprise software owns decision traces, not just object data.
Objects can be accessed from anywhere.
Decision traces, once encoded in a system, create unprecedented switching costs.
This is where the next trillion dollars will be built.
References
- Foundation Capital: “AI’s Trillion-Dollar Opportunity: Context Graphs”
- Reference: Jamin Ball’s “Long Live Systems of Record”
- Related: Context Graphs - Overview for technical architecture
- Related: Context Graphs in Agent Architecture for how this manifests