Summary

Enterprise systems were built to record states and transactions for people. Agents need those records, but they also need relationships, authority, provenance, policy, decision rationale, outcomes and feedback. The useful progression is from systems of record to systems of context, then decision, then agency. The advantage will belong to organisations that turn institutional experience into a decision environment agents can interpret, evaluate and act within.

Companies have spent decades accumulating data, yet many enterprise agents still behave as though they joined the organisation this morning.

The CRM is full. The ticketing system contains years of incidents. Contracts, repositories and analytics platforms preserve an extensive history of work. Connect an agent to all of them, however, and organisational understanding does not simply appear.

This matters because the interface to enterprise software is changing. Salesforce and Anthropic describe Claudeforce as making Salesforce data, workflows, business logic, actions and governance accessible to Claude. The announcement is a strong signal: a general-purpose agent can become the front door while an incumbent continues to control the records and actions underneath.

Access is becoming easier. The harder question is what an agent finds when the door opens.

Data access gives an agent information; organisational understanding tells it which information should govern a decision.

Systems of record were designed for people

Classic enterprise systems optimise for transactions, CRUD operations, reporting, compliance and human-operated workflows. They are good at preserving authorised business state. Salesforce can tell us that an opportunity moved to Closed Lost. Jira can show that a ticket was resolved. Git can reproduce the code at a point in time.

Those records often leave the most useful questions unanswered. What nearly saved the deal? Which hypothesis resolved the incident? Why was an exception approved? What alternative architecture was rejected, and does that decision still apply? This is the same gap that makes a well-stocked data lake unready for AI: presence is not the same as usable meaning.

A signed contract is not the negotiation. A closed ticket is not the investigation. A conversion event is not a causal explanation. Final state is evidence, but it is a lossy compression of the work that produced it.

That loss was tolerable when a knowledgeable employee sat between the database and the decision. People supplied the missing relationships from experience, asked a colleague which policy was current, and recognised that a technically valid record was an exceptional case. An agent cannot be assumed to possess that unwritten layer.

Agents change what data is for

When software mainly displayed information to people, storing the result could be enough. When software starts acting, the system needs enough information to reconstruct how acceptable decisions are made.

The plumbing is improving quickly. The Model Context Protocol specification separates resources that provide structured context from tools that let a model take actions. OpenAI's practical guide to building agents makes a similar distinction between data tools, action tools and the instructions and guardrails governing behaviour.

These are necessary building blocks. They solve how an agent reaches information and systems. They do not determine whether the information itself contains enough organisational meaning.

From systems of record to systems of agency

System of record

The first layer stores authoritative business state: customers, orders, contracts, tickets, source code and financial transactions. It answers what happened?

System of context

The second connects the information needed to understand the work: the customer to the conversation, the contract to its negotiation, the incident to its logs, and the code change to the production behaviour it affected. The primary problem becomes relationships, not document retrieval.

System of decision

The third captures policies, precedents, thresholds, approvals, exceptions and rationale. It answers a different question: given this situation, how does this organisation decide?

This is where provenance becomes operational. The W3C's PROV-O standard provides a model for representing and exchanging provenance across systems. Research on decision provenance extends the idea towards accountability: trace the data flows that influence decisions, not merely the final output.

System of agency

The fourth stage makes the previous three usable by software that can interpret, decide, act and evaluate an outcome. It includes permissions and escalation paths because knowing what to do is not the same as being allowed to do it.

A system of agency is an organisational capability, not another database category waiting to be bought.

It may be assembled across an incumbent platform, a vertical application, an internal data layer and general-purpose models. The boundary matters less than whether the whole system preserves meaning from evidence through action.

Why retrieval is not enough

Retrieval-augmented generation is valuable. It answers: where is the information likely to be? That is not a small contribution. But retrieval does not inherently answer which source is authoritative, whether a policy is superseded, when an exception applies, whether two records describe the same entity, or whether the agent has permission to act.

It can return a current policy and an obsolete one with equal confidence. It can find the decision without its rationale, or the outcome without the correction that followed. More relevant tokens do not resolve contradictions that the organisation itself has never modelled.

