Context Graphs for Explainable, Decision-Aware AI Agents

How do you give an agent the knowledge it needs to solve a particular problem? Language, reasoning, and creativity do not by themselves supply the facts and context of an organization. Zaid Zaim opens with this gap: knowledge graphs can connect agents to relevant information and tools, enriching what they have available when a task arrives.

Memory adds another dimension: an agent needs both the current conversation and context that persists beyond it. The talk distinguishes three complementary kinds of memory.

A graph represents this information through nodes and relationships, making connections between different kinds of data explicit. The representation matters because useful context often sits in those connections, rather than in an isolated fact.

Context graphs remain part of context engineering, but broaden what the agent receives. Alongside knowledge, tools, and content, they supply rules and policies that help determine whether an action is appropriate. Knowing what an agent can do is only part of the problem; a decision also needs an explanation of why it should do it.

An organization already contains a network of relationships spanning finance, products, suppliers, and other functions. Those relationships become consequential when the question changes from retrieving a fact to deciding something—for example, whether someone is eligible to receive a particular amount of money. The financial example is a decision question: relevant knowledge has to meet the rules governing eligibility.

The memory graph brings these requirements together. Short-term memory captures conversations and state history; long-term memory supplies the broader picture of people and organizations; reasoning connects a proposed task to the policies and rules that justify it. This makes the basis for a decision part of the context available to the agent.

The agentic GraphRAG path begins with a user query:

1. The agent checks whether the requested knowledge is available in its knowledge source.
2. If it is missing, the agent turns to the graph database.
3. A tool such as Text to Cypher translates natural language into Cypher, the database query language.
4. Graph traversal retrieves relevant content for the response.

The intended benefit is a more reliable, better-grounded answer. This walkthrough describes the retrieval mechanism and its goal; it does not establish a measured reliability improvement.

Retrieval leaves a harder question: what happens when an agent reaches a circumstance its instructions did not anticipate? Andreas Kollegger uses OpenClaw and similar autonomous agents to make the problem concrete. Give an agent a credit card, access to an Amazon account, and a goal of keeping the refrigerator stocked with Red Bull. When supplies run low, ordering more satisfies the instruction. But what if rent is coming due and the purchase would leave too little money to pay it?

You can add a prompt instruction for that conflict, then another for the next one. The broader problem is how the agent should make decisions when a new conflict appears. A graph and memory provide inputs, but the agent still needs a process for using them.

The difficulty grows when one autonomous agent becomes several specialists. They must collaborate and remain aware of both their own responsibilities and one another’s activity. Kollegger proposes making familiar human decision practices explicit as an agent workflow. It can be implemented in LangGraph or expressed through skills; the essential work is transferring implicit judgment into instructions an agent can follow.

The workflow starts with framing. An agent has followed some sequence of reasoning and actions, reached uncertainty, and now needs to enter a deliberate decision subprocess instead of simply choosing the next action. Kollegger suggests starting with how the agent arrived here, even though the slide lists the objective first.

The frame needs three parts:

• Objective: What should this decision resolve? It might be a request to increase a loan or a question about ordering more Red Bull.
• Causality: What prior reasoning, actions, or events made this objective relevant now?
• Environment: In what setting will the decision operate—purchasing, finance, medical guidance, or something else?

The environment changes the stakes. A purchasing question and a medical decision involving a life cannot use the same assumptions about acceptable error. Humans often infer that distinction from experience; the agent needs it supplied explicitly.

Local framing feeds into global context. First, look for what happened in comparable situations: prior decisions can support consistency. Then bring in the business’s hard and soft rules. These may live in formal business-process descriptions, but they may also appear as informal guidance in Slack channels or Google Docs.

Precedent is evidence, not automatic permission. A previous decision may remain appropriate, or a changed rule may justify overruling it. The agent needs both the earlier choice and the rules that apply now before it begins analyzing alternatives. Otherwise, consistency can become repetition of a decision whose justification no longer holds.

With the local frame and global guidance in place, the agent can perform risk–value analysis. Kollegger argues that risk deserves much of the attention, with greater scrutiny for more serious decisions. He calls the first check reference class validation: establish what matters to the affected parties and whether the general assumptions fit their particular circumstances.

In Kollegger’s hypothetical medical example, a drug appropriate for 99% of a population could be fatal for the remaining 1%. These are illustrative proportions, not clinical measurements. The point is that a broadly appropriate recommendation cannot resolve the individual case until the relevant subgroup is known. An agent must make that distinction explicit rather than treating what usually works as sufficient justification.

Two further questions shape the risk assessment:

• Reversibility: Can the action be undone if it turns out to be wrong?
• Cost of error: What happens if the decision fails? A life at stake and an empty shelf in the refrigerator carry very different consequences.

An easily reversible mistake permits a different decision process from one whose consequences cannot be recovered.

The value side also requires an explicit objective. Should the purchasing agent maximize availability of Red Bull, preserve the budget, or protect savings for a vacation or a house? Is it maximizing a benefit or minimizing a cost? Without that direction, an agent may substitute its general knowledge of what is usually appropriate for the particulars of the user’s goals.

The output of analysis is a proposal, not an action. In Kollegger’s preferred arrangement, a focused analysis agent produces alternatives with their pros and cons. It hands those alternatives to another agent responsible for deciding whether it can act. This separates evaluating a choice from exercising authority.

The receiving agent checks its authority. If it can act, it can rank the options and take the selected action. If it lacks certainty or authority, it escalates to another actor: a human or an agent with higher privileges.

Oversight is a subprocess in the workflow. Declining to act locally is a valid branch, allowing someone with the necessary judgment or authority to make the call.

The workflow can end with a decision or with a deferral because information or certainty is insufficient. When a decision is made, record the process: what was considered, what was not considered, the decision itself, and the actions taken. Saving these connected records in the graph supplies a basis for tracing and accountability.

For the Red Bull scenario, consider a deferred purchase while the effect on rent remains unresolved. A compact Cypher representation can distinguish a considered option from an executed action:

CREATE (d:Decision {
  id: 'restock-red-bull-001',
  objective: 'Keep the refrigerator stocked with Red Bull',
  status: 'deferred',
  reason: 'Effect of the purchase on rent funds is unresolved',
  considered: ['Restocking need', 'Upcoming rent'],
  notConsidered: ['Alternative suppliers'],
  actionsTaken: []
})
CREATE (o:Option {
  id: 'order-red-bull-001',
  description: 'Order more Red Bull',
  status: 'proposed'
})
CREATE (d)-[:CONSIDERED]->(o)
RETURN d, o;

This example records a deferral, not a purchase. The option remains proposed, and actionsTaken is empty. Keeping those states distinct prevents a later reader of the graph from mistaking deliberation for execution.

Future agents can retrieve that record as precedent. This is the self-learning loop described in the talk: experience becomes available to the next decision process through graph memory. No model-training step is specified; the improvement mechanism is reuse of recorded decisions and their context.

The completed workflow connects framing, global guidance, risk–value assessment, authorized action, oversight, and outcome recording. Kollegger suggests implementing it in LangGraph, ADK, or skills. The orchestration vehicle can vary while preserving those responsibilities and the paths that allow an agent to defer or seek oversight.

The framework is general; the decision criteria are domain-specific. Each step needs concrete definitions of relevant context, acceptable risk, applicable policy, and authority. Purchasing and medical guidance can share a workflow without sharing those definitions. Kollegger closes by inviting additional domains for the speakers’ growing catalog of examples: the work lies in making each domain’s implicit judgment explicit enough for an agent to use.