Full transcription of a 20-slide builder's guide on choosing the memory architecture that matches your data shape and query patterns. Kept complete on request — every detail matters here. Overview + other memory tools: memory systems. Social-media source; claims unverified.

(Note: the original post's final sections — the full Python memory-router code, troubleshooting, and cheat sheet — were paywalled behind the creator's subscription; everything public is below.)

---

RAG VS GRAPH VS TABULAR MEMORY: THE AI BUILDER'S DECISION GUIDE

@DATASCIENCEBRAIN

SAVE THIS. BEFORE YOU LOSE IT. 👇

---

Stop Picking the Wrong Memory for Your Agent: A Builder's Guide to RAG, Graphs & Structured Data

Created by: https://www.instagram.com/datasciencebrain

---

Architecture Overview

+------------------------------------+  +------------------------------------+  +------------------------------------+
|             Vector RAG             |  |          Knowledge Graph           |  |            Tabular / SQL           |
|                                    |  |                                    |  |                                    |
|             [Document]             |  |               (Person)             |  |      +----+------+-------+-------+ |
|                 |                  |  |               /   |   \            |  |      | ID | Name | Cat   | Amt   | |
|         [Split into Chunks]        |  |     works_for/ attends \lives_in   |  |      +----+------+-------+-------+ |
|          /      |      \           |  |             v     v     v          |  |      | 1  | WidA | Gadg  | 120.0 | |
|    [Chunk]   [Chunk]   [Chunk]     |  |     (Company) -> (Event) ->(Location)| |      | 2  | WidB | Gadg  | 75.5  | |
|       |         |         |        |  |         |        ^    ^    ^         |  |      +----+------+-------+-------+ |
|       v         v         v        |  | produces|features|    |    |         |  |                 [ Q ]              |
|      [( Vector Database )]         |  |         v      /     /    /          |  |                                    |
|                 |                  |  |       (Product)-----/----/           |  |                                    |
|                 v                  |  |                                    |  |                                    |
|         Search / Similarity        |  |                                    |  |                                    |
+------------------------------------+  +------------------------------------+  +------------------------------------+
|  Store document chunks as vectors  |  |   Model entities and relationships |  |    Store structured data in tables |
|   Retrieve by semantic similarity  |  |      Enable multi-hop reasoning    |  |       Query with SQL for precision |
+------------------------------------+  +------------------------------------+  +------------------------------------+

---

Table of Contents

The Real Problem Nobody Talks About
How Agent Memory Actually Works: The Four Tiers
The Three Long-Term Memory Architectures
RAG - The Semantic Similarity Machine
Knowledge Graphs - The Relationship Reasoner
Tabular / Structured Memory - The SQL Brain
Head-to-Head: When Each One Wins and Fails
The Decision Framework
Hybrid Architectures: What Production Actually Looks Like
A Lightweight Memory Router in Python
Quick Reference Cheat Sheet

---

1. The Real Problem Nobody Talks About

When an AI agent gives you a wrong, irrelevant, or hallucinated answer, your first instinct is to blame the model. Change the LLM. Tweak the prompt. Try a different temperature.

Nine times out of ten, that is the wrong diagnosis.

The model is fine. The retrieval layer is broken.

Here is the core insight that separates engineers who build reliable agents from those who spend months debugging in circles:

Your agent is only as good as what it can remember and retrieve. The model processes. The memory decides what gets processed.

An agent that cannot find the right context will always fail, no matter how capable the underlying LLM is. You could wire up GPT-5 or Gemini 3 Pro to a poorly designed memory layer and watch it confidently hallucinate. You could use a smaller, cheaper model with a well-designed retrieval architecture and watch it perform reliably at scale.

The question this guide answers is not which memory technology is best in the abstract. That is the wrong question. The right question is:

Which memory architecture matches the shape of my data and the reasoning pattern my agent needs?

Get this decision right early and your agent is fast, accurate, and scalable. Get it wrong and you will spend months debugging what look like model failures but are actually retrieval failures.

Let us fix that.

---

2. How Agent Memory Actually Works: The Four Tiers

Before comparing specific technologies, you need a mental model of how agent memory is structured. Most builders only think about one tier. Production agents use all four.

