AI Agents Do Not Need More Data. They Need Business Context.

One development. Different views on what enterprise AI actually requires.

The enterprise AI debate is moving beyond the model.

The question is no longer simply which company has access to the most capable large language model. The harder question is whether that model—or the agent built around it—can understand how the organisation actually works.

That requires more than data.

An agent must know what the data means, how business objects relate, which information matters to the decision in front of it, what policies apply and what it is authorised to do next.

In his article Building the AI Agent’s Brain, Isaac Sacolick separates several concepts that are frequently collapsed into one:

A semantic layer establishes consistent business meaning.
A knowledge graph connects entities, relationships, metadata and systems.
A context layer determines which information is relevant to a particular task or decision.
Governance controls what information and actions an agent may access.
Memory allows the agent to learn from previous interactions and outcomes.

The distinction is useful. But it also raises a larger management question:

What must be true before an AI agent can be trusted to act inside an enterprise?

That sounds like an architecture question. It is actually a strategy, data, operating-model, process, talent and accountability question hiding inside one diagram.

The existing work of sapperment’s Leading Top Voices offers several different views.

The architecture matters. The management questions matter more.

A semantic layer can define what an “active customer” means. A knowledge graph can connect that customer to contracts, products, invoices, service cases and account teams. A context layer can decide which of those relationships matters when an invoice becomes overdue.

None of those layers decides whether the customer should be contacted, whether credit should be restricted or whether protecting the relationship matters more than collecting the payment today.

That requires business intent, policy and authority.

The distinction becomes even more important when AI moves from recommending an action to executing one.

A copilot can explain why an invoice is blocked. An agent might correct the posting, release the invoice and notify the account owner. That one step—from recommendation to execution—changes the conversation from productivity to accountability.

As argued in AI Agents in ERP, the right first agents will probably be boring: high-volume processes with understood rules, documented exceptions and actions that can be detected and reversed when they are wrong.

The spectacular demonstration is rarely the responsible starting point.

The operating-model view: context is not authority

An agent may have excellent context and still lack the right to act.

Enterprise autonomy requires five things to work together:

A defined business outcome.
Trusted process and data context.
Explicit decision rights.
Guardrails that bind the action.
A named human accountable for the result.

Without those conditions, the organisation has a better-informed assistant—not an autonomous operating model.

This is the central distinction in Autonomous Enterprise: Why Enterprise AI Needs a New Operating Model. AI as a feature improves an individual task. AI as an operating model changes how the company senses, decides and acts across functions.

The context layer therefore cannot be treated as another technical component to purchase. It must reflect the real operating model:

Who defines the outcome?
Which policy applies?
What may the agent decide independently?
Which exceptions require approval?
Which systems may it update?
Who can stop it?
How will the organisation know whether the decision was good?

Context tells the agent what is happening. Governance determines what it may do about it.

And, as Embedded AI Governance argues, governance for acting AI must live in the process itself. A quarterly review board cannot control thousands of actions taken between meetings.

A review board can govern suggestions. Only architecture can govern actions.

Nina Simosko: does it change the growth equation?

A sophisticated context layer is infrastructure. It is not yet a business case.

Nina Simosko’s Growth Mandate supplies the commercial test:

Can the investment be traced from capability to customer behaviour, commercial outcome and enterprise value?

For an AI context layer, that means asking what becomes possible that was not possible before.

Does better context allow the company to:

identify an expansion opportunity earlier?
resolve a customer problem before it becomes a renewal risk?
serve a segment that was previously uneconomic?
reduce friction in the buying journey?
improve pricing realisation?
convert operational capacity into revenue?

If the answer is only that the organisation can deploy more agents, the investment remains a technology programme.

The number of connected sources, graph relationships or automated actions measures activity. It does not prove value.

A company could build an elegant enterprise knowledge architecture while leaving the binding constraint on growth untouched. It could automate customer interactions without improving the customer experience. It could accelerate decisions that should not have been made in the first place.

The board should therefore resist counting agents.

It should ask which part of the revenue equation changes, through what mechanism, by when—and who owns the outcome. The full argument: When Does Technology Transformation Become a Growth Strategy?

Rej Pathania: one truth does not mean one representation

The semantic problem becomes especially difficult at the boundary between an enterprise and the market.

In The Closed Door, Rej Pathania distinguishes between governed facts and contextual representations.

