Context Graph vs Vector RAG vs Raw History: Which Multi-Agent Memory Costs Less per Query?

The Problem Multi-Agent Memory Has to Solve

When you run an AI coding workflow with multiple agents — planner, executor, reviewer, perhaps a separate test-writer — the agents need to share state. Agent_Planner decides on PostgreSQL at turn 3. Agent_Reviewer at turn 23 needs to know that decision happened, and exactly what it was. The question of how that information moves between agents is the question of multi-agent memory architecture, and it's one of the highest-leverage cost decisions in agent workflow design.

A Towards Data Science post published in late June 2026 ran a tight, deterministic benchmark on three common memory architectures across 18 graded queries — three architectures, five scripted scenarios, zero LLM calls in the evaluator (which keeps the benchmark reproducible and unbiased). The headline numbers are striking enough to reshape how mid-sized teams should think about multi-agent costs.

The Three Memory Architectures

Raw history dump. Every agent receives the full transcript of prior turns. This is the simplest pattern — no infrastructure, no retrieval logic. It scales linearly in token cost with conversation length, and the LLM has to re-read everything to find the relevant prior decision.

Vector RAG. Prior turns are embedded as vectors. When an agent needs context, it queries the vector store for the K most similar past turns and includes them in the prompt. Token cost grows with K rather than total conversation length, but retrieval quality depends entirely on the embedding model's ability to match query intent to past content.

Context graph. Facts and decisions are stored as entities and relationships in a graph structure rather than raw text. "Decided to use PostgreSQL" becomes a node (Decision) with relationships (made_by → Planner, at_turn → 3, type → Technology_Choice). Retrieval is a graph traversal: "find all decisions of type Technology_Choice made by Planner."

The Benchmark Numbers

Across the 18 graded queries:

• Context graph: 88.9% accuracy at 26.9 tokens per query.
• Raw history dump: 61.1% accuracy at 490.9 tokens per query.
• Vector RAG: 50.0% accuracy at 75.9 tokens per query.

The context graph is 18× more token-efficient than raw history dump while delivering 28 percentage points better accuracy. Even against vector RAG — the architecture most multi-agent frameworks ship by default in 2026 — the context graph is 2.8× more token-efficient and 39 percentage points more accurate.

Why Vector RAG Underperforms for Multi-Agent Memory

Vector RAG works well for content retrieval — find the article paragraph closest in meaning to my question. It works poorly for fact-recall queries — find the specific decision made twenty turns ago — for a few structural reasons:

Semantic similarity ≠ factual relevance. A query like "what database did we pick?" might semantically match many past turns that discussed databases, decisions, technical choices, or PostgreSQL specifically. The embedding model surfaces the most similar, not the most authoritative.

Stale facts pollute retrieval. If Agent_Planner first proposed PostgreSQL at turn 3, then revised to MySQL at turn 15, then committed back to PostgreSQL at turn 28, vector RAG may surface any of the three turns depending on which is most semantically similar to the query. There's no native concept of "latest decision."

Entity boundaries blur in embeddings. When the query is "what did Agent_Reviewer say about the auth design?", vector RAG can't trivially filter by which agent said something. It surfaces semantically similar content from any agent.

Why Context Graphs Work Better for State Recall

The same characteristics that make context graphs more verbose to build make them more efficient to query:

Entity-typed queries are precise. "Find all Decision entities made by Planner of type Technology_Choice with status=active" is unambiguous and returns exactly the right facts.

Temporal versioning is native. Each decision can have a timestamp and supersedes relationship, making "what is the current decision about X?" a graph traversal rather than a similarity match.

Token efficiency is structural. The query returns just the fact and its metadata, not paragraphs of surrounding context. The benchmark's 26.9 tokens per query is roughly "DECIDED: Postgres (by Planner, turn 3, status: active)" plus minimal framing.

When to Use Each Architecture

The benchmark doesn't say context graphs are always right. It says context graphs are right for multi-agent state recall queries. Choose based on the dominant query pattern in your workflow:

Use context graphs when: agents need to recall structured facts and decisions, the conversation has clear entity types (Decision, Constraint, Component, Test_Result), and you can afford some upfront engineering to define the schema. Multi-agent coding workflows almost always fit this profile.

Use vector RAG when: the queries are semantic (find similar prior content) rather than factual (find a specific decision), the corpus is dominated by free-form text, and structured entity extraction isn't natural. Document Q&A and codebase navigation often fit.

Use raw history dump when: the conversation is short (under 10 turns), no infrastructure investment is justified, or you need full fidelity for downstream audit. Quickie experiments and single-developer workflows.

Cost Math at Production Scale

Apply the benchmark numbers to a representative multi-agent coding workflow:

• 200 memory recall queries per agent task
• 10,000 agent tasks per month (mid-size engineering team)
• Input token cost: $3 per million (mid-tier Claude/GPT pricing)

Raw history dump: 200 × 10,000 × 490.9 tokens = 982M input tokens/month = $2,946/month.
Vector RAG: 200 × 10,000 × 75.9 = 152M input tokens/month = $455/month.
Context graph: 200 × 10,000 × 26.9 = 54M input tokens/month = $162/month.

Annual savings of context graph vs. vector RAG: ~$3,500. Annual savings vs. raw history: ~$33,000. For team workflows with 10× the agent task volume, multiply accordingly.

Implementation Cost

Context graphs aren't free to build. The infrastructure investment is roughly:

• 2-4 engineer-weeks for initial schema design and entity extraction logic.
• Graph storage backend (Neo4j, Memgraph, JanusGraph, or homegrown over Postgres with extensions).
• Ongoing maintenance as agent capabilities and task types evolve — adding new entity types, query patterns, deduplication logic.
• Two bugs the benchmark author called out: stale-fact retrieval and entity-matching gaps. Both are predictable and worth budgeting time for.

For workflows with above ~5,000 agent tasks/month, the engineering investment pays back in 6-12 months on token savings alone. Below that, vector RAG is the pragmatic default.

Bottom Line

For multi-agent coding workflows in 2026, context graphs are roughly 3× more token-efficient than vector RAG and 18× more token-efficient than raw history dumps — while delivering substantially higher accuracy on state recall queries. The architecture costs more to set up but pays back through both lower token bills and better agent decisions. If you're running multi-agent coding at any scale, the question isn't whether to investigate context graphs but when.