Corrective (adaptive) RAG

Corrective RAG has loops and branches: grade, then maybe rewrite and retrieve again, maybe search the web, then maybe regenerate. A linear chain cannot express that cleanly. In LangGraph each step is a node returning a state update, and conditional edges read typed fields like relevance flags or retry counts to decide where to go. That makes the control flow explicit and testable. I also get a checkpointer, so every super-step is saved per thread_id; I can resume after a failure, inspect exactly which documents were graded out, and use get_state_history to replay or fork a bad run. Streaming modes let me show progress like 'searching the web' to the user. The result is a pipeline where retrieval failure is a handled state, not a silent bad answer.

Sourced from Docs by LangChain (MCP)

I use a TypedDict with question, the current query, documents, generation, retries, source and attempt counters. Question stays fixed as the user's original wording, so graders and the grounding check always judge against intent. Query is what the rewriter changes. Documents holds normalised chunks, each with id, text, source type and URL or index reference. Retries counts rewrite loops, and a separate generation_attempts counts regenerations, so each limit is enforced on its own. Source records whether context came from the index or the web, for citations and analytics. The graded list uses an operator.add reducer so parallel grader outputs merge. The other keys are overwritten, which keeps the semantics of each update simple.

Sourced from Docs by LangChain (MCP)

I count by path, using top-k as k. On the happy path there is one router call, k grader calls, one generate call, and one grounding call if relevance and answer checks share a structured call. That is k plus 3, so 8 calls when k is 5. Each rewrite loop adds one rewriter call and another k grader calls. Web fallback adds grading of the web results. Each regeneration adds a generate and a grounding call. So the worst case is set by the retry and attempt limits, and I compute it explicitly when I set them. Grader calls dominate the count, though each is small. Generate dominates output tokens. I would then multiply by expected traffic and measured token sizes, rather than quoting numbers before measuring.

Sourced from Docs by LangChain (MCP)

I treat all retrieved text as untrusted data, never as instructions. In prompts, context goes inside clear delimiters, with a system instruction that content inside them cannot change the task. None of the LLM nodes that read context can call tools with side effects. The only tool is web search, and only a node decides to call it, based on the decide edge rather than document text. Structured output limits what graders can return. The grounding check is a second line of defence, because injected instructions rarely produce claims supported by the other context. I also allowlist or denylist domains for web search, strip scripts and hidden text during normalisation, and log flagged documents for review.

Sourced from Docs by LangChain (MCP)

I keep explicit counters in state, for example rewrite_attempts and generation_attempts, incremented by the rewriter and generator nodes. The conditional edge after grading checks the counter: below the limit it routes to rewrite, at the limit it routes to web search. After the grounding check, the same idea applies: regenerate only while attempts remain, otherwise return an abstention message. I treat the recursion limit as a safety net, not the design, because hitting it raises an error rather than a graceful answer. I also log every loop iteration to traces, so if loop rates rise I can see whether the index, the rewriter prompt or the grader threshold is the cause, and tune that rather than raising limits.

Sourced from Docs by LangChain (MCP)

First, they return structured output, a binary or scored field with a short reason, so edges branch on data. Second, I build a labelled eval set in LangSmith with relevant and irrelevant chunks and grounded and ungrounded answers, and measure grader agreement with human labels before trusting it in production. Third, the grounding checker gets the exact context passed to generation plus the answer, and checks claims against it; I prefer a different prompt and ideally a different model from the generator to reduce self-approval. Fourth, I monitor drift: pass rates, abstention rates and sampled human reviews. If the grader is too strict, loops and latency rise; too lenient, hallucinations slip through, so the threshold is tuned on data.

Sourced from Docs by LangChain (MCP)

The conditional edge after the router needs a value it can branch on reliably. With structured output I bind a schema, for example a Literal of 'vectorstore' or 'web_search', so the model returns a validated field rather than prose I would have to parse. That removes a whole class of failures, such as 'I think web search might help', which a string match would misroute. It also makes the decision loggable and testable: I can build a labelled set of questions and measure routing accuracy. If validation still fails, I default to a safe route, usually retrieval first, because the later grading and web fallback can correct a bad choice. A crash or a silent wrong branch is worse.