+---------------------------------------------------------------------------------------------------------+
|                                      THE FOUR TIERS OF AGENT MEMORY                                     |
+------------------------------------+------------------------------------+-------------------------------+
| Tier 1: Working Memory             | What the model sees RIGHT NOW      | 128K-200K tokens | Instant    |
| (Context Window)                   |                                    | Bounded                       |
+------------------------------------+------------------------------------+-------------------------------+
| Tier 2: Episodic Memory            | What happened in THIS conversation | Conversation logs | Short-term|
| (Session State)                    |                                    | Per-session                   |
+------------------------------------+------------------------------------+-------------------------------+
| Tier 3: Semantic Memory            | What the agent KNOWS about the     | RAG / Knowledge Graphs /      |
| (Long-term Knowledge)              | world                              | Tables | Persistent           |
+------------------------------------+------------------------------------+-------------------------------+
| Tier 4: Procedural Memory          | HOW the agent does things          | Tool definitions | Function   |
| (Skills & Tools)                   |                                    | schemas | Workflows          |
+------------------------------------+------------------------------------+-------------------------------+

Tier 1 - Working Memory (Context Window)

This is the model's "active desk." Everything injected into the context window - the system prompt, the user's question, retrieved documents, conversation history - lives here. It is instant to query and cheap, but it is bounded. Once it fills up, something gets dropped. This tier is not configurable in terms of technology; every LLM provider manages it differently.

Tier 2 - Episodic Memory (Session State)

This is the record of what happened in a session. When a user says "as I mentioned before" or "continue from where we left off," they are asking the agent to access episodic memory. Simple implementations store raw conversation logs. Smarter implementations compress session history into structured summaries after each turn, so the agent carries forward the meaning of a conversation, not just its literal text. This tier typically lives in a key-value store or database, scoped per user and per session.

Tier 3 - Semantic Memory (Long-term Knowledge)

This is the tier this guide is about. Semantic memory is persistent, cross-session knowledge that the agent uses to ground its answers in facts. This is where RAG, knowledge graphs, and tabular models live. The choice of technology here determines whether your agent can answer complex questions accurately, personalise responses, reason over relationships, or handle structured lookups.

Tier 4 - Procedural Memory (Skills & Tools)

This is how the agent knows what it can do. Tool definitions, function schemas, workflow templates. This is defined at build time and does not change per query. It is the least discussed tier and the least configurable.

The rest of this guide focuses entirely on Tier 3 - Semantic Memory, because that is where the architecture decisions are hardest, the tradeoffs are highest, and the failure modes are most common.

---

3. The Three Long-Term Memory Architectures

Every piece of information your agent needs to retrieve has a shape. The shape of the data - how it is structured, how it relates to other data, how it changes over time - determines which retrieval architecture fits.

       DATA SHAPE                              MEMORY ARCHITECTURE
+---------------------------+             +---------------------------+
|      Structured Data      | ----------> |       Tabular / SQL       |
| (rows, columns, numbers)  |             |   Deterministic Lookup    |
+---------------------------+             +---------------------------+
|     Unstructured Text     | ----------> |        Vector RAG         |
|  (docs, PDFs, articles)   |             |    Semantic Similarity    |
+---------------------------+             +---------------------------+
|      Relational Data      | ----------> |      Knowledge Graph      |
|  (entities + connections) |             |   Relationship Traversal  |
+---------------------------+             +---------------------------+

Three architectures. Three different shapes of data. Three different reasoning patterns. This is the map. The sections below are the territory.

---

4. RAG - The Semantic Similarity Machine

What it is

Retrieval-Augmented Generation (RAG) is the most widely deployed long-term memory pattern for AI agents today. The core idea is elegant: instead of storing information in the model's weights (which requires expensive retraining), you store it externally as vector embeddings. At query time, you retrieve the chunks most semantically similar to the user's question and inject them into the model's context.

How the pipeline works

 [Documents]
      |
      v
 (1. Chunk 200-1000 tokens)
      |
      v
  [Chunks] <------------------------------------------+
      |                                               |
      v                                               v
 (2. Embed via embedding model)                 [? User Query]
      |                                               |
      v                                               v
  [Vectors]                                     (4. Embed query)
      |                                               |
      v                                               v
  (3. Store)                                    [Query Vector]
      |                                               |
      v                                               v