Retrieval makes knowledge available. Structure makes it interpretable. Governance makes it trustworthy. Feedback makes the system learn.

This is the difference between giving an agent a library and giving it a working institution.

The hidden enterprise asset is decisions

Companies often describe their moat as data. In many cases, the more valuable asset is the accumulated history of decisions made with that data.

A bank has loan applications, but it also has approvals, rejections, risk policies, exceptions, defaults and recoveries. A manufacturer has defect records, but also the institutional method for deciding which defects matter and which intervention is proportionate. A software company has code, but also architectural choices, migrations, incidents, rejected approaches and operational lessons.

These decision structures are rarely held in one place. Some live in formal policy. Some can be reconstructed from version history. Others remain in review comments, meeting notes or the judgement of experienced staff. The practical work is not to capture everything. It is to identify which decisions are consequential enough to make explicit.

Memory is not learning

General-purpose agent memory will improve. That weakens any advantage based only on remembering a customer's preferences or recovering last week's conversation. Remembering and learning remain different capabilities.

An agent can remember every decision an organisation has made and still have no idea which ones were good. Learning requires an evaluation signal: an outcome, an expert correction, a reason for rejection or a measurable change in performance.

The NIST AI Risk Management Framework treats production monitoring and feedback as inputs to evaluation and management. The principle travels beyond risk. If an enterprise wants an agent to improve at a job, it must preserve what happened after the action and connect that outcome to the decision that produced it.

Harvey's Tenet research preview offers a concrete vertical example. Its training set used roughly 1,750 agentic legal-task environments, combining synthetic, public and human-expert data. Tasks averaged about 50 rubric criteria. The point is not the model name. It is that professional capability was built from assignments, tools, expert standards and evaluated outcomes--not from a large folder of completed documents alone.

Software architecture is one instance of the problem

A repository contains source code, configuration, dependencies and commits. It may still fail to explain why PostgreSQL was chosen, whether an architectural decision remains authoritative, which constraint applies to which path, or whether an AI coding agent may violate it.

The repository records software state, but it rarely captures a complete, current and enforceable account of architectural intent.

This is the specific problem I am working on with Mneme HQ: making selected architectural decisions machine-readable and, where appropriate, enforceable during AI-assisted development. It applies the distinction between prompting and governance to one domain. It is one application of the broader shift, not the whole thesis.

What enterprises should capture now

Most organisations do not need another data lake before they begin. They need to choose a consequential workflow and make six elements explicit:

Start where decisions repeat, judgement matters, experts can review the result and outcomes become visible. Capture the minimum structure that makes those decisions reviewable. Then test whether the agent uses it correctly before expanding the surface area.

The strategic implication

Will incumbents own enterprise agents because they own the data? Sometimes. Owning an authoritative record and the action surface around it is a substantial advantage.

But the customer's job is usually larger than one record. The contract is not the legal matter. The opportunity is not the sale. The ticket is not the customer's resolution. Valuable work crosses systems, teams and organisational boundaries.

A general agent may coordinate that work. An incumbent may expand outward. A vertical company may learn one job more deeply. An enterprise may build its own decision layer. The durable advantage belongs to whichever arrangement can turn fragmented information into a high-quality environment for decisions and feedback.

The most important enterprise data advantage in the agent era may not be possessing the largest dataset. It may be knowing how to turn institutional experience into something an agent can understand, evaluate and act on.

Key takeaways

Frequently asked questions

What is a system of agency?
A system of agency is an organisational capability that makes records, context, decisions and feedback usable by software that can interpret, decide and act. It is not necessarily a new database or product category.
Why is enterprise data not enough for AI agents?
Most enterprise data records states and transactions. An agent also needs to know which source is authoritative, why a decision was made, which policy applies, whether an exception is legitimate and whether the outcome was good.
Does RAG create organisational understanding?
No. Retrieval-augmented generation can locate and supply relevant information, but it does not inherently resolve authority, provenance, applicability, supersession, permissions or conflicting sources.
What should enterprises capture for AI agents?
Enterprises should capture authority, provenance, applicability, decision rationale, outcomes and expert corrections around consequential work. These elements turn stored information into a decision environment an agent can use and evaluate.