Support FAQ bot with semantic caching

I treat article lineage as part of every cache entry. When the RAG agent produces an answer, the structured output includes cited article IDs, and I store those IDs and versions with the cached answer. The CMS emits a change event on publish, edit or retire. A worker consumes it, deletes all cache entries tagged with that article ID, and re-chunks and re-embeds the article in the KB vector store. On a cache hit I also check that the stored versions match current ones, which covers races. A TTL sits underneath as a backstop for anything missed. I also track time from publish to purge so editors know when the bot reflects their change.

Sourced from Docs by LangChain (MCP)

The chat API receives the message, redacts phone numbers, emails and account IDs, and classifies intent. Account-specific intents skip the cache and go to the agent or a human. FAQ intents are embedded and searched in a cache index filtered by language and segment. A hit counts only if it is above the tuned threshold and its linked article versions are still current. On a miss, a create_agent agent calls a retriever tool over the KB vector store and returns a structured answer with citations, confidence and a needs_human flag. A confidence gate either answers, caches generic high-confidence results, or hands off to a human. A separate path handles CMS change events: re-embed the article and purge tagged cache entries. Tracing closes the loop.

Sourced from Docs by LangChain (MCP)

There are two reasons: privacy and hit quality. If raw phone numbers or account IDs were embedded, the cache key would carry personal data. A stored entry could also leak one customer's details to another through a near match. Redaction also makes queries more uniform. "Why was 98xxxxxxx charged roaming" and the same question with a different number collapse to one pattern, which improves reuse. Redaction alone is not the full defence, though. Answers about a specific account still bypass the cache entirely, because the answer itself is personal even when the query looks generic. PIIMiddleware on model calls adds a second layer in case something slips past the API redaction.

Sourced from Docs by LangChain (MCP)

Each entry holds an ID, the redacted query text and its vector, and the embedding model name and version. It also holds the language, the customer segment, the intent label, the answer text, and a list of cited article IDs, each with the version used. Then it holds the created time, the TTL expiry, and the generating model plus trace ID for audit. The article IDs need to be filterable metadata, because the reindex worker deletes by article ID. The versions let the read path reject an entry whose article has moved on. Storing the embedding model version prevents mixing vectors from different models. No customer identifiers are stored, because entries are shared across customers.

Sourced from Docs by LangChain (MCP)

I would not guess a number. I build a labelled set of query pairs from real logs: true paraphrases, and tricky near-misses like activate versus deactivate roaming or prepaid versus postpaid. I sweep thresholds and look at precision of hits, because a wrong cached answer costs more than a miss. I pick the point where false hits are acceptably rare, then watch it in production by sampling hits for review and using thumbs-down and human resolution labels. Metadata filters for language and segment reduce the burden on the threshold. If negation errors remain, I add a cheap check such as a reranker or keyword guard before serving.

Sourced from Docs by LangChain (MCP)

Handoff triggers should be explicit and testable: the customer asks for a person, the question needs account access like billing disputes or SIM swaps, the structured output reports low confidence or no supporting article, or the conversation keeps looping. I use a deterministic gate on the response_format fields rather than parsing free text. For smoothness, the thread is persisted with a LangGraph checkpointer, so the human agent receives the full transcript, the retrieved articles and the detected intent. The customer should not have to repeat anything. Human resolutions are then fed back as labels to improve the KB and cache rules.

Sourced from Docs by LangChain (MCP)

Two questions can be almost identical in meaning yet have different correct answers. "How do I check my data usage" may have one answer for prepaid and another for postpaid. The embeddings will be very close, so the similarity score cannot tell them apart. Filtering by segment as metadata makes a wrong-segment answer impossible, not just unlikely. Language works the same way. A Hindi speaker should get the Hindi answer, and a cross-lingual embedding could otherwise return an English cached answer. These are hard partitions applied before ranking. The similarity threshold then only has to separate paraphrases from different questions within the same partition.

Sourced from Docs by LangChain (MCP)

