Web research agent that writes a report

I make citations a data problem, not a prompt problem. The search subagent writes notes to files with the exact quote, URL and access date, and gives each source an ID. The report schema in response_format requires every finding to carry source IDs that exist in those files, so a missing reference fails validation. Then a critique subagent checks each claim against its stored quote and flags unsupported ones, which get fixed or marked as uncertain. I also never let the model cite from memory; only fetched pages count. Finally, a human approves before publishing, and in LangSmith I sample reports to measure the citation support rate over time, so regressions show up as a number.

Sourced from Docs by LangChain (MCP)

The analyst submits a question with scope, audience and deadline. The API opens a thread_id, and a checkpointer saves state after every step so the run can resume. A deep agent built with create_deep_agent loads saved preferences from the LangGraph store, then uses write_todos to split the question into sub-questions and a report outline. For each sub-question it calls the task tool to spawn a search subagent with a clean context. That subagent uses an MCP search tool adapted with MultiServerMCPClient, fetches pages, converts HTML to text and writes quoted notes to the virtual filesystem. Summarization keeps the main context small. A critique subagent checks the draft against the notes. The result is returned as Pydantic structured output, and a human-in-the-loop interrupt gates publishing.

Sourced from Docs by LangChain (MCP)

Raw pages and long quotes fill the context window fast. That raises cost and latency, and the model reasons worse when the evidence it needs is buried. In this design the main agent's context holds plans, todos and short summaries, while the files hold the evidence: quotes, URLs and access dates. When summarization compresses older messages, nothing important is lost, because the notes are still on disk and can be re-read. The files also give the critique subagent a stable, inspectable record to check claims against. As a bonus, a human reviewer can open the same notes and audit exactly what the agent saw.

Sourced from Docs by LangChain (MCP)

For each finding, it reads the cited source IDs, opens the matching notes files and looks for a quote that directly states the claim, including its numbers, dates and scope. A claim fails if no quote is cited, if the quote only touches the topic, if it overstates what the quote says, or if the only support is a duplicate of another source. The critique subagent also flags weak sources and gaps in the outline. It returns a list of issues to the main agent. The main agent then either finds better evidence, rewrites the claim to match the quote, or marks the claim as uncertain. A model judging support can still be wrong, so the human review step remains essential.

Sourced from Docs by LangChain (MCP)

I would build a test set of research questions with known good sources and key facts, including some with traps: conflicting sources, outdated pages and questions with no good answer. The main metrics are citation support rate, meaning the share of findings whose quotes truly support them; coverage of key facts; the rate of unsupported claims; and correct use of uncertain flags and open questions. Schema validity is checked automatically. Citation support can be graded by a model, with human spot checks to calibrate the grader. I would also track cost, steps and latency per run. In production, analyst edits and rejections at the interrupt are a valuable signal for where the agent fails.

Sourced from Docs by LangChain (MCP)

A simple create_agent loop is fine for short tasks: a few searches and a paragraph answer. Once the task needs many sub-questions, dozens of pages and a long report, a single context fills with raw page text and quality drops. create_deep_agent pre-assembles what I would otherwise build myself: a planning todo tool, a filesystem to hold notes outside the context, subagents that run sub-questions in isolated contexts, summarization, and prompt caching. So my rule is task length and breadth. If the agent must keep state across many steps or the output is a multi-section document, I start with Deep Agents; otherwise I keep the simpler agent and add middleware only when needed.

Sourced from Docs by LangChain (MCP)

I assume every fetched page is hostile. Page content goes into tool results and files as data, and the system prompt states that instructions inside sources must never be followed. More importantly, I limit blast radius: search subagents only get search, fetch and file-write tools, with no email, publish or shell access. The only irreversible action, publishing the report, sits behind a human-in-the-loop interrupt. I strip scripts and hidden text when converting HTML, cap page length, and use a model call limit so an injected loop cannot run forever. I also keep red-team pages in my evaluation set in LangSmith to check the agent ignores them.

