Software Teardown: Systems of Record

Ask ten people what a "system of record" means and you'll get twelve answers. It's a database, it's a CRM, it's whatever spreadsheet Linda in accounting refuses to let anyone else touch.

At DOSS, we're building operations software for the Real World - warehouses doing inventory counts, accounting teams closing books, supply chain operators moving goods, consumer brands trying to understand their margins. Our customers aren’t debating abstractions. They’re trying to answer simple, critical questions: what do we have, what happened, and what do we do next?

We started the Software Teardown series to understand how software actually meets the physical world. In this panel, we brought together leaders from DOSS, Google, Rippling, Retool, and Airtable to unpack what a “system of record” really means in the age of AI.

One idea kept emerging:

This post breaks down what that means in practice.

The conversation started with a deceptively simple question: what actually is a system of record?

“The system where all your data lives” sounds reasonable - until you look closer.

Does it include just storage, or also the query layer? Does every piece of data need to be equally trustworthy? Should emails, notes, and annotations live alongside transactional data?

They shouldn’t.

In practice, only a small subset of data needs to be provably correct: inventory counts, financial records, order states. This is the data that drives decisions and must be auditable. Everything else - emails, call notes, annotations, loosely structured context - is still valuable, but it doesn’t require the same guarantees.

That leads to a different architecture:

• A core system that is tightly controlled, structured, and correct
• A surrounding layer that is flexible, integrated, and often AI-managed

Once you accept that, the next question becomes: what role does structure play in a more flexible world?

AI is pushing us toward more flexible and semi-structured systems. So it’s natural to ask: do rigid schemas still matter?

They do, but not the way they used to.

The real challenge isn’t storage. It’s context management: getting the right information into the right place at the right time.

A fully unstructured system, like a giant file system of documents, technically works. An agent can navigate it like a human browsing folders. But it’s slow, ambiguous, and non-deterministic. It’s the equivalent of replacing spreadsheets with paragraphs and asking someone to extract answers manually.

Instead, structure is what makes systems usable. Especially for AI. What’s changed is not whether systems are structured, but where that structure lives. Historically, composability only existed at the extremes:

• Small teams used Excel and hacked together whatever they needed
• Enterprises paid for heavily customized systems like SAP or Oracle
• Everyone in between was stuck with rigid tools that didn’t quite fit, regularly forcing them off-chain

AI-native systems change that equation. At DOSS, every customer has a schema tailored specifically to their business for every use case across different business lines, geographies, and product types. The bottleneck used to be engineering capacity. Now, with AI and the industrialization of software creation, that constraint is collapsing.

Agents can understand unique schemas without a mountain of custom code, which brings enterprise-level composability into the mid-market. We keep the system structured, but we bring the structuring to each customer’s needs.

This is what enables agents to actually operate effectively on top of these systems.

A common narrative is that AI agents fail because they exercise poor judgement in real world operations. In practice, that is rarely the issue.

Agents fail because they are missing context or applying decisions based on invalid context.

At DOSS, this plays out in implementation. Our forward-deploy team goes in, learns a business, maps their operations against our system, and deploys a unique agentic solution. The hardest part isn't the technology but rather extracting the institutional knowledge these companies have about how they do business. That knowledge is almost never documented anywhere, and if it is documented, it’s almost surely stale.

As with most knowledge work, AI turns out to be surprisingly effective at extracting it. We record demos and conversations, then process them through models that align transcripts with UI interactions and reconstruct what’s actually happening. This speeds up the explicit structuring of previously implicitly built systems.

But once that context exists, a new problem emerges: debugging systems that operate on fuzzy inputs.

The solution is to bound the problem:

• Inject high-fidelity structured context
• Limit how much context the agent sees at once
• Force the agent to surface assumptions and ambiguities

When you do this, failures become much more understandable: “You asked how many were sold - I didn’t know if that meant completed transactions or shipped orders.”

The key insight is:

This is why systems of record still matter. They remain the source of truth, while agents operate on top, continuously validating against them rather than replacing them.

This shift matters most in the mid-market; that’s where traditional systems have failed the most.

Legacy systems are designed around the “largest common denominator.” The moment your workflow doesn’t fit, you go off-chain. Data leaks into spreadsheets, email threads, and one-off processes. Over time, the system of record stops being a system of record.

This creates a predictable cycle:

1. Start with a rigid tool
2. Work around it
3. Lose visibility and trust in your data
4. Upgrade to a more expensive system

This is the source of transformative change in the mid market - system flexibility is no longer governed by human scarcity, but rather simply by compute.

Mid-market companies can now access structured systems with customizations for their business, while retaining fast implementation timelines and low cost. They are driving token spend to develop customizations on business application platforms.

In the next generation of software, there are really only two durable company types: platform companies and model companies. Everyone else risks getting compressed. Platforms will commoditize business systems while models will commoditize custom deployment and business logic. A CPG brand won’t prompt their way to an inventory management solution or go through a lengthy implementation. Instead, a platform will be the backbone while a model will be the interface.

Therefore, the focus remains on building customers a system of record they can rely on before anything else.

Systems of record aren’t going away. They’re becoming more important - and more nuanced.

The next generation won’t be monolithic systems. They’ll be:

• Layered → a core of truth surrounded by flexible context
• Structured → but customizable per customer
• AI-native → with agents operating on top, not replacing the source of truth

The disruption won’t come from adding chatbots to existing systems. It will come from rethinking the system itself. Our customers didn’t come to DOSS for AI. They came because they didn’t know where they stood: inventory, margins, revenue. They needed a foundation.

That's the Real World. And that's what we're building for.

It wouldn’t be 2026 if a panel about Systems of Record didn’t somehow veer entirely into agent code writing.

An audience member asked the most practical questions of the night: how do you handle code review when AI can generate thousands of lines instantly?

The answer is that traditional review processes don’t scale.

Two shifts are emerging:

1. Test-driven development is resurging

AI is extremely effective when it has something to verify against. Tests become the anchor.

2. Code generation changes what gets reviewed

Repetitive patterns are moved into generators. Large portions of code are produced automatically and don’t require line-by-line review. A 10,000-line PR might only have a small percentage of human or agent-authored logic.

But the most important shift isn’t technical, it’s organizational. Communication has to move upstream. Teams can now introduce entirely new abstractions overnight. The solution is to discuss concepts before they appear in PRs, not after.