Find the System of Record: The First Rule of Reliable AI Workflow Design

A mid-market private equity firm asked us to build an agent that produced a weekly portfolio KPI pack. The first version looked great in the demo. Then a portfolio company's controller called: the agent had reported $4.1M in monthly recurring revenue for a SaaS asset that was actually at $3.6M. Nobody had lied to it. The agent had pulled the number from a board deck PDF that was six weeks stale, because the deck was the easiest thing to read and nothing told it the billing system was the real answer.

That is not a model problem. A larger model would have made the same mistake faster. It is an authority problem, and it is the single most common reason AI workflows that pass a demo fall apart in production. Before you write a prompt, choose a framework, or argue about agents versus workflows, you have to answer one question for every fact your system touches: which system is allowed to say what is true?

A system of record is an answer to "who owns this fact"

The term predates AI by decades. In enterprise architecture, a system of record (SoR) is the application that holds the authoritative version of a given data element. Martin Fowler's writing on enterprise application patterns and on keeping a clear source of truth framed it long before agents existed: many systems can hold a copy of a value, but only one is allowed to be canonical.

What is new is that AI agents are unusually good at ignoring this. A traditional integration fails loudly when it reads the wrong table. An agent reads a stale PDF, a Slack message, and a CRM field, then produces a confident, well-formatted blend of all three. The output looks authoritative precisely because the model is good at writing. So the discipline that used to be optional in data engineering becomes mandatory the moment a language model sits in the loop.

A useful working definition for builders: a system of record is the system you would point to in a dispute. If two values conflict, the SoR wins, and everything else is a cache.

In practice your map looks like this:

The point of the table is not the rows. It is the act of filling it in before you build anything.

The three ways missing authority breaks an agent

When no system of record is wired in for a fact, agents fail in three predictable ways. Naming them helps you spot the risk during design review.

Inventing state. With nothing authoritative to read, the model falls back on its prior. Ask it for a customer's plan tier and it will produce a plausible one. This is the failure people call hallucination, but the cause is architectural: you gave the agent a question and no source, so it answered from training data. Research on building effective agents makes the point that the augmented model is only as good as the retrieval and tools you attach. No tool for a fact means the model guesses.

Writing to the wrong tool. An agent resolving an invoice dispute updates a note in the CRM because that is the tool it happened to have, while the ERP still shows the invoice as open. Now two systems disagree and neither knows it. The next workflow that reads invoice state reads the wrong one.

Treating a stale document as truth. This is the KPI pack story. Documents are seductive to agents because they are easy to retrieve and rich in text. But a document is a snapshot, not a system of record. The board deck was true the day it was made. Six weeks later it is a confident liar.

All three share a root cause and a single fix. The fix is not a guardrail bolted on at the end. It is deciding, per fact, which system owns the truth, and wiring the agent so it cannot answer that fact any other way.

The decision rule: one writer per fact

Here is the rule we apply on every build, and it is deliberately strict: any number of systems may read a fact, but exactly one is allowed to write it.

Reads are cheap and safe. Let the agent read the customer's status from the CRM, the invoice from the ERP, and the ticket from the helpdesk all in the same run. Writes are where authority matters. If your agent can change customer stage, that write goes to the CRM and nowhere else. If it can mark an invoice as disputed, that write goes to the ERP.

To assign the writer, ask a single question: who is accountable when this fact is wrong? The team that owns the consequence owns the system of record.

• When a customer is billed for the wrong plan, finance answers for it, so the ERP owns invoice state.
• When a support SLA is missed, the support team answers for it, so the helpdesk owns ticket status.
• When a deal is misreported to the investment committee, the deal team answers for it, so the CRM owns pipeline stage.

This maps cleanly onto the distinction the LangChain team draws between workflows and agents: predetermined paths for the predictable parts, model-driven decisions only where you genuinely need them. Authority assignment is a workflow-level decision. You do not want the model deciding at runtime which system is canonical. You decide that at design time and the model lives inside those rails.