+-------------------------------+             (5. Similarity Search)
| Vector DB                     | <----------- (cosine / dot product)
| Pinecone / Qdrant /           |                     |
| ChromaDB / pgvector           |                     v
+-------------------------------+             [Retrieved chunks]
                                                      |
                                                      v
                                            [LLM Context Window]
                                                      |
                                                      v
                                                 (7. Generate)
                                                      |
                                                      v
                                              [Grounded Answer]

Ingestion - Documents are split into overlapping chunks (typically 200–1,000 tokens with a 10–20% overlap). Each chunk is passed through an embedding model (like text-embedding-3-large, gemini-embedding-001, or a HuggingFace model) and converted into a high-dimensional vector. That vector - along with the original chunk text and metadata - is stored in a vector database.
Retrieval - When a query arrives, it is embedded using the same embedding model. The vector database performs a nearest-neighbour search (using cosine similarity or dot product) and returns the top-K chunks whose embeddings are most similar to the query embedding. These chunks are injected into the LLM's context window.
Generation - The LLM sees the original question plus the retrieved chunks as grounding context. It synthesises a response based on what was retrieved, not purely on what it learned during training.

What RAG is really good at

Broad document Q&A. If you have a corpus of PDFs, wikis, support tickets, or research papers and you want your agent to answer natural language questions about them, RAG is the right architecture. It handles unstructured text natively and scales to millions of documents through approximate nearest-neighbour indexing.
Citation-friendly answers. Because every retrieved chunk is traceable to a source document, RAG makes it easy to attach references to answers. This is critical in enterprise settings where "trust but verify" is the standard.
No model retraining. New documents simply get chunked, embedded, and added to the vector store. The model weights never change. This means your knowledge base can be updated in real time without any ML training pipeline.
Fuzzy, semantic queries. RAG understands intent, not just keywords. A query like "what causes neural networks to forget old knowledge?" will correctly retrieve documents about catastrophic forgetting, even if the exact phrase "catastrophic forgetting" never appeared in the query.

Where RAG breaks down

Understanding RAG's failure modes is just as important as understanding its strengths. These are not edge cases - they are structural limitations of the architecture.

Multi-hop reasoning failure. Consider this question: "How did the delay in Project Apollo affect Q3 APAC margins?" A RAG system will retrieve documents about Project Apollo and documents about APAC margins. What it cannot do is reason about the causal relationship between them - that is a connection that requires traversing a chain of logic, not just finding similar text. RAG retrieves; it does not reason over relationships.
Chunk boundary problems. Information is split into chunks during ingestion. If a critical piece of context spans a chunk boundary, both halves may be retrieved independently, but the connection between them may be lost. This is why careful chunk size and overlap tuning matters so much.
No session continuity. Standard RAG has no concept of "what did this user ask before." Every query goes to the same flat index and retrieves the same type of results regardless of who is asking or what they asked in previous sessions. Personalisation requires an additional memory layer on top.
Semantic noise at scale. The more documents you index, the noisier the retrieval becomes. Two chunks can be semantically similar but contextually irrelevant for a given query. Top-K retrieval has no way to distinguish "this is similar" from "this is what you actually need."
Context window stuffing. If retrieved chunks are long or retrieval is tuned aggressively, the injected context can consume most of the model's context window, leaving little room for reasoning or multi-turn dialogue.

Cross-reference: The LightRAG guide in this vault covers how LightRAG addresses several of these failures by combining vector search with a knowledge graph layer - getting semantic retrieval and relationship reasoning in one system.

---

5. Knowledge Graphs - The Relationship Reasoner

What it is

A knowledge graph represents the world as a network of entities (things) and edges (relationships between things). Where RAG asks "what text is most similar to this query?", a knowledge graph asks "how is X connected to Y, and through what path?"

This is a fundamentally different way of thinking about information. Instead of retrieving passages, you traverse structure.

How a knowledge graph is built and queried

========================= INGESTION =========================
 [Raw Text] -> (NLP Extraction) -> [Entity-Relation Triplets]
                                      (Subject->Predicate->Object)
                                                  |
                                                  v
                                      +-------------------------+
                                      | Knowledge Graph DB      |
                                      | Neo4j / Neptune         |
                                      | LightRAG / GraphRAG     |
                                      +-------------------------+
                                                  |
