If you're building agents right now, you've probably hit the wall.
Your agent can reason. It can plan. It can call tools, write code, analyze data, and hold a conversation. The models are genuinely impressive. But the second your agent needs to pull the right context from a large, messy, real-world body of information, everything falls apart.
It retrieves the wrong things. It misses connections that seem obvious in hindsight. It hallucinates because the context it got was close but not actually what it needed.
I've spent the last several months building and running a system that solves this problem. Not in theory. In daily practice, across my entire life and work. And the more I use it, the more convinced I am that the bottleneck for useful agents was never model intelligence.
It was always context.
The Retrieval Problem Nobody Talks About
Most agent systems today rely on some version of the same retrieval pattern: chunk your documents, embed them into vectors, retrieve the top-k most similar chunks, and stuff them into the prompt. This is what people call RAG, retrieval-augmented generation. And it works reasonably well for simple lookups.
But agents don't do simple lookups.
An agent managing a project needs to reason across people, decisions, timelines, dependencies, and communications. An agent doing research needs to connect findings across papers, conversations, and prior analysis. An agent helping you run your life needs to understand that a calendar event from last Tuesday, an email from three weeks ago, and a decision you made six months ago are all connected even though they share zero keywords and sit in completely different semantic neighborhoods.
Vector similarity cannot do this. It treats every chunk as an isolated point in embedding space. There is no concept of relationships, structure, or connection between pieces of information. Two chunks can be highly related through three degrees of separation and vector search will never know.
I ran an empirical comparison on my own data. Semantic search hit 95.6% precision on conceptual queries compared to 40% for keyword matching. But both approaches completely failed on multi-hop relationship queries. The answer wasn't in any single chunk. It lived in the connections between them.
That's the gap. And that's where graph RAG changes everything.
The Three-Layer Stack
After months of research, building, and iteration, I've converged on a retrieval architecture with three layers. Each one catches what the previous one misses.
Layer 1: Hybrid Search
Lexical matching and semantic similarity running in parallel, fused through reciprocal rank fusion with k=60 (directly from the Cormack et al. SIGIR paper). BM25 for exact keyword hits via PostgreSQL full-text search. Vector search for conceptual similarity. RRF to blend the results intelligently.
The fusion formula: 0.35 * normalizedRRF + 0.65 * directSimilarity, then multiplied by temporal decay, graph boost, and feedback signals across a 9-stage pipeline.
This is becoming standard in production systems. Elasticsearch, Azure AI Search, Weaviate, and others all support it natively now. If your agents aren't doing hybrid search, they're already behind. It's table stakes.
But hybrid search alone still treats every piece of information as isolated. It finds better individual results. It doesn't find relationships.
Layer 2: Knowledge Graph with Typed Edges
This is the part most people building with AI are sleeping on.
When your data lives in a knowledge graph with typed relationships, you can traverse it. Not just "these two things are related." Actual named edges: depends_on, authored_by, member_of, used_in, content_ref.
A person authored a decision. That decision blocked a project. That project depends on a service. That service was referenced in an email thread from two weeks ago.
No embedding model will surface that chain. Vector similarity measures how close two pieces of text are in meaning. It has zero concept of structural or causal relationships between entities. You need edges.
The research backs this up. Microsoft's GraphRAG demonstrated that graph-structured retrieval outperforms flat vector search for complex queries, especially when the answer requires synthesizing information across multiple sources. HippoRAG showed that graph priors like edge proximity and centrality scoring significantly improve retrieval relevance. LightRAG proved you can do incremental graph indexing efficiently. KG2RAG from NAACL 2025 formalized the seed-expand-organize pipeline that makes graph context compilation practical.
I synthesized these patterns into a working system. The key insight is that scoring weights should adapt based on what the query actually needs. My hybrid query planner classifies each query and shifts weights accordingly:
- Relationship queries ("how is X connected to Y"): graph=1.05, semantic=0.45, lexical=0.35
- Synthesis queries ("summarize what I know about X"): graph=0.80, semantic=1.00, lexical=0.40
- Exact queries ("find the entity named X"): graph=0.40, semantic=0.30, lexical=1.20
- General queries: graph=0.75, semantic=0.75, lexical=0.55
A static scoring formula treats every query the same way. An adaptive one puts graph signal front and center for relationship queries but backs off when you just need a keyword match. This is the difference between a retrieval system that works in demos and one that works in practice.
On top of the hybrid scores, the pipeline applies a 1 + 0.30 * normalizedPageRank graph authority boost. High-PageRank entities get a measurable lift because they're structurally important in the graph, not just textually similar to the query.
The context compiler then packs the results into model-specific token budgets: 4,000 tokens for fast lightweight tasks, 8,000 for standard, 16,000 for deep analysis. The graph does the heavy lifting of selecting what matters. The model gets clean, relevant, high-signal context every time, not a full document dump.
Layer 3: Agentic Traversal
The third layer is what turns this from a retrieval system into a reasoning system.
Instead of a static pipeline that runs the same way every time, an AI agent reasons about which connections to follow. It looks at the query, considers the graph structure, and decides: should I go one hop or two? Should I follow the depends_on edge or the authored_by edge? Is this community cluster relevant or noise?
This is what the research calls "agentic RAG" and there's now a formal taxonomy for it. A January 2025 survey paper identified six architectural patterns, from single-agent routers to hierarchical multi-agent systems to graph-based frameworks where agents explicitly reason over knowledge graph structures.
In my system, the agent has access to graph traversal tools: neighbor expansion, shortest path finding, community detection, link prediction, and gap analysis. It can walk the graph, pull in context from multiple hops, and synthesize relationships that no static pipeline would ever find.
The execution pipeline runs a 10-node preflight graph on every request: parse the request, resolve intent, resolve entities, build a tool plan, retrieve candidates, orchestrate and bundle context, resolve decisions, expand the graph, compile context, and build the preflight manifest. Graph traversal isn't optional. It's a required primitive in every request.
And here's what makes this compound over time: the more your agents use the graph, the more they heal and build it. Every interaction reinforces edges, fills gaps, and strengthens connections. An agent that searches for context and finds a missing link can propose a new edge. An agent that traverses a path and finds a dead end can flag it for repair. The graph isn't just self-building. It's self-improving.
Where Do the Edges Come From?
This is the first objection everyone raises. "Knowledge graphs sound great in theory, but who's going to sit there and manually label thousands of relationships?"
Nobody is.
The graph builds itself through a tiered signal extraction pipeline that processes data as it streams in from connected systems.
Tier 1: Structural extraction. Deterministic, zero cost. An email sender maps to a person entity. A domain maps to an organization. Recipients create communicates_with edges. Calendar events create temporal relationships. This is pure metadata parsing.
Tier 2: Content pattern matching. Cheap, high precision. URLs in emails map to tools or resources. @mentions map to people. Entity titles found in message bodies create content_ref edges. A UUID from your infrastructure showing up in an email thread creates a link between that infrastructure entity and the conversation. This is fuzzy and exact matching across systems that don't share IDs.
Tier 3: Semantic inference. LLM-powered, probabilistic. Lightweight models analyze content and extract implicit relationships that were never explicitly stated anywhere. "We need to delay the launch until the auth migration is done" creates a depends_on edge between two project entities even though neither one is mentioned by name in a structured field.
The identity resolution layer ties it all together with a four-step pipeline: exact email and phone matching, domain-to-organization matching, nickname matching with last-name corroboration, and Jaro-Winkler fuzzy string matching at a 0.85 similarity threshold. Implicit edges materialize directly on the entity link table with confidence scores and evidence tracking.
Every connected system makes the graph denser and more useful. Email, calendar, messages, code repositories, documents, fitness tracking. The more data flows through, the more relationships emerge.
Temporal Decay: The Missing Algorithm
One of the biggest things people overlook in context management is temporal decay. And not just "newer is better." That's a naive approach that breaks immediately in practice.
Different types of entities decay at fundamentally different rates. My system implements this with entity-type-specific exponential decay half-lives:
- Journals: 14-day half-life. Yesterday's log is relevant. Last month's is noise.
- Work items: 30-day half-life. Active tasks matter. Completed ones fade.
- People, projects, goals: 90-day half-life. Relationships and initiatives stay relevant for a quarter.
- Notes: 120-day half-life. Knowledge persists longer than tasks.
- Decisions, organizations, resources, tools: 180-day half-life. Strategic choices and stable entities decay the slowest.
But decay isn't absolute. Two mechanisms fight it:
First, active status overrides decay entirely. A pending work item, an active project, a decision marked for revisit -- these skip the decay function completely. Status is a stronger signal than age.
Second, access-boost recovery. When you or an agent accesses an entity, it recovers up to 30% of its lost relevance, with a 7-day half-life on the access freshness itself. This means entities you're actively working with resist decay naturally, without manual intervention.
The decay function has a floor of 0.1, so nothing ever fully disappears. Old context can still surface if it's structurally connected to something relevant. But it has to earn its way into the context window through graph connections, not just recency.
This is what separates a context engine from a search engine. A search engine finds things. A context engine understands what matters right now.
The Real Cost Argument: Speed and Tokens
The emergent intelligence is compelling. But the practical argument for graph RAG is simpler and more immediate: speed and cost.
Consider what happens when an agent needs to answer a relationship question without a graph. "How is Andrew Huberman connected to my storage auction business?" With flat vector search, the agent has to:
- Run a broad semantic search for "Andrew Huberman." Get back podcast notes, health content, neuroscience references. Read through them.
- Notice a mention of Tim Ferriss. Search again for "Tim Ferriss." Read through those results.
- Find references to productivity systems. Search for those. Read more results.
- Eventually stumble into ListForge context. Search again. Find the Bargain Circus connection.
- Synthesize the chain across all those intermediate results.
That's 4-5 retrieval rounds, each stuffing thousands of tokens of context into the prompt, each requiring the model to read, reason, and decide what to search next. You're burning tokens on all that intermediate reasoning. The agent might spend 30 seconds and $0.50+ in LLM calls working through it. And it might still miss the connection entirely if the intermediate hops weren't in the top-k results of any single search.
With the graph, the same answer comes back in one traversal call:
Andrew Huberman -[content_ref]-> Tim Ferriss -[content_ref]-> ListForge -[content_ref]-> Bargain Circus
Under 300 milliseconds. Effectively zero LLM cost for the traversal itself. The relationship is structural, encoded in the edges. The agent doesn't have to search, read, reason, and search again. It walks the edges.
This isn't a marginal improvement. It's a category difference in how agents consume resources. Every multi-hop question that would have required iterative search-and-reason loops becomes a single graph operation. At scale, across thousands of queries, that compounds into massive savings in both latency and token spend.
The hidden connections are the exciting part. The speed and cost reduction is the business case.
Emergent Intelligence
Here's what nobody tells you about knowledge graphs, and what I didn't fully appreciate until I experienced it.
When you wire up enough systems and let the graph grow organically, it develops emergent properties. The graph starts surfacing connections you never made yourself.
My graph currently has over 2,000 nodes and 700+ communities spanning people, projects, goals, decisions, organizations, tools, notes, and communications. When I run graph metrics, interesting things show up.
Tim Ferriss, a podcaster, appears at #8 in my betweenness centrality rankings with a score of 0.039. He's an information broker in my personal knowledge graph because his content notes bridge multiple life domains: health, business, productivity, relationships. His node connects to Andrew Huberman, Jocko Willink, Seth Godin, Marcus Aurelius, and dozens of topical notes. Nobody designed that structure. The graph revealed it.
When I ask the system "how is Andrew Huberman connected to my storage auction business?" it finds the path in under 300 milliseconds:
Andrew Huberman -[content_ref]-> Tim Ferriss -[content_ref]-> ListForge -[content_ref]-> Bargain Circus
A neuroscience podcaster connects to a storage auction operation through three hops of graph traversal. No keyword search or embedding model would ever surface that chain. The path exists because Huberman appeared in notes about Ferriss's podcast, Ferriss's content referenced productivity systems I use for ListForge, and ListForge shares strategic context with Bargain Circus. Each edge was created automatically by the signal extraction pipeline. The path was discovered by the graph traversal algorithm.
The link prediction algorithm identifies relationships that probably should exist but don't yet. It uses Adamic-Adar scoring to find entities with high numbers of common neighbors. The top prediction in my graph has 68 common neighbors. Others range from 16 to 32 common neighbors. The system is finding social and professional proximity through pure graph structure with zero semantic analysis.
That's not retrieval. That's emergent intelligence. The system understands things about my world that I haven't explicitly told it.
The Trillion Token Engine
I've been calling this concept the Trillion Token Engine. The idea is simple.
When your retrieval stack actually understands how information relates through typed edges, graph traversal, and temporal awareness, you can reason across a practically unlimited corpus and still pull exactly what matters. Not by reading everything. By knowing where to look and what connections to follow.
A flat vector store with a trillion tokens is useless. You'll drown in noise. But a knowledge graph over a trillion tokens with hybrid search, adaptive scoring weights, graph algorithms, and agentic traversal? That's a system that gets more useful the more information it has, because the graph structure itself becomes the index.
The context compiler packs retrieved information into token budgets calibrated to the task: 4,000 tokens when speed matters, 8,000 for standard analysis, 16,000 when you need the full picture. The graph does the heavy lifting of selecting what matters. The model gets clean, relevant, high-signal context every time.
What I'm Building
I've been running this system as my personal operating system for months under the name MindGraf. It manages my projects, tracks my goals, connects my communications, surfaces context across my entire personal and professional life, and runs autonomous agents that do work on my behalf.
I'm packaging it up for release. Free desktop app, CLI, and MCP server that runs entirely on your machine. Your data stays local. A paid tier will add cloud sync so your knowledge graph is accessible across agents and devices.
I'm also adapting this architecture for enterprise use at my day job at EPM. The personal graph problem is hard. The enterprise graph problem is harder. When thousands of people generate communications, decisions, documents, and code across dozens of systems, the graph becomes an organizational nervous system that no single person could maintain manually. Multi-tiered knowledge graphs that auto-build organizational process flows across teams and systems. That's a whole other story and I'll be sharing more on it soon.
The Real Unlock
The industry is starting to call this broader shift "context engineering." Gartner declared 2026 the year of context. The community is moving past the naive chunk-embed-retrieve pattern and recognizing that the real challenge isn't making models smarter. It's giving them the right information at the right time.
This is not another memory framework. This is not a toy demo. This is the next evolution of how we give agents the context they need to actually do valuable work.
The models are ready. The context infrastructure is what's missing. And knowledge graphs are how we build it.
MindGraf is launching soon. Follow me for the download link, technical deep dives, and daily posts on context engineering, knowledge graphs, and building AI systems that actually understand the world they operate in.