A product may have one authoritative identity, one regulated ingredient statement and one accountable owner. Those facts should remain controlled.

But the same product may need to be presented differently to different retailers. Each retailer has its own taxonomy, mandatory attributes, controlled vocabulary and item-setup rules. One governed fact may therefore require several contextually valid outputs.

This exposes an important limitation in the idea of a single enterprise truth.

The governed fact should be singular. Its valid use may be contextual.

The same principle applies far beyond product data:

Finance and Sales may use different customer hierarchies for valid reasons.
A supplier classification appropriate for procurement may be insufficient for compliance.
A global job architecture may require local interpretation.
A service priority may change according to contract, customer importance and operational risk.

A semantic layer cannot eliminate these differences by decree. It must make them explicit and govern which definition applies in which context.

AI is valuable here because it can propose mappings, flag anomalies and translate between vocabularies. But consequential adjudication still needs an owner.

The useful boundary is:

Let the machine propose. Let an accountable person decide where being wrong is expensive. Keep the decision auditable.

Otherwise, the context layer does not resolve ambiguity. It distributes it faster.

Philip Zhang: can the architecture perform real work?

Architecture diagrams tend to end where implementation becomes difficult.

The builder’s questions begin there:

How does the agent retrieve the context?
Which tools and APIs can it call?
How is state maintained between actions?
How does it distinguish current information from stale information?
What happens when retrieval is incomplete?
How are permissions enforced at runtime?
How is an incorrect action reversed?

Philip Zhang’s Builder’s Proof is concerned with this implementation layer: agents, local models, retrieval systems, governed tools and working enterprise software.

But execution alone is not enough. In an enterprise system, a successful API call does not prove a correct business outcome. The action must still pass deterministic business rules, operate on trusted data, respect permissions and controls, handle exceptions, and leave an auditable result.

An agent has not demonstrated enterprise capability because it produced the right answer in a controlled conversation. It must work against trusted operational data, real permissions, real business rules, real exceptions and real system constraints.

The smallest useful proof is therefore a governed loop that can:

detect a relevant signal;
retrieve the correct business context;
evaluate an action;
apply policy and authority;
execute or escalate through governed systems;
validate and record what actually happened;
measure the business outcome.

If the demonstration stops before execution, it has proved insight—not agency.

If execution cannot be validated against business rules and outcomes, it has proved automation—not enterprise agency.

Deborah Born: operational truth comes before intelligence

Enterprise context ultimately depends on whether operational systems reflect reality.

In transportation, that test is immediate.

As Deborah Born explains in AI in SAP TM — what’s real, an ETA model is useful only in proportion to the quality and reach of the carrier signals feeding it. An agent cannot manage a transportation exception if the freight order, execution status or carrier event is incomplete.

The same is true for freight charges. A model cannot reliably predict or challenge costs when the underlying rate structures cannot be explained by the people operating them.

For an SAP TM agent, meaningful context could include:

the transportation requirement and freight order;
route, stops and planned milestones;
carrier commitments and capacity;
telematics and execution events;
service-level obligations;
charge calculation and settlement status;
customer priority;
inventory and production consequences;
the financial cost of delay.

But access to all of that information does not automatically produce a good decision.

A late shipment may justify expediting for one customer and not for another. A cheaper carrier may create unacceptable service or compliance risk. A technically valid route change may damage a downstream warehouse plan.

The agent needs more than the shipment status. It needs the commercial and operational consequences surrounding it.

This is where the phrase “business context” becomes real.

AI built on execution data that does not reflect physical reality automates a fiction.

Before adding intelligence, establish operational truth.

Tobias Unger: semantic disagreement is organisational disagreement

When two functions define the same business object differently, the problem is rarely solved by adding another platform.

It is usually an unresolved organisational decision.

In The Limits of Language and the Power of Context, Tobias Unger’s Transformation Office examines why language alone cannot reproduce the conditions under which humans know what to do — and what it takes to carry meaning across people, process and technology. Applied to enterprise context, that perspective asks who owns definitions across organisational boundaries.

Consider a simple term such as “customer.”

Sales may mean the buying account. Finance may mean the legal entity being invoiced. Service may mean the installed-base owner. A regional organisation may use a parent hierarchy that differs from the global one.

All of those definitions can be technically available. The agent still needs to know which one governs the decision in front of it.

The semantic layer therefore requires more than a data dictionary. It requires:

