The Missing Layer in Agentic AI

Most current agent systems treat context primarily as conversation history, retrieved documents, or vector similarity results. This approach works reasonably well for conversational tasks, but operational systems require a fundamentally different type of context management.

In real environments, decisions depend not only on retrieved information, but also on:

• entity relationships,
• organizational structure,
• temporal events,
• ownership chains, 
• previous decisions,
• active constraints,
• and continuously evolving operational state [1]. 

A customer is not just a document. A company is not just a text chunk. A regulatory event is not simply another retrieval result. Operational systems require a continuously evolving state model. This is where the distinction between memory and operational context becomes critical.

Memory stores information. Operational context maintains system state.

In practice, this means the system must continuously maintain and update structures such as entities, relationships, temporal event chains, policy bindings, and execution history. This is one of the reasons why graph-based approaches are becoming increasingly important in agent systems. 

A graph is not only useful for retrieval. It provides a runtime representation of operational state. Instead of treating context as isolated text fragments, the system can reason over connected entities, evolving relationships, temporal dependencies, and contextual propagation paths. This changes the role of the graph entirely. The graph stops being a storage layer and becomes:

• contextual memory,
• operational state representation,

• and execution context for decision systems.

  

  As agent systems move toward autonomous operations, this distinction becomes increasingly important. Because autonomous execution requires not only information retrieval, but also continuous contextual state management[4].

Imagine a dispute agent handling a chargeback request. The customer claims that a transaction was fraudulent. The transaction was made from a trusted device. The merchant has a low risk score. On the surface, the case looks simple. But the transaction occurred shortly after an unusual password reset, the customer had a recent device change, and the bank’s fraud policy requires escalation when multiple weak signals appear together within a short time window.

At this point, the policy cannot remain a PDF. It must become part of the reasoning substrate.

In an operational agent system, policies should not be retrieved only as text after the LLM has already formed an answer. They must actively constrain execution: blocking certain actions, triggering escalations, changing approval paths, requiring additional evidence, or preventing automated resolution. This idea is closely related to earlier policy-based planning approaches, where execution is continuously shaped by constraints, goals, and environmental conditions rather than isolated task completion logic [6].

This is where graph-based operational context becomes critical.

The graph represents the dispute state: customer, account, transaction, merchant, device, password reset event, fraud indicators, prior decisions, policy rules, and execution history. Policies are then connected to this graph as executable constraints, not as isolated documents. In many ways, this resembles the evolution of multi-agent execution environments, where intelligent entities coordinate through a continuously shared operational state rather than isolated message exchanges [4].

A reasoning layer can operate over this graph using rule-based or logic-based mechanisms derived from earlier logic programming and deductive database systems [8]. For example, a Datalog-like rule can express that a dispute must be escalated if a disputed transaction follows a password reset, involves a new device, and exceeds a risk threshold — an approach conceptually aligned with classical deductive reasoning systems and database logic engines [9].

The LLM may interpret the case, explain the decision, and interact with users, but the policy condition itself is evaluated deterministically over the graph.

In this architecture, the graph engine becomes the operational substrate, while the reasoning layer evaluates constraints, obligations, permissions, and dependencies over the current state. This separation between probabilistic reasoning and constrained execution also echoes earlier BDI-based agent models, where intelligent behavior emerges not only from goals, but also from continuously maintained beliefs, intentions, obligations, and execution constraints (Rao & Georgeff, 1995).

The key shift 

This allows an autonomous dispute agent to reason not only over what happened, but also over what is allowed, required, blocked, or escalated at each step of execution.

Once context becomes a continuously evolving operational state and policies become executable constraints, the next challenge is decision execution itself.

At this stage, the problem is no longer retrieval. It becomes runtime decision control. Most current agent systems still operate as action-generation systems: retrieve context, reason over it, generate an action, execute the result. But operational systems require an additional layer between reasoning and execution: a constrained decision pipeline.

This distinction is critical because operational environments rarely contain a single valid action. Instead, they contain:

• feasible actions,
• forbidden actions,
• escalated actions,
• delayed actions,
• and conditionally allowed actions.

The role of the system is therefore not only to generate actions, but to continuously filter and validate them under runtime constraints. A simplified pipeline increasingly looks like this: 

This changes the role of several components in the stack. The graph is no longer used only for retrieval. It becomes the runtime operational state of the system. 

Policies are no longer static documentation. They become executable runtime constraints evaluated during decision generation. The planner is no longer simply sequencing tasks. It becomes responsible for generating operationally feasible actions under active constraints.

