How AI Agents Can Understand Complex Documents Without Loading Full Content
Complex documents are not storybooks to be read end-to-end. They are dependency graphs where concepts reference other concepts, chapters build on previous chapters, and understanding one part requires understanding its connections.
A dependency graph maps these relationships so an AI agent can navigate intelligently without loading everything into context.
This emerged from a conversation about the Book Integrator agent - an agent that needs to "know" a 22-chapter book well enough to answer questions about where new insights fit, what chapters might need updating, and whether content is duplicated.
The problem: Loading 100k+ tokens every session is expensive and still suffers from context rot - the phenomenon where model performance deteriorates with increased context complexity.
The breakthrough came from examining the RLM (Recursive Language Models) paper which demonstrated that code execution + recursion allows AI to intelligently search over large contexts by treating documents as data objects to be queried, not text to be read.
| Approach | Why It Fails |
|---|---|
| Stuffing Full Context | Context rot. Expensive. Signal buried in noise. Performance deteriorates before token limit is hit. |
| Summarization | Lossy. Important connections lost. Agent gradually drifts off task. |
| RAG (Semantic Similarity) | Only retrieves "similar" chunks. Cannot follow logical relationships. Chunking strategy is brittle. |
Complex documents require multihop reasoning - looking at one part, reasoning about it, finding another related part, applying conditions. Raw LLMs deteriorate when multihop reasoning meets large context.
This leads to models that are confidently wrong - the quickest way to break trust in any AI system.
"Rather than trying to model these things as a storybook that you read end to end, model them as dependency graphs."
For a book: Nodes = Chapters, Concepts, Terms. Edges = How they reference each other.
For code: Nodes = Functions, Classes, APIs. Edges = What calls what, what depends on what.
| Agent | Context Size | Purpose |
|---|---|---|
| Graph Keeper | ~5k tokens (graph only) | Answers "what depends on what?" Holds structure, not content. |
| Book Integrator | Light (queries as needed) | Answers "where should this go?" Coordinates with Graph Keeper. |
| Chapter Reader | One chapter at a time | Deep-reads specific content when needed. |
| Graph Builder | Full content (expensive) | Periodically rebuilds/updates the dependency graph. |
Unlike a simple index, the dependency graph captures decisions and relationships:
| Field | Purpose |
|---|---|
node_id |
Unique identifier for concept/chapter/section |
defined_in |
Where this is canonically defined (the source of truth) |
referenced_in |
Where this is used without re-definition |
duplicated_in |
⚠️ Violations - where content was repeated instead of referenced |
decision_reasoning |
WHY it was placed here - the architectural justification |
relationship_type |
DEFINES, DEPENDS-ON, BUILDS-ON, CONTRADICTS, DUPLICATES |
The decision_reasoning field is what separates this from a simple index. When you ask "why is this concept in Chapter 7 instead of Chapter 16?", the Graph Keeper can explain the architectural decision, not just report the location.
We validated this architecture by analyzing two chapters that appeared to have overlap:
"Chapter 7 should remain canonical for theory. Chapter 16 should be revised to reference Chapter 7 and emphasize its unique practical contributions."
This is exactly what a human editor would say - but the Graph Keeper can answer this query instantly, consistently, and at any time.
Once the protocol is proven, it applies to multiple domains:
| Domain | What Gets Graphed |
|---|---|
| Entity Veracity (Book) | Chapters, concepts, claims, cross-references |
| Super-Intelligent AI (Software) | Files, agents, endpoints, what breaks if X changes |
| Future Book Spines | Same pattern as Entity Veracity |
| Client Knowledge Bases | Their documents, their concepts, their dependencies |
One protocol. One schema. Multiple applications.
This is the fractal pattern - get it right once, apply it everywhere.
The Socratic Triad extracts load-bearing insights from conversations (Q→A→R chains). The Dependency Graph tracks how those insights relate to each other structurally.
| System | Question It Answers |
|---|---|
| Socratic Triad | "What is the insight?" (extraction) |
| Dependency Graph | "How does this insight connect to other insights?" (structure) |
They connect: Eureka insights become nodes. The dependency graph tracks how those nodes relate.