At Ai4 in Las Vegas this week, I attended two sessions that came together in a way I had not expected.
The first was a four-hour workshop on advanced Retrieval-Augmented Generation. It went far beyond the familiar “chunk, embed, retrieve, generate” pattern, covering hybrid retrieval, routing, adaptive chunking, indexing, reranking, guardrails, observability, and evaluation.
But the session that really caught my attention came later.
Keith Soura, CTO of Arch, presented a talk with a wonderfully precise title:
“RAG is a Flashlight. Your AI Agent Needs a Map. Graph Theory as an AI Agent’s Superpower.”
The premise was simple. RAG may give an AI system access to enormous amounts of information, but having an encyclopedia containing everything about the world does not tell you how to get from New York to Los Angeles. For that, you need a map: an origin, a destination, and a way to navigate the territory between them.
That points to an important distinction for enterprise AI:
RAG can provide the knowledge. An autonomous agent also needs a map.
Advanced RAG solves a real problem
Basic RAG is conceptually simple. Split documents into chunks, create embeddings, retrieve semantically similar information, and give that context to a language model.
In production, things quickly become more complicated.
The workshop demonstrated how dense and sparse retrieval can be combined, queries routed to different retrieval strategies, results reranked, and chunking adapted to different types of information. It also covered different indexing strategies and, importantly, systematic evaluation of retrieval quality.
Did we retrieve the right evidence? Did the model actually use it? Is the answer grounded? What does each stage cost in latency?
This is where enterprise RAG is heading. The challenge is no longer simply connecting an LLM to a vector database. It is designing a retrieval pipeline whose quality can be measured and continuously improved.
But better retrieval does not solve every problem.
Similarity is not a process model
Soura’s talk focused on regulated financial processes, particularly mortgage origination and alternative investments.
His starting point was that RAG is good at finding relevant context. But similarity does not tell an agent how a business process works.
Consider a mortgage.
Pull a credit report. Verify income. Calculate a debt-to-income ratio. Request documents. Recalculate eligibility. Trigger disclosures. Wait for dependencies. Possibly repeat steps when something changes.
Activities depend on facts, create new facts, and trigger other activities. There are branches, loops, deadlines, permissions, exceptions, and regulatory constraints.
The mortgage system described in the session contained around 1,800 registered activities, roughly 26,000 fact references, and about 5,400 activity-to-activity edges.
You can embed the regulations, operating procedures, and historical cases.
But an embedding does not inherently tell you that activity A must precede B, that B triggers C, that C is currently blocked because a required fact is missing, or that a certain transition is prohibited.
That is not primarily a semantic-search problem.
It is a graph problem.
The graph becomes the map
In Soura’s architecture, facts and activities form a living dependency graph.
Facts might include verified income, a credit score, a document status, or a calculated ratio. Activities consume facts and create new ones. Activities can also trigger other activities.
Once the domain is represented this way, decades of graph theory become available.
Graph algorithms can identify nodes that gate large parts of a process, find cycles, detect tightly connected clusters, and remove redundant paths.
The objective is not to give the agent the entire graph. It is to determine which part matters now.
In the mortgage example, roughly 5,400 relationships could be reduced to around 1,200 edges for high-speed reasoning.
Instead of stuffing an entire enterprise process into the context window, the agent gets the relevant section of the map.
Why this resonated with me
This was probably the part of the presentation I liked most, because the underlying engineering principle was very familiar to me.
I have successfully used essentially the same graph-oriented approach when implementing complex pricing systems in the reinsurance domain.
Reinsurance pricing can require a large number of calculations where the result of one calculation becomes the input to several others. Some calculations can only run once particular data is available. A change to an upstream value may invalidate downstream results and require part of the calculation chain to execute again. Multiple calculations may also share intermediate results.
Representing such a pricing system as a dependency graph makes the complexity much easier to manage.
Input data and intermediate results become facts or nodes. Calculations become transformations. Edges describe their dependencies.
Instead of constructing one enormous procedural calculation sequence, the graph describes how information flows through the pricing model.
Graph theory itself is obviously not new.
What I found fascinating in Soura’s presentation was applying the same engineering principle to AI agents.
The new element is putting a probabilistic reasoning engine on top of deterministic structure.
The language model can still interpret an unusual situation, understand natural language, explain a result, or decide how best to communicate.
But the possible routes through the underlying business system are supplied by the graph.
That is a very different role for the LLM.
The encyclopedia and the map
Soura’s analogy provides a useful architectural model.
RAG gives the agent the encyclopedia.
It retrieves the underwriting guideline, policy wording, previous case, operating procedure, contract clause, or technical documentation.
Advanced RAG increases the probability that the correct pages of that encyclopedia are found.
The graph gives the agent the map.
It describes how things are connected, where the process currently stands, which dependencies remain unresolved, and what actions can legitimately happen next.
You need both.
Without good retrieval, an agent may navigate the correct process using weak evidence.
Without the map, it may have excellent information and still take the wrong turn.
This distinction becomes much more important as we move from conversational AI toward autonomous agents.
A chatbot can generate an incorrect paragraph.
An agent can execute an incorrect action.
Once agents can move money, change policies, approve transactions, or trigger workflows, “probably correct” is no longer a sufficient operating model.
The graph knows about things that are not there
One particularly interesting limitation of embeddings is absence.
You cannot retrieve the embedding of a document that should exist but does not.
Soura illustrated this using tax documents in alternative investments.
If a particular tax statement has not arrived, there is nothing for semantic search to find. But a graph can encode the surrounding relationships and determine that the document is expected because equivalent positions have already produced theirs.
The absence itself becomes information.
Graphs can also carry provenance. In the investment example, relationships were connected back to source documents. An answer such as exposure to a particular company could therefore be represented as a path through the graph, with the individual steps remaining traceable to their underlying evidence.
For regulated enterprise applications, that is much more useful than simply returning a confidence score.
Deterministic rails for probabilistic reasoning
This is why I would not simply call the concept “Graph RAG.”
Embeddings can certainly exist on the graph. Documents can be attached to nodes, and semantic retrieval can provide supporting information.
But the embedding should not be the steering layer.
The graph determines what is reachable.
The LLM reasons within those rails.
Toward the end of the session, Soura described this as putting a probabilistic reasoning system on top of deterministic rails. Facts remain grounded in identifiable sources, while the actions available to the agent come from defined graph transitions.
This also suggests a different approach to agent governance.
Today we often give an agent broad capabilities and then monitor it with guardrails, validation, approval mechanisms, and observability.
The graph offers another principle:
Do not only detect the wrong turn. Make sure the wrong road is not available in the first place.
Of course, this does not make an agent bullet-proof.
A deterministic map can still be wrong. Missing dependencies, incorrect business rules, bad source data, or outdated regulations can make an agent reliably follow the wrong route.
The map itself therefore becomes a governance artifact. It needs provenance, versioning, testing, and auditability.
This shifts the trust question from simply:
Can we trust the model?
to:
Can we trust the map the model is navigating?
For enterprise technology, I find the second question much more actionable.
From better retrieval to safer autonomy
My takeaway from the two Ai4 sessions is not that graph theory replaces RAG.
They solve different problems.
Advanced RAG improves the quality of evidence available to an agent.
Graph-based context improves the quality of navigation available to an agent.
A strong enterprise architecture can combine both: use sophisticated retrieval to find trustworthy evidence, model operational facts and dependencies as a graph, reduce that graph to the relevant state, and then let the LLM reason within that environment.
The model can interpret language, explain results, and choose among legitimate alternatives.
But it should not invent the roads.
Perhaps the next major advance in enterprise AI will therefore not come from ever larger context windows.
We may already have enough flashlights.
What our agents increasingly need are trustworthy maps.