Sourced from Docs by LangChain (MCP)

After retrieve, a conditional edge function reads the documents and returns a list of Send('grade_document', {'question': q, 'document': d}) objects, one per chunk. Each Send runs the grader node with its own small per-item state rather than the full graph state. These branches run in parallel within the same super-step. Each grader returns either {'graded_documents': [d]} or an empty list. The operator.add reducer concatenates those updates into the shared state. The next node, or the decide edge, only runs after every branch in that super-step has finished, so the fan-in happens naturally. This is LangGraph's map-reduce pattern, and it avoids writing threading code by hand.

Sourced from Docs by LangChain (MCP)

operator.add only appends. On the second pass, the newly kept documents are added to the ones kept on the first pass. The decide edge may then count stale chunks from a different query and wrongly conclude that enough documents passed. Generate can also mix contexts. There are a few fixes. I can write a custom reducer that accepts a sentinel, such as a reset marker or None, to clear the list, and have the rewriter or retrieve node send it. Or I can key graded documents by attempt number and only read the current attempt. Or I can keep accumulation but have the decide edge filter by query version. I prefer the explicit reset reducer because it is easy to test.

Sourced from Docs by LangChain (MCP)

I do it in two layers. First, a deterministic check. The generate node returns structured output, such as claims with lists of cited ids. Code then confirms that every cited id exists in the current graded documents and that no claim lacks a citation. A fabricated or stale id fails immediately at no LLM cost. Second, the grounding grader checks each claim against the text of the documents it cites, not against the whole context. That catches answers where the citation exists but does not support the sentence. If either layer fails, the answer goes down the regenerate path under the attempt limit. Users never see citations that have not been verified.

Sourced from Docs by LangChain (MCP)

Parallel grading through Send already turns k sequential calls into one round of concurrent calls. Beyond that, I use a small, fast model for routing and grading, and keep the stronger model for generation. I can cut k after reranking so fewer chunks need grading. I cache embeddings and repeated retrievals for popular questions. I could start a web search speculatively when the router's confidence is low, but only use it if the decide edge needs it. That trades some cost for latency. What I do not skip is the grounding check. Instead, I keep it to one structured call, and I stream status updates so the user sees progress while it runs.

Sourced from Docs by LangChain (MCP)

If I stream with the messages mode, generate's tokens would reach the user before grounding is verified, which breaks the guarantee. So I filter the messages stream by node metadata to exclude generate's tokens. For the answer itself there are two options. The first is to buffer the generation and, once the grounding check passes, emit it from a final node using the custom stream mode, chunked for perceived speed. The second is to stream the draft into a clearly labelled 'checking' area that the client discards if the check fails. The first is safer and simpler to reason about. Meanwhile, updates mode can show progress such as 'retrieving' and 'verifying sources', so the wait does not feel empty.

Sourced from Docs by LangChain (MCP)

For local development and tests I use InMemorySaver. In production I use a Postgres checkpointer, so state survives process restarts and can be shared across workers. For a single question-answer run, I make thread_id a unique run id, often combined with the conversation id, so every run can be replayed on its own. If the product is conversational and follow-ups should see earlier state, I use one thread per conversation and keep run ids in metadata. The thread_id must never come straight from client input without an authorisation check. Otherwise one user could load another user's checkpoint, which contains their questions and the documents retrieved for them.

Sourced from Docs by LangChain (MCP)

The rewritten query leaves our boundary and goes to a third-party search provider. It may contain personal data, customer names or confidential project terms from the user's question. To control this, I run a redaction step before the search tool that removes or masks PII and internal identifiers, and I let tenants switch web fallback off entirely. For sensitive tenants, the router can be configured never to choose web. I check the provider's data retention terms and record which queries were sent externally. The checkpointer also stores full state, including questions and documents. That means checkpoints need encryption at rest, a retention policy, and deletion support for data subject requests.

Sourced from Docs by LangChain (MCP)

