Classic vs Graph vs Agentic vs Multi-Agent RAG

Core Concept LearningJuly 1, 20264 min readUpdated July 17, 2026

Retrieval-Augmented Generation (RAG) grounds LLM answers in your data, not only model weights. Four levels show up in production: Classic (fixed retrieve → generate), Graph (linked entities), Agentic (one agent that plans, tools, and retries), and Multi-Agent (orchestrator + specialists).

Treat them as levels of control and cost, not rival brands. Over-building a FAQ into a multi-agent mesh wastes money; under-powering research with Top-K chunks alone leaves gaps. For the broader vocabulary map, see RAG Types and When to Use Them. For stores see Top 15 Vector Databases; for agent loops see What Is Agentic AI? and MCP vs A2A vs ACP.

Knowledge map: Classic → Graph → Agentic → Multi-Agent (cost ↑)

Learning path

Follow these checkpoints in order — each builds on the last.

Question shape picks the level — a paragraph answer wants Classic, a relationship question wants Graph — and upgrading before measured quality plateaus just adds latency and ops cost with nothing to show for it.
Classic RAG's quality lives in chunking, embeddings, and Top-K — not the agent framework wrapped around it, and no planner here re-queries when the context comes back thin.
A knowledge graph pays off on "how are A and B related?" questions — building one for a flat FAQ like a refund policy just adds extraction drift and schema maintenance with no query it answers better.
An agent's plan → act → observe loop without a step cap is how a single-doc FAQ question turns into a tool loop and unbounded spend — cap steps and tokens before the first production run, not after.
Three agents answering "what is our refund policy?" is over-engineering — multi-agent earns its ops cost only when trust domains or specialist surfaces genuinely split, not by default.
Promote Classic → Graph → Agentic → Multi-Agent only when the next level beats the current one on the same gold set by a margin that justifies its added cost and latency — architecture fashion isn't a metric.

Comparison at a glance

Skim this ladder before the deep sections. Upgrade only when measured answer quality plateaus — not because a slide looks complete.

Classic — lowest latency/cost; best for FAQ facts in a paragraph; fails on multi-hop relations and live tools.

Graph — medium cost; best when the question is about how entities connect; fails if you never built a maintainable graph.

Agentic — higher latency/tokens; best for multi-step tool use and retries; fails with tool loops and unbounded spend.

Multi-Agent — highest ops cost; best when specialists or trust domains truly split; fails when one agent with clear tools would do.

Quick reference

Question shape → level: paragraph → Classic · relationship → Graph · tools+retry → Agentic · split domains → Multi-Agent.
Latency/cost generally rises Classic → Graph → Agentic → Multi-Agent.
Compose upward: agents call vector and graph tools — they are not mutually exclusive products.
Measure before upgrading: faithfulness, citation hit rate, cost per query, p95 latency.

Remember this

Question shape picks the level — a paragraph answer wants Classic, a relationship question wants Graph — and upgrading before measured quality plateaus just adds latency and ops cost with nothing to show for it.

Classic RAG

Classic RAG is a fixed pipeline: ingest → embed chunks into a vector DB → at query time embed the question → retrieve Top-K → augment (query + passages + system prompt) → generate. No planner decides whether to retrieve again.

It wins on FAQs when the answer lives in a paragraph. Quality is mostly chunking, embeddings, and Top-K — not agent frameworks.

Classic RAG: Query → Embed → Vector DB → Augment → LLM → Output

Quick reference

Flow: data → embed → vector DB; query → embed → retrieve → augment → LLM.
Best for: FAQs, support, internal docs, single-hop facts.
Weak at: multi-hop relationships and live system actions.
Stack: embeddings + Pinecone/Chroma/Weaviate/pgvector + LLM.

Pipeline: retrieve → generate

1const qVec = await embed(userQuery);2const hits = await vectorDb.search(qVec, { k: 5 });3const context = hits.map((h) => h.text).join("\n---\n");4 5const answer = await llm.chat([6  { role: "system", content: "Answer only from CONTEXT. Cite sources." },7  { role: "user", content: `CONTEXT:\n${context}\n\nQUESTION: ${userQuery}` },8]);

Limits of this pipeline

1// No re-query if CONTEXT is thin2// No tool calls (tickets, SQL, web)3// No graph traversal of "vendor → risk → Acme"4// Fix first: chunking, filters, hybrid search5// Add agents only after evals still fail

Remember this

Classic RAG's quality lives in chunking, embeddings, and Top-K — not the agent framework wrapped around it, and no planner here re-queries when the context comes back thin.

Graph RAG

Graph RAG stores nodes and edges. At query time you extract entities, traverse a neighborhood, and pass that connected context to the LLM — not only cosine-similar chunks.

Use it for org charts, supply chains, compliance maps. Skip it when the corpus is flat FAQ text. Often hybrid: vector hit, then expand via graph neighbors.

Graph RAG: Query → Entities → Knowledge graph → Context → LLM

Quick reference

Pipeline: extract entities/relations → store graph → traverse at query time.
Strong for fraud, recommendations, regulatory mapping.
Higher build/ops cost than Classic RAG.
Hybrid is common: vectors for prose, graph for links.

Traversal sketch (Cypher-style)

1// After NER: entities = ["Acme", "VendorX"]2const cypher = `3MATCH (a:Org {name: $name})-[r:SUPPLIES|SHARES_RISK*1..2]-(b)4RETURN a, r, b LIMIT 405`;6const subgraph = await graph.query(cypher, { name: "Acme" });7const context = formatGraph(subgraph); // nodes + edge labels as text8const answer = await llm.chat([9  { role: "system", content: "Use only the graph context. Name relationships." },10  { role: "user", content: `GRAPH:\n${context}\n\nQ: ${userQuery}` },11]);