========================= QUERYING ==========================
 [? User Query]                                   | (Graph Traversal)
       |                                          v
       v                                      [Subgraph]
 (Entity Recognition)                             |
       |                                          v
       v                                  [Structured Context]
 [Seed Entities]                                  |
       |                                          v
       +----------------------------------> (Inject into LLM)
                                                  |
                                                  v
                                      [Relationship-Aware Answer]

Ingestion - Text is processed by an entity extraction pipeline (often an LLM itself) that identifies entities (people, organisations, products, concepts) and the relationships between them, producing triplets in the form (Subject -> Predicate -> Object). For example: ("Project Apollo" -> "delayed_by" -> "3 weeks") and ("Project Apollo" -> "affects" -> "Q3 APAC Revenue"). These triplets are stored in a graph database.
Querying - When a query arrives, the system identifies seed entities from the query text, then traverses the graph outward from those seeds, following edges to collect a relevant subgraph. This subgraph - which encodes not just facts but their relationships and the paths between them - is serialised and injected into the LLM's context.
Generation - The LLM receives structured, relationship-aware context. It can now answer multi-hop questions because the relationships are explicit, not implied.

What knowledge graphs are really good at

Multi-hop reasoning. This is the killer use case. A knowledge graph can answer "Which engineers worked on projects that were flagged by the same auditor who reviewed Project Beta?" by traversing a chain of relationships: engineer -> project -> auditor -> review. RAG cannot do this. The answer is not in any single document; it exists only as a path through a graph.
Relationship queries. "How is concept A related to concept B?" "What is the shortest path between entity X and event Y?" "What are all the dependencies of component Z?" These are all native graph queries. The answer comes back as a traversable path, not a block of text.
Consistency and deduplication. Knowledge graphs enforce entity identity. If your documents mention "Apple Inc.", "Apple", and "AAPL", a well-built graph collapses these into a single node. RAG would retrieve different chunks for each representation, potentially missing connections.
Explainable answers. Because the reasoning path through the graph is explicit - A -> B -> C -> answer - knowledge graph responses can be fully traced. This is valuable in regulated industries where you need to explain why an answer was given.

Where knowledge graphs break down

High construction cost. Building a high-quality knowledge graph requires a reliable entity extraction pipeline, careful schema design, and ongoing maintenance as new data arrives. If your extraction pipeline is noisy (which LLM-based extractors often are), your graph will be polluted with incorrect or duplicate entities, and queries will return wrong results.
Poor handling of unstructured nuance. Some information simply does not reduce to triplets. Tone, ambiguity, context-dependence, and narrative flow are all lost when text is converted to a graph. A document that argues "usually, but not always, when X happens, Y follows" becomes (X -> causes -> Y), which is a lossy and potentially misleading representation.
Tooling gap. RAG has mature, well-documented tooling (LangChain, LlamaIndex, ChromaDB, Qdrant) with huge communities and abundant online content. Knowledge graph tooling (Neo4j, Amazon Neptune, Graphiti) has a steeper learning curve, less documentation in accessible formats, and fewer tutorials aimed at beginners.
Update complexity. When facts change in a graph - a product is deprecated, a person changes roles - you need to update specific nodes and edges. In RAG, you re-chunk and re-embed the updated document. Graphs require more surgical precision, and incorrect updates can cascade through connected nodes.

Cross-reference: The GraphRAG from Scratch guide in this vault walks you through building a full knowledge graph with Neo4j AuraDB and FastAPI that handles entity ID namespace collisions - a real-world problem this theory section cannot cover.

---

6. Tabular / Structured Memory - The SQL Brain

What it is

Tabular memory is the use of structured, relational databases as an agent's long-term knowledge store. This is not a new technology - SQL databases have existed for decades. But they are consistently underused in AI agent architectures, often because builders default to RAG for everything.

If your data is already structured - rows, columns, foreign keys, timestamps - then forcing it through a vector embedding pipeline and doing semantic search on it is not just unnecessary. It is actively harmful. It introduces approximation error where deterministic lookup is both possible and correct.

How tabular memory works in an agent context

 [? Natural Language Query]
 "What did user123 order last month?"
             |
             v
     (Interpret intent)
             |
             v
   [LLM SQL Generator]  (Text-to-SQL)
             |
             v
       [Generate SQL]
             |
             v
+-------------------------------+
| Relational DB                 |
| PostgreSQL / SQLite / MySQL   |
+-------------------------------+
             |
             v
     (Execute & return)
             |
             v
  [Query Results (rows)]
             |
             v
        (Summarise)
             |
             v
       [Precise Answer]
  "3 orders totalling ₹4,200"