The tenant and user permissions come from the authenticated request context and are passed in the graph's configuration. They are never inferred by an LLM or taken from the question text. The retrieve node always applies a metadata filter on the vector store query, such as tenant_id plus allowed groups, and that filter is applied server-side, so it cannot be bypassed by query wording. Ideally I also use separate collections or namespaces per tenant for stronger isolation. Grading cannot fix a leak, because a leaked chunk could still be judged relevant. So isolation has to happen at retrieval. I add tests that try to retrieve another tenant's documents and assert that nothing comes back.

Sourced from Docs by LangChain (MCP)

I build a labelled dataset of questions with expected routes, relevant document ids and reference answers, including questions the index cannot answer. I evaluate components separately: router accuracy, grader precision and recall against labelled relevance, and retrieval hit rate. End to end, I measure answer correctness, citation validity, the grounded rate, and how often the graph correctly returns 'could not find a reliable answer' for unanswerable questions. Abstaining when it should is a success, and guessing is a failure. I also track average retries, web fallback rate and LLM calls per question. Every prompt or model change runs against the dataset in CI, and regressions block the release.

Sourced from Docs by LangChain (MCP)

Usually not. Grading is a narrow binary judgement run k times per round, so a smaller, cheaper, faster model with structured output often does well and dominates the savings. Generation benefits from a stronger model. For the grounding check, I want a model that is at least as capable as the generator, ideally a different one, so it does not share the generator's blind spots or approve its own style of mistake. The cost is having more models to evaluate and version. I validate each choice against labelled relevance and grounding data. If the small grader's recall drops, the graph rewrites and searches the web more, which shows up as cost and latency.

Sourced from Docs by LangChain (MCP)

I treat it as a tunable parameter and set it from evaluation data, not intuition. A common starting rule is that at least one relevant document must pass. For questions that need synthesis, I may require two, or a minimum share of the top-k. Then I measure it on a labelled set. If the threshold is too high, the graph rewrites and searches the web needlessly, which adds latency and cost. If it is too low, generate works from thin context and the grounding check fails more often. I log how many documents passed on every run. That lets me plot the threshold against answer quality and fallback rate, and adjust it per domain or per index.

Sourced from Docs by LangChain (MCP)

I pass the rewriter the original question, the previous queries it has tried, and short reasons from the grader about why the chunks were judged irrelevant. I instruct it to change strategy rather than paraphrase. Examples are expanding acronyms, adding domain terms, splitting a compound question, or making the query more general. I also add a cheap deterministic check: if the new query is identical, or nearly identical by normalised string comparison, to an earlier one, I skip retrieval and move to web search. That avoids spending a retry for nothing. Keeping a list of past queries in state also makes the behaviour visible in traces, which helps when tuning the prompt.

Sourced from Docs by LangChain (MCP)

The grader, generate and grounding nodes then have a single contract. Each document has an id, text, source type and locator, which is a URL for web results or a document reference for the index. Without this, every downstream node needs branches for two shapes, and citations become inconsistent. During normalisation I also strip boilerplate, truncate to a size budget, record the fetch time, and assign stable ids, for example a hash of the URL plus the chunk position. I run web results through the same relevance grader. A search engine ranking something highly does not mean it answers the question, and the guarantee of never returning unsupported answers depends on uniform grading.

Sourced from Docs by LangChain (MCP)

A whole-answer judgement tends to pass answers that are mostly right but contain one invented number or name, because the grader weighs the overall impression. Breaking the answer into atomic claims and checking each against the cited chunks makes the requirement precise: every claim needs support. It also gives useful diagnostics. I know which claim failed, and I can pass that to the regenerate node with an instruction to drop or correct it. The cost is more tokens or more calls. I keep that manageable by grading all claims in one structured call that returns a verdict per claim. For very long answers, I batch the claims.

Sourced from Docs by LangChain (MCP)

They are different failures. Unsupported means the context may be fine but the model added material beyond it, so the fix is to generate again under tighter instructions, and possibly name the failing claims. Off-target means the answer is grounded but does not address the question. That usually signals the retrieved context was about the wrong thing, so regenerating from the same documents would just restate it. Rewriting the query and retrieving again changes the inputs. Both paths increment their own counters and share an overall attempt ceiling. If either limit is reached, the graph returns the explicit no-reliable-answer response instead of looping.

