The System of Record Was Never Designed to Be the System of Action

There is something almost comical about how much money companies have spent over the past few decades making sure they remember absolutely everything, while somehow managing to forget why half of those things happened in the first place.

We've built these enormous, incredibly sophisticated systems that can tell us when a contract was signed, who approved it, what the final amount was, which department requested it, and probably what time somebody clicked the little green button that made everything official, but ask why the company agreed to those particular terms, and suddenly everyone starts looking for Susan.

Susan, apparently, is the only person who remembers what happened.

Let's imagine a fairly ordinary situation at a large enterprise, the procurement team has just completed negotiations with a major technology supplier, the agreement is worth $1.8 million annually, it took eleven weeks to finalize, involved procurement, engineering, finance, legal, and a few executives who occasionally appeared in meetings to ask whether we were done yet.

Eventually, everyone agrees, the contract gets signed, someone updates the ERP, the finance department records the commitment, and the project is considered complete.

Beautiful, another successful enterprise transaction.

Except those eleven weeks were anything but straightforward, there were disagreements over pricing, concerns about security, a technical limitation that almost killed the deal, several alternatives that were considered and rejected, and one rather important concession the supplier made after a particularly uncomfortable meeting.

Where does all of that go?

Well, some of it lives in emails, some in Slack, a few things are buried in meeting transcripts, and there's probably a spreadsheet somewhere called something like Vendor_Evaluation_FINAL_v7_ActuallyFinal.xlsx.

The final contract tells you what everyone agreed to, but it doesn't tell you how they got there.

Now imagine that next year, the company deploys an AI agent to handle supplier renewals, which sounds like a perfectly reasonable idea, especially considering how much time people spend negotiating the same things over and over again.

The agent connects to the ERP, retrieves the contract, examines the payment history, checks the renewal date, and begins preparing its recommendation, everything is working exactly as intended.

But unless the relevant history was preserved somewhere the agent can access and correctly interpret, it may have no idea that the original price was conditional on an expansion that never happened, or that the supplier reluctantly agreed to a provision that legal considers nonnegotiable.

It knows what the company bought, but not necessarily what the company learned while buying it.

And I think that distinction is going to become a much bigger problem than most organizations realize.

A few weeks ago, I came across an interesting article by Seema Amble at Andreessen Horowitz called The Incumbents Are Coming, published in September 2026, which explores how established enterprise software companies are responding to AI agents and why the systems they've spent decades building might actually become more valuable rather than less. You can read it here: https://a16z.com/the-incumbents-are-coming/

It's a fascinating argument because we're constantly hearing that AI is going to kill traditional software, apparently every application we've ever used is about to disappear, which is certainly an exciting prediction if you're raising money for a startup, and probably less exciting if you're Salesforce.

But when you think about it for a moment, why would the systems that hold a company's most important records suddenly become irrelevant?

If anything, agents need those records to do their jobs, and the more responsibility we give them, the more important it becomes that the underlying information is accurate, accessible, and properly governed.

What might change is how people interact with those systems.

Today, someone opens Salesforce, clicks through a few screens, updates an opportunity, and moves on with their day, tomorrow, they might simply ask an agent to review their accounts, identify the ones that need attention, and take care of the administrative work.

Salesforce still holds the information, the agent still needs permission to access and update it, but the human may never actually open Salesforce.

Which, depending on how much you enjoy updating CRM records, might be one of the more compelling arguments for artificial intelligence I've heard.

Now, the interesting part of the a16z article isn't necessarily the disappearing interface, it's the suggestion that the work companies need to accomplish is much bigger than the records their applications were designed to maintain.

A procurement process isn't just a purchase order, just as a customer relationship isn't simply a collection of CRM fields, these are complex, ongoing activities involving people, decisions, negotiations, exceptions, and occasionally a little corporate politics.

And this creates a peculiar architectural problem.

For decades, enterprise software has been organized around departments and functions, sales has its tools, finance has its tools, product has its tools, engineering has its tools, and every department has very reasonable explanations for why its particular collection of applications is absolutely essential.

The trouble starts when something needs to happen across all of them... Take our supplier renewal, for instance.

The procurement agent might have everything it needs from the ERP, but engineering knows that the supplier's product caused performance problems last quarter, security is concerned about a recent incident, and someone in finance has been quietly discussing whether the company should consolidate three vendors into one.