Sourced from Docs by LangChain (MCP)

I would use one file per source, or one per sub-question with a section per source, in a predictable layout. Each entry gets a stable source ID, URL, page title, publisher if known, access date, and the sub-question it serves. It also holds a list of verbatim quotes, each with a short note on which claim it could support. I would add a flag for source type, such as primary, secondary or opinion, and a field for duplicates or syndication. Keeping quotes verbatim is the key point. Later steps can then check that a finding's source ID points to a quote that truly says what the report claims, rather than to a paraphrase that drifted.

Sourced from Docs by LangChain (MCP)

The top-level Report model has a title, a summary, a list of Finding objects, a list of Source objects and a list of open questions. A Finding holds a statement, a list of source IDs and a confidence or uncertain flag. A Source holds an ID, URL, title, access date and optionally the supporting quote. I would pass the schema to the agent through response_format, so the output is parsed and type-checked. On top of that, downstream code runs its own checks: every source ID in a finding must exist in the sources list, no finding may have zero sources unless it is marked uncertain, and URLs must be well formed. Schema validity alone does not prove the citations are true.

Sourced from Docs by LangChain (MCP)

The checkpointer saves graph state after every step, keyed by thread_id. That state includes messages, todos and, with the default Deep Agents state-backed filesystem, the notes files too. If a worker crashes, another worker can load the latest checkpoint for that thread and continue from the last completed step instead of starting over. The step that was running at crash time may run again. Side-effecting tools should therefore be idempotent or safe to repeat; a repeated web search costs money but does no harm, while publishing must never happen twice. For production, use a durable checkpointer backed by a database rather than an in-memory one, and make sure it is shared by every worker.

Sourced from Docs by LangChain (MCP)

Short-term memory is scoped to one thread through the checkpointer: the conversation, the todo list, the drafts and the run's working files. It exists so a single research job can continue and resume. Long-term memory lives in a LangGraph store as JSON documents organised by namespace and key. It holds things that should persist across threads, such as the analyst's preferred report style, trusted or blocked domains, audience defaults and citation format. The store can optionally support semantic search. I would not put raw web content in the long-term store by default, because it goes stale and raises privacy and copyright questions. Preferences are loaded at the start of a run and updated only with clear intent.

Sourced from Docs by LangChain (MCP)

I would build it bottom-up from measured traces, not guesses. Cost per report is roughly: planning calls, plus the number of sub-questions times the subagent cost, plus critique and revision passes, plus the final structured output. Subagent cost is driven by searches per sub-question, pages read and the average text kept per page, plus the model calls that summarise them. Main-agent cost depends on how big the context stays, which summarization limits, and on prompt caching, which reduces the cost of repeated prefixes. I would run a sample of real questions, record tokens per step, then multiply by expected volume. I would also set a model call limit so the worst case is bounded. I would not quote prices without checking the provider's current rates.

Sourced from Docs by LangChain (MCP)

There are layers. For transient tool errors such as timeouts or rate limits, tool retry middleware retries with backoff. If a search keeps failing, the subagent should record the failure in its notes and return a summary saying the sub-question is unresolved, rather than inventing an answer. For model errors, model fallback middleware tries backup models in order. Because the checkpointer saves after every step, a crashed run resumes rather than restarts. Finally, the report schema has an open questions field. Anything the agent could not verify goes there, so failures are visible to the analyst instead of being hidden by confident prose.

Sourced from Docs by LangChain (MCP)

I bound it in several ways. A model call limit middleware caps the number of model calls per run, and per subagent if needed. The plan from write_todos sets a finite list of sub-questions, and I limit searches and pages per sub-question in the subagent prompt and its tool settings. The analyst's deadline becomes a wall-clock budget that the API enforces. When a limit is hit, the agent should stop and produce the best report it can, with unresolved items in open questions, rather than failing with nothing. Tracing every step lets us see which sub-questions burn the most calls, so we can tune the limits.

Sourced from Docs by LangChain (MCP)