Sourced from Docs by LangChain (MCP)

Checkpoints are written at super-step boundaries. The state after retrieve is therefore saved, and LangGraph also keeps pending writes from branches that completed successfully within the failed super-step. To resume, I invoke the graph again with the same thread_id and None as input. It continues from the last checkpoint rather than restarting from the router. Branches whose writes were already saved do not need to rerun. Because nodes can rerun, I keep them idempotent: graders are pure functions of their input, and any side effects, such as logging to an external system, use the run id and node as an idempotency key, so a retry does not create duplicates.

Sourced from Docs by LangChain (MCP)

I trace each run as a tree of node executions, with inputs, outputs, latency, tokens and model used, using LangSmith or an equivalent tool. Key metrics are the route distribution, documents passed per grading round, rewrite count, web fallback rate, regeneration count, and the abstention rate. Others are grounding failures by reason, end-to-end latency percentiles, and cost per question. Alerts go on sudden shifts. A spike in web fallback may mean the index is stale or retrieval is broken. A rising abstention rate may mean a model or prompt regression. Because the checkpointer keeps the full run, any flagged trace can be replayed exactly for debugging.

Sourced from Docs by LangChain (MCP)

Not on the default path for user questions, because it adds unbounded latency. Good candidates are high-stakes domains, such as policy or legal answers, where a reviewer approves an answer before it is released. Another is the abstention path, where a human can answer a question the system could not and feed that answer back into the index. A third is approving web search for sensitive tenants. Mechanically, a node calls interrupt() with the draft and citations. The checkpointer persists the paused state, so it can wait hours. The reviewer's decision is passed back with Command(resume=...) on the same thread_id, and the graph continues to release, edit or reject.

Sourced from Docs by LangChain (MCP)

Safe caches include query embeddings, retrieval results keyed by query, tenant and index version, and grader verdicts keyed by question, document id and document version, because these are deterministic enough and expensive in total. Web search results can be cached for a short time to live, since the whole point of web search is freshness. Final answers can be cached for identical questions within a tenant, but only when the index version is unchanged, and only grounded answers. Never cache across tenants or permission sets, because that leaks data. Do not cache the abstention response so aggressively that newly added documents stay invisible. Cache keys must include anything that changes what the user may see.

Sourced from Docs by LangChain (MCP)

First, I store freshness metadata, such as last-updated dates, on chunks so graders and generate can see them. For time-sensitive questions, the router can detect phrases like 'latest' or 'current' and choose web search directly. The grader can also be told to mark outdated documents as irrelevant when the question asks about recency. If both sources are present and they conflict, generate should say so and cite both, rather than silently picking one. The grounding check still applies to whichever claims are made. Operationally, a rising web fallback rate for a topic is a useful signal that the index needs refreshing.

Sourced from Docs by LangChain (MCP)

The design is already forgiving. If the router sends a web-needing question to the index, grading finds too few relevant chunks, the rewrite loop runs, and the web fallback catches it. That costs latency but not correctness. The reverse error, sending an index question to the web, is worse for internal knowledge, because the web cannot have the answer and may return plausible but wrong content. So when unsure, I bias the router toward the index first, and I can let the web path fall back to the index if its graded results are thin. I measure misroutes from traces and add hard cases to the router's evaluation set.

Sourced from Docs by LangChain (MCP)

Both runs would read the same latest checkpoint and write competing updates, so the history interleaves and replay becomes confusing. Retry counters could also be wrong. I prevent this at the application layer by using a fresh thread or run id per question, so concurrent questions never share a thread. If a conversation thread must be shared, I serialise runs per thread, either by rejecting or queueing a second run while one is active, or by using the deployment platform's options for handling concurrent runs on a thread. The general rule is that a thread is one ordered history, and only one writer should advance it at a time.

Sourced from Docs by LangChain (MCP)

I separate the routing logic from the model calls. Conditional edge functions, such as decide and the grounding router, are pure functions of state, so I unit test them with handcrafted states that cover the threshold edges, exhausted retries and both failure types. For node tests and whole-graph tests, I inject fake models that return scripted structured outputs. With InMemorySaver, I can then assert the exact sequence of nodes visited, the counters, and that the abstention path triggers at the limit. On top of that, a smaller evaluation suite with real models runs in CI to catch regressions in prompt quality that mocks cannot reveal.

