Better Models Won't Fix the Enterprise: Why Context Must Come Before Autonomy
Most enterprise AI programmes begin with a model question. The question that decides whether the initiative becomes useful and trusted is what the system is allowed to know, decide and do — and how anyone will prove it acted appropriately.
Written as at 26 September 2026. It reflects sources, products, standards and regulation at that date; later developments may change the analysis.
enterprise-aiagentic-aiai-governanceenterprise-architectureletters
Most enterprise AI programmes begin with a model question: which model should we use?
It is understandable. Models are visible, fast-moving and easy to compare. But it is rarely the question that determines whether an AI initiative becomes useful, trusted and scalable.
The harder question is this: what is this system allowed to know, decide and do — and how will we prove it acted appropriately?
That is not a model question. It is an enterprise-context question.
A language model can generate an answer. An enterprise system must establish whether an answer is grounded, permitted, current and actionable.
At a glance
- A capable model without organisational context can produce plausible but unsafe or irrelevant work.
- An enterprise-ready agent needs more than retrieval: it needs bounded authority, evidence, identity and observable outcomes.
- Start with one governed decision or workflow, not a general-purpose autonomous assistant.
The gap between impressive demonstrations and dependable work
An AI demonstration can look convincing with a carefully prepared prompt, a small set of documents and a helpful human nearby. Enterprise work is different. The system must operate across changing policies, incomplete data, multiple systems of record, different access rights and real accountability.
Consider a procurement assistant. It may summarise supplier proposals beautifully. But should it see every proposal? Which policy version should it use? Can it recommend an exception? Can it send a supplier message? Who is accountable when a restricted document is exposed, or a recommendation rests on an obsolete rule?
Those questions are often left to “implementation”. They are the implementation.
Context is more than a knowledge base
When people say an agent needs context, they often mean retrieval-augmented generation: provide relevant documents at the moment of asking. That is valuable, but insufficient.
In an enterprise, context has at least five parts:
- Meaning — what the data, process and terms mean in this domain.
- Authority — who may access, approve, delegate or act.
- Time — which policy, version, status and event sequence applies now.
- Evidence — the sources, reasoning trace and decision record needed to justify an outcome.
- Outcome — the measurable business result, and the feedback that shows whether the action helped.
If any of these is missing, the system may still sound intelligent. It simply cannot be trusted to operate beyond a narrow, supervised task.
This is why a perfectly fluent answer can be the wrong answer. It might reflect a superseded policy, assume authority the user does not have, or combine information that should never have been combined.
The enterprise agent is a governed participant, not a clever interface
The right mental model is not “chatbot connected to data”. It is a governed participant in a socio-technical system.
That participant should have a distinct identity, least-privilege access, explicit tools, scoped delegation and a record of material actions. It needs an escalation path when confidence, authority or evidence is inadequate. It should not silently convert uncertainty into action.
This view aligns with the direction of established guidance. NIST’s AI Risk Management Framework describes a structured approach to governing and managing AI risk, while its Generative AI Profile addresses risks specific to generative systems. OWASP’s agentic guidance similarly treats tool use, goal integrity and action boundaries as security concerns rather than simply prompt-design concerns.
The implication is practical: evaluation cannot stop at answer quality. We must also test whether the agent accessed the right information, obeyed the right boundary, cited the right evidence and achieved the intended outcome without creating an unacceptable control failure.
A simple design test
For every proposed agent, I suggest a four-part design test.
| Question | What a credible answer includes |
|---|---|
| Context — what does it need to understand? | Domain vocabulary, current state, source quality and policy context. |
| Authority — what may it do? | Identity, least privilege, delegated limits, approvals and escalation. |
| Evidence — how can its work be checked? | Source references, tool and action logs, versioning and evaluation results. |
| Outcome — why does it exist? | A measurable decision, workflow or service result; an owner and a feedback loop. |
The four questions are the test. The mechanisms in the figure are what an organisation builds to pass it: a Context Contract for what may be known, authority that attenuates as it is delegated, a decision record produced by the act of deciding rather than reconstructed afterwards, and flow mining to show whether the real path matched the intended one.
If the team cannot describe those four elements in plain language, it is too early to grant autonomy. The answer is not necessarily to cancel the use case. It may be to narrow it: read-only research before recommendation; recommendation before workflow initiation; workflow initiation before any external commitment.
That staged approach preserves learning while avoiding the common mistake of treating autonomy as a binary feature.
Start with a bounded decision, not an enterprise-wide assistant
The most promising early agents are not the ones asked to “help everyone”. They are the ones that make a specific, repeatable decision or work step safer, faster or more visible.
Examples include:
- assembling evidence for a security exception review, while leaving approval with the accountable owner;
- explaining why a customer case was routed to a particular team, with cited policy and case data;
- preparing a change-impact assessment that names the systems, controls and owners it relied on;
- monitoring a defined operational signal and escalating when a pre-agreed threshold is met.
Each has a purpose, a boundary and a way to measure whether it works. More importantly, each builds the architecture and governance muscle that broader capability will need later.
The strategic question
It is not “how autonomous can we be?” It is “where does bounded agency create genuine value, and what must be true for it to be trustworthy?”
The organisations that answer this well will not merely deploy more AI. They will build an operating capability: shared organisational context, explicit authority, evidence-producing systems and measurable outcomes.
That is the central argument of my forthcoming book, The Contextual Agentic Enterprise. The next generation of enterprise AI will not be defined only by better reasoning. It will be defined by the quality of the context, controls and accountability around that reasoning.
Where has your organisation found that the real barrier to AI value was not the model, but the missing context, authority or evidence around it?
References
- NIST (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Released 26 January 2023. https://www.nist.gov/itl/ai-risk-management-framework
- NIST (2024) AI RMF Generative Artificial Intelligence Profile. 26 July 2024. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence-profile
- OWASP GenAI Security Project, Agentic AI Threats and Mitigations. https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
- OWASP GenAI Security Project (2025) Securing Agentic Applications Guide 1.0. 27 July 2025. https://genai.owasp.org/resource/securing-agentic-applications-guide-1-0/
- Karimi, H. (forthcoming) The Contextual Agentic Enterprise, Preface and Chapter 1.
Related
Six Frameworks Answer the Question. None of Them Ask Yours.
TOGAF, COBIT, ITIL, SAFe, programme management and enterprise risk each answer a real question about the enterprise. So do the AI management standards, and so do the vendor agent platforms. None of them answers the one that decides whether an agent should have acted.
From Assistance to Agency: Why Enterprise AI Creates a New Architectural Problem
Letting a service desk assistant reset MFA is not phase two of the same programme. Once an agent can change state, the question becomes what it may change, and on whose authority.
A Model Can Recommend an Action. It Does Not Acquire Authority to Perform It
Directors ask whether their AI is safe. The better question is on whose authority it acts, because accuracy, confidence and technical access are not a delegation.