Purging is asynchronous and can fail or lag. The webhook might be delayed, the queue might back up, or a delete might partly fail. A version check at read time compares each cited article's stored version with the current version registry. That closes the window between publish and purge, so a stale answer is never served even while the purge is pending. It is cheap, because it is a key lookup on a small set of article IDs. Think of purging as keeping the cache clean and the version check as the correctness guarantee. The TTL is a third backstop for anything both miss.

Sourced from Docs by LangChain (MCP)

The agent may start on a cache miss, retrieve article v3, and still be generating while v4 is published and the purge runs. If it then writes its answer, a stale entry appears after the purge. The fix is a conditional write. Before inserting, compare the cited article versions in the answer with the current version registry, and skip the write if any are outdated. The read-time version check is a second guard, because even if the write slipped through, the entry would be rejected on lookup. Storing the version with each retrieved chunk is what makes this possible. The structured output only gives article IDs, so the versions should come from the retrieved chunk metadata.

Sourced from Docs by LangChain (MCP)

That is the riskiest failure, so I would design for it. First, set the classifier's operating point to favour bypassing: when unsure, treat the question as account-specific, since a missed cache hit only costs latency. Second, use cheap rules alongside the model, such as possessives with billing terms or redaction placeholders in the query. Third, the agent's structured output has a needs_human flag, and a question needing account access triggers handoff. Fourth, at write time, block caching if the answer contains redaction placeholders or personal patterns. Finally, sample cached entries in review to catch misrouted intents and retrain.

Sourced from Docs by LangChain (MCP)

It is defence in depth at a different boundary. API redaction handles the inbound customer message. During the agent loop, though, personal data could enter through other paths: retrieved content, tool results, earlier thread history, or a format the API regex missed. PIIMiddleware runs around model calls and can redact, mask or block types such as email and phone. That protects both what goes to the model provider and what comes back. It also lowers the chance that an answer containing personal data reaches the cache write step. I would still keep a separate check at the cache write, because caching shared data has the highest privacy risk.

Sourced from Docs by LangChain (MCP)

Not on its own. Self-reported confidence from an LLM is often poorly calibrated, and it can be confidently wrong. I would combine it with objective signals. Did the retriever return chunks above a relevance floor? Are the cited article IDs actually among the retrieved chunks? Is the article current? Is the intent on the list of intents allowed in the cache? The gate treats model confidence as one input. Answering requires grounding, and caching requires the strictest combination. Over time, compare confidence with human resolution labels and feedback from tracing, and calibrate the threshold per intent rather than using a single global number.

Sourced from Docs by LangChain (MCP)

After the agent returns, check each cited ID against the set of chunks the retriever tool actually returned in that run. Then check it against the current version registry. If the model cites an ID it never retrieved, or an article that is retired, treat the answer as ungrounded and either retry or hand off. If no valid citations remain, the step five rule applies: no supporting article means handoff. This check matters most for caching. The cited IDs are the invalidation tags, so a wrong or missing ID means the entry would never be purged when the real source article changes.

Sourced from Docs by LangChain (MCP)

Assume at-least-once delivery. The webhook handler should write the event to a durable queue and acknowledge quickly. The worker processes events idempotently, keyed by article ID and version, so a duplicate repeats a harmless purge and reindex. Failed events retry with backoff and go to a dead-letter queue with an alert. For lost webhooks, run a periodic reconciliation job. It compares CMS article versions with the version registry and KB index, and emits events for any mismatch. The read-time version check and the TTL limit the damage while the pipeline catches up. Tracing should show the lag from publish to purge.

Sourced from Docs by LangChain (MCP)

Reindexing takes time, because chunking and embedding a long article is not instant. If you purge only afterwards, the old cached answers stay valid-looking for that whole window and can be served after the editor has published a correction. That might be a wrong tariff or a withdrawn offer. Purging first means that during the window, queries miss the cache and go to the agent. The agent may still see old chunks briefly, which is why version checks at write time matter. The cost of purging early is a short burst of extra agent calls. That is a cheap price compared with serving an outdated answer.