When Graph RAG is the wrong default

1// Wrong: build a knowledge graph for "What is our refund policy?"2// Right: Classic RAG on the policy doc3// Escalate to Graph when questions are mostly "how are A and B related?"4// Budget for extraction drift and schema maintenance

Remember this

A knowledge graph pays off on "how are A and B related?" questions — building one for a flat FAQ like a refund policy just adds extraction drift and schema maintenance with no query it answers better.

Agentic RAG

Agentic RAG puts a single agent in the loop: memory + planning + tools (retrievers, APIs, search). Mechanism: plan → act → observe → (optional) replan. Failure modes: tool loops, unbounded cost, silent bad retrieves.

When not to: a single-doc FAQ — Classic is simpler. Trace every tool call in production.

Agentic RAG loop: plan → act → observe → retry until done

Quick reference

Agent owns planning; retrieval is one tool among many.
Self-check reduces thin replies — watch token spend.
Frameworks: LangGraph, CrewAI, AutoGen, or a tiny custom loop.
Classic/Graph retrievers become tools — not rival products.

Minimal ReAct-style loop

1async function agenticAnswer(query: string, maxSteps = 4) {2  const memory: string[] = [];3  for (let i = 0; i < maxSteps; i++) {4    const step = await llm.plan({ query, memory }); // { tool, args } | { final }5    if (step.final) return step.final;6    const observation = await tools[step.tool](step.args); // vectorSearch, graphQuery, http7    memory.push(`tool=${step.tool} → ${truncate(observation)}`);8  }9  return llm.summarize({ query, memory }); // forced stop10}

Guardrails this loop still needs

1// Cap steps and tokens per request2// Idempotent tools; log every call3// Self-check / citations before user-facing answer4// Prefer Classic when one retrieve succeeds on the eval set

Remember this

An agent's plan → act → observe loop without a step cap is how a single-doc FAQ question turns into a tool loop and unbounded spend — cap steps and tokens before the first production run, not after.

Multi-Agent RAG

Multi-Agent RAG adds an orchestrator that delegates to specialists. MCP is one way to expose tools — a tool interface, not a requirement for the label “multi-agent.” Prefer one strong agent until product boundaries force specialists (credentials, rate limits, parallel skills).

Multi-Agent: Aggregator → specialists (tools/MCP) → merge → generate

Quick reference

Aggregator routes; specialists retrieve/act; model may synthesize.
ReAct/CoT describe planning style — not a separate product.
Best for: research across trust domains, parallel tool-heavy work.
Skip when one retriever + one LLM answers the measured set.

Orchestrator sketch

1async function multiAgentAnswer(query: string) {2  const plan = await orchestrator.plan(query);3  const parts = await Promise.all(4    plan.tasks.map((t) => specialists[t.agent].run(t))5  );6  const draft = await orchestrator.merge(parts);7  return generativeModel.complete({ query, context: draft });8}

When multi-agent is the wrong default

1// Wrong: three agents for "What is our refund policy?"2// Right: Classic RAG (or one agent + vector tool)3// Escalate when trust domains or specialist surfaces truly split

Remember this

Three agents answering "what is our refund policy?" is over-engineering — multi-agent earns its ops cost only when trust domains or specialist surfaces genuinely split, not by default.

How to measure which level is enough

Do not pick a level by architecture fashion. Build a small eval set (20–50 real questions with expected citations or graded answers). Score faithfulness (answer supported by retrieved context), citation hit rate, refusal on unknowns, p95 latency, and cost per query (embed + LLM + tools).

Libraries in the RAGAS / DeepEval family help automate faithfulness and relevancy checks — use them as harnesses, not as a substitute for domain-labeled gold answers. Promote Classic → Graph → Agentic → Multi-Agent only when the next level wins on the same set by a margin that justifies cost.

One query: retrieval scores too low — refuse instead of inventing

Quick reference

Start with Classic baseline metrics on your gold set.
Add Graph only if relationship questions fail Classic after retrieval tuning.
Add Agentic only if tool-needed questions fail one-shot retrieve.
Add Multi-Agent only if one agent’s tool surface or trust boundaries break down.
Track cost/query and p95 — agent loops hide spend until production.

Remember this

Promote Classic → Graph → Agentic → Multi-Agent only when the next level beats the current one on the same gold set by a margin that justifies its added cost and latency — architecture fashion isn't a metric.

Key takeaway

Classic RAG retrieves text in one shot. Graph RAG retrieves relationships. Agentic RAG plans, tools, and retries with one agent. Multi-Agent RAG delegates across specialists — useful when domains truly split, expensive when they do not.

Practice (25 min): Label ten real questions Classic / Graph / Agentic / Multi-Agent. Run Classic retrieve→generate on the FAQ subset. Write two eval questions that would force a tool-using agent — name the tools, not a framework shopping list.

RAG AI

RAG Types and When to Use Them

Jul 30, 2026 · 9 min read

RAG taxonomy gets confusing because people mix three different ideas: architecture levels, retrieval tricks, and product…

Read

AI Agents

Agentic AI Tech Stack Explained

Jul 30, 2026 · 8 min read

The infographic is useful because it names the eight shelves most agentic AI systems touch: deployment infrastructure, e…

Read

AI LLM

AI Stack Map: 12 Tools Across Six Lanes