Sourced from Docs by LangChain (MCP)

Only for things that should persist across threads. The checkpointer already covers state within a run. A Store, such as PostgresStore with namespace tuples like (tenant_id, 'query_rewrites'), could hold rewrites that worked for recurring question patterns, user preferences such as preferred sources, or a list of questions the system abstained on for curation. Its optional semantic search lets the rewriter look up similar past questions and their successful queries. I would be careful: anything stored is long-lived data that needs tenant namespacing and retention rules. Memory must also never become a source of answers that bypasses grounding. It can guide retrieval, but it is not context.

Sourced from Docs by LangChain (MCP)

I compile the graph with a Postgres checkpointer and deploy it on LangSmith's Agent Server. That exposes it over an API with threads and runs, so clients can start a run, stream it, and resume or inspect it by thread_id. The server also exposes an MCP endpoint at /mcp, so other agents or MCP-capable clients can call the corrective RAG graph as a tool. I put authentication in front of it and map the caller's identity to tenant filters. I also make sure the graph's input and output schema is small and explicit: a question in, and an answer with citations or an abstention out.

Sourced from Docs by LangChain (MCP)

Checkpoints store state keyed by channel and node names, so renaming nodes or changing state keys can break resuming or replaying old threads. I treat the state schema like an API. I prefer to add optional keys rather than rename them, and I record a graph version in the state or metadata. Finished runs are only replayed for debugging, so I keep the old graph version available for that, or accept that replay targets the version that produced the run. In-flight runs, such as those paused on interrupt(), need compatibility, so I either drain them before deploying or migrate their state with update_state.

Sourced from Docs by LangChain (MCP)

1. ACommand(goto=...)
2. BSendCorrect answer
3. Cinterrupt()
4. DA subgraph

Why: Returning a list of Send objects from a conditional edge runs the target node once per item, each with its own per-item state, which is the map step of map-reduce.

Sourced from Docs by LangChain (MCP)

1. ARun graders in a for loop inside the retrieve node only
2. BOverwrite the documents key from each grader call
3. CDeclare the key with a reducer such as operator.add and fan out using SendCorrect answer
4. DStore results in a global Python variable

Why: Send fans out one grader invocation per document, and a reducer like operator.add merges each update into the list instead of the last write overwriting the others.

Sourced from Docs by LangChain (MCP)

1. AStreaming in messages mode
2. BIncreasing the recursion limit
3. CThe vector store's version history
4. DA checkpointer with get_state_history and update_state on the thread_idCorrect answer

Why: Checkpointers save state per thread_id at every super-step, so you can list checkpoints with get_state_history and replay or fork from an earlier one, optionally editing state with update_state.

Sourced from Docs by LangChain (MCP)

1. AAs a plain list that each grader overwrites
2. BAs a string that graders join with commas
3. CAs Annotated[list, operator.add] so updates are concatenatedCorrect answer
4. DAs a Store namespace

Why: Parallel branches write to the same key in one super-step, and an operator.add reducer merges their list updates instead of letting one overwrite another.

Sourced from Docs by LangChain (MCP)

1. ANo checkpointer, relying on logs
2. BA Python dict global
3. CInMemorySaver
4. DA Postgres-backed checkpointerCorrect answer

Why: A Postgres checkpointer persists state durably and is shared across processes, while InMemorySaver is meant for development and loses state on restart.

Sourced from Docs by LangChain (MCP)

1. Athread_id in the configCorrect answer
2. BThe node name
3. CThe LLM model name
4. DThe vector store collection name

Why: Checkpoints are stored per thread_id, so passing the same thread_id in the config targets that run's history.

Sourced from Docs by LangChain (MCP)

1. Adebug
2. Bvalues
3. Cupdates
4. DmessagesCorrect answer

Why: The messages mode streams LLM tokens with node metadata, which lets you filter out tokens from nodes such as an unverified generate step.

Sourced from Docs by LangChain (MCP)

