GraphRAG versus vector search is the wrong fight. Apollo runs both, in sequence.

An operations agent gets asked a two-hop question on a Tuesday: which vendor caused the Q2 renewal to slip, and was that decision ever reversed. The vector index returns three chunks that mention the vendor, the renewal, and a reversal, each with a healthy similarity score, none of them connected to one another. The agent stitches together its best guess and gets the reversal backwards.

That’s the shape of the fight everyone is having right now: GraphRAG vs vector RAG, argued like one side has to win. It won’t, because the two are good at exactly what the other is bad at.

The production answer for agent memory is a hybrid substrate where vectors find candidates fast and the graph does the multi-hop reasoning and keeps the provenance, not one or the other alone.

This post defends that hybrid as the only substrate that survives contact with a live agent: why vector-only retrieval mangles the reversal in the opening scene, why a graph built once and traversed in full is too slow and too stale to trust on every turn, and how Apollo’s own agent memory runs the pipeline that gets a correct, cited answer back in a few hundred milliseconds without waiting on a rebuild.

The naive fight: GraphRAG vs vector RAG

The naive framing has two camps, and both have a real point. The vector camp says embeddings scale: cheap to compute, cheap to query, already powering every retrieval-augmented system in production. The graph camp says relationships matter, that a pile of similar-sounding chunks isn’t the same thing as knowing which fact caused which, and that the vector camp’s demos quietly skip every question needing more than one hop.

Here’s why picking a side fails. Vector-only retrieval has no concept of a relationship, only of distance, so it cannot chain “vendor delayed the renewal” to “the delay decision was reversed” unless both facts sit close to the same query in embedding space. Static GraphRAG, the term and architecture from Microsoft’s 2024 research on community-summarized retrieval, solves the reasoning problem by building a full graph up front and traversing community summaries to answer global questions. That works, but it’s built once, traversed in full each time, and goes stale the moment a new fact arrives the graph hasn’t reconciled yet.

Neither failure is a bug you patch. They’re two different jobs, and 2026’s converging answer is to stop asking one system to do both.

Why vector-only retrieval mangles a multi-hop question

The naive pitch here is simple: embed everything, chat logs, tickets, documents, decisions, and let cosine similarity do the rest. If the fact is in the store, a close-enough query surfaces it.

The mechanism that breaks this is worth being precise about. A vector encodes how semantically close two pieces of text are, nothing more. “The vendor missed the March deadline” and “the renewal decision was reversed in April” can both score high against a query about the renewal without the store ever representing that one caused the other, or that the second event supersedes the first. Similarity has no opinion about causation, sequence, or which fact currently holds. This is a close cousin of the failure RAG is not memory already described, retrieval finding a document instead of memory holding a conclusion, but one layer further down: even a memory store that reconciles facts correctly still can’t chain two related facts together at query time if all you run against it is pure similarity search.

The gap isn’t theoretical. One independent benchmark comparing a graph-structured context layer against vector-only retrieval on the same question set found 80.0% accuracy on multi-hop join queries for the graph-based approach against 20.0% for vector-only search, a four-to-one gap on exactly the kind of question the opening scene describes (towardsdatascience.com, “Vector RAG Isn’t Enough”). It’s worth citing precisely because it isolates the one thing vector similarity structurally cannot do: reason across an explicit relationship instead of guessing from proximity.

A vector store answers “what’s similar to this.” A multi-hop question asks “what follows from that,” and similarity was never built to answer it.

Why a static graph alone can’t keep up with a live agent

If vector search can’t chain facts, the naive fix looks obvious: build the whole knowledge graph up front, index every relationship deeply, and traverse it at query time. Now the reasoning works.

It does, until you look at what “build it up front” costs on the next update. Static GraphRAG answers global, corpus-level questions by traversing community summaries computed at index time, precisely why the reasoning is right and precisely why it’s heavy. Reconciling a graph against new facts is a different, harder operation than appending a row to a vector index, so most static deployments batch-rebuild instead of updating live, authoritative on build day and increasingly behind every day after. A graph correct on build day and wrong a week later is the same shape of failure memory with a clock describes at the level of a single fact: decaying correctness is a different bug than correctness never retrieved, and just as damaging to a live agent.

The speed cost of skipping structured retrieval entirely is concrete, not hand-waved. Zep’s own benchmark measured a naive baseline, stuffing the full conversation history into the context window on every turn rather than narrowing first, at 28.9 seconds of median latency per query against gpt-4o, compared to 2.58 seconds for their hybrid structured-retrieval path, a roughly 91% cut (arXiv 2501.13956, Table 2). A system that can’t narrow before it reasons pays for it in tens of seconds. Static GraphRAG pays a narrower, harder-edged version of the same cost once at build time instead of per query, then runs stale between rebuilds, a worse failure because nobody sees it until the answer is already wrong.

A graph that’s right on the day it’s built and wrong on every day after is not a reasoning engine. It’s a snapshot pretending to be memory.

