The agentic RAG architecture map

What you'll learn

• Place each architecture from the course in one of five families by the kind of component it adds to plain RAG.
• Compare architectures in one unit, model calls per question, using the counts earlier labs recorded.
• Explain what that unit leaves out: index-time work, tokens per call and parts to test.
• Count a stacked design component by component, so a review can remove one and know what it saves.

T14.1 asked whether a requirement needs retrieval or a fine-tuned model. This module assumes retrieval and asks which retrieval architecture.

Picture Larkspur's design review. The support assistant answers from the handbook, and three engineers each bring a proposal for the outage question, What happens if my server goes down? One wants Self-RAG, one a supervisor over billing, operations and data agents, one GraphRAG. Each argues in the vocabulary of the module that taught it: reflection tokens, handoffs, communities. Nobody can say which proposal costs more, or which part of the pipeline each one changes.

We call this a feature-list review: designs compared by what they contain instead of by what they change and what they cost. The rest of this page gives the review two things it lacks, a map that sorts the designs by the component they add, and a common unit to price that component.

The course keeps two inventories of what it teaches. The wider one, docs/agentic-architectures.yaml, rendered as Agentic Architecture Coverage, compares the course with an upstream catalogue of 35 agentic architectures in seven families. It finds all 35 covered: 33 by a dedicated notebook, 1 merged into another notebook and 1 taught as an adaptation. Five of the 35 are retrieval architectures, and all five are on the mandatory track:

Table 1: The five retrieval architectures of the upstream catalogue, numbered as it numbers them, and the modules that teach them.

The narrower inventory is this lesson's reading. It maps the retrieval side by graph shape rather than by folder, and names five architectures covered end to end: CRAG, Adaptive RAG, Self-RAG, domain-router RAG and retrieval as a tool. For each one it writes out the nodes and the conditional edges between them. CRAG, for example, retrieves, grades the documents, then either rewrites the query and retries or falls back to web search, and only then generates. Its table has a sixth row, the T9.1 agent with query rewriting and guardrails, although the text above it says five. It lists RAPTOR and the GraphRAG notebooks as anthology variants, and records one gap: CacheRAG exists in the source repository only as an empty placeholder.

Neither inventory says when to use what. For that, the architectures need a common unit. Every one of them is the T5.1 pipeline (retrieve, then generate) with components added, and each component is paid for in model calls per question. The course's labs have counted those calls on Larkspur questions:

Figure 1: Model calls per question for each architecture, as the course's labs and notebook code counted them. The magenta point is plain RAG at 1 call, the baseline every range is measured against.

The ranges come from different questions and settings. Read them as orders of magnitude. The same counts as a table, cheapest first:

Table 2: The counts behind Figure 1. Collapsed-tree RAPTOR and GraphRAG have no counted query cost.

The top of the scale has a source each. The retry loop reaches 10 calls in T9.1 with two rewrites allowed, and Self-RAG reaches 20 at k = 5 on a question the handbook cannot answer (T9.2).

Pitfall: the index-time blind spot. RAPTOR and GraphRAG are missing from the axis because their main cost is model calls made while building the index, one summary or extraction call after another. A per-question count makes them look free. Count that work separately, and count it again each time the handbook changes.

A count tells us what a design costs. The next section sorts the designs by what they buy with it.

The module objectives sort the architectures into five families. Each family adds a different kind of component to plain RAG, at a different place in the pipeline:

Figure 2: Plain RAG with each family's component in its place. A tool-based design hands the retrieve, grade and rewrite loop to a model that decides when to search.

Each family has a module whose theory page measures what its component buys:

• Entry-level changes nothing in the control flow and improves what reaches the model. Plain RAG and its baseline (T5.1), indexing that searches small and returns large (T5.6), hybrid search (T6.1), query transformation (T6.2) and reranking (T6.3). Late interaction (lesson 2 of T15.1) belongs here too. Most add no model call; query rewriting adds one, decomposition four.
• Self-correcting puts a judgement between retrieval and the answer: grade, rewrite and retry (T9.1), CRAG and Self-RAG (T9.2), graders and user feedback (T9.5). Each check is a model call, and each failed check sends the question round again.
• Routing decides where a question goes before anything is retrieved: a classifier over knowledge bases and adaptive RAG (T9.3), then supervisors, hierarchies and swarms of specialist agents (T11.1). A misroute hides the answer, because the filter restricts retrieval to a knowledge base that does not hold it.
• Tool-based hands retrieval to a model that decides when to call it: ReAct (T7.2), plan and execute (T8.1) and retrieval as a tool (T9.4). The same tool can be served over MCP and called across agents over A2A (T12.1 to T12.4) without changing the loop.
• Structural changes the shape of the index: summary trees (T13.1), knowledge graphs (T13.2) and community-based GraphRAG (T13.3). The work moves to index time, and the index has to be rebuilt or patched when the handbook changes.

Memory (T10.1, T10.2) cuts across all five. A follow-up such as How long do I have? needs rewriting into a standalone question before any of these architectures can retrieve for it.

The families also stack. The T9.1 agent is a tool-based loop with a self-correcting grader, and adaptive RAG in T9.3 is a router in front of two graders. A stacked design priced as one total is a lump-sum design: a later review cannot remove one component without guessing what it cost. Count each component's calls separately instead, the loop's and the grader's, and the design document shows what each removal saves.

The map and the unit come together when we run one question through every family.

The T15.1 lab holds the counts earlier labs recorded for six Larkspur questions. For Can I export my data after I cancel my plan? it lists ten architectures, and all but one answer:

Table 3: The export question through every family, as the T15.1 lab records it. The routing rows assume the handbook split into three knowledge bases.

Read the table as the review should:

1. Plain TF-IDF RAG already answers, at 1 call.
2. Every family above it also answers, and each adds calls without changing the outcome: the grader passes both chunks, CRAG never searches the web, Self-RAG's checks all say yes.
3. The one architecture that falls short is an entry-level swap: dense retrieval ranks cancel above export and recalls half the evidence. A retrieval upgrade is not better on every question.

Key distinction: a family earns its calls on the questions where the cheaper design fails. On a question plain RAG answers, every extra call is overhead. Lesson 3 of T15.1 turns this into a decision procedure, run on the questions where plain RAG does fail.

The map compares query-time model calls, and three costs sit outside it:

• Index-time work. The structural family's main cost, paid again on every handbook change.
• Tokens per call. A loop re-reads its message list on every call, and its tenth call costs more than its first.
• Different questions. Each range in Figure 1 comes from the question and settings its lab used. Two ranges are comparable in order of magnitude, not call for call.

The code for this lesson is in these notebooks. Colab runs one in your browser: install the packages its first cell imports and set the API keys it reads. To run every notebook as written, clone the repository and use its uv environment.

• Every architecture is retrieve-then-generate with components added. Compare them in model calls per question: plain RAG is 1, routing and tool loops 2 to 7, self-correcting loops up to 20.
• Each family adds one kind of component: better context, a judgement step, routing, a model that calls retrieval, or a new index shape whose cost moves to index time.
• Families stack. Count each component's calls separately so a review can remove one and know what it saves.