1. ALoop back to the rewriter again
2. BRoute to the web search fallbackCorrect answer
3. CCall generate with no context
4. DReturn END with an empty string

Why: The workflow uses web search when retries are exhausted, so it gets fresh context instead of looping or generating from nothing.

Sourced from Docs by LangChain (MCP)

1. ADisable parallel grading
2. BRemove the reducer so parallel graders overwrite each other
3. CUse a custom reducer that supports a reset, or scope graded documents per attemptCorrect answer
4. DRaise the threshold so stale documents do not matter

Why: operator.add only appends, so the state needs an explicit way to clear or separate each round's results while still merging parallel writes.

Sourced from Docs by LangChain (MCP)

1. ATreat context as delimited data, give context-reading nodes no side-effecting tools, and keep the grounding checkCorrect answer
2. BIncrease top-k so the page is diluted
3. CTrust top-ranked search results
4. DLet the generate node call any tool the page mentions

Why: Prompt injection is contained by separating data from instructions, limiting tool authority, and verifying claims against the context.

Sourced from Docs by LangChain (MCP)

1. AAsk the LLM to ignore other tenants' documents
2. BRely on the grader to drop documents from other tenants
3. CApply a server-side metadata filter or namespace taken from the authenticated requestCorrect answer
4. DFilter citations after generation

Why: Access control must come from authenticated identity and be applied at retrieval. Later LLM steps cannot reliably undo a leak.

Sourced from Docs by LangChain (MCP)

1. ASkip the grounding check on the next request
2. BReturn the last draft anyway
3. CRaise the recursion limit and keep looping
4. DReturn an explicit abstention or 'could not find a reliable answer' responseCorrect answer

Why: The workflow's core guarantee is not returning unsupported answers, so at the bound it should abstain clearly rather than ship an ungrounded draft or loop indefinitely.

Sourced from Docs by LangChain (MCP)

1. AOnly when update_state is called
2. BOnly when the graph reaches END
3. COnly when an exception occurs
4. DAt every super-stepCorrect answer

Why: Checkpoints are written per thread at each super-step, which enables resuming after failure and time travel.

Sourced from Docs by LangChain (MCP)

1. Astream with mode 'custom'
2. Bget_state_historyCorrect answer
3. Cadd_conditional_edges
4. Dwith_structured_output

Why: get_state_history returns the thread's checkpoints, and you can then replay from one or fork it with update_state.

Sourced from Docs by LangChain (MCP)

1. Avalues with full state only at the end
2. BNo streaming is possible with conditional edges
3. Cmessages
4. DupdatesCorrect answer

Why: The updates mode emits the state changes from each node as it completes, which maps naturally onto progress indicators.

Sourced from Docs by LangChain (MCP)

1. AIncreasing the recursion limit
2. Btime.sleep in the generate node
3. CRaising an exception and asking the user to retry
4. Dinterrupt() in a node, then Command(resume=...) on the same threadCorrect answer

Why: interrupt() pauses the node with its state checkpointed, and Command(resume=...) continues it with the reviewer's input.

Sourced from Docs by LangChain (MCP)

1. AReturn a Send to END
2. BCall get_state_history
3. CWrite to a Store
4. DReturn Command(goto=..., update=...)Correct answer

Why: Command with goto and update lets a node route and apply state updates in a single return.

Sourced from Docs by LangChain (MCP)

1. ASkip to the next user question
2. BRegenerate from the same documents
3. CReturn the answer anyway
4. DRewrite the query and retrieve againCorrect answer

Why: An off-target answer suggests the context was about the wrong thing, so the workflow rewrites the query rather than regenerating from the same documents.

Sourced from Docs by LangChain (MCP)

1. ARegenerate the answerCorrect answer
2. BSearch the web for the claim and keep it
3. CReturn it with a disclaimer
4. DDelete the retrieved documents

Why: An unsupported answer goes back to regenerate under tighter grounding, and the hard attempt limit keeps that bounded.

Sourced from Docs by LangChain (MCP)

1. AIt is required by the checkpointer
2. BSo grading, generation, citations and grounding work the same way regardless of sourceCorrect answer
3. CTo make web results look internal to users
4. DWeb results cannot be embedded