The modern pattern for tabular memory in agents is Text-to-SQL: the agent uses an LLM to translate a natural language query into a SQL statement, executes it against the database, and then uses the LLM again to summarise the results into a natural language response. This is deterministic at the retrieval stage - the SQL query either returns the right rows or it does not. There is no approximation, no "close enough."

What tabular memory is really good at

Numerical and financial queries. "What was the average order value in March?", "Which product has the highest return rate?", "Show me all users who have spent more than ₹10,000 this quarter." These questions have exact, deterministic answers. Embedding them as vectors and doing cosine similarity search would introduce unnecessary uncertainty into a problem that has a precise solution.
User state and personalisation. Every user's preferences, history, tier, and session data are naturally tabular. An agent that personalises responses based on user history should store that history in a structured database, not a vector index. "What has this specific user bought?" is a lookup, not a similarity search.
Audit logs and time-series. Agent actions, conversation summaries, tool call histories - these are naturally event-structured data. Time-series queries ("what did the agent do between 2pm and 4pm yesterday?") are trivially fast in a relational or time-series database. They are awkward and slow in a vector store.
Regulatory and compliance contexts. In finance, healthcare, and legal domains, answers often need to be exactly right, not approximately right. A RAG system might retrieve a policy document that is 90% similar to what you need. A SQL query retrieves the exact record you specified. When the answer has legal or financial consequences, determinism matters.
High-cardinality filtering. "Find all customers in Kerala who signed up in April 2026 and have not placed an order since." This is a multi-condition filter over structured fields. SQL handles this natively with indexes. A vector store would require metadata filtering, which is slower and less precise at scale.

Where tabular memory breaks down

Unstructured text content. If the answer to a question lives in a paragraph inside a document, a SQL query cannot find it. Relational databases store structured values in typed columns - they do not understand the meaning of a text blob. You cannot semantically search a notes column the way you can search a vector index.
Fuzzy or intent-based queries. "Find me something related to the onboarding problem we discussed" cannot be expressed as a SQL WHERE clause. Natural language understanding requires either a vector search or a very sophisticated text-to-SQL pipeline. Tabular memory requires that the user (or the LLM) knows approximately what they are looking for in structural terms.
Graph-like relationship queries. "Find all projects that share a dependency with Project X" requires self-joins or recursive CTEs in SQL. It is possible, but complex. It is trivial in a graph database. As the relational structure of your data becomes more complex, the SQL queries become harder to generate correctly, especially via an LLM.

---

7. Head-to-Head: When Each One Wins and Fails

Scenario	RAG	Knowledge Graph	Tabular/SQL
Q&A over a PDF corpus	Best fit	Overkill	Wrong shape
Multi-hop reasoning across entities	Struggles	Best fit	Complex joins
"What did this user buy last month?"	Wrong tool	Wrong tool	Best fit
"How is concept A related to B?"	Approximate	Best fit	Wrong tool
Semantic search over support tickets	Best fit	Overkill	Keyword only
Financial aggregate queries	Approximates	Wrong tool	Best fit
Citation-traceable answers	Native	Native	Native
Real-time data update	Re-embed	Surgical edits	UPDATE query
Beginner-friendly tooling	Very mature	Steep curve	Very mature
Handles unstructured nuance	Strong	Lossy conversion	Cannot

---

8. The Decision Framework

Use this as your first-pass filter whenever you are designing a new agent or adding a new knowledge source.

The Decision Flowchart

                     [What shape is your data?]
                            /          \
                           /            \
       [Unstructured text]               [Rows and columns]
         (docs, PDFs, wikis)            (users, orders, metrics)
                |                                  |
                v                                  v
 [What kind of questions will agents ask?]   ✅ Tabular / SQL Memory
         /                     \             PostgreSQL, SQLite, MySQL
        /                       \            Text-to-SQL pattern
[Find info]                 [Trace connections]
(semantic search)           (multi-hop reasoning)
      |                             |
      v                             v
✅ Vector RAG                 [Do relationships matter
ChromaDB, Qdrant,              more than raw text?]
pgvector                            /         \
Chunk->Embed->Retrieve             /           \
                             [Yes]           [No]
                              /                 \
                             v                   v
                    ✅ Knowledge Graph      ✅ Hybrid: RAG + Graph
                    Neo4j, LightRAG,        LightRAG, GraphRAG
                    GraphRAG                Semantic + Structural
                    Entity->Edge->Traverse