This distinction is important because many operational failures do not originate from missing information. They originate from invalid action selection under changing conditions.

For example:

• an action may violate an authority boundary,
• conflict with an active compliance rule,
• trigger an invalid process sequence,
• or create downstream operational risk.

In these cases, the problem is not intelligence failure. It is a constraint failure. This is why constrained planning becomes increasingly important in autonomous systems.

Instead of directly executing generated actions, the system must:

• evaluate feasibility,
• prune invalid paths,
• apply runtime constraints,
• detect conflicts,
• and generate alternative execution paths when necessary.

Conceptually, this brings modern agent systems closer to classical planning systems than traditional conversational AI architectures.

Approaches such as:

• GraphPlan,
• constraint satisfaction systems,
• heuristic search,
• A* variants,
• and dynamic replanning algorithms

become relevant again once systems operate under continuously changing runtime conditions.

However, unlike classical planners, modern operational systems also contain probabilistic semantic interpretation, unstructured inputs, evolving graph context, and dynamically changing policies.

As a result, the emerging architecture is neither purely symbolic nor purely probabilistic. It becomes a hybrid execution model where LLMs interpret, graphs maintain operational state, constraints define execution boundaries, and planners generate feasible actions within those boundaries.

This separation is important because it allows autonomous systems to remain flexible without losing operational control. The goal is not to eliminate probabilistic intelligence.

The goal is to prevent probabilistic reasoning from directly controlling operational execution without deterministic validation layers around it.

Once operational context, executable constraints, and constrained planning become part of the runtime itself, autonomous execution stops being a simple orchestration problem. The system continuously operates on a changing operational state: entities evolve, relationships change, constraints activate or expire, and execution feasibility shifts over time.

Under these conditions, execution can no longer depend solely on generated outputs. The system must continuously reevaluate context, validate constraints, adapt plans, and maintain operational consistency across changing conditions.

This becomes even more critical as agent systems move beyond short-lived workflows toward long-running, goal-driven operations. In these environments, goals persist, multiple agents interact, organizational boundaries matter, and execution paths evolve dynamically during runtime.

As a result, planning stops being a one-time task and becomes a continuous operational process. This is where graph-based operational state, executable policies, and constraint-aware planning start converging into a new runtime architecture for autonomous systems.

And over time, this architecture will likely introduce a new generation of operational artifacts:

• persistent goals inspired by goal-oriented requirement engineering approaches such as KAOS [10],
• executable organizational roles and responsibilities similar to Gaia’s role-oriented organizational modeling for multi-agent systems [11],
• adaptive coordination structures resembling organizational MAS approaches such as MOISE+ [12],
•  and runtime organizational patterns for long-horizon multi-agent systems explored in organizational logic and adaptive multi-organizational system research [13][14].

The next generation of enterprise AI systems may therefore be defined not by how many actions they can generate, but by how reliably they can sustain coordinated goal-oriented behavior under continuously changing constraints.

1. Hogan, A., Blomqvist, E., Cochez, M., et al. Knowledge Graphs. ACM Computing Surveys, 2021.

2. Edge, D., et al. From Local to Global: A GraphRAG Approach to Query-Focused Summarization. arXiv, 2024.

3. Nii, H. P.The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures. AI Magazine, 1986.

4. Wooldridge, M. An Introduction to MultiAgent Systems. Wiley, 2009.

5. Ferber, J. Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence. Addison-Wesley, 1999.

6. Myers, K. L. Towards a Framework for Continuous Planning and Execution. AAAI, 1999.

7. Rao, A. S., Georgeff, M. P. BDI Agents: From Theory to Practice. ICMAS, 1995.

8. Ceri, S., Gottlob, G., Tanca, L. Logic Programming and Databases. Springer, 1990.

9. Abiteboul, S., Hull, R., Vianu, V. Foundations of Databases. Addison-Wesley, 1995.

[10].  van Lamsweerde, A. (2001). Goal-Oriented Requirements Engineering: A Guided Tour.

[11] Wooldridge, M., Jennings, N. R., & Kinny, D. (2000). The Gaia Methodology for Agent-Oriented Analysis and Design.

[12] Hannoun, M., Sichman, J. S., Boissier, O., & Sayettat, C. (2000). MOISE: An Organizational Model for Multi-Agent Systems.

[14] Dignum, V., & Dignum, F. (2018). The Role of Organizational Models in Agent Systems.

[15] Tamersoy, M., Ekinci, E. E., Erdur, R. C., & Dikenelli, O. (2017). A Requirements Model for Adaptive Multi-Organizational Systems. SASO 2017.