Before You Deploy the Agent, Own the Record It Has to Read

The most expensive misreading of 2026 is the one being repeated in operating reviews right now. A company runs a high-profile AI program in a customer-facing department, the program degrades, the company walks it back, and the conclusion in the room is some version of "the model was not ready." That conclusion feels safe because it points at the technology, which is outside the room's control, rather than at the operating model, which is inside it. It is also wrong often enough to be dangerous.

The story I keep coming back to is Klarna, because it became the reference case the whole market now uses to calibrate its own AI ambition. Klarna leaned hard into an AI-first customer-service posture, reported strong early numbers, then publicly softened it and brought human agents back into the loop for the harder cases. The press coverage settled into a comfortable narrative: AI hit its ceiling, the hype met reality, score one for the humans. Klarna has not publicly attributed its quality problems to fragmented or un-owned data, so the case does not prove a data-substrate failure. What it does is expose a question that every AI-first service model eventually faces, and that every department rolling out agents this quarter is one decision away from answering badly: when the automation reaches the difficult cases, does the agent have the account history, the policy context, the resolution knowledge, and the escalation authority that an experienced human draws on by default?

The agent is not a smarter chatbot, it is a new reader of your system of record

Start with what an AI agent does inside a business workflow, because the popular mental model is wrong in a way that hides the real risk. The popular model treats an agent as a chatbot with better answers, a more fluent front end bolted onto the same operation. Under that model the only variable that matters is the model itself, so when the program struggles the natural question is whether the model is good enough.

The accurate model is closer to this: an agent is a reader, and it is only as capable as the context it can retrieve, the policies it can apply, the authority it is granted, and the escalation path built around it. To resolve a customer's problem, a competent human support agent reads a system of record: the customer's order history, the prior tickets, the refund policy as it applies to this account tier, the note a colleague left three weeks ago about a known shipping defect. Much of what that human reads is not a tidy database record at all. It is tacit knowledge, exception precedent, and known-issue context that a tenured rep carries in their head. That reading, explicit and tacit, is most of the work. The talking is the easy part. When you put an AI agent into that role, you are not replacing the talking. You are replacing the reading, and the agent can only read what you have made readable, current, and governed, including the tacit knowledge someone has bothered to convert into operational guidance the agent can actually retrieve.

This is where the data substrate comes in, and it is the load-bearing term for the rest of this piece. The data substrate is the system of record the agent reads from to do the work: the structured and unstructured organizational memory that holds what happened, what the policy actually is, the resolution outcomes and exception precedents, and the context a human would have had by default. The precondition for an agentic workflow is that this substrate is authoritative and governed, not that you happen to host it yourself. Where the substrate is fragmented or opaque, thin, scattered across systems nobody is accountable for, or stale, the agent loses the context a competent human had by default, and it loses it silently. Where it is complete, current, and governed, the agent has what the human had. The model did not get worse. The reader was handed a worse book.

What Klarna actually shows, and what it does not

Start with what the public record supports, because the popular reading runs past it. Klarna pushed an aggressive AI-first customer-service stance and reported strong early productivity claims. Its own February 2024 announcement said the assistant had handled 2.3 million conversations, roughly two-thirds of its customer-service chats, doing work the company equated to about 700 full-time agents, and had cut average resolution time from 11 minutes to under 2. Klarna then softened the posture and increased human-agent access after quality and customer-experience concerns surfaced. The CEO's own later framing is the tell: he said that when cost becomes too predominant an evaluation factor, what you end up with is lower quality. Klarna did not abandon AI. By its own account the assistant still handles a large share of inquiries; the company recalibrated toward human access for the cases where the cost of getting it wrong is high.

Here is the discipline the popular reading skips. Klarna has not publicly attributed its quality problem to fragmented or un-owned data, so this case does not prove a data-substrate failure, and I am not going to claim it as one. What it proves is narrower and more useful: efficiency metrics can look excellent while quality quietly degrades, and an organization that optimizes hard for cost can ship that degradation without seeing it until the hard cases arrive. Klarna's own CEO named the mechanism, and it was about evaluation incentives, not data architecture.

That is the trigger, not the proof. The reason to put Klarna next to the data-substrate question is that the substrate is one of the most common reasons an AI-first service model degrades on the difficult cases specifically, and it is the one almost nobody is measuring. When automation reaches the tickets that depend on account-specific, policy-specific, history-specific context, the agent can only perform if that context is authoritative, current, and governed. Whatever happened inside Klarna, the question every department should take from it is the one Klarna's metrics could not answer on their own: does the record this agent has to read hold up when the easy cases run out? The lesson is not "be more cautious than Klarna." The lesson is "govern the substrate before you scale the reader," because that is the failure mode you cannot see from an efficiency dashboard.

Most departments ship the reader before they own the record

Here is the uncomfortable part. The Klarna pattern is not an exception that strong execution avoids. It is the path of least resistance that strong execution walks straight into, because the reader is cheap to deploy and the record is expensive to own.

Deploying an agent is a procurement-and-integration project measurable in weeks. Owning the system of record is an operating-model project measurable in quarters, and it has no demo. So departments do the thing with a demo. Support stands up an agent against whatever transcript history happens to exist. Sales points an agent at a CRM that three teams have been filling out inconsistently for years. Operations wires an agent into exception logs that were designed for after-the-fact debugging, not for an autonomous reader making live decisions. Each of these is a local win on the day it demos and a stalled pilot ninety days later, for the same reason: the agent was given a substrate nobody had made fit for an agent to read.