It should not quietly pick one. The notes keep both quotes with their sources and dates. In the report, the finding states the disagreement, cites both and, where possible, explains it: different dates, definitions, scope or methods. If the conflict cannot be resolved, it goes into open questions or is marked uncertain. The critique subagent should flag any finding that cites one side while notes contain a contradicting quote. Preferring the more recent or more primary source is a reasonable default, but the reasoning must be visible so the analyst can judge. Hiding a conflict is a form of unsupported claim, because the report then implies a consensus that does not exist.

Sourced from Docs by LangChain (MCP)

I would use HumanInTheLoopMiddleware with interrupt_on set for the publish or share tool, not for every tool. Reviewing each search would make the agent unusable. The allowed decisions are approve, edit and reject. When the interrupt fires, the reviewer should see the structured report, the source list with quotes, the critique's open issues and anything marked uncertain. Approve lets publishing proceed. Edit lets the analyst change the tool arguments, such as the report content or recipients. Reject sends feedback, and the run resumes on the same thread with the feedback as input. The interrupt is persisted by the checkpointer, so the run can wait for hours without holding a worker.

Sourced from Docs by LangChain (MCP)

When the subagent saves a quote, the fetch step should also keep the extracted page text, or a hash of it, tied to the source ID. A deterministic check, outside the model, then confirms that each quote appears in that text, using normalised whitespace and punctuation. A quote that cannot be found is treated as fabricated or mangled, and the claim it backs goes back for repair. This check is cheap and catches a common failure: a model paraphrasing and presenting it as a quote. It does not prove the quote supports the claim; that is the critique subagent's job. Together, they cover both whether the quote exists and whether it supports the claim.

Sourced from Docs by LangChain (MCP)

Each research job is its own thread_id, so runs are independent and can be spread across stateless workers that share a durable checkpointer and store. I would put a job queue in front, because these runs are long. That gives back-pressure and per-tenant concurrency limits. The main bottlenecks are external: search API rate limits, page-fetch throughput and model provider quotas. So I would rate-limit per tool and per tenant, cache search results and fetched pages briefly, and use model fallback middleware to absorb provider outages. The HITL pause means many threads sit idle waiting for humans. That is cheap if state lives in the checkpointer and not in worker memory.

Sourced from Docs by LangChain (MCP)

First, I limit collection. The subagent saves only the quotes it needs, not whole pages. Second, PIIMiddleware can redact, mask or block types like email addresses and phone numbers in content passing through the model. Here I would usually redact or mask in notes and output unless the person's details are the point of the research and the use is lawful. Third, I scope storage: the notes for each thread are isolated, and they get a retention policy. Raw content is not copied into the long-term store. In India, the Digital Personal Data Protection Act matters for personal data, so purpose limitation and deletion should be designed in, with legal review for sensitive topics.

Sourced from Docs by LangChain (MCP)

Treat it as an external dependency with its own credentials. The search API key lives on the server side or in a secrets manager, never in prompts or the agent's state. The connection uses authenticated transport, and the MultiServerMCPClient configuration loads only the specific servers and tools this agent needs. That keeps the tool surface small. I would review which tools the server exposes, because an MCP server can offer more than search, and expose only read-only ones to subagents. Add rate limits and logging on calls. If page fetching is a separate tool, restrict it to http and https and block internal network addresses, to prevent server-side request forgery.

Sourced from Docs by LangChain (MCP)

Many articles are rewrites of one press release or wire story. Counting them as separate confirmations inflates confidence. The subagent should record the canonical origin when a page says it is republished, and the notes model has a duplicates field. The critique subagent is explicitly asked to flag duplicate sources. In the report, a claim backed by five copies of one release has one independent source, not five. Where possible, I prefer citing the primary source, such as the original filing, dataset or official statement, over news coverage of it. Normalising URLs, for example by stripping tracking parameters, also catches simple duplicates before the model sees them.

Sourced from Docs by LangChain (MCP)