Building the whole graph and traversing it in full solves the reasoning problem and reintroduces the latency and staleness problems from the other side.

What a hybrid substrate does, query by query

So the naive move on both sides fails the same way: each one tries to make a single mechanism do a job it wasn’t built for. Apollo’s own agent memory is built to run the fix directly, not describe it from the sidelines, and it maps onto the three layers named for AI systems generally: a system of record, a system of intelligence, and a system of action. The vendor-renewal-reversal question from the opening scene is the concrete case.

Apollo’s system of record for agent memory is the vector index and the temporal graph together, one substrate, not two separate products glued at the API. The system of intelligence is the agent loop reasoning over that record query by query, built to run in the same order Graphiti, the temporal knowledge graph engine underneath Zep’s production agent memory, validated: vector recall first, cosine similarity pulls a small set of candidate nodes out of a much larger store in milliseconds. Those candidates are entry points into the graph, not the answer. Graph traversal expands next, following the typed edges that connect one fact to another, the vendor to the renewal to the reversal, rather than guessing from proximity. A hybrid reranker then merges three signals at once, cosine semantic similarity, keyword search, and the graph traversal result, into a final answer with its supporting path intact.

That’s the same three-step pattern Graphiti reports running in production with a P95 retrieval latency of 300 milliseconds and zero LLM calls at query time, scoring 94.8% on the Deep Memory Retrieval benchmark with gpt-4-turbo and 98.2% with gpt-4o-mini (arXiv 2501.13956; Neo4j engineering blog on Graphiti). Apollo’s pipeline is built against that published architecture on purpose, not invented from scratch: Zep’s own results are the validation Apollo designs the pattern against, the way an engineering team benchmarks a build against a public spec instead of guessing at one. We go deeper on how the three layers of agent memory divide this work in the three kinds of memory your agent needs.

Apollo’s own loop is built to do a third thing neither the vector-only nor the static-graph camp needed to: the system of action. Once the reranked answer resolves the reversal, it’s designed to write that resolution back into the same record as a new typed, timestamped edge, superseding the stale fact instead of sitting beside it, so the next agent asking about the same vendor reads the settled fact instead of re-deriving it from three disconnected chunks. That write-back is what keeps the record, the reasoning, and the action inside one auditable loop, instead of a layer that answers correctly once and forgets it ever did.

Vector recall narrows the search space in milliseconds, graph traversal reasons over just that narrowed set, and a hybrid rerank merges both signals without calling the model to do it, then the action layer writes the resolved fact back into the record it started from.

What this costs, honestly

None of this is free, and pretending otherwise would undercut the whole argument. A hybrid substrate means running and maintaining two systems instead of one, a vector index and a graph store, kept in sync. Every new fact costs more to write than a plain append to an index: it has to be reconciled against existing nodes, typed against the right edges, and, in a temporal graph, timestamped so a later contradiction supersedes it instead of sitting beside it. That write amplification is real, the price of a graph that can answer “why” and “as of when,” not just “what.”

Owning both layers also means giving up the easy option of swapping in whichever vector database or graph engine looks best this quarter. The two stores have to agree on identity and scope, what counts as the same entity across both, and that coupling is a real commitment, not a footnote. A team expecting a drop-in graph plugin on top of an existing vector store will find the integration work closer to a rebuild of the retrieval layer than a bolt-on.

The tradeoff is worth it for one reason: the alternative isn’t cheaper, just cheaper to build and expensive to be wrong. A vector-only system that gets the reversal backwards in front of a customer costs more than the maintenance overhead ever will, and a static graph right once a week and stale the other six days trades one kind of unreliability for another. Paying for reconciliation and sync is the cost of an agent trusted with a two-hop question the first time it’s asked.

The turn

Step back from the pipeline diagram for a second, because the person asking the original question doesn’t care which store answered it.

What they care about is whether the agent can be trusted with a two-hop question the way a colleague who was actually in the room would answer it, correctly, on the first try, not on the third rephrase after the wrong answer already went out. That trust is exactly what neither pure mechanism delivers alone: vector search alone gets a fast, confident, occasionally backwards answer; a static graph alone gets a correct answer that arrives after the moment that needed it has passed. The production answer for agent memory is a hybrid substrate where vectors find candidates fast and the graph does the multi-hop reasoning and keeps the provenance, not one or the other alone, precisely because it’s the only version of the system that gets there both correct and on time.

The production answer for agent memory is a hybrid substrate where vectors find candidates fast and the graph does the multi-hop reasoning and keeps the provenance, not one or the other alone. Say it enough times and it stops sounding like a compromise between two camps and starts sounding like what it is: routing each question to the mechanism built to answer it.

---

That’s the loop Apollo’s own agent memory is built to run, not just the substrate it’s designed around: vector recall to narrow fast, a graph to reason across what’s connected and keep the receipts on why, and the write-back that resolves the answer into the record so the next agent doesn’t reopen the case, wired so an operations agent asked about a vendor, a renewal, and a reversal gets the right answer before the conversation moves on, not tens of seconds after.