Chapter 10
A Personalized, Diagram-Based Explainer
Chapter 9 explains this app's architecture, but it does so the same way for every reader: one fixed diagram, one fixed block of text, regardless of what that specific person actually wants to understand. The feature below works differently. Ask it your own question, in your own words, and it builds a diagram and an explanation scoped to exactly what you asked, not a page everyone sees identically.
It's built with two related but genuinely distinct tools from the same ecosystem: LangChain and LangGraph. People new to both tend to collapse them into one thing because they're developed by the same company and typically imported together, but they solve different problems, and this page's own backend code uses both of them separately, in different files and for different jobs.
LangChain is the older and more general of the two: a library of standardized building blocks for a single call to a language model. Instead of writing provider-specific HTTP calls for Claude, then separate ones for GPT-4 or a local model, LangChain gives every provider the same interface, so switching providers is a one-line change instead of a rewrite. It also supplies reusable pieces around that one call: prompt templates (fill-in-the-blank wrappers around a system prompt, so the surrounding instructions don't get retyped for every request), and typed message objects for the system instructions and the human's input, rather than hand-built JSON. A single LangChain call, by itself, has no multi-step workflow at all: prompt in, one model call, text back out. That's exactly what this page's diagram and explain steps each do under the hood, through LangChain's ChatAnthropic class and its SystemMessage/HumanMessage types, visible directly in this app's backend source (backend/src/explainer/buildAndRun.ts). Chapter 1's token-cost calculator and Chapter 4's agent make the same kind of single call to Claude, just via the raw Anthropic SDK instead of LangChain's wrapper around it, which is why this feature, not those, is the one actually demonstrating what LangChain is for.
LangGraph, built on top of LangChain, solves a different problem: once an application needs more than one model call, in some fixed or branching order, something has to track which step runs next and what accumulated state, the original question, the passages retrieved so far, the diagram once it exists, gets carried forward into the next one. LangGraph's answer is an explicit graph: named nodes, each a plain function that reads the shared state and returns updates to it, wired together with edges that declare which node is allowed to run after which. Real production uses go well beyond this page's fixed three-step line: a customer-support bot that retries a failed tool call once before escalating to a human, a coding assistant that loops back to search again if its first attempt at a fix doesn't compile, or a claims-processing pipeline with a conditional edge that skips an expensive manual-review step entirely once a cheaper automated check already clears the claim. This page's own feature is the simplest shape that idea can take: a StateGraph with exactly three nodes, retrieve, diagram, and explain, wired START → retrieve → diagram → explain → END in one straight line, with no branching or retries, because unlike the examples above, this particular task never needs to double back.
In this demo
Every question you ask below runs the actual three-node StateGraph described above:
retrieve— your question is embedded and searched against the same real, pgvector-backed knowledge base Chapter 3's RAG demo uses, so the diagram and explanation are grounded in real retrieved passages, not invented from nothingdiagram— a real LangChain call to Claude turns those passages into a Mermaid diagram definition, plain text describing which boxes exist and how they connect; a separate, deterministic renderer (not the model) turns that text into the actual diagram you seeexplain— a second real LangChain call to Claude writes the accompanying explanation from the same retrieved passages
There's also a plain, standalone version of this same feature at /explain, with none of this chapter's own explanation attached, meant for someone who wants the app explained to them before they've decided to read a chapter about how it works.
Sources & Further Reading
Try it yourself
Two separate, real implementations, run back to back below so the difference is something you can see, not just read about. Same general task, explaining a concept, deliberately different machinery underneath.
LangChain only
one direct callThis box does the simplest thing possible: it takes the word you type below, drops it into a ready-made question like “explain this term in a couple sentences,” sends that straight to Claude, and shows you whatever Claude writes back. One request, one reply, nothing else happens in between. No searching anything first, no multiple steps, no second AI call.
Or try one of these
LangGraph workflow
3-step graphThis box does more work behind the scenes, in the same fixed order every time. First, it searches a real knowledge base for passages related to your question. Second, it sends those passages to Claude and asks for a diagram. Third, it sends the same passages to Claude again, separately, and asks for a written explanation. Three steps chained together in sequence, not the single request-and-reply in the box above.
Not sure what to ask? Try one of these