Sourced from Docs by LangChain (MCP)

The bare follow-up has almost no meaning on its own, so embedding it would match random entries or nothing. There are two safe options. First, rewrite the turn into a standalone question using the thread context, such as "how do I activate international roaming on postpaid". Then redact it, re-evaluate segment and intent, and look it up. Second, bypass the cache for context-dependent turns and let the agent answer with the thread history. Rewriting improves the hit rate but adds a model call, and a bad rewrite can cause a false hit. I would start by bypassing and add rewriting once evaluation showed it was reliable.

Sourced from Docs by LangChain (MCP)

Yes. A user might use prompt injection to make the agent produce a misleading answer, which would then be cached and served to everyone with similar questions. The defences come in layers. Cache only generic intents with high confidence and valid citations to current articles. Check that the answer is grounded in retrieved text rather than in user-supplied instructions. Keep the system prompt firm that the KB is the only source. Consider caching only when the query matches a known FAQ topic. Rate-limit cache writes per session. Sample cache entries for review, and provide a manual purge-by-entry tool so a bad answer can be removed at once.

Sourced from Docs by LangChain (MCP)

For the cache, track hit rate per intent, language and segment; the similarity score distribution for hits and near misses; the false-hit rate from sampled reviews; and stale-rejection counts from the version check. For the agent, track latency for hits and misses, model fallback rate, structured output failures, the confidence distribution, and citation validation failures. For handoffs, track the rate by reason: low confidence, no article, user asked for a person, or account access. For freshness, track lag from CMS publish to purge and dead-letter queue depth. For outcomes, track customer feedback and human resolution labels.

Sourced from Docs by LangChain (MCP)

Use three kinds of pairs from redacted historical queries. First, true paraphrases that should share an answer. Second, near-miss pairs that look alike but differ: activate versus deactivate roaming, prepaid versus postpaid, a daily pack versus a monthly pack. Third, account-specific questions that must never hit. Label each pair with whether the answer should be shared. Run the embedding, threshold, filters and intent classifier over the set, and measure false hits and missed reuse per intent. Also include staleness tests: edit an article and confirm its entries are purged and rejected. Re-run the set whenever the embedding model, threshold or classifier changes.

Sourced from Docs by LangChain (MCP)

The TTL is a backstop, not the main invalidation mechanism. It limits how long an entry can survive if both the purge and the version check fail. Examples are an article edited outside the CMS, a missed webhook, or a bug in tagging. It also ages out answers that depend on things the CMS does not track, such as a policy explained in a system prompt. I would choose it from how often articles change and how costly a stale answer is. Plan and tariff topics would get shorter TTLs than stable how-to content. I would check the effect on hit rate in tracing, since too short a TTL wastes the cache.

Sourced from Docs by LangChain (MCP)

Start with the number of distinct generic questions you expect to cache within the TTL window. FAQ traffic tends to concentrate on a limited set of topics, but you should measure that from logs rather than assume it. Vector storage is roughly entries times dimensions times bytes per value. For example, 100,000 entries at 1,024 float32 dimensions is about 410 MB. Add the index overhead, which depends on the index type, and add the metadata and answer text. Multiply by the number of language and segment partitions if entries are duplicated per partition. Even generous estimates usually fit in one vector store node, so lookup latency matters more than storage.

Sourced from Docs by LangChain (MCP)

A cache hit costs one embedding call, one filtered nearest-neighbour search, and one version check. Use a fast embedding model, and keep it on the same model as the cache vectors. Use an approximate index with metadata filtering that runs efficiently, rather than filtering after the search. Keep the article version registry in a fast key-value store. Run the lookup with a strict timeout. If it times out, fall through to the agent instead of failing the request. Reuse the query embedding for KB retrieval where the models match, so a miss does not pay twice. Measure the p95 of the hit path in tracing against the miss path.