Each team holds a different piece of the situation, each system records a different part of the work, and the agent is somehow expected to make a sensible recommendation from all of it.

Of course, you can connect the applications, build integrations, create workflows, and give the agent access to the relevant information, none of this is particularly revolutionary, and modern enterprise platforms have been working on these problems for years... But connecting systems and understanding what their combined information means are not quite the same thing.

What happens when a supplier was approved under conditions that no longer apply, or a customer was promised something that never made it into the formal contract, or a product decision was reversed after the documentation had already been published?

These are not necessarily technical failures, sometimes they're perfectly normal consequences of people running businesses, changing their minds, making exceptions, and occasionally forgetting to tell everyone else.

Humans navigate much of this through experience, relationships, and institutional knowledge, we know whom to ask, which documents to distrust, and when an apparently straightforward answer deserves another conversation.

An AI agent doesn't automatically acquire that judgment because it has access to a database.

What makes this particularly interesting is another distinction in Amble's article, the difference between remembering and learning.

Remembering that a particular supplier received a discount is useful, but learning why that discount was granted, what happened afterward, and whether the same concession would be appropriate again is something different.

And this matters enormously when we start talking about organizations deploying dozens, hundreds, or eventually thousands of AI agents.

Imagine an agent successfully negotiates a better supplier agreement, another discovers a recurring customer complaint, and a third identifies why an engineering project keeps getting delayed.

All potentially valuable outcomes.

But what happens to what those agents learn?

Does that understanding disappear into an execution log, remain buried inside one agent's memory, or become something the organization can evaluate, preserve, and appropriately reuse?

And before anyone gets too excited about the idea of AI agents teaching each other everything, let's remember that companies have permissions, confidential information, conflicting incentives, and occasionally very good reasons not to share certain things.

A procurement agent probably shouldn't have unrestricted access to employee medical records simply because they're stored somewhere in the same enterprise, and a sales agent shouldn't be allowed to invent pricing exceptions because it found something vaguely similar in an old contract.

Sharing understanding responsibly is more complicated than giving every agent access to every system.

It requires knowing where information came from, whether it's still valid, who is allowed to use it, and when a conclusion needs to be questioned rather than automatically accepted.

There's an interesting discussion along similar lines in an October 2026 a16z conversation with Vladimir Keil, the CEO of procurement AI company Lio, where they examine the work that happens outside traditional systems of record and what it takes for agents to handle more of that work, including negotiations, supplier communication, and decisions that cross departmental boundaries. The conversation is here: https://a16z.com/podcast/why-ai-agents-can-beat-the-incumbents/

What I find compelling is that the opportunity isn't necessarily to build another application that stores more information, enterprises already have plenty of those, and most CIOs would probably prefer not to receive another sales presentation promising to become their single source of truth.

The bigger opportunity might be helping organizations develop a reliable way to carry their understanding forward.

Not replacing the systems that record transactions, not replacing the agents that perform tasks, but making sure the knowledge required to perform those tasks doesn't have to be rediscovered, reinterpreted, or reinvented every single time.

And that understanding can't simply become another static document that someone writes once and forgets about, because businesses change constantly, a policy that made sense in January might be completely inappropriate by October, and the reasons behind an important decision can become just as valuable as the decision itself.

I sometimes wonder whether we've been looking at enterprise AI from the wrong direction.

We spend enormous amounts of energy discussing which models are smarter, which agents can perform more tasks, and which software applications are going to survive, all legitimate conversations, but perhaps we're overlooking a more basic question.

What does it actually mean for a company to know something?

Not for an employee to know it, not for an application to store it, and not for an AI agent to retrieve it from a document, but for the organization itself to maintain an understanding that can survive employee turnover, changing systems, evolving policies, and the inevitable moment when Susan decides she's had enough and goes on a three-week vacation.

Because if we've learned anything from decades of enterprise software, it's that recording what happened is relatively straightforward compared with understanding why.

And now that we're building software capable of acting on that information, we might finally have to take the second part just as seriously.

Otherwise, we'll end up with extraordinarily intelligent agents working for companies that still can't remember why they made half their decisions.

And poor Susan will never get a vacation...