Web pages change, move or disappear, so the access date tells a reader what the page said when the agent read it. It also makes stale evidence visible. For time-sensitive topics such as prices, regulations or rankings, I would capture the page's own publication or update date where available, alongside the access date. The planner should prefer recent sources when the question is about current state, and the critique subagent should flag findings based only on old sources. In the report, statements should be time-anchored, for example 'as of the source dated…', rather than written as timeless facts.

Sourced from Docs by LangChain (MCP)

I would trace every run by thread_id, including each model call, tool call, subagent spawn, retries, fallbacks and the interrupt decision. For each run I want: the number of sub-questions, searches and pages fetched, tokens per step, time spent waiting on humans, and the final outcome (approved, edited or rejected). Quality signals include the count of critique flags, findings marked uncertain and schema validation failures. Alerts should fire on search error spikes, frequent model fallbacks, runs hitting the call limit and unusual cost per report. Traces contain fetched web content and possibly personal data, so they need access control and retention limits too.

Sourced from Docs by LangChain (MCP)

Parallel subagents cut wall-clock time, and each has its own clean context, so they do not interfere in the model's reasoning. The costs are bursts against search and model rate limits, harder debugging, and possible duplicate work when sub-questions overlap. Sequential runs are slower but let later searches build on earlier findings. My default is bounded parallelism: run independent sub-questions concurrently up to a per-run and per-tenant cap, and run dependent ones afterwards. The planner can mark dependencies in the todos. Notes files should be named per sub-question or per source, so parallel subagents do not overwrite each other.

Sourced from Docs by LangChain (MCP)

SummarizationMiddleware is configured with a trigger, for example by tokens, and a keep setting, such as the most recent messages. Deep Agents pre-assembles summarization, so the job is mostly tuning. If it triggers too late, cost and latency rise and the model gets lost in long context. If it triggers too early, or keeps too little, the agent can forget decisions, constraints from the brief or which todos are done. The mitigation in this design is that durable facts live outside the message history: the plan in todos, the evidence in notes files. The summary then only needs to keep the reasoning thread. I would test tuning on long runs and check that the final report still matches the original brief.

Sourced from Docs by LangChain (MCP)

Naive conversion keeps menus, cookie banners, ads and footers. That wastes tokens and can mislead the model. Pages rendered by JavaScript may return almost no content to a plain fetch. Paywalls and login walls return teasers. PDFs and tables need different handling, and flattening a table can break the link between numbers and their labels, which is dangerous for citations. I would use a main-content extractor, detect empty or blocked pages and record them as unreadable rather than guessing, and keep table structure where possible. Respecting robots rules and site terms matters too. If a page could not be read properly, the notes should say so, so no claim gets cited to it.

Sourced from Docs by LangChain (MCP)

The risk is that the summary loses nuance or adds certainty the evidence does not have. The main agent might then write the report from the summary instead of from the evidence. I manage this in three ways. The summary must reference the notes files and source IDs it came from. The main agent reads the relevant notes when drafting findings, not only the summaries. And the critique step checks the draft against the notes files, not against the summaries. The summary is a routing aid that says what was found and where. It is not evidence, and it should never be cited.

Sourced from Docs by LangChain (MCP)

I would use a namespace tied to the tenant and user, for example organisation and user ID, with keys such as report_style, trusted_domains, blocked_domains and audience_defaults, each a JSON document. A team-level namespace can hold shared defaults, with user values overriding them. The agent loads these at the start of the run. The API derives the namespace from the authenticated user, never from model output, so one user cannot read another's data. Writes should be deliberate, for example when the analyst says 'always use this format', not inferred silently. Semantic search over the store is optional and only worth adding if memories grow large and unstructured.

Sourced from Docs by LangChain (MCP)

Every resource is scoped by tenant. Thread IDs are created by the API and mapped to the owning user, so resuming or reading a thread checks ownership. The virtual filesystem lives in thread state, so one run's notes are not visible to another. If you switch to a persistent file backend, paths must be namespaced per tenant and thread. Store namespaces include the tenant ID. Tool credentials and rate limits are per tenant. The model never chooses these identifiers; they come from the authenticated request. Logs and traces get the same access controls. Finally, I would write tests that try cross-tenant reads, because a bug here is a data breach.