A second rule rides along with the first: separate the read path from the write path. Agents should retrieve current state at the moment they act, not reason from values they read three steps ago. State goes stale inside a single agent run, especially long ones. Re-read before you write.

What this looks like in PE and mid-market workflows

The pattern is abstract until you ground it. Here are four workflows we see across private equity portfolios and mid-market operators, each annotated with its systems of record.

Portfolio KPI pack. The warehouse or billing system owns the metrics, full stop. The agent's job is to assemble and narrate, never to source numbers from decks or emails. If a metric is missing from the warehouse, the agent flags a gap rather than borrowing a number from a PDF. This single rule would have prevented the $4.1M error. McKinsey's work on where AI creates value in private equity repeatedly lands on the same prerequisite: the data foundation has to be trustworthy before the analytics layer means anything.

Invoice exception routing. The ERP owns invoice state. The agent reads invoices, classifies exceptions, and proposes a routing decision, but the only write it makes to invoice status flows through the ERP. Notes and context can land in the helpdesk or CRM; the canonical state cannot fork.

Support escalation. The helpdesk owns ticket status and history. An agent drafting escalations reads the ticket, reads the customer record from the CRM for context, and writes its escalation back into the helpdesk thread. It does not quietly close tickets in a side system.

Implementation onboarding. The document system owns source files, the CRM owns account status, and a project tool owns task state. The risk here is the agent treating an onboarding checklist document as the live status of the project. The document describes the plan. The project tool holds the truth about what is done.

Industry analysts have started naming this as the gating factor for AI in the asset class. FTI Consulting's 2026 Private Equity AI Radar and practitioner guides like Thirdbridge's view on AI in due diligence both keep circling back to data provenance: an AI conclusion is only as defensible as the source it can point to. In diligence especially, "where did this number come from" is not a nice-to-have. It is the whole job.

Make authority auditable, not implicit

Knowing the system of record is half the work. The other half is making the agent's claims traceable back to it. Every fact an agent reports should carry a pointer to where it came from and when it was read. This is the same discipline that data governance teams apply to master data management, where the single source of truth exists precisely so downstream consumers can resolve conflicts deterministically.

For agents, that means three concrete habits:

• Cite the source on every value. A KPI in the pack should be able to say "pulled from billing, June 9, 09:14 UTC," not just "$3.6M."
• Re-read before any write. Treat values older than the current step as suspect. State drifts.
• Flag conflicts instead of resolving them silently. When the CRM and a document disagree, the workflow surfaces the disagreement to a human. The system of record decides the winner, but a person should see that a copy was wrong, because a recurring conflict usually means a broken upstream process.

This is also where observability earns its keep. Tracing tools exist so you can answer "why did the agent say that" after the fact. When every claim ties back to a named source and a timestamp, a wrong output becomes a fixable data issue instead of an unexplainable model mystery.

How OpenNash Can Help

Most of the value here lands before any model is chosen. In our audit phase we map operations to systems of record: which application owns each fact a proposed workflow will touch, who is accountable when it is wrong, and where stale copies currently masquerade as truth. That map becomes the contract the agent is built against.

From there the design phase sets the read and write paths explicitly, defines where a human approves a write, and decides how conflicts get surfaced. The build and deployment phases wire the agent so it cannot source a canonical fact from anywhere but its system of record, with citations and traces baked in so the output is auditable on day one. Clients own the result outright, including the authority map, which tends to outlive any individual model choice.

If you are weighing a platform instead, that can be the right call when your facts already live in one suite that owns both the data and the workflow. Custom work earns its cost when authority is spread across a CRM, an ERP, a helpdesk, and a document store that were never designed to agree. That fragmentation is the normal state of a mid-market operator or a PE portfolio company, and it is exactly the case where guessing which copy is true gets expensive.

Pick the system of record for every fact before you build. Wire the agent so it cannot answer any other way. Then the question stops being "do we trust the AI" and becomes "do we trust the source," which is a question your finance, support, and deal teams already know how to answer.

Book a call to map your systems of record before you build the agent.