What context does an enterprise AI agent need beyond RAG?
Before a consequential action, the workflow should make current state, accountable ownership, requesting actor, delegated authority, applicable policy, temporal validity, provenance, preconditions, permitted actions, exception routing and completion evidence explicit—and enforce machine-decidable controls outside model reasoning where possible.
RAG solves a real problem—but a different one
The original 2020 retrieval-augmented generation paper combined a model's parametric memory with retrieved non-parametric memory for knowledge-intensive language tasks. The design addressed access to external knowledge and the ability to update that knowledge without relying only on model weights.
That is useful. An enterprise agent may need a policy document, product definition, incident history, customer record or technical runbook before it can reason well. But retrieving an incident procedure does not establish whether the service is healthy now, whether the requester may update the record, which policy version applies or which independent read-back proves that the requested state change happened.
Those are not merely more documents. They are part of the operating state and control boundary of the workflow.
Context now means several different things
The enterprise market is converging on broader business and process context, although vendors package it differently. Oracle describes entities, relationships, policies and workflows, including what can be done, under which conditions and with whose authority; its newly announced capabilities remain scheduled within the next 12 months. ARIS connects processes, people, systems, risks and controls. OpenAI and ServiceNow pair business context with workflow actions while applying existing rules and permissions, with several capabilities still planned. SAP's Agent Gateway makes a complementary boundary explicit: discovery does not itself grant permission to invoke an agent.
The pattern is real. The terminology is not settled. Separating four layers prevents context from becoming a synonym for everything in the prompt.
| Layer | Question | Examples |
|---|---|---|
| Knowledge | What does the organization know? | Documents, definitions, relationships, retrieved records |
| State | What is true now? | Task status, approval state, asset condition, freshness |
| Authority | What may this actor do? | Identity, delegated scope, policy, permitted action |
| Evidence and recovery | What proves success or requires escalation? | Receipts, validators, exception owner, verified outcome |
What standards and specifications already tell us
NIST's AI Risk Management Framework says intended purpose, deployment context, business use and relevant requirements should be understood and documented. Its MAP function also expects context to be revisited as capabilities, risks and impacts evolve.
NIST's October 2026 agent-identity post proposes an initial set of ten design tenets. They include initiator linkage, attenuated delegation, least privilege, separation of policy from model reasoning, deterministic access decisions and independent evidence. These are proposed tenets in a NIST blog, not a formal standard.
Other sources fill adjacent gaps. NIST Zero Trust supports resource-specific authorization based on current identity and environmental signals. W3C PROV formalizes provenance across entities, activities and agents. The live A2A development specification gives tasks explicit status and output artifacts and warns that messages are not a reliable delivery mechanism for critical information.
Together they support an engineering boundary: the model can reason over context, but the workflow must own the controls that determine whether an action is allowed and whether it completed.
The Ariftly Workflow Context Contract v1.0
Ariftly proposes a 12-field contract for one bounded workflow action. It is intentionally narrower than an enterprise context layer: it is the execution-time slice a workflow harness must resolve before an agent participates in a specific action.
This is a proposed engineering framework, not an empirically proven universal minimum. A regulated payment, clinical workflow or safety-critical industrial process may need additional fields. The point is not the number twelve; the point is that the fields are explicit and testable.
| Field | Question the workflow must answer |
|---|---|
| Workflow objective | What bounded outcome is this run attempting to achieve? |
| Current state | What execution-relevant facts are true now? |
| Accountable owner | Who owns the business outcome and unresolved decisions? |
| Requesting actor | Who or what initiated the task? |
| Delegated authority | What authority was delegated, by whom and for what scope? |
| Applicable policy | Which policy or rule set governs this action? |
| Effective date | When are the state, policy and authority valid? |
| Source provenance | Where did each material fact come from? |
| Preconditions | What must be true immediately before the action? |
| Permitted actions | Which actions, resources and parameters are authorized? |
| Exception route | Where does uncertainty, conflict or a failed control go? |
| Completion evidence | What observable evidence is required before completion? |
Four outcomes when context is incomplete
A workflow should not respond to every missing field by asking the model to do its best. The contract connects incomplete or invalid context to one of four operating outcomes.
| Outcome | Use when | Operating meaning |
|---|---|---|
| Permit | Context is current, authority is valid, preconditions pass and the action is in scope | The bounded action may proceed; this is not a claim that the whole workflow is safe or complete |
| Refresh | State, policy or authority may be stale | Reread the authoritative source before reasoning or acting |
| Escalate | Sources conflict, judgment is required or authority is exceeded | Route an evidence bundle to the accountable exception owner |
| Block | Identity or authority is missing, a precondition fails, scope is exceeded or evidence is absent | Do not execute or mark the action complete |
Why policy and authority should not live only in the prompt
An agent may need to see a policy to explain a decision. That does not mean the agent should be the component that grants itself permission. NIST's proposed agent-identity tenets explicitly separate policy from reasoning and recommend deterministic capabilities as the primary mechanism for access decisions.
If a workflow can test whether an approval exists, a policy version is current, a threshold was exceeded or a target resource matches an authorization grant, that check should occur outside the model response. The model may interpret ambiguity or prepare an action, but it should not convert uncertainty into its own permission.
MCP connectivity is not workflow authority. OpenAI's MCP documentation describes an open specification for connecting AI clients to external tools and data. A tool can be reachable while a particular business action remains unauthorized.
The evidence is directional, not proof of causality
The 2026 Process Context Study conducted by The Hackett Group with ARIS surveyed 200 respondents at large and multinational organizations. The underlying report says 86% selected that AI agents cannot be deployed reliably without process context, while 22% reported comprehensive real-time visibility across business operations.
Read those numbers narrowly. The study is sponsored, cross-sectional and self-reported; its public methodology is not detailed enough to treat the percentages as universal enterprise prevalence, and it cannot establish that process context causes better AI outcomes. ARIS's launch release also presents different headline percentages—82% and 21%—so this article uses the figures in the underlying report and flags the discrepancy rather than blending them.
The engineering case does not need a causal survey claim. A valid operational action depends on state, authority and acceptance conditions whether or not a survey measures them.
Ariftly View: from human-operated to AI-operated
A human-operated workflow often carries context informally. An experienced operator remembers which record is authoritative, knows which manager can approve an exception, recognizes that a policy changed last month and checks a second system before declaring the work complete.
AI assistance can retrieve information, compare records, draft next steps or prepare an exception. Bounded AI execution requires more: informal context must become explicit enough for the surrounding workflow to enforce. It needs a current-state read, a defined authority envelope, deterministic checks where possible, an exception owner and evidence of the result.
Progressively more AI-operated work should increase only where execution evidence supports it. More context does not itself grant more autonomy. Accountability remains with the people and organizations that define policy, own the workflow and handle consequential exceptions.
The intended customer value is practical: less repetitive interpretation, faster exception preparation, fewer false-success states, stronger evidence and more human attention for consequential decisions. These are outcomes to measure against a workflow baseline, not performance results claimed here.
How Ariftly would operationalize this workflow
Ariftly would begin with one bounded workflow and the people accountable for its outcome. In Record, the work is to capture the real inputs, systems, state transitions, decision owners, policies, exceptions and evidence people already use. That is where missing context becomes visible.
In Redesign, the Workflow Context Contract becomes an engineering boundary around each consequential action: which state must be refreshed, which authority must be checked, which rules are deterministic, what AI may prepare or execute, which cases route to people and what proves completion.
In Operate, the contract would need to resolve against actual systems and execution evidence rather than remain documentation. A changed policy, expired grant or failed precondition should alter workflow behavior.
Ariftly applies this workflow-first method to enterprise modernization and other complex operational work. Ariftly Forge organizes the work around Record, Redesign and Operate, while Forward-Deployed AI Engineering connects the method to the systems, policies and accountable teams inside a scoped workflow.
Across modernization work, the pattern is consistent: capture the real business and system context, make state and authority explicit, separate AI reasoning from deterministic controls, route consequential exceptions to people and verify the outcome before advancing the workflow.
Methodology and limitations
Research was rechecked through November 2, 2026. The framework starts with RAG's original scope; extracts context, accountability and response concepts from NIST AI RMF; uses NIST's proposed agent-identity tenets for delegation, least privilege, deterministic authorization and evidence; draws dynamic authorization principles from NIST Zero Trust and provenance concepts from W3C PROV; and uses A2A for task-state and artifact semantics. Oracle, ARIS, OpenAI/ServiceNow and SAP are implementation examples, not standards.
The 12 fields are an authored synthesis. They have not been validated as a universal minimum across industries or tested against customer production workflows. Provenance does not prove truth. Valid identity does not prove valid authority. Complete context does not prove correct model reasoning, and correct reasoning does not prove that a downstream action succeeded.
The contract does not replace source-system authorization, identity and access management, process modeling, data governance, legal or compliance analysis, model evaluation, runtime isolation, human accountability or domain-specific acceptance criteria.
Cite this research
Framework: Ariftly Workflow Context Contract v1.0. Version date and evidence cutoff: November 2, 2026.
Suggested citation: Ariftly. “The Enterprise Context Gap: Why AI Agents Need Workflow State, Not Just RAG.” Ariftly Insights, November 3, 2026, https://www.ariftly.io/insights/enterprise-agent-workflow-context.
The framework table, CSV and synthetic example are available under CC BY 4.0, excluding Ariftly trademarks and logo.