named ownership;
an agreed decision process;
version-controlled definitions;
documented exceptions;
cross-functional governance;
adoption in the processes where decisions are made.

Technology exposes organisational seams. It does not repair them.

If leaders cannot agree what a customer, order, margin, delay or exception means, the context layer will preserve the disagreement with greater technical sophistication.

In this case, Company Memory can function as a type of ontology of what a term means in a given decision context. The value is that once the organisation settles that argument about what customer means, the answer is persistent, traceable, and available at inference time. It also operates at a different speed than the evolution of knowledge graphs.

The hard work remains managerial.

Robert Lienhard: better context raises the human standard

As machines become better at retrieving information and performing bounded tasks, human value moves elsewhere.

Robert Lienhard’s What Must Remain Human applies that question to talent attraction, but its implication is wider.

People will spend less time finding information, summarising records and coordinating routine hand-offs. They will spend more time defining intent, judging exceptions, challenging recommendations and owning consequences.

That requires different capabilities:

framing the right decision;
recognising when context is incomplete;
understanding competing business interests;
explaining why an exception matters;
challenging confident but weak machine output;
taking responsibility when no rule provides a complete answer.

An organisation cannot introduce agentic AI while leaving its roles, incentives and accountability unchanged.

If people are rewarded for processing transactions, they will defend the transaction. If they are accountable for outcomes, automation can create capacity for better judgment.

The question is therefore not simply which work AI removes.

It is which human contribution becomes more valuable once the keystrokes disappear.

What the different views reveal

Read together, these perspectives produce a more demanding definition of enterprise context.

An enterprise agent needs:

Trusted facts — data with known ownership, quality and lineage.
Agreed meaning — definitions that can be interpreted consistently, and contextual differences that are explicit rather than hidden.
Relevant relationships — the connections between customers, products, orders, contracts, risks, policies and outcomes.
Situational context — the information that matters to this decision, at this moment.
Governed authority — clear boundaries around what the agent may recommend, execute or escalate.
Human accountability — a named person who owns the policy, the exceptions and the consequences.
Measurable value — evidence that the decision improves revenue, cost, risk, service, working capital or another meaningful business outcome.

Remove trusted facts and the agent becomes unreliable.

Remove meaning and it becomes inconsistent.

Remove context and it becomes generic.

Remove authority and it remains an assistant.

Remove governance and it becomes dangerous.

Remove accountability and nobody owns the result.

Remove value and it becomes another technology programme.

A practical 90-day starting point

Do not begin by designing an enterprise-wide “AI brain.”

Begin with one consequential decision.

Days 1–30: Define the decision

Choose a process where delay, inconsistency or manual coordination has measurable economic impact.

Document:

the triggering signal;
the desired outcome;
the current decision path;
the people and systems involved;
the information used;
the exceptions;
the cost of delay or error.

Days 31–60: Build the minimum viable context

Identify the smallest set of governed facts, relationships and definitions needed to make that decision confidently.

Resolve disagreement before automating it.

Define what the agent may see, propose and execute. Establish thresholds for human approval and a named owner for every consequential action.

Days 61–90: Prove the operating loop

Build the smallest end-to-end version that can detect the signal, retrieve context, apply policy, act or escalate, record the result and measure the outcome.

Do not measure prompts, demonstrations or agents deployed.

Measure cycle time, exception reduction, service level, working capital, revenue protected, risk avoided or another business outcome that already matters.

The executive takeaway

Knowledge graphs, semantic layers and context layers are important. But they are not the strategy.

They are components of a larger management system that connects business intent to governed execution.

The decisive questions are therefore not:

Which context platform should we buy?
How many data sources can it connect?
How many agents can we deploy?

The decisive questions are:

Which decision must improve?
What does the agent need to know?
Who owns the meaning?
What is it authorised to do?
When must a person intervene?
Can every action be explained and reversed?
What measurable value will change?

The enterprise with the most data will not necessarily have the most capable agents.

The advantage will belong to the enterprise that can turn trusted information into relevant context, relevant context into a governed decision, and that decision into a measurable outcome.

That is not an AI layer.

It is an operating model.

Related sapperment reading

Editorial note: The perspectives above are an editorial synthesis of the authors’ published sapperment work and defined columns. They are not presented as new quotations from the individual authors.

sapperment is an independent publishing platform and is not affiliated with SAP SE. SAP is a registered trademark of SAP SE.