Sourced from Docs by LangChain (MCP)

The fallback model may differ in quality, refusal behaviour, structured output reliability and calibration of its confidence field. The confidence gate may then let through answers that would not pass with the primary model. I would record which model produced each answer in tracing. I would also consider not writing fallback-generated answers to the shared cache, or applying a stricter confidence bar to them, so an outage does not fill the cache with weaker answers for the whole TTL. Test the fallback model with response_format in advance, because a model that often fails schema validation turns a provider outage into a flood of human handoffs.

Sourced from Docs by LangChain (MCP)

The worker should never move an article backwards. Keep the current version per article in the registry and apply an event only if its version is newer. A late v4 after v5 is then dropped, apart from a purge, which is always safe. The reindex should fetch the latest published content from the CMS rather than trusting the event payload, so the result matches the CMS. Partitioning the queue by article ID keeps events for one article in order, but the version comparison is what guarantees correctness. Out-of-order events then cost only extra work, never stale content.

Sourced from Docs by LangChain (MCP)

An edit replaces content: re-chunk, re-embed, swap in the new chunks and purge cache entries tagged with the article. A retirement removes content. The worker must delete the article's chunks from the KB vector store, purge every cache entry tagged with it, and mark it retired in the version registry. The read-time check then rejects any entry citing it. If the retired article was the only source for some answers, later queries on that topic may find no support and go to a human. That is correct behaviour. Tracing will show a rise in handoffs on that topic, which tells editors a replacement article is needed.

Sourced from Docs by LangChain (MCP)

A tool lets the model reformulate a query, search again when the first results are weak, or decide that no article supports an answer and set needs_human. A fixed chain always does one retrieval and then generates, which is simpler, cheaper and more predictable. For a FAQ bot the trade-off is real. I would keep the tool set small, possibly only the retriever, and cap iterations with the model call limit middleware so cost and latency stay bounded. If evaluation showed single-shot retrieval was good enough, a two-step chain would be an acceptable choice too.

Sourced from Docs by LangChain (MCP)

The checkpointer stores thread-scoped state under a thread ID, including the message history. When the chat moves to a human, the agent console loads that thread, so the customer does not have to repeat the issue. The concern is that the history may contain personal data, especially for account questions. Apply the same redaction rules to what is stored where possible. Restrict console access by role, and set a retention period that follows telecom and data protection rules. Never let checkpointer content feed the shared semantic cache. Cache writes use only the redacted generic query and the grounded answer.

Sourced from Docs by LangChain (MCP)

False hits are silent, because the customer gets a fluent answer to the wrong question. Sample cache hits regularly, stratified by similarity score, with extra weight near the threshold. Have reviewers label whether the cached question and the new question truly share an answer. Watch for cache hits followed by negative feedback, a rephrase or a request for a human, which are strong signals. Compare with human resolution labels when those chats escalate. Feed confirmed false pairs into the evaluation set. Then tighten the threshold for that intent or add a rule, such as keeping activate and deactivate apart.

Sourced from Docs by LangChain (MCP)

I would keep them separate. The filter is by language, so each language has its own entries and answers. Even if a multilingual embedding places them close together, the customer must get an answer in their own language. Translating a cached answer on the fly adds latency and risk. Code-mixed input, such as Hinglish, is common, so language detection needs a clear rule for which partition that input goes to. Separate partitions slightly lower hit rates for less common languages, but they keep answers correct and make review simpler.

Sourced from Docs by LangChain (MCP)

LangGraph stores hold JSON documents by namespace and key, with optional semantic search. A namespace like language and segment maps naturally to the partitions, so it is a workable option for modest volume. The key requirement here, though, is bulk deletion by article ID across all entries, along with efficient filtered nearest-neighbour search and tight latency. A dedicated vector store with metadata filters and delete-by-filter usually suits that better. I would choose based on whether the store can do a fast, reliable delete of every entry tagged with an article ID, because invalidation correctness matters more than convenience.

Sourced from Docs by LangChain (MCP)

