Rung 1 · Start here
Files
You have context.
What it is
Plain text and markdown on disk. Folders that mean something. An index file that maps the territory. The model reads the files directly; there is no retrieval system because none is needed yet.
Files read as the beginner option. They are the correct default. Modern context windows hold more than most projects ever produce.
How to use it
- Small files, named for what they contain. The filename is the first retrieval system.
- Maintain an index. One file that says what exists and where. The model reads the map, then the territory.
- One subject per file. Mixed files rot fastest.
- Let the model update the files it reads. Memory that only humans write goes stale.
Why it works
Context beats retrieval whenever the whole map fits. A model with your actual files in context sees everything you know; a model holding retrieved fragments sees samples. Long-context recall is not perfect, but at this scale the window is nowhere near stressed, and retrieval is a downgrade you paid extra for.
Files are also inspectable. You can open your memory and read it. Every rung above this one trades away some of that.
When the rung fails
You catch yourself scanning many files to answer a question a query would answer instantly. Counting, filtering, sorting, "show me all X where Y." The facts have shape and you keep flattening them into prose.
That is structure asking to exist. Climb.
Projects that live here
Rung 2
Database
You have structure.
What it is
Plain tables. SQLite or Postgres, nothing exotic. Entities you repeat get a schema; facts get rows; questions get queries.
No AI anywhere on this rung. Just fifty years of boring reliability, sitting right there, skipped by everyone racing to the top of the ladder.
How to use it
- Schema only for what repeats. Everything else stays in files; the rungs stack, they do not replace each other.
- Give the model a thin tool layer to query and write. Deterministic reads, validated writes.
- Keep the schema small enough to fit in the prompt. If the model can hold the schema, it can write the query.
- Timestamps on everything. Cheap now, priceless later.
Why it works
Exact answers to exact questions. A query returns the truth, the whole truth, and nothing hallucinated. It is cheap, fast, auditable, and deterministic; four words no rung above this one can say together.
When the rung fails
The questions turn semantic. "Find things like this." "What do we know about X." Meaning does not fit in a WHERE clause, and the unstructured text is piling up beside your tidy tables.
That is recall asking to exist. Climb.
Projects that live here
Rung 3
RAG
You have recall.
What it is
Embeddings and vector search over chunks of your corpus. The model no longer reads everything; it asks for what is relevant and reasons over what comes back.
This is the first rung where you accept sampling. Retrieval returns candidates, not certainty. That trade is worth it exactly when the corpus outgrew the rungs below, and not one day sooner.
How to use it
- Chunk deliberately. Chunk boundaries are answer boundaries; split mid-thought and you retrieve half-thoughts.
- Hybrid search from day one. Vectors for meaning, keywords for names, IDs, and exact terms. Pure vector search whiffs on the exact stuff.
- Store metadata and filter with it. Recency, source, type. Retrieval without filters degrades as the corpus grows.
- Measure retrieval, not vibes. If you cannot say what percent of answers had the right chunks in context, you are not running RAG; you are hoping.
Why it works
Semantic recall at a scale context cannot reach. When the corpus is a hundred times the window, reading everything is off the menu. The choice left is retrieval or ignorance.
When the rung fails
Retrieval returns the right chunks and the answer is still wrong, because the answer is not in any chunk. It is between them. Multi-hop questions fail; "how does A relate to C" comes back as A and C with no bridge.
When the relationship is the answer, recall cannot carry you. That is relationships asking to exist. Climb.
Projects that live here
Rung 4 · The hottest rung
Graph
You have relationships.
What it is
Entities and edges as first-class data. People, systems, decisions, and the typed connections between them, traversable at read time. Add timestamps to the edges and the graph also knows what was true when.
How to use it
- The write path is the whole game. Graphs fail at extraction, not traversal; a graph of sloppy entities answers confidently and wrongly.
- Validate extraction against an outcome metric. Sample the writes, score them, tune the extractor. Never trust it on faith.
- Resolve entities aggressively. "Bob," "Robert," and "R. Evans" as three nodes is how graphs quietly die.
- Keep RAG running beside it. The graph holds relationships; the vectors hold everything the graph's schema cannot see.
Why it works
Some answers are edges. No amount of better chunking finds a connection that lives in no chunk. The graph stores the connection itself, so multi-hop questions become walks instead of guesses.
When not to climb
Not because a benchmark thread said so. Not because the demo was impressive. Not because it is the hottest rung and you want to be seen on it.
The graph is the most expensive rung to keep true. Every entity extracted wrong is a lie your system will repeat politely, forever. Earn this rung with a real failure on the rung below, or stay off it.
Projects that live here
"I sat down here until I could name the failure that sent me up. You should too."
The top of the ladder splits: RAG/Graph vs Graph/RAG
At the top, RAG and graph run together. The fight over which one "wins" is malformed; they are interchangeable leads, and the order encodes which system goes first. Read the slash as "then."
RAG/Graph
Vectors lead · graph expands
The wall it leans on: find it, then connect it.
You do not know where the answer lives. Vector search finds the entry points, matching against entity or chunk embeddings; the graph traversal expands the neighborhood around what it found and returns the connected picture.
The graph is the second opinion here. It enriches what search found.
Built by
- Research and discovery tools over large corpora
- Support and internal search, "what do we know about this"
- Investigation work where the starting point is a phrase, not an entity
Graph/RAG
Graph leads · vectors fill
The wall it leans on: constrain it, then fill it.
You know the entity; you need its world. Graph traversal draws the boundary first, this account, these systems, that time window, and vector search runs inside the boundary to fill in the detail.
The vectors are the second opinion here. They add texture to what the graph scoped.
Built by
- Entity-centric operations: accounts, patients, incidents, SKUs
- Compliance and audit, where scope must be provable
- Recommendations anchored to a known node
Same two systems. Same four rungs. The data and the work decide which one leads; that is the whole disagreement, and it was never a fight.
All four rungs, one system
The rungs stack; they do not replace each other. A mature system runs all four at once, and each one holds the kind of truth it is best at. Here is the split in a customer operations assistant.
The agent's charter, the renewal playbook, the escalation rules, the writing style. The things that change rarely and get read every time. This is how the system knows how to act on what it learns.
Accounts, tickets, SLAs, usage numbers, renewal dates. Anything you would ever count, sort, or filter. When the answer must be exact, it comes from here and nowhere else.
Ticket text, call notes, emails, doc pages. The unstructured record of what was actually said. When you need meaning and tone rather than counts, retrieval finds it here.
Which accounts run which integrations, which incidents touched which systems, which champion knows which team. The edges nobody wrote down in any one document.
"Acme's renewal is in 30 days. What's the risk, and who else looks like them?"
- The graph draws the boundary. Acme connects to two integrations, one open incident, and a champion who left last quarter. The scope of "Acme's world" now exists as a subgraph, and the lookalike question is already answerable: two other accounts share the same integration and the same incident.
- The database makes risk a number. Inside that boundary: open tickets, SLA breaches, usage trend, days to renewal. Exact figures from queries, not impressions from prose.
- RAG recovers the tone. Retrieval over Acme's ticket text and call notes finds where the language turned; the facts said "slowing down" and the words said "frustrated." Only the unstructured record holds that.
- Files decide the move. The renewal playbook says what this risk tier gets; the charter says how the agent speaks when it reaches out. Judgment was written once and applied here.
Remove a rung and name what breaks
- No graph: you never find the two lookalike accounts, because that answer is an edge.
- No database: "risk" becomes a vibe with no number behind it.
- No RAG: you miss the moment the tone turned, because tone lives in text.
- No files: the system knows everything and still does not know how you respond.
Frequently asked questions
When should I move from files to a database for AI memory?
When you catch yourself scanning many files to answer a question a query would answer instantly. Counting, filtering, and sorting are the signal; once facts have shape, put them in tables and keep prose in files.
When should I use RAG?
When the corpus outgrows the context window and an index no longer covers it. RAG adds semantic recall over unstructured text; below that scale it adds cost without adding capability.
When should I add a knowledge graph to RAG?
When retrieval returns the right chunks and the answer is still wrong because it spans documents. Multi-hop questions are the trigger; a graph stores relationships as data, so those questions become traversals instead of guesses.
What is the difference between RAG/Graph and Graph/RAG?
The order names which system leads. In RAG/Graph, vector search finds entry points and the graph expands around them. In Graph/RAG, the graph draws the boundary and vector search fills in detail inside it. Same two systems; the data and the work decide which leads.
Can files, a database, RAG, and a knowledge graph run in one system?
Yes, and mature systems do. Files hold the judgment, the database holds exact facts, RAG holds the unstructured words, and the graph holds the connections. The rungs stack; nothing gets replaced.
The ladder doesn't care what shipped this week. Climb when the rung below fails. Not before.
Files, then structure, then recall, then relationships. Each rung stacks on the last; nothing gets replaced, everything gets earned.
Done with the ladder? Keep going.
The sibling catalog
LLM Failure Modes
The Anti AI-Slop catalog. The ways models fail, named, so your prompts and agents can check for them.
See the failure modes →
The writing
Signal Thinking
Patterns for the agentic age. Where frameworks like this one get built in public, argued, and sharpened.
Read Signal Thinking →
The architect
robertrevans.com
Twenty years of production systems, now designing AI architectures. See the work, or bring Robert yours.
Visit the site →