Sourced from Docs by LangChain (MCP)

It should be explicit and structured, not buried in hedged prose. Each finding carries a confidence or uncertain flag in the schema, so downstream code and reviewers can filter on it. A claim is marked uncertain when its support is weak, indirect, single-sourced, old or contradicted. Questions the agent could not answer within budget go into open questions, with a note on what was tried. Confident wording should only appear where quotes directly support the claim. This gives the analyst an honest picture and makes the HITL review faster, because attention goes straight to the risky parts.

Sourced from Docs by LangChain (MCP)

Not necessarily. init_chat_model with a 'provider:model' string makes it easy to choose per role. The main agent does planning, synthesis and final structured output, so it benefits from a strong reasoning model. Search subagents do many repetitive steps, such as choosing queries and extracting quotes, so a faster, cheaper model may be enough. The critique subagent judges whether evidence supports claims, and quality matters there, so I would not cut corners. Every choice should be checked against the eval set, especially the citation support rate. Model fallback middleware adds resilience, but fallback models must also support the structured output and tool calling the role needs.

Sourced from Docs by LangChain (MCP)

When the analyst's questions depend on private material that web search cannot reach, such as past reports, internal research or policy documents. I would build a standard pipeline: document loaders, text splitters, embeddings, a vector store and a retriever. The retriever is exposed as another tool the search subagent can call. Internal results get the same treatment as web results, with quotes and a source ID in the notes, but pointing to the document and version instead of a URL. Access control must follow the user's permissions on the source documents, otherwise the agent could leak restricted content into a report shared more widely.

Sourced from Docs by LangChain (MCP)

I would keep the approved report, its outline and its source list as a versioned artifact, outside the thread's temporary state. A refresh starts a new thread seeded with the old outline and sources. The agent re-fetches each cited source to check that it still exists and still says the same thing, comparing against the saved quote. It then searches for newer material on each sub-question. The critique step highlights changed, removed or newly contradicted findings, and the reviewer sees a diff instead of a whole new report. Preferences come from the store as before. Reusing a thread for a month-later refresh would bloat context, which is why a new thread is cleaner.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware
2. BA LangGraph store keyed by namespace
3. CA checkpointer keyed by thread_idCorrect answer
4. DThe virtual filesystem's write_file tool

Why: Short-term, thread-scoped state is persisted by a checkpointer using the thread_id, which enables resume.

Sourced from Docs by LangChain (MCP)

1. ARetry, skip, abort
2. BApprove, edit, rejectCorrect answer
3. CSummarize, cache, publish
4. DAllow, deny, escalate

Why: interrupt_on is set per tool, with allowed decisions of approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. AFix it with real evidence or mark it as uncertainCorrect answer
2. BApprove it automatically at the interrupt
3. CKeep it, since the model is confident
4. DDelete the sources list

Why: The workflow requires the main agent to fix flagged claims or mark them as uncertain, never present them as supported.

Sourced from Docs by LangChain (MCP)

1. AIt removes the need for a checkpointer
2. BSubagents always use a cheaper model automatically
3. CThe subagent works in an isolated context and returns only a concise result, keeping the main context cleanCorrect answer
4. DIt is the only way to call external tools

Why: Subagents handle noisy, multi-step work in their own context and pass back a summary, which prevents raw search results from bloating the orchestrator's context.

Sourced from Docs by LangChain (MCP)

1. AA text splitter
2. Bresponse_format with a schema such as a Pydantic modelCorrect answer
3. CMultiServerMCPClient
4. DSummarizationMiddleware

Why: Structured output via response_format makes the agent's final answer conform to a schema, so missing fields fail validation.

Sourced from Docs by LangChain (MCP)