It is not worth it when traffic is spread thinly across many distinct questions so hits are rare, or when most questions are account-specific and must bypass the cache anyway. It is also not worth it when articles change so often that entries are purged before reuse, or when the agent path is already fast and cheap enough. Each lookup adds an embedding call and a search to every FAQ request. A false hit costs more than a miss, because it is a wrong answer delivered with confidence. I would measure potential hit rate from logs offline first, by replaying redacted historical queries against a simulated cache, before building it.

Sourced from Docs by LangChain (MCP)

Take the most common generic questions from historical chat logs and search queries, redacting them first. Group paraphrases together, and run each representative question through the normal agent path. Write only the answers that pass the same confidence, citation and intent rules as live traffic. Have editors spot-check the warm set before launch. Do not hand-write answers straight into the cache, because that bypasses grounding and citation tags, and those tags are needed for invalidation. Warming improves early hit rates, but live traffic will quickly reshape the cache anyway.

Sourced from Docs by LangChain (MCP)

HumanInTheLoopMiddleware interrupts before specific tool calls, with allowed decisions of approve, edit or reject. It suits tools with side effects. The FAQ agent's retriever is read-only, so it does not need approval. Handoff in this design is a different mechanism, where the whole conversation is routed to a human agent. If the bot later gained action tools, such as raising a ticket or changing a plan, I would set interrupt_on for those tools so a human approves or edits the call before it runs. That keeps the cheap read path automatic and gates only the actions that change something.

Sourced from Docs by LangChain (MCP)

1. Ainitialize_agent
2. BAgentExecutor.from_tools
3. Ccreate_react_chain
4. Dcreate_agentCorrect answer

Why: LangChain v1 builds agents with create_agent (createAgent in JS), which runs the model-tool loop on LangGraph.

Sourced from Docs by LangChain (MCP)

1. Asystem_prompt
2. Boutput_parser
3. Ctool_choice
4. Dresponse_formatCorrect answer

Why: Structured output in LangChain v1 is configured with response_format.

Sourced from Docs by LangChain (MCP)

1. ACache the answer after redacting the amount
2. BSearch the cache only within the postpaid segment
3. CBypass the cache, because the answer is personalCorrect answer
4. DServe the closest cached answer if similarity is high

Why: Account-specific questions are marked to bypass the cache, because their answers depend on the individual customer's data.

Sourced from Docs by LangChain (MCP)

1. AThe same customer asked the question earlier
2. BSimilarity above the tuned threshold, matching language and segment, and linked article versions still currentCorrect answer
3. CSimilarity above the threshold only
4. DThe entry is younger than its TTL only

Why: Lookups are filtered by language and segment, and a hit must clear the threshold and have current article versions.

Sourced from Docs by LangChain (MCP)

1. AThe entire cache
2. BEntries whose similarity to A-17 is high
3. CEvery entry tagged with article ID A-17Correct answer
4. DOnly entries older than the TTL

Why: The worker deletes every cache entry tagged with the changed article's ID.

Sourced from Docs by LangChain (MCP)

1. AMore model fallbacks
2. BSlower webhook delivery
3. CFalse hits that serve an answer to a different questionCorrect answer
4. DHigher embedding storage cost

Why: A low threshold accepts less similar queries, so the cache returns answers that belong to different questions.

Sourced from Docs by LangChain (MCP)

1. AA cited answer about roaming activation steps
2. BAn answer describing the customer's own unpaid billCorrect answer
3. CA grounded answer about recharge validity rules
4. DAn answer in Hindi about SIM replacement steps

Why: Account-specific answers contain personal data and are only correct for one customer. Caching them risks leaking data and serving wrong answers to others.

Sourced from Docs by LangChain (MCP)

1. ALLMChain(model=...)
2. BChatModel.load("model")
3. Cinit_chat_model("provider:model")Correct answer
4. Dget_llm(provider, model)

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

Sourced from Docs by LangChain (MCP)

