--- title: "what the heck is a system of record" description: "where i share what i think a system of record is in 2026, and why it's more than a google drive mcp" published: "2026-08-15T13:08:00+00:00" canonical: https://jaskaran.me/blog/what-is-a-system-of-record markdown: https://jaskaran.me/blog/what-is-a-system-of-record.md --- # what the heck is a system of record ## **"system of record", "memory", "intelligence", "data as a moat". what does that even mean?** if you're building saas in 2026, it's worth knowing what's actually defensible. most customers i've spoken to have already shifted a chunk of their daily workflows to claude (or something else), because moving data from one system to another isn't hard anymore. saas used to be about organizing data in a consistent, governable, consumable way, but that’s no longer enough. case in point: we built a generic MCP client into sidebar and watched it operate hubspot and jira with a breeze, no prompt needed on what it can or can't do. this is supposed to be a legal ai agent, but it does revops and project planning just as well, because the baseline has gotten that good. the only argument against using an agent for filing is token cost, and honestly, this is the most expensive and worst it's ever going to be. # **what claude \+ drive mcp can't do** moving data between products and consuming it has become cheap via an agent, which means older-gen saas all reduces to "an opinionated DB," not a deep moat. claude can help you spin up a hyper-personalized store in supabase with negligible know-how; all you have to do is slot-machine it and hit "allow". but we don’t even have to do that. take a notion or a google drive, connect it to claude, ask a question about a document or two, and we know that works well. where it fails: ask "how many of my documents talk about x" and it has to read through every single one. it usually does, up to 50, then cooks up a neat looking dashboard that people who aren't paying attention are happy with. not me, and definitely not your customers, who want outcomes, not fancy fake dashboards. when i ask to consolidate the 3 milestones across 3 different PRDs, i get a different answer every time, and have to nudge it to cover all the blindspots. it burns through tokens and stops feeling like magic. exhaustive relationship mapping is hard and expensive, unless that cost gets amortized over the lifetime of the document and its contents. # **the pay-once llm call** read-time transformation is what claude+drive does: raw documents sit there unchanged, and every query pays the full cost of turning unstructured text into an answer, from zero, every time. write-time transformation is what a real system of record does: the moment something enters the system, or the moment a relationship becomes knowable, you do the work of extracting it and writing it down as structure, once. a support ticket doesn't just get indexed, it gets linked to the account, the feature area, the eventual root cause, as structure, at the time those facts become knowable. a new signup doesn't just land in a table, it gets matched against existing accounts, tagged with likely segment, connected to the marketing touch that brought it in, all written down once, not re-inferred every time someone opens the record or asks a question. the inference cost is paid once, as it should be. # **the wiki is the right mental model, not the database** if you're living under a rock, the llm-wiki model already covers this: an llm needs a persistent wiki instead of rederiving everything from context every session. a wiki page isn't regenerated from source material every time someone reads it, it was written once, by someone (or something) that did the synthesis, and it sits there, correct, free to read, for as long as nothing about the underlying reality changes. when something does change, someone (an agent) edits the page, an incremental, targeted update, not a full rewrite. the cost is paid once per new fact or per change to an existing fact, never once per read. > If you wish to make an apple pie from scratch, you must first invent the universe. \- Carl Sagan a knowledge graph inside a system of record should feel like it's building up over time. it's not frozen at creation, it evolves: a customer's org changes hands, a bug's root cause gets found three weeks after the ticket was filed and the original entry gets updated, a policy doc's dependent pages get flagged stale. all of that is fine, expected, even necessary. what's not fine is rederiving the current state of that fact from raw source material every time someone wants to know it. you update the page when the world changes, and don't reinvent the universe when a question needs to be answered. # **why claude with an mcp connector can't compete with this, structurally** anyone can point a frontier model at their documents via mcp. that's now table stakes, a commodity capability that will only get cheaper and better. what it structurally cannot do, no matter how good the model gets, is know something about your data that you haven't written down as structure. it can infer, brilliantly, in the moment, and it can do that inference fresh every single time, at full cost, with zero memory of having done it before, for anyone. if you're building saas in 2026, your product's advantage isn't that your ai is smarter than claude's, it almost certainly isn't. your advantage is that when your product gets asked a relational question, in spotdraft's case something like "which of these contracts does this msa actually govern," it's a graph lookup, because someone already decided, at ingestion time, that this relationship was worth capturing as structure, not re-deriving on every ask. a generic agent asked the same question over an unstructured document store either can't answer it well, or has to re-run the same expensive reconstruction every time, at cost, with no guarantee of getting the same answer twice. the moat is not "we have ai," it's "we've already spent the effort figuring out what's true about your data and writing it down as a graph, and every day that graph gets a little richer, so a competitor starting today, even with a better model than ours, starts from zero on it." claude with drive access can match you on any single document. it cannot match you on the accumulated relational structure you've built by deciding, over and over, which facts were worth transforming and persisting instead of re-deriving. the real product work is understanding from customers what these relationships could look like, and building the structured frameworks agents can sit on top of to make sense of their data. the one question i get in almost every customer interview is "why is sidebar better than claude," and the answer isn't the harness, it's access to the underlying data in meaningful ways. claude is only as good as the data it can see. as an ai-native saas builder, my job is defining the data structures and relationship constructs that let an agent derive great insight from meaningful data without having to do the transformation itself. this also goes back to building [good ax](https://www.jaskaran.me/blog/the-new-user-persona), and i’m going to continue talking about what that means over time. ![image](https://dzcjqzzfpmulffvcphbd.supabase.co/storage/v1/object/public/blog-post-images/blog-uploads/3675ac0c-d091-4127-adfa-4d39401786d4.png) # **aside: this is not the deterministic-vs-ai split** forming an answer from pre-derived facts is easier, quicker, and more deterministic by definition, which is easy to confuse with the [predictability quadrant](https://www.jaskaran.me/blog/the-predictability-quadrant) (whether a given ask should get routed to a deterministic tool or an llm call), a separate question about routing individual asks. this thesis is upstream of that: it's not about *how* you answer a question, deterministically or probabilistically, it's about *whether* the answer to a relational question exists as structure before the question is even asked. you can have a beautifully engineered router that sends the right asks to code and the right asks to models, and still have zero system of record, if none of those calls, deterministic or probabilistic, ever write their output back into a persistent, queryable store. conversely, a system with unsophisticated routing but a rich, continuously updated store/graph underneath it is a real system of record. the graph is the asset. the routing is just plumbing for how you fill and query it. # **the actual question to ask** "when we learn something relational about our data, does it get written into structure that persists and can be traversed later, or does it live only inside whatever document or conversation it was mentioned in, waiting to be rediscovered?" if it's the latter, you don't have a system of record, you have a very good filing cabinet with a very good ai reading the files for you, which is exactly what anyone with an mcp connector already has. i'd pivot. ## Images - https://dzcjqzzfpmulffvcphbd.supabase.co/storage/v1/object/public/blog-post-images/blog-uploads/3675ac0c-d091-4127-adfa-4d39401786d4.png