This is the failure mode I see in departments rolling out agents, and it is the data-layer expression of a pattern that shows up across AI transformation. Pilots create local wins that do not compound, because the thing that would let them compound, a governed and owned data substrate shared across the workflow, was never built. Instead the organization accumulates shadow stacks and unmanaged data flows: this team's agent reads one slice of the record, that team's agent reads another, neither slice is authoritative, and nobody owns the whole. The company ends up with more AI activity and no more AI performance, which is the most expensive place to be, because it has paid for the tools and the integration and the change-management theater without changing the metric that justifies any of it.

The deeper point, and the one that connects this to the broader operating-model thesis, is that the data substrate is an operating-model object, not a technology object. Governing it means deciding who is accountable for the record being correct, who governs what the agent is allowed to read, and how the record stays current as the business changes. None of that is a model-selection question. A better model can squeeze more out of a thin substrate at the margins, but it cannot supply context that was never made readable, and no model upgrade closes an accountability gap over who owns the record. The substrate is the constraint a model upgrade does not lift, which is why this is an organizational-capability problem before it is a technology one.

Authoritative versus fragmented: a per-department map of the record the agent reads

The abstraction becomes useful the moment you make it concrete per department. Note that the axis is not who hosts the data. A record sitting in a SaaS platform like Salesforce or Zendesk can be fully authoritative; a self-hosted warehouse can be fragmented and stale. What matters is accountability, access, and quality: is there an owner answerable for the record being correct, is access governed, and is the content complete and current. The question to ask before any agent ships is not "is the model good enough." It is "does the department have an authoritative, governed version of the specific record this agent has to read, or a fragmented and opaque one." The difference is the difference between an agent that performs like your best tenured employee and one that performs like a temp on their first day.

The column that matters most is the last one, because it is the Monday-morning test. If you cannot name what the department does measurably differently once the substrate is authoritative and governed, you have not yet found the operating-model change, and you are about to automate the absence of one. When you can name it, you have found the actual work, and you will notice it is mostly not AI work. It is accountability work, access-governance work, data-quality work, and role-redesign work that the agent then reads on top of.

How you would see whether the substrate is actually owned

The trap with everything above is that "own the data substrate" can become another slogan, agreed to in the meeting and undone in the execution. So the useful question is how you would verify it, and the answer is to stop asking people whether they own the record and start reading the artifacts that ownership produces.

There is a measurement lens I apply to operating-model change generally, the Shift Harness Artifact Test, which reads whether the operating model actually changed from the artifacts it leaves behind rather than from what people report. For the data-substrate question, the artifact test resolves into six measures you can actually inspect. Completeness: is the context an agent needs for a given case actually present in the record, or does the hard case depend on knowledge that lives only in someone's head. Freshness: is the record current at the moment of the decision, not current as of the last quarterly cleanup. Consistency: when authoritative sources overlap, do they agree, or does the agent get a different answer depending on which slice it reads. Provenance: for any piece of context the agent uses, can you identify the source and the version it came from. Retrieval coverage: when the agent acted, did it actually receive the evidence the case required, or did the right record exist but never reach the agent. Outcome quality: did the action the agent took actually resolve the case correctly, traced back to whether the record supported it. The decision log that supports all of this records what the agent retrieved, which policy versions and tools it used, what approvals it cleared, and what outcome followed, so a human can audit the read and the action. It does not pretend to log why the model decided what it decided; hidden model reasoning is not a reliable audit record, and a substrate measure that depends on it is not a measure. If those artifacts exist and are current, the substrate is authoritative. If the only artifact is a slide that says the substrate is owned, it is fragmented in practice, and the agent will find out before your customers do.

The implication: govern the substrate before you scale the reader

The conclusion is an ordering rule, and it runs against the grain of how most AI programs are funded and staffed. Most programs sequence the agent first because the agent is visible, fundable, and demo-able, and they treat the data substrate as a cleanup project to be done later if the metrics disappoint. The point is not that you must perfect the record before you touch an agent. Waiting for a perfect substrate is its own way of never shipping. The point is that the substrate and the agent's autonomy have to expand together, deliberately, instead of the autonomy racing ahead of the record.

So the practical move for a tech-company owner or a C-level accountable for AI outcomes is a minimum-viable-substrate rollout. Select one bounded workflow, not the whole department. Define its minimum viable substrate: the specific records that workflow's hard cases actually need, and the completeness, freshness, and quality thresholds those records have to meet. Establish ownership and those quality thresholds before you widen the agent's remit. Then deploy under controlled evaluation, watching the hard cases specifically, not just the aggregate resolution rate. As the substrate proves out, expand the substrate and the autonomy together. Redesign precedes scale, but learning begins well before perfection. This is the same move at the data layer that the broader operating-model shift makes everywhere: the tool is not the transformation, the redesign underneath the tool is, and the redesign has to come first. For the agentic case, that redesign has a precise name. It is making the system of record the agent reads from authoritative and governed, and it is the precondition, not the cleanup.

Klarna did not fail at AI, and neither will you if you read it for what it is rather than what the headline says. The walk-back, whatever its internal causes, is a reminder that an efficiency dashboard cannot see the hard cases coming, and that the part no model does for you is deciding who owns the record, governing what the agent reads, and keeping it current before you hand it to a reader who can only be as good as the record you let it read. The departments that take that from Klarna will govern the substrate before they scale the reader. The ones that read it as "AI was not ready" will scale the next reader against the next fragmented record, and they will write the next walk-back themselves.

Frequently Asked Questions