1. AThe redacted queryCorrect answer
2. BThe full thread history
3. CThe agent's draft answer
4. DThe raw customer message

Why: Phone numbers, emails and account IDs are redacted first, and then the redacted query is embedded and searched.

Sourced from Docs by LangChain (MCP)

1. AA day after reindexing
2. BOnly when the TTL expires
3. CAfter reindexing completes successfully
4. DBefore or together with the reindexCorrect answer

Why: Purging before or together with the reindex ensures no stale answer survives the change.

Sourced from Docs by LangChain (MCP)

1. AThe checkpointer retention policy
2. BA backstop in case event-driven purges or version checks miss somethingCorrect answer
3. CThe main invalidation mechanism
4. DThe similarity threshold

Why: The workflow uses a TTL only as a backstop. Purging on change events and version checks are the main controls.

Sourced from Docs by LangChain (MCP)

1. ARedact, mask or blockCorrect answer
2. BApprove, edit or reject
3. CSummarise, trim or drop
4. DEncrypt, sign or hash

Why: PIIMiddleware supports redact, mask and block strategies for PII types.

Sourced from Docs by LangChain (MCP)

1. ARoutes every call to the cheapest model
2. BTries fallback models in order when the primary model call failsCorrect answer
3. CRetries tool calls with backoff
4. DCaches model outputs

Why: Model fallback middleware tries the configured fallback models in order when a model call fails.

Sourced from Docs by LangChain (MCP)

1. AThe checkpointer's thread-scoped stateCorrect answer
2. BThe semantic cache
3. CThe KB vector store
4. DThe CMS webhook queue

Why: Short-term memory is thread-scoped through the checkpointer, so the human agent can see the saved thread history.

Sourced from Docs by LangChain (MCP)

1. AOnly a timestamp
2. BThe full cache contents
3. CThe editor's credentials
4. DThe article ID and new versionCorrect answer

Why: The webhook emits a change event containing the article ID and its new version.

Sourced from Docs by LangChain (MCP)

1. AFlush the whole cache on every event
2. BIgnore all events after the first per day
3. CReject the second event with an error
4. DIdempotent processing keyed by article ID and versionCorrect answer

Why: With at-least-once delivery, idempotent handling keyed by article ID and version makes duplicates harmless.

Sourced from Docs by LangChain (MCP)

1. ANo article supports the answer
2. BA generic FAQ answered with high confidence and valid citationsCorrect answer
3. CThe question needs account access
4. DThe customer asks for a person

Why: High-confidence, grounded answers to generic questions go straight to the customer. The other cases are handoff triggers.

Sourced from Docs by LangChain (MCP)

1. ATo choose the customer segment
2. BTo allow purging by article ID and to check freshness at read timeCorrect answer
3. CTo rank entries by popularity
4. DTo pick the embedding model

Why: The IDs are the purge tags, and the versions let the read path reject entries built on outdated articles.

Sourced from Docs by LangChain (MCP)

1. ASegment filtering will separate them
2. BThe threshold alone cannot separate them, so near-miss evaluation pairs or rules are neededCorrect answer
3. CThey should share one cached answer
4. DEmbeddings capture negation perfectly

Why: Opposite intents can embed close together, so you need near-miss test pairs, per-intent tuning or rules to stop false hits.

Sourced from Docs by LangChain (MCP)

1. AWhenever confidence is low, so it can be reviewed later
2. BWhen the intent is generic and confidence is highCorrect answer
3. CAlways, after it is sent
4. DOnly when a human approves it

Why: Only generic, high-confidence answers are cached, together with the vector, segment, and cited article IDs and versions.

Sourced from Docs by LangChain (MCP)

1. ACount webhook events
2. BTrack the TTL expiry rate
3. CReview sampled cache hits, especially near the threshold, alongside human resolution labelsCorrect answer
4. DMonitor CPU usage

Why: The workflow reviews sampled hits and human resolution labels to tune the threshold and catch false hits.

