Dev.to Security 🔐 Cybersecurity 👁 0 📖 4 min read

Why Enterprise AI Agents Need Workflow State, Not Just RAG

The phrase “agent context” now covers several architectural problems that should not be collapsed into one prompt. At the knowledge layer, an agent needs relevant enterprise information: documents, definitions, records

Why Enterprise AI Agents Need Workflow State, Not Just RAG

Ariftly Workflow Context Contract showing an enterprise operator at a controlled execution boundary

The phrase “agent context” now covers several architectural problems that should not be collapsed into one prompt.

At the knowledge layer, an agent needs relevant enterprise information: documents, definitions, records and relationships. RAG, semantic search and knowledge graphs can help supply that material.

At the state layer, the agent needs to know what is true now. A workflow may depend on an approval that was revoked thirty seconds ago, an incident that changed status, a payment whose balance moved or a deployment whose health check failed. Historical retrieval is not a substitute for current state.

At the authority layer, the workflow must know who initiated the task, which rights were delegated, what policy applies and which specific actions are allowed. A tool being visible or technically callable does not establish that business authority. SAP’s October 2026 Agent Gateway architecture makes this distinction explicit: discovery does not itself grant permission.

At the evidence layer, a workflow needs to know what will prove completion and where the case goes when it cannot proceed. A model saying “done” is not equivalent to an independently observed downstream state.

These four layers are the basis for the Ariftly Workflow Context Contract v1.0.

The proposed contract contains 12 fields:

  1. workflow objective;
  2. current state;
  3. accountable owner;
  4. requesting actor;
  5. delegated authority;
  6. applicable policy;
  7. effective date;
  8. source provenance;
  9. preconditions;
  10. permitted actions;
  11. exception route;
  12. completion evidence.

The fields are deliberately attached to a bounded action, not to an agent brand or general-purpose memory store.

That action-level scope matters. Consider a synthetic incident workflow. An agent may be allowed to prepare a resolution note when the service appears healthy. That does not automatically mean it may change the incident to resolved. Before the state-changing action, the workflow can reread service health, verify that no blocking child incident remains open, check the requestor’s task-scoped grant, resolve the current incident policy and verify that incident.update is inside the permitted action set.

If any condition is stale, the correct response is not necessarily refusal. The contract uses four operational outcomes.

Permit means the required context is present and current, preconditions pass and the proposed action is inside the defined authority envelope.

Refresh means the field exists but has exceeded its freshness or effective-date window. The workflow rereads the authoritative source and reevaluates.

Escalate means context conflicts or the decision requires accountable judgment. The system sends an evidence bundle to the named exception route instead of asking the model to invent a policy resolution.

Block means a required control is missing or failed: no attributable requester, expired delegation, failed mandatory precondition, out-of-scope action or an attempt to claim completion without required evidence.

The contract also distinguishes model-visible context from independently enforced context.

A model may need to read an authorization scope to explain why an action is unavailable. It still should not be the component that expands that scope. A model may interpret a policy, but a machine-decidable policy condition should be evaluated by deterministic software where possible.

This separation is directly aligned with NIST’s October 2026 proposed design tenets for agent identity management. NIST recommends architectural separation of policy from reasoning and deterministic access capabilities as the primary mechanism for agentic authorization. NIST also proposes linking agents to their task initiators, attenuating delegated rights, defining human-review triggers and preserving immutable evidence.

Older standards reinforce other parts of the contract. NIST AI RMF asks organizations to establish intended purpose, deployment context, business use and responsibilities, and to maintain response/override mechanisms. NIST Zero Trust Architecture evaluates access against current identity and environmental signals instead of implicit trust. W3C PROV supplies a formal way to represent provenance across entities, activities and agents. The current A2A specification gives task state and output artifacts explicit protocol semantics.

None of those sources mandates the exact 12-field Ariftly contract. The framework is a synthesis across them.

Current vendors are also converging on adjacent ideas. Oracle’s October 27 announcement describes entities, relationships, policies and workflows, including what can be done, under which conditions and with whose authority; Oracle states the new AI Data Platform capabilities will become available within the next 12 months. ARIS describes process context across processes, roles, systems, rules, risks and controls. OpenAI and ServiceNow connect business context with workflow actions and existing rules and permissions. Lenovo Press published a detailed enterprise context layer reference architecture on October 29 that includes current state, workflow status, user authority, effective dates, provenance and permitted actions.

That last source is an important originality check. The broad idea “agents need more than RAG” is already in the market. The contribution of the Workflow Context Contract is narrower: a small execution-time record, a field-level failure behavior and a boundary between reasoning and enforcement.

The framework has limitations. It has not been validated as a universal minimum, and regulated or safety-critical domains will need additional fields. Provenance does not prove truth. Valid identity does not prove authority. Complete context does not prove correct model reasoning. And correct reasoning still does not prove that a downstream action succeeded.

That is why completion evidence remains a separate field.

For enterprise teams, a practical first exercise is simple: choose one consequential workflow action and attempt to populate all 12 fields from real systems and owners. The fields that cannot be resolved reliably are the context-engineering backlog to address before increasing execution authority.

Read the complete research article and download the Ariftly Workflow Context Contract v1.0: https://www.ariftly.io/insights/enterprise-agent-workflow-context

Disclosure: This adaptation was prepared by Ariftly with AI-assisted research and editing, then reviewed against the cited sources and Ariftly’s public messaging boundaries.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.