Amidst the “AI frenzy”, I do believe there is a level of naivety among developers and among some investors around the complexity of these SORs (& this article does point some of those complexities out). I have also recently heard “CRM for AI native companies” & I am still trying to figure out what that means - perhaps one of you can enlighten me!
Very interesting! "The familiar SaaS front ends that used to sit on top of those systems of record will matter less over time"--what's your take on the importance of keeping these UIs at all? I kind of wonder myself if as a user I'd want to still see the Hubspot/Salesforce UI for the sake of certainty, or is a chat interface completely enough...kind of like do i really need a wheel of the car is self driving?
10000000000% LLM's and agents have zero "organizational context". Much of that context isn't rational or easily accessible. Not only do people measure "ARR" differently, different systems can give the illusion of knowing the number (using an engineering dashboard measuring credit usage vs. a finance dashboard that include contractual things like free credits etc..). The agent is like a very smart intern on the first day, who tries his/her best, but needs very explicit instructions.
What's missing here is a graph layer between today's SORs and the agents. SORs aren't going anywhere, but agents without an ontology can only fail — they lack the context to understand how entities actually relate to each other.
Your ARR question nails it: which ARR should the agent use? A graph doesn't just store "official_arr = $X" — it encodes that this number is derived from these contracts, excludes these adjustments, and is the one we report externally. Meanwhile sales_arr has different rules and a different purpose. The agent needs that relational context to pick the right one, not just access to the values.
Agents need more than APIs into your systems. They need an ontology that captures how the business actually thinks. Graphs are the natural substrate for that.
As a data professional, I am pleased to see the acknowledgement that data system can be the "center of the universe" for enabling AI based on information from multiple systems of record. However, the Enterprise has still not solved for clean, trusted, reliable data and the reticence to pay for it. Executives and Enterprises simply do not want to fund data foundation work despite all wanting data they can trust. If a data system is to be the cross-system aggregator of context and truth, we have a lot of work to do ahead of us to get it there. And until we solve that prioritization problem, AI without context or reliable data will simply be additional wasted spend, false promises, and contribute to the already salty narrative around data.
Love this framing of SoR as “where does the truth live”, agents make canonical sources + precedence rules non-negotiable.
The missing layer I keep seeing in practice is the decision trace: why a value changed in this case, what exception route/precedent applied, and who had binding authority at commit time. Without that, we get truth… but not defensible autonomy.
Thank you for a very interesting treatise of the topic of System of Record, which is massive in the Life Sciences industry sector. We are in a regulatory-based, scientifically-sound, and compliance-confirmed business environment. Working in the R&D side of things, we have so many many systems of record that it's sometimes impossible to see the clear when you speak about AI and "where does the truth live". I would be very interested in learning more from others in Healthcare or Life Sciences (or better learn from outside our space) as to how we carefully consider best way to tackle / address this topic.
Great points, especially on the complexities of building agents and workflows. I think one of the key things we overlook is that enterprise software is used differently by different companies and even people in the same company.
Agents need to know the system of record, how it’s used, and how the user wants to see the data. The it needs to reliably translate one to the other. The complexity makes it very prone to errors via chat.
Pushing for simplicity for the users will hit a limit of ROI at some point.
Very informative write up. Would a better way to frame “systems of record are dying” be “existing systems of record are dying” in the sense they are facing disruptions by new companies building agents to capture workflows which eventually lead to them capturing additional layers of the enterprise value chain, including the system of record?
Amidst the “AI frenzy”, I do believe there is a level of naivety among developers and among some investors around the complexity of these SORs (& this article does point some of those complexities out). I have also recently heard “CRM for AI native companies” & I am still trying to figure out what that means - perhaps one of you can enlighten me!
Very interesting! "The familiar SaaS front ends that used to sit on top of those systems of record will matter less over time"--what's your take on the importance of keeping these UIs at all? I kind of wonder myself if as a user I'd want to still see the Hubspot/Salesforce UI for the sake of certainty, or is a chat interface completely enough...kind of like do i really need a wheel of the car is self driving?
10000000000% LLM's and agents have zero "organizational context". Much of that context isn't rational or easily accessible. Not only do people measure "ARR" differently, different systems can give the illusion of knowing the number (using an engineering dashboard measuring credit usage vs. a finance dashboard that include contractual things like free credits etc..). The agent is like a very smart intern on the first day, who tries his/her best, but needs very explicit instructions.
What's missing here is a graph layer between today's SORs and the agents. SORs aren't going anywhere, but agents without an ontology can only fail — they lack the context to understand how entities actually relate to each other.
Your ARR question nails it: which ARR should the agent use? A graph doesn't just store "official_arr = $X" — it encodes that this number is derived from these contracts, excludes these adjustments, and is the one we report externally. Meanwhile sales_arr has different rules and a different purpose. The agent needs that relational context to pick the right one, not just access to the values.
Agents need more than APIs into your systems. They need an ontology that captures how the business actually thinks. Graphs are the natural substrate for that.
As a data professional, I am pleased to see the acknowledgement that data system can be the "center of the universe" for enabling AI based on information from multiple systems of record. However, the Enterprise has still not solved for clean, trusted, reliable data and the reticence to pay for it. Executives and Enterprises simply do not want to fund data foundation work despite all wanting data they can trust. If a data system is to be the cross-system aggregator of context and truth, we have a lot of work to do ahead of us to get it there. And until we solve that prioritization problem, AI without context or reliable data will simply be additional wasted spend, false promises, and contribute to the already salty narrative around data.
Strong synthesis. Feels like the quiet shift is from building systems that process data to systems that encode meaning. Once that happens, semantics outlasts models and platforms. I’ve been exploring this through the lens of an Enterprise Semantic Foundation here: https://open.substack.com/pub/machinereadable/p/the-missing-layer-in-your-stack?r=28rls4&utm_medium=ios&shareImageVariant=overlay
Love this framing of SoR as “where does the truth live”, agents make canonical sources + precedence rules non-negotiable.
The missing layer I keep seeing in practice is the decision trace: why a value changed in this case, what exception route/precedent applied, and who had binding authority at commit time. Without that, we get truth… but not defensible autonomy.
I noticed you don't label your axes so I assume that in any chart the first variable in the header is the vertical axis?
Just seems that systems of records are not where work will get done, but still very necessary
Thank you for a very interesting treatise of the topic of System of Record, which is massive in the Life Sciences industry sector. We are in a regulatory-based, scientifically-sound, and compliance-confirmed business environment. Working in the R&D side of things, we have so many many systems of record that it's sometimes impossible to see the clear when you speak about AI and "where does the truth live". I would be very interested in learning more from others in Healthcare or Life Sciences (or better learn from outside our space) as to how we carefully consider best way to tackle / address this topic.
Great points, especially on the complexities of building agents and workflows. I think one of the key things we overlook is that enterprise software is used differently by different companies and even people in the same company.
Agents need to know the system of record, how it’s used, and how the user wants to see the data. The it needs to reliably translate one to the other. The complexity makes it very prone to errors via chat.
Pushing for simplicity for the users will hit a limit of ROI at some point.
Very informative write up. Would a better way to frame “systems of record are dying” be “existing systems of record are dying” in the sense they are facing disruptions by new companies building agents to capture workflows which eventually lead to them capturing additional layers of the enterprise value chain, including the system of record?