Why: A single document contract means downstream nodes and citation ids behave uniformly, and web results are graded like any other context.

Sourced from Docs by LangChain (MCP)

1. AIn the typed graph state, incremented by the rewriterCorrect answer
2. BIn the LLM prompt only
3. CIn the vector store metadata
4. DIn a module-level global variable

Why: Keeping retries in checkpointed state makes the limit correct across resumes and replays, and visible to the conditional edges.

Sourced from Docs by LangChain (MCP)

1. AIt guarantees the route is always correct
2. BIt makes the LLM free
3. CIt returns a validated route value the conditional edge can branch onCorrect answer
4. DIt removes the need for a vector store

Why: A schema-constrained output, such as a Literal route, avoids fragile parsing of prose, though the route can still be wrong and needs evaluation.

Sourced from Docs by LangChain (MCP)

1. ARerun the whole graph with a new thread_id
2. BFind the checkpoint via get_state_history, apply update_state, and continue from itCorrect answer
3. CEdit the Postgres rows by hand
4. DRaise the recursion limit

Why: Forking means updating state at an earlier checkpoint and resuming from there, which keeps the original history intact.

Sourced from Docs by LangChain (MCP)

1. AAfter every grader branch in that super-step has completedCorrect answer
2. BOnly after a human resumes the graph
3. CBefore the graders, to prepare state
4. DAs soon as the first grader finishes

Why: Send branches run in the same super-step, and the graph advances only when all of them finish, which gives a natural fan-in.

Sourced from Docs by LangChain (MCP)

1. A13
2. B3
3. C5
4. D8Correct answer

Why: That is 1 router, plus 5 graders, plus 1 generate, plus 1 grounding call, which totals 8.

Sourced from Docs by LangChain (MCP)

1. ACheckpoints stop being saved
2. BThe router runs twice
3. CTokens arrive out of order
4. DUsers may see text that later fails the grounding checkCorrect answer

Why: Generation happens before verification, so unfiltered token streaming breaks the rule that only grounded answers reach the user.

Sourced from Docs by LangChain (MCP)

1. AAsking the generator, in the same call, to declare its own answer groundedCorrect answer
2. BEvaluating the grader against labelled examples
3. CA separate grader checking each claim against cited chunks
4. DA deterministic check that cited ids exist in the graded documents

Why: Self-assessment in the same call is not independent verification and tends to approve its own errors.

Sourced from Docs by LangChain (MCP)

1. AInvoke with a new thread_id and the original question
2. BCall update_state with an empty dict on a new thread
3. CRestart the server, which resumes all threads automatically
4. DInvoke again with the same thread_id and None as the inputCorrect answer

Why: Invoking with None on the same thread continues from the saved checkpoint instead of starting over.

Sourced from Docs by LangChain (MCP)

1. ARe-embed the answer
2. BAsk the user to verify them
3. CCheck in code that every cited id exists in the current graded documentsCorrect answer
4. DRun a new web search per citation

Why: A deterministic id check catches fabricated or stale citations at no LLM cost, before the claim-level grounding grader runs.

Sourced from Docs by LangChain (MCP)

1. AAgent Server
2. BMCP endpoint
3. CInMemorySaverCorrect answer
4. DPostgresStore

Why: InMemorySaver keeps checkpoints in process memory, which suits development but not durable production runs.

Sourced from Docs by LangChain (MCP)

1. AReducers
2. BSend
3. CCheckpointers
4. DStores such as InMemoryStore or PostgresStoreCorrect answer

Why: Stores hold cross-thread data under namespace tuples, with optional semantic search, while checkpointers hold per-thread state.

Sourced from Docs by LangChain (MCP)

1. A/graphql
2. B/mcpCorrect answer
3. C/v1/chat
4. D/stream

Why: Agent Server exposes deployed agents over an API and an MCP endpoint at /mcp.

Sourced from Docs by LangChain (MCP)

1. AAs a stream mode
2. BAs a thread_id
3. CAs a subgraph used as a nodeCorrect answer
4. DAs a Store namespace

Why: LangGraph lets you compose graphs by adding a compiled graph as a node in another graph.

Sourced from Docs by LangChain (MCP)