Knowledge graph vs vector search for agent memory

Short version: Vector search and knowledge graphs solve different memory problems. Vectors find “similar in meaning” — they save you when the question is phrased differently. A graph stores state and relations — it answers “what’s decided”, “what’s open”, “what depends on what”. Agent memory needs both properties, so the working answer is a hybrid: a graph as the core of state, semantic search as the way to find things in it.

Two different problems both called “memory”

The “graph vs vectors” debate usually stalls because the two sides are solving different problems. Let’s separate them.

The retrieval problem: “find things similar to this question”. The user asks “how does our auth work”, but the note says “login via JWT”. Same meaning, different words.

The state problem: “what’s the status of the migration task”, “what did we decide about caching and why”, “which bugs are open”. What’s needed here isn’t “similar text” but an exact current fact and its relations.

Vector search is built for the first. A knowledge graph is built for the second. Here’s each one honestly, weaknesses included.

Vector search: strengths and failure modes

The idea: text is turned into a vector (a list of numbers), and proximity between vectors means proximity of meaning. Search is nearest-neighbor lookup.

Strengths:

• Paraphrases. “Auth” and “login” end up close together in vector space even though the words differ. This is the main advantage, and it’s real.
• Unstructured corpora. Thousands of notes, documents, messages — indexed with no manual markup.
• Low barrier to entry: grab an embedding model, grab a vector database — it works.

Weaknesses:

• “Similar” doesn’t mean “correct”. A query for “task X status” finds five texts about task X: from a month ago, a week ago, yesterday. A vector doesn’t know which one is current. For agent memory this is critical: a stale fact is worse than a missing one.
• No negations or exact constraints. “We do NOT use Redis” and “we use Redis” are nearly identical vectors.
• No relations. “Which bug blocks the release” is a graph traversal, not text proximity.
• A hidden price: every record costs an embedding model call, plus full reindexing when you switch models.

Knowledge graphs: strengths and failure modes

The idea: memory is entities (project, task, decision, person) plus explicit relations between them (“task blocks release”, “decision made by the owner”). Facts are atomic observations with dates; bugs and tasks carry statuses.

Strengths:

• Accuracy on facts. “Task X status” is a field on a specific entity, not a similar text. The answer either exists or is honestly absent.
• State by construction. Open tasks, current decisions, change history — that’s what the graph structure holds. Compaction and session switches don’t affect it: the graph lives outside the window (about compaction).
• Relations as first-class citizens. “What depends on this decision” is an edge traversal, not a hope for semantic closeness.

Weaknesses:

• Paraphrases are the sore spot. If the agent searches for “auth” but the entity is named login-flow, plain text matching falls short. You need either disciplined naming or semantic search over the graph.
• Someone has to build the structure. A fact must be recorded as an entity with observations, not dumped as a wall of text. A protocol handles this (the agent writes it itself, following rules) — but it’s discipline, not free lunch.

Side by side

A pure vector approach is a good corpus search engine and a poor state memory. A pure graph is good state and weak paraphrase retrieval. The table is symmetric, and that’s no accident: the two approaches cover each other’s blind spots.

Our path: hybrid

We build MaxGraph with a graph at the core because an agent’s main pain is state: decisions, open tasks, “what’s next”. That’s what gets lost between sessions and in compaction, and it’s the most expensive thing to reconstruct by hand.

On top of the graph runs ranked full-text search — it smooths out the graph’s main weakness, finding entities even when the query is phrased differently from what’s stored. And where true semantic paraphrasing is needed (a large document corpus, “similar in meaning”), a vector index can be added alongside — as a retrieval layer, not as the store of state.

The principle we follow: state lives in the graph, search lives on top. The reverse architecture (state in vectors) gives you an agent that confidently quotes month-old facts.

The economics favor a graph-core hybrid too. A graph write is recording a fact — no embedding call per sneeze; reading state at session start is one digest with a fixed budget. In our measurements, a digest-backed session start costs ~4,200 tokens versus ~8,900 for reading the project from scratch.

How to choose for yourself

• Questions are mostly “find something similar in the docs” → vector search; a graph is optional.
• Questions are mostly “what did we decide / what’s in progress / what changed” → graph at the core.
• Daily agent work on a living project → hybrid: graph for state, semantic search on top for phrasing.

FAQ

Is vector memory the same as RAG? RAG is the “retrieve + stuff the results into context” pattern, and the retrieval is usually vector-based. Vector memory is RAG applied to work history. The limitations are the same: similarity instead of currency.

Can I store state in vectors if I write carefully? You can, but you’ll be hand-solving what a graph gives you for free: fact versioning, statuses, relations. This usually ends with a graph being built on top of the vector store — a homemade one, held together with duct tape.

Isn’t a graph too complex to start with? Not if the agent maintains the structure rather than you. Following the protocol, it creates entities and records facts itself; your job is to check. Running the local server: 10 minutes for Claude Code or for Cursor.

How does this compare to Mem0, Zep and other services? We have a dedicated breakdown: MaxGraph vs Mem0 and Zep — architectures, locality, and pricing.

What’s next

• The big picture of approaches: the agent memory guide.
• Terms from this article: the agent memory glossary.
• The cost measurements: the price of repeated context.