Sourced from Docs by LangChain (MCP)

1. ASet a checkpointer on the agent
2. BUse SummarizationMiddleware
3. CPass response_format to create_agentCorrect answer
4. DAdd HumanInTheLoopMiddleware

Why: response_format on create_agent produces structured output. The other options handle summarisation, tool approvals and thread memory.

Sourced from Docs by LangChain (MCP)

1. AOnly lower the similarity threshold
2. BRebuild or clear the cache index with the new modelCorrect answer
3. CIncrease the cache TTL
4. DNothing, cached answers are text

Why: Vectors from different embedding models are not comparable, so similarity scores between new queries and old cached vectors are meaningless until the index is rebuilt.

Sourced from Docs by LangChain (MCP)

1. ARetry, skip or fail
2. BCache, purge or expire
3. CApprove, edit or rejectCorrect answer
4. DRedact, mask or block

Why: interrupt_on is configured per tool, and the allowed decisions are approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. AJSON documents by namespace and key, with optional semantic searchCorrect answer
2. BPlain text files per user
3. CVectors with no metadata
4. DRows keyed by thread ID only

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

Sourced from Docs by LangChain (MCP)

1. AMore stale answers
2. BPII leaks
3. COut-of-order change events
4. DFew hits, so most queries pay the full agent cost and latencyCorrect answer

Why: A very strict threshold rejects valid paraphrases, which lowers the hit rate and sends more traffic to the agent.

Sourced from Docs by LangChain (MCP)

1. Awrap_model_call
2. Bwrap_tool_callCorrect answer
3. Cbefore_model
4. Dafter_model

Why: wrap_tool_call wraps tool execution. wrap_model_call, before_model and after_model act around model calls.

Sourced from Docs by LangChain (MCP)

1. ARewrite it into a standalone question before lookup, or bypass the cacheCorrect answer
2. BCache it under the prepaid segment
3. CHand it to a human every time
4. DEmbed it as is and serve any hit

Why: Context-dependent fragments carry little meaning on their own, so they need a standalone rewrite or a cache bypass to avoid false hits.

Sourced from Docs by LangChain (MCP)

1. ARemove its chunks from the KB vector store and purge cache entries tagged with itCorrect answer
2. BNothing, because retirement is not a content change
3. CKeep its chunks but stop showing citations
4. DExtend the TTL of its cache entries

Why: Retirement is a change event. Its content must leave the KB and every cached answer citing it must be purged.

Sourced from Docs by LangChain (MCP)

1. AAbout 41 MB
2. BAbout 4 GB
3. CAbout 410 MBCorrect answer
4. DAbout 4 MB

Why: 100,000 × 1,024 × 4 bytes ≈ 409.6 million bytes, or about 410 MB, before index overhead and metadata.

Sourced from Docs by LangChain (MCP)

1. Atrigger=("cache_hits", 100)
2. Btrigger=("seconds", 30)
3. Ctrigger=("tokens", 4000), keep=("messages", 20)Correct answer
4. Dkeep=("articles", 5)

Why: SummarizationMiddleware takes a trigger such as ("tokens", 4000) and a keep setting such as ("messages", 20).

Sourced from Docs by LangChain (MCP)

1. AAdapt them with the MCP adapters, for example MultiServerMCPClientCorrect answer
2. BRegister them as text splitters
3. CCall the MCP server from the system prompt
4. DStore the tools in the checkpointer

Why: MCP tools are converted into LangChain tools with the MCP adapters, such as MultiServerMCPClient.

Sourced from Docs by LangChain (MCP)

1. ANo, because deep agents cannot call tools
2. BYes, because it is required for RAG
3. CNo. It pre-assembles filesystem, subagents and summarization for long tasks, while a short FAQ loop fits create_agentCorrect answer
4. DYes, because only deep agents support response_format

Why: create_deep_agent targets long, multi-step tasks. A short retrieve-and-answer FAQ loop is well served by create_agent.

Sourced from Docs by LangChain (MCP)