Five questions to sharpen your decision

Beyond the flowchart, these five questions will resolve most edge cases:

What is the shape of my data?

Text blobs -> RAG. Entities and relationships -> Knowledge Graph. Numbers, records, structured fields -> Tabular. If your data is a mix, your architecture should be a mix.

What kind of questions will my agent need to answer?

"Find me something similar to X" -> RAG. "How does A connect to B through C?" -> Knowledge Graph. "Give me the exact value of X for user Y" -> Tabular.

How often does the data change?

Frequent, unstructured updates (new documents daily) -> RAG handles this well, just re-embed. Structural changes to relationships -> Graph requires more careful management. Structured record updates -> SQL is trivially easy.

What is my team's capability?

RAG and SQL have the deepest tooling ecosystems and the most tutorials. If your team is new to AI engineering, RAG + SQL will get you 80% of the way to production faster than a knowledge graph will. Graphs require more upfront investment in schema design and extraction quality.

Does the answer need to be deterministic or approximate?

Regulatory, financial, or audit contexts where the answer must be provably correct -> Tabular. Research, Q&A, or discovery contexts where "close enough" is fine -> RAG. Relational reasoning where the answer is a path, not a value -> Knowledge Graph.

---

9. Hybrid Architectures: What Production Actually Looks Like

Here is the uncomfortable truth: the question is not "which one do I use?" It is "which combination do I use, and in what proportion?"

Most serious production agent architectures use more than one memory type. The data you are working with rarely fits neatly into a single category, and real user queries span multiple reasoning patterns.

The most common hybrid patterns

1. RAG + Tabular (the most common)

This is the default pattern for agents that serve real users. The agent uses RAG to answer knowledge questions from documents, and SQL to answer personalisation and history questions from structured records.

Example: A customer support agent that retrieves policy documents via RAG ("what is our refund window for electronics?") and retrieves user-specific order history via SQL ("show me this customer's last three orders").

2. RAG + Knowledge Graph (GraphRAG pattern)

This is what LightRAG and Microsoft's GraphRAG implement. The agent builds both a vector index and a knowledge graph from the same corpus. Simple semantic queries go to the vector index. Multi-hop relationship queries go to the graph. The retrieval layer routes based on query complexity.

Example: A research agent that can answer "What is the main theme of this paper?" via RAG and "Which authors in this corpus have co-published with researchers from IIT Bombay?" via graph traversal.

Cross-reference: Your LightRAG guides (Groq stack and Gemini free tier stack) in this vault cover the GraphRAG pattern in complete detail, including the cost story: $50+ per document with Microsoft GraphRAG vs. free with Gemini.

3. All Three (the production-grade pattern)

The most robust production agents maintain all three tiers: RAG for document knowledge, a knowledge graph for entity relationships, and SQL for user state and structured records. This is complex to build but covers virtually every retrieval pattern an agent will encounter.

The key engineering insight in a hybrid architecture is the memory router - a lightweight classifier (often an LLM call with a structured output prompt) that decides which memory backend to query before the retrieval happens. This is the component we will build in the next section.

---

10. A Lightweight Memory Router in Python

This section gives you a working skeleton of the hybrid architecture described above. The goal is not a production-ready system - it is a clear, readable illustration of how the routing logic works so you can extend it to your own backends.

                  [? User Query]
                        |
                        v
               +------------------+
               | Memory Router    | (LLM-based classifier)
               +------------------+
                 /      |       \
                /       |        \
  Semantic/fuzzy   Relational     Structured/exact
              /     multi-hop             \
             v          |                  v
    🔵 Vector RAG       v         🟡 SQL Database
    ChromaDB/Qdrant  🟣 Knowledge  PostgreSQL/SQLite
                     Graph (Neo4j)
             \          |                  /
              \         |                 /
               v        v                v
               +-------------------------+
               | ⚡ Context Assembly     |
               +-------------------------+
                            |
                            v
                    🤖 LLM Generation
                      (Final Answer)

We use Groq (llama-3.3-70b-versatile) as both the router and the answer generator. All three backends are simplified in-memory implementations so you can run this without any external database.

---