If you are building an AI that answers questions about your own work, you have two architectures to choose from: retrieval over embeddings (RAG) or a context graph. Suda is built on the second, and this piece explains why, without hand-waving.

The one-line difference

RAG finds the text that looks most similar to a question. A context graph answers from how your work actually connects. Similarity is not truth, and that gap is where RAG breaks.

How RAG works, and where it falls short

RAG splits your documents into chunks, turns each chunk into a vector, and stores them. At question time it embeds the query and returns the nearest chunks. It works well for “find me passages about X.” It struggles the moment the right answer depends on context the chunk does not carry:

No sense of time. An old chunk and a new chunk about the same policy look equally relevant. RAG cannot tell which one is current.
No sense of authority. It does not know that a decision in Linear supersedes a note in Notion.
No sense of structure. It returns the closest paragraph, not the four connected facts that together answer the question.

This is why an AI on top of raw retrieval keeps giving outdated and contradicting answers. The retrieval did its job. The job was the wrong one.

How a context graph works

A context graph stores facts and the relationships between them: ownership, supersession, membership, recency. When you ask a question, it walks those relationships and assembles the current, coherent context, then hands the model only what is needed.

That last part matters for cost. Because the graph sends the needed context instead of every similar-looking chunk, Suda passes about 85% less text to the model per answer. Fewer tokens, less noise, lower bill.

Side by side

	RAG / vector database	Context graph (Suda)
Retrieves by	Text similarity	How facts connect
Handles stale facts	No, old and new look alike	Yes, stale facts retire
Handles contradictions	Returns both	Resolves to what is current
Cross-tool answers	One chunk at a time	Walks the connected facts
Context sent to model	Every similar chunk	Only what is needed (~85% less)
Upkeep	Re-index, re-chunk, clean	Self-updating

When RAG is still fine

RAG is a good fit for open-ended search over a static corpus: documentation, a research library, a help center where nothing contradicts. If your content does not change and facts do not compete, similarity search is enough.

The moment your context is live, spread across tools, and full of decisions that override each other, you need the graph.

Where Suda fits

Suda connects your sources (more than 700, including Notion, Slack, and Linear), builds the graph, and keeps it current. Any agent reads it over MCP. Access is permissioned. Setup is one command:

npx suda connect

If you want the definitional background first, start with what is a context graph.