1. AIn a LangGraph store as a JSON document under a namespace and keyCorrect answer
2. BIn the system prompt of each subagent, hard-coded
3. CIn the thread's message history
4. DIn a notes file in the virtual filesystem

Why: Long-term memory shared across threads uses LangGraph stores, which hold JSON documents by namespace and key.

Sourced from Docs by LangChain (MCP)

1. ABreaking the question into sub-questions and an outlineCorrect answer
2. BSaving notes with quotes and URLs
3. CApproving the final report
4. DCompressing older messages

Why: The deep agent uses write_todos to plan, turning the question into sub-questions and a report outline.

Sourced from Docs by LangChain (MCP)

1. AIt runs the critique subagent
2. BIt adapts tools from MCP servers into LangChain toolsCorrect answer
3. CIt stores checkpoints
4. DIt validates the Pydantic report

Why: The MCP adapters, including MultiServerMCPClient, turn MCP server tools such as web search into LangChain tools.

Sourced from Docs by LangChain (MCP)

1. AIt asks the human to choose a model
2. BIt restarts the thread from scratch
3. CIt returns an empty response
4. DIt tries the configured fallback models in orderCorrect answer

Why: Fallback models are tried in order when the primary model fails.

Sourced from Docs by LangChain (MCP)

1. AFilesystem, summarization, subagents and prompt cachingCorrect answer
2. BVector store, retriever, embeddings and loaders
3. CPII redaction, model fallback and HITL only
4. DWeb search, HTML parsing and publishing

Why: Deep Agents pre-assembles filesystem, summarization, subagents and prompt caching for long tasks.

Sourced from Docs by LangChain (MCP)

1. AOnly a brief summary, with full notes kept in filesCorrect answer
2. BNothing; it publishes directly
3. CThe raw search API response
4. DThe full HTML of every page

Why: The subagent writes detailed notes to files and returns only a short summary to keep the main context small.

Sourced from Docs by LangChain (MCP)

1. AIn the model's weights
2. BIn the HITL interrupt payload only
3. CNowhere; it is lost
4. DIn the notes files in the virtual filesystemCorrect answer

Why: Full notes stay in files while the main context keeps plans and summaries.

Sourced from Docs by LangChain (MCP)

1. AAsking the main agent if it is sure
2. BDeterministically matching the quote against the saved extracted page textCorrect answer
3. CChecking that the URL uses https
4. DCounting how many sources the report has

Why: A text match against the fetched content catches fabricated or paraphrased quotes without relying on model judgement.

Sourced from Docs by LangChain (MCP)

1. APIIMiddleware
2. Bwrite_todos
3. CLangGraph store
4. DTool retry middlewareCorrect answer

Why: Tool retry handles transient tool failures before escalating.

Sourced from Docs by LangChain (MCP)

1. ABefore the report is published or sharedCorrect answer
2. BAfter each summarization
3. CBefore loading preferences
4. DBefore every web search

Why: The workflow pauses before publishing or sharing, which is the irreversible, high-impact action.

Sourced from Docs by LangChain (MCP)

1. ANo personal data is present
2. BEvery claim is true
3. CEvery citation supports its claim
4. DThe output has the required fields and typesCorrect answer

Why: Schema validation checks structure and types; citation support needs separate checks such as critique and quote matching.

Sourced from Docs by LangChain (MCP)

1. AA vector store retriever
2. BPIIMiddleware
3. CModel fallback middleware
4. DA checkpointer saving thread-scoped stateCorrect answer

Why: Short-term memory is thread-scoped through a checkpointer, so the paused graph state can be resumed with the human's decision on the same thread_id.

Sourced from Docs by LangChain (MCP)

1. AHow many tool calls are allowed
2. BThe size of each notes file
3. CThe maximum length of the final report
4. DWhen summarization of older messages startsCorrect answer

Why: The trigger sets the threshold at which older messages are summarized; keep sets what recent context is retained.

Sourced from Docs by LangChain (MCP)

1. ATranslate it
2. BMask itCorrect answer
3. CEmbed it into a vector store
4. DCite it as a source

Why: PIIMiddleware supports strategies such as redact, mask or block for types like email and phone.

Sourced from Docs by LangChain (MCP)

1. Abefore_model
2. Bafter_model
3. Cwrap_tool_callCorrect answer
4. Dwrap_model_call

Why: wrap_tool_call wraps tool execution; the other hooks act around model calls.

Sourced from Docs by LangChain (MCP)

1. Aresponse_format
2. Bbefore_modelCorrect answer
3. Cwrap_tool_call
4. Dafter_model

Why: before_model runs before the model is invoked; response_format is not a hook.

Sourced from Docs by LangChain (MCP)

1. AThe MCP server
2. BThe checkpointer alone
3. CLangGraphCorrect answer
4. DA vector store

Why: In LangChain v1, create_agent runs the model-tool loop on LangGraph.

Sourced from Docs by LangChain (MCP)

1. Ainit_chat_model("provider/model/version")
2. Binit_chat_model(provider_id=3)
3. Cinit_chat_model("model@provider")
4. Dinit_chat_model("provider:model")Correct answer

Why: Models are initialised with a "provider:model" string.

Sourced from Docs by LangChain (MCP)

1. ABecause web pages change, so readers know when the content was seenCorrect answer
2. BTo compute token cost
3. CBecause MCP requires it
4. DTo sort files alphabetically

Why: Pages change or disappear, so the access date anchors what the source said when it was read.

Sourced from Docs by LangChain (MCP)

1. AOne namespace in the store
2. BGlobal across all users
3. COne thread, via the checkpointerCorrect answer
4. DOne tool call

Why: Short-term memory is thread-scoped and persisted by a checkpointer.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware
2. BModel call limit middlewareCorrect answer
3. CPIIMiddleware
4. DLLM tool selector

Why: Model call limit middleware bounds the number of model calls, preventing runaway loops.

Sourced from Docs by LangChain (MCP)

1. Asystem_prompt
2. Binterrupt_on
3. Ckeep
4. Dresponse_formatCorrect answer

Why: Structured output is configured with response_format.

Sourced from Docs by LangChain (MCP)

1. AOneCorrect answer
2. BZero
3. CIt depends on the model
4. DFive

Why: Syndicated copies share one origin, so they count as one independent source; the critique step flags duplicates.

Sourced from Docs by LangChain (MCP)

1. AEvery source ID in a finding exists in the sources listCorrect answer
2. BThe summary is under one sentence
3. CFindings are in alphabetical order
4. DThe title contains the deadline

Why: Cross-checking source IDs against the sources list catches dangling citations that the type schema alone may not.

Sourced from Docs by LangChain (MCP)

1. ASummarization merges them
2. BEach run uses its own thread_id with the checkpointerCorrect answer
3. CAll runs share one thread
4. DThe MCP server stores state per user

Why: State is scoped per thread_id, so concurrent runs are independent and can be resumed individually.

Sourced from Docs by LangChain (MCP)

1. AHumanInTheLoopMiddleware
2. BModel fallback
3. CTool retry
4. DLLM tool selectorCorrect answer

Why: The LLM tool selector middleware picks relevant tools from a larger set.

Sourced from Docs by LangChain (MCP)

1. ADocument loader, text splitter, embeddings, vector store, retrieverCorrect answer
2. BVector store, loader, retriever, splitter, embeddings
3. CSplitter, retriever, loader, vector store, embeddings
4. DRetriever, embeddings, loader, splitter, vector store

Why: Documents are loaded, split, embedded, stored in a vector store and then queried through a retriever.

Sourced from Docs by LangChain (MCP)

1. AIt replaces the checkpointer
2. BIt only works with MCP tools
3. CIt is required for every store
4. DIt is optionalCorrect answer

Why: LangGraph stores hold JSON documents by namespace and key, with semantic search as an optional feature.

Sourced from Docs by LangChain (MCP)