Customer chat with short- and long-term memory

Short-term memory is the conversation itself, so I keep it in a LangGraph checkpointer keyed by thread_id. Each chat resumes its own message state and nothing else. Long-term memory is durable facts about the customer, so it goes in a LangGraph store under a namespace like users, user_id, preferences, with one JSON document per key. The split matters because the two have different lifetimes, access patterns and retention rules. Threads can expire after the conversation, while preferences persist until the customer changes them or withdraws consent. I would only write to the store through an explicit, validated tool, and I would derive user_id on the server from the authenticated session. Only allow-listed preference fields would ever be stored, never account details.

Sourced from Docs by LangChain (MCP)

The chat API authenticates the session, then resolves a server-side thread_id and user_id. It invokes an agent built with create_agent, using thread_id in configurable and user_id as runtime context. A Postgres checkpointer gives short-term memory per thread. A LangGraph store holds long-term preferences. Middleware runs in order: PIIMiddleware masks identifiers, a custom before_model hook injects the customer's preferences into the system prompt, and SummarizationMiddleware compresses long histories. The model answers only through a search_faq retriever over approved FAQ content and cites the entry. It writes lasting preferences through a validated save_preference tool. Questions about accounts or transactions are escalated to a human along with the thread summary. Replies stream back to the customer, and events go to an audit log.

Sourced from Docs by LangChain (MCP)

These two values decide whose memory the agent reads and writes. If a client or the message text could supply them, anyone could type another customer's ID and load that person's thread or preferences. So the chat API derives them from the authenticated session. It maps the session to the customer's user_id and to a thread it owns, then passes thread_id through config and user_id through runtime context. The model never sees these values as editable inputs. Tools such as save_preference read user_id from the runtime, never from tool arguments. That means even a prompt-injected model cannot redirect a write to someone else's namespace. This is the single most important control for keeping customers isolated.

Sourced from Docs by LangChain (MCP)

The model decides when to call the tool. Its judgement can be wrong, or a customer can manipulate it with a message like 'remember my account number'. An allow-list of fields, such as language and contact_channel, each with allowed values or formats, turns long-term memory into a closed schema. Anything outside the list is rejected and the tool returns an error message to the model. This stops sensitive data, free-text notes and injected instructions from being persisted and later replayed into every future conversation. It also makes memory predictable for compliance reviews, because you can list exactly what the bank stores about a customer's preferences. The rule lives in code, so it does not depend on the prompt.

Sourced from Docs by LangChain (MCP)

I use layered controls. First, PIIMiddleware masks or redacts card numbers, account numbers, phones and emails before the model runs. Raw identifiers therefore never reach the model, the checkpoint or the summary. Account-number formats need custom regex detectors on top of the built-in types. Second, save_preference accepts only allow-listed fields with constrained values, so a sixteen-digit string cannot be saved as a language. Third, the tool can run a final pattern check and reject values that look like identifiers. Fourth, the store is never written from free text, only from that tool. Finally, I would scan stored records periodically and alert on any match. No single layer is trusted alone.

Sourced from Docs by LangChain (MCP)

I would give the agent an escalate_to_human tool and a clear policy: anything that needs account data or a transaction action goes to a human. That includes balances, disputes and blocking a card. The tool creates a handoff ticket in the contact-centre system, using the server-side user_id and thread_id from runtime context, and attaches the thread summary. It returns a reference the bot can share with the customer. I would also add a deterministic check, such as a keyword or classifier pre-check, so escalation does not rely only on the model noticing. The bot then tells the customer a human will take over. It never guesses at balances or promises outcomes.

Sourced from Docs by LangChain (MCP)

Several layers protect against this, and none depends on the model obeying. PIIMiddleware masks the account-number pattern before the model sees it, so the real digits are gone. If the model still tries to call save_preference, the allow-list rejects any field that is not permitted, such as 'account_number'. The value check rejects identifier-like strings in allowed fields. The write is scoped to the runtime user_id, so it cannot target another customer. The system prompt also tells the model to decline, but the prompt is the weakest layer. What actually enforces the rule is the code in the tool and middleware. I would log and monitor these rejected attempts.

Sourced from Docs by LangChain (MCP)

I would add SummarizationMiddleware to create_agent with a token-based trigger, for example tokens at 4000, and a keep rule such as the last 20 messages. Older turns get replaced by a model-written summary, and recent turns stay verbatim, so immediate follow-ups still resolve. Before tuning the thresholds, I would build an evaluation set of real long transcripts, anonymised, and check whether answers late in the thread still get the product, the issue and the customer's constraints right. I would also make sure PII masking runs before summarization so summaries never contain raw identifiers. If summaries keep dropping specific facts, I would move those facts into structured state or the preference store rather than just raising the keep count.

Sourced from Docs by LangChain (MCP)

Isolation has to come from infrastructure, not the prompt. The chat API derives thread_id and user_id from the authenticated session and passes them through config and runtime context. The model never supplies them, and the client cannot override them. Tools and middleware build store namespaces only from that runtime user_id. I would add tests that run two customers concurrently and assert that no reads cross namespaces. I would also make sure no default or shared thread_id exists anywhere in the code. On top of that, PII masking limits what could leak even if a bug slipped through, and audit logs record which namespace each read and write touched, so we can detect and investigate issues.

Sourced from Docs by LangChain (MCP)

I would use a namespace tuple such as ('users', user_id, 'preferences'), with one key per preference field, for example 'language' or 'contact_channel'. Each value is a small JSON document containing the value, an updated_at timestamp and a source, such as 'stated in chat'. Keeping the user_id inside the namespace means every read and write is naturally scoped, and a whole customer can be listed or deleted by prefix. One key per field avoids read-modify-write races on a single big document, and each field can be validated separately. I would not store free-text notes here. The namespace holds only allow-listed, structured preferences, which keeps it auditable and stops sensitive data from slipping in.

Sourced from Docs by LangChain (MCP)

If you scrub only at persistence time, the raw identifier still reaches the model provider. It can then be echoed in the reply, copied into a summary, or passed as a tool argument before any scrubber sees it. Running PIIMiddleware before the model means the state the agent works on already has masked values. So the checkpoint, the SummarizationMiddleware output and any tool calls all inherit the masked version. This also cuts the data shared with a third-party model, which matters for banking privacy obligations. The trade-off is that the bot cannot act on a real account number. That is acceptable, because account-specific questions are escalated to a human who works in authenticated bank systems.

Sourced from Docs by LangChain (MCP)

The system prompt tells the model to answer bank-policy questions only from search_faq results, cite the FAQ entry ID or title, and say it cannot confirm when nothing relevant is found. The search_faq tool queries a vector store built only from approved FAQ documents, and each chunk carries metadata such as entry ID, title and version. I can use response_format to require a structured answer that includes a citations field, then reject or regenerate any answer with no citation. Offline, I would evaluate on a set of real questions and check two things: that the answers are faithful to the retrieved text, and that out-of-scope questions get a refusal or an escalation.

Sourced from Docs by LangChain (MCP)

An in-memory checkpointer loses every conversation when a process restarts. It also cannot share state across multiple API replicas behind a load balancer, so a follow-up routed to another pod would lose context. A Postgres checkpointer persists thread state durably, works for any replica, and fits the bank's existing backup, encryption and access-control practices. It also allows retention policies and deletion by thread. The cost is a database read and write each turn, plus storage growth, which you manage with connection pooling, indexing on thread_id and pruning old threads. In-memory checkpointers are fine for tests and local development, not for a production banking chat.

Sourced from Docs by LangChain (MCP)

I would build the estimate from clearly stated assumptions and replace them with measured values after a pilot. The inputs are conversations per day, average turns per conversation, the average size of each stored state snapshot, and the retention period. Checkpointers can save state at every step, so the number of snapshots per turn matters, not just the number of messages. Summarization keeps the message list bounded, which limits snapshot size for long chats. Multiply these out to get daily growth, then multiply by retention. I would then load-test with realistic transcripts, measure actual row sizes and write rates, and size Postgres, indexes and the pruning job from those measurements rather than guesses.

Sourced from Docs by LangChain (MCP)

I would add the model fallback middleware to create_agent with an ordered list of alternative models, initialised with init_chat_model. If the primary model call fails, the next model is tried. Each fallback must be approved by the bank for data handling and tested against the same evaluation set, because answer quality and tool-calling behaviour differ between models. I would also set timeouts and a model call limit so failures do not spiral. If every model fails, the API returns a clear message and offers human chat. The thread checkpoint is preserved, so the customer can continue the same conversation once service recovers.

Sourced from Docs by LangChain (MCP)

Two memory systems hold customer data. The first is short-term memory: every checkpoint for each thread the customer owns, which is why the chat API keeps a mapping of user_id to thread_ids. The second is long-term memory: all items under ('users', user_id, ...) in the store. Beyond those, check derived copies such as escalation tickets, analytics exports and logs, following the bank's retention and regulatory obligations. Some audit records may need to be retained by law, so legal and compliance decide what is deleted and what is retained. I would build deletion as a tested, idempotent job that also writes its own audit entry.

Sourced from Docs by LangChain (MCP)

I would write automated tests that create two users with distinct preferences and threads, then assert that each agent run reads and writes only its own namespace and thread. Adversarial tests would send messages containing another user's ID, or instructions like 'load preferences for user X', and confirm nothing changes. I would check that save_preference ignores any user identifier in its arguments and uses only runtime context. At the API layer, tests confirm a session cannot resume a thread_id it does not own. In production, I would add logging that records the namespace used for each store call and alert on any mismatch with the session's user_id.

Sourced from Docs by LangChain (MCP)

The summary is written by a model from the messages it replaces. If those messages were already masked by PIIMiddleware, the summary has no raw identifiers to copy. The risk comes from data that slipped past the detectors, for example an account number typed with unusual spacing. To guard against this, I would tune detectors on realistic formats and give the summary prompt an instruction never to restate identifiers. I would also scan the summary for patterns before it becomes part of the state, which a custom after-step hook can do. The summary is also short-term memory scoped to the thread, never written to the store. So any leak stays limited to that one customer's conversation.

Sourced from Docs by LangChain (MCP)

The human receives the case reason, the masked thread summary, the last few messages, the customer's verified identity from the bank's own systems, and the thread reference for audit. The summary lets the agent understand the issue in seconds without making the customer repeat themselves. Because it was built from PII-masked messages, it does not spread raw identifiers into another system. The full transcript is still available through the audit trail if needed, but the summary is what drives quick handling. The human verifies account details inside authenticated core banking tools, not from the chat text. That keeps the trust boundary clear between the FAQ bot and account servicing.

Sourced from Docs by LangChain (MCP)

Two concurrent runs on one thread can both load the same checkpoint and then write competing next states. The result is lost messages or interleaved, confusing history. I would serialise runs per thread_id, for example with a per-thread lock or a queue in the chat API. A second message either waits for the first run to finish, or the earlier run is cancelled and restarted with both messages. The UI can also disable sending while a reply is streaming. Preference writes are less risky because each field is its own key and the latest value wins, but the conversation thread itself needs ordering to stay coherent.

Sourced from Docs by LangChain (MCP)

I would add tool retry middleware to handle transient errors, with limited attempts and backoff. If search_faq still fails, the tool returns an explicit error result rather than nothing. The system prompt tells the model that without retrieved content it must not answer policy questions from memory. Instead it apologises and offers a human agent or a link to the official help page. Monitoring tracks retriever error rate and latency, and alerts on spikes. The key principle is to fail closed: a banking bot that invents a fee or eligibility rule during an outage is worse than one that says it cannot answer right now.

Sourced from Docs by LangChain (MCP)

save_preference writes to the store immediately. The custom before_model middleware reads preferences on every model call, so the next model call sees the new value. Often that is the very next step in the same run, once the tool result returns. Within the current turn, the model also has the tool result in its messages, so it can switch language right away. I would have the tool return a confirmation that states the stored value, so the customer can correct it. Reading per model call costs a small store lookup each time. That is cheap compared with serving stale preferences, though a short cache could be added if store latency matters.

Sourced from Docs by LangChain (MCP)

I would log events, not raw content. That means the thread reference, user reference, timestamps, which tools were called and whether they succeeded, FAQ entry IDs cited, preference fields changed with their old and new allowed values, escalation events, model and fallback used, and token counts. Any message text included should be the PII-masked version, and only where policy requires it. I would avoid raw prompts containing identifiers, authentication tokens, and full retrieved documents. The log should be append-only with restricted access, because it serves compliance and incident review. Streaming should not delay audit writes, so I would emit events asynchronously but reliably, for example through a durable queue.

Sourced from Docs by LangChain (MCP)

I would start from the model's context window and the fixed overhead: the system prompt, injected preferences, tool definitions and retrieved FAQ chunks. The trigger must fire well before the window fills. The keep value should cover enough recent turns for follow-ups like 'and for a credit card?' to resolve, while keeping tool calls paired with their results. A low trigger summarises often, adding cost and the risk of lost detail. A high trigger means expensive, slow prompts. I would replay real long transcripts at a few settings and compare answer quality, token cost and latency. Then I would pick values from that data rather than defaults.

Sourced from Docs by LangChain (MCP)

The FAQ source owned by the bank's content team is the system of record. On publish, a pipeline reloads the changed documents, splits them, re-embeds the chunks and updates the vector store. It replaces old chunks by entry ID so stale versions are not retrievable. Each chunk carries a version and an effective date, so citations point to the current entry and audits can show what was live when. Old checkpoints and summaries may mention the earlier answer. The prompt can tell the model to trust the latest retrieved content over the conversation history. I would also run a regression evaluation after each re-index.

Sourced from Docs by LangChain (MCP)

The before_model middleware adds 'respond in Hindi' to the system prompt from the stored preference. The model may translate the customer's question into English before calling search_faq, or you can use a multilingual embedding model so a Hindi query still retrieves English chunks. The model then answers in Hindi while citing the English FAQ entry. Translation can change the meaning of fees and conditions, so for critical facts I would keep amounts and terms exact and link to the official entry. Where the bank publishes official Hindi FAQs, index them as well and prefer them. I would evaluate retrieval accuracy and answer faithfulness separately for each supported language.

Sourced from Docs by LangChain (MCP)

This is a short, interactive FAQ chat with a few tools, not a long autonomous task. create_agent gives the standard model-tool loop on LangGraph, plus checkpointer, store and middleware support. That covers summarization, PII masking, fallbacks and custom hooks. create_deep_agent adds a filesystem, subagents and planning for long multi-step work, which adds surface area a bank FAQ bot does not need. A hand-written graph gives the most control but more code to maintain. I would move to one only if I needed deterministic routing steps that middleware cannot express cleanly, such as a fixed compliance workflow before every answer.

Sourced from Docs by LangChain (MCP)

I would track four groups of metrics. Quality: the share of answers with a valid FAQ citation, faithfulness to retrieved content in sampled reviews, and correct escalation of account-specific questions. Safety: PII detections, rejected save_preference attempts, and any identifier patterns found in stored memory, which should be zero. Experience: containment rate, escalations, repeat questions and customer feedback. Operations: latency to first streamed token, model and tool error rates, fallback usage, summarization frequency and tokens per conversation. I would run an offline evaluation set before each prompt, model or FAQ change, so regressions are caught before customers see them.

Sourced from Docs by LangChain (MCP)

Not for this design. Preferences are a small, fixed set of allow-listed fields read by exact namespace and key, so a direct get is faster, cheaper and deterministic. Semantic search makes sense when long-term memory holds many free-form items, such as notes or past issues, and you need to find the relevant ones by meaning. That is exactly the kind of unstructured memory I would avoid in a bank because of sensitive-data risk. If the product later needs richer memory, I would add it as a separate namespace, put it through its own review and redaction, and only then consider an embedding index on it.

Sourced from Docs by LangChain (MCP)

I would add the model call limit middleware to cap the number of model calls per run, and possibly per thread. That way a confused model cannot keep calling search_faq with slightly different queries. Tool retry is bounded too. The system prompt tells the model to answer or escalate after a small number of searches. When the limit is hit, the run ends with a graceful message offering a human agent instead of an error. I would monitor model calls per turn and tokens per conversation, and alert on outliers, because loops often reveal retrieval gaps or confusing FAQ content that should be fixed at the source.

Sourced from Docs by LangChain (MCP)

That is a product decision enforced by the chat API, not the agent. One option is to resume the most recent open thread the authenticated user owns, looked up server-side, so the conversation continues. The other is to start a new thread, which keeps contexts clean. Either way, long-term preferences follow the customer, because they live in the store under the user_id, not in the thread. A common approach is to resume a thread that was active recently and start fresh otherwise. Whichever you choose, the server checks ownership before loading any thread, and the client never chooses an arbitrary thread_id.

Sourced from Docs by LangChain (MCP)

It helps wherever downstream code needs reliable fields instead of free text. For example, the final answer could be a schema with the reply text, a list of cited FAQ entry IDs, and an escalate flag with a reason. The API can then enforce that answers have citations, route escalations deterministically and log the cited entries without parsing prose. The trade-off is extra constraints on the model, and streaming the reply text gets a little more complex. I would validate the structured result, and if it fails validation, retry or fall back to a safe message plus escalation.

Sourced from Docs by LangChain (MCP)

Probably not in the customer-facing loop. It interrupts a tool call so a reviewer can approve, edit or reject it, and a waiting customer cannot be the reviewer for internal actions. Here the risky operations, account data and transactions, are deliberately out of scope and handed to humans through escalation. A possible use is an internal back-office variant where staff review certain actions before they run. For save_preference, the allow-list and a confirmation message to the customer are usually enough. Adding interrupts would hurt latency without much safety gain for low-risk, constrained fields.

Sourced from Docs by LangChain (MCP)

1. ASetting response_format on the agent
2. BAdding the LLM tool selector middleware
3. CPassing a checkpointer to create_agent and invoking with a consistent thread_idCorrect answer
4. DStoring messages in the vector store used for retrieval

Why: Short-term memory is thread-scoped state saved by a checkpointer. Reusing the same thread_id in the config resumes that thread's messages.

Sourced from Docs by LangChain (MCP)

1. AFrom a tool argument the model fills in
2. BFrom the FAQ vector store metadata
3. CFrom a field the model extracts from the customer's message
4. DFrom runtime context set by the chat API after authenticating the sessionCorrect answer

Why: The server resolves user_id from the authenticated session and passes it as runtime context. That way neither the customer nor the model can change whose memory is used.

Sourced from Docs by LangChain (MCP)

1. AThe model fallback middleware
2. BSummarizationMiddleware
3. CPIIMiddlewareCorrect answer
4. DHumanInTheLoopMiddleware

Why: PIIMiddleware redacts, masks or blocks sensitive patterns before the model runs, so the checkpoint and summary inherit the masked text.

Sourced from Docs by LangChain (MCP)

1. ATo choose which model to call
2. BTo decide when to summarize
3. CTo speed up store writes
4. DTo restrict long-term memory to approved fields, so sensitive or arbitrary data is rejectedCorrect answer

Why: Validating fields in code keeps long-term memory to a closed schema, whatever the model or the customer asks for.

Sourced from Docs by LangChain (MCP)

1. ASave the request as a preference
2. BEstimate it from earlier messages
3. CAnswer from the model's general knowledge
4. DEscalate to a human agent with the thread summaryCorrect answer

Why: Questions that need account data or a transaction action are outside the FAQ bot's scope and are escalated.

Sourced from Docs by LangChain (MCP)

1. AStore access is scoped to the server-provided runtime user_id, not to message contentCorrect answer
2. BSummarization removes the request
3. CThe vector store filters by user
4. DThe model is instructed to refuse

Why: Isolation is enforced in code through the runtime user_id, so message text cannot change the namespace.

Sourced from Docs by LangChain (MCP)

1. AThe system prompt hard-coded at deploy time
2. BThe checkpointer of the previous thread
3. CA LangGraph store document under a per-user namespace and keyCorrect answer
4. DThe SummarizationMiddleware summary

Why: LangGraph stores hold JSON documents by namespace and key across threads, which makes them the long-term memory layer. Checkpoints are scoped to a single thread.

Sourced from Docs by LangChain (MCP)

1. ASummarizes every 20 messages regardless of length
2. BWhen history exceeds about 4000 tokens, replaces older messages with a summary and keeps the most recent 20 messagesCorrect answer
3. CTruncates the model's output to 4000 tokens
4. DBlocks the request when it exceeds 4000 tokens

Why: The trigger decides when summarization runs, and keep decides how much recent history stays verbatim. Everything older is condensed into a summary.

Sourced from Docs by LangChain (MCP)

1. AAs a tool argument to search_faq
2. BIn config as {'configurable': {'thread_id': ...}}Correct answer
3. CAs a key in the LangGraph store
4. DInside the system prompt

Why: The checkpointer scopes short-term memory using thread_id, which is supplied in the configurable section of the invocation config.

Sourced from Docs by LangChain (MCP)

1. AThe LangGraph store's semantic search
2. BThe thread's saved message state loaded by the checkpointerCorrect answer
3. CThe FAQ retriever's metadata filter
4. DThe audit log

Why: Short-term memory is the thread's message state, which the checkpointer persists and reloads for each turn.

Sourced from Docs by LangChain (MCP)

1. A('users', user_id, 'preferences')Correct answer
2. B('threads', thread_id)
3. C('faq', 'preferences')
4. D('preferences',)

Why: Including user_id in the namespace isolates each customer's preferences and supports reads and deletion by prefix.

Sourced from Docs by LangChain (MCP)

1. AThey are moved to the LangGraph store
2. BThey are summarized first
3. CThey are deleted
4. DThey are kept verbatim while older messages are replaced by a summaryCorrect answer

Why: The keep setting preserves recent messages exactly, and only older messages are condensed into a model-written summary.

Sourced from Docs by LangChain (MCP)

1. ATo compress long conversations
2. BTo authenticate the session
3. CTo ground answers in approved FAQ content and cite the entryCorrect answer
4. DTo store customer preferences

Why: Retrieval over approved content prevents unverified answers from the model's general knowledge and enables citations.

Sourced from Docs by LangChain (MCP)

1. ALLM tool selector
2. BModel fallback middlewareCorrect answer
3. CPIIMiddleware
4. DSummarizationMiddleware

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

Sourced from Docs by LangChain (MCP)

1. Aload_llm('model')
2. BChatAgent.from_string('model')
3. Cinit_chat_model('provider:model')Correct answer
4. Dcreate_model('provider/model')

Why: init_chat_model accepts a 'provider:model' string to create a chat model.

Sourced from Docs by LangChain (MCP)

1. ABecause checkpointers cannot store text
2. BTo trigger summarization sooner
3. CBecause the model is cheaper on masked text
4. DSo raw identifiers never reach the model, the checkpoint or the summaryCorrect answer

Why: Masking early means every downstream artefact, including the provider call, summary and checkpoint, sees only the masked values.

Sourced from Docs by LangChain (MCP)

1. AOnly the model provider
2. BOnly the system prompt
3. COnly the vector store
4. DThe checkpoints for the customer's threads and the store items under their user namespaceCorrect answer

Why: Short-term memory lives in thread checkpoints and long-term memory in the store namespace, so both must be covered.

Sourced from Docs by LangChain (MCP)

1. AEscalation events
2. BRaw account numbers from customer messagesCorrect answer
3. CTimestamps of tool calls
4. DCited FAQ entry IDs

Why: The audit log records events and masked content. Raw identifiers would spread sensitive data into another system.

Sourced from Docs by LangChain (MCP)

1. AA custom before_model middlewareCorrect answer
2. Bwrap_tool_call on search_faq
3. CAn after_model hook on the final reply
4. DThe checkpointer's save method

Why: The design reads preferences from the store in a custom before_model middleware and adds them to the system prompt before each model call.

Sourced from Docs by LangChain (MCP)

1. ANo checkpointer; resend history from the client
2. BThe LangGraph store under the user namespace
3. CAn in-memory checkpointer on each pod
4. DA Postgres checkpointer shared by all replicasCorrect answer

Why: A durable, shared Postgres checkpointer keeps thread state across restarts and across replicas.

Sourced from Docs by LangChain (MCP)

1. AModel call limitCorrect answer
2. BPIIMiddleware
3. CHumanInTheLoopMiddleware
4. DTool retry

Why: The model call limit middleware bounds the number of model calls, which stops costly loops.

Sourced from Docs by LangChain (MCP)

1. AIncrease the summarization trigger
2. BStore FAQ answers in the preference namespace
3. CRemove the tool and let the model answer from memory
4. DAdd tool retry middleware with bounded retriesCorrect answer

Why: Tool retry handles transient failures. After retries are exhausted, the agent should fail closed rather than guess.

Sourced from Docs by LangChain (MCP)

1. ARaw HTTP request logs
2. BBinary checkpoints keyed by thread_id
3. CJSON documents organised by namespace and key, with optional semantic searchCorrect answer
4. DOnly vector embeddings of FAQ content

Why: Stores keep JSON documents by namespace and key and can optionally support semantic search.

Sourced from Docs by LangChain (MCP)

1. AOne-time password
2. BDebit card number
3. CPreferred contact channelCorrect answer
4. DLast transaction amount

Why: Preferences like language and contact channel are safe and lasting. Identifiers, transactions and secrets must never be stored.

Sourced from Docs by LangChain (MCP)

1. AA model-written summaryCorrect answer
2. BThe FAQ entries they referenced
3. CThe customer's stored preferences
4. DNothing; they are dropped

Why: SummarizationMiddleware condenses older messages into a summary and keeps the recent ones verbatim.

Sourced from Docs by LangChain (MCP)

1. ACheckpointer, store and middleware
2. BPIIMiddleware and SummarizationMiddleware
3. CAn audit log and a queue
4. DDocument loaders, text splitters, embeddings, a vector store and a retrieverCorrect answer

Why: RAG in LangChain combines loaders, splitters, embeddings, vector stores and retrievers.

Sourced from Docs by LangChain (MCP)

1. ADisable the checkpointer
2. BWrite messages to the store instead
3. CGive each message a random thread_id
4. DSerialise runs per thread_id in the chat APICorrect answer

Why: Serialising runs per thread prevents concurrent runs from overwriting each other's checkpoint state.

Sourced from Docs by LangChain (MCP)

1. AUse response_format with a schema that includes a citations field and validate itCorrect answer
2. BIncrease the model temperature
3. CStore citations in the preference namespace
4. DRely on the summary

Why: Structured output gives machine-checkable fields, so the API can reject answers that have no citation.

Sourced from Docs by LangChain (MCP)

1. AAfter the vector store re-indexes
2. BOnly in a new conversation
3. CImmediately, because the before_model middleware reads the store before each model callCorrect answer
4. DAfter the next summarization

Why: Preferences are read from the store on each model call, so a new write takes effect from the next call.

Sourced from Docs by LangChain (MCP)

1. ARetry, skip or cache
2. BSummarize, keep or drop
3. CMask, hash or block
4. DApprove, edit or rejectCorrect answer

Why: interrupt_on is set per tool and allows approve, edit or reject decisions.

Sourced from Docs by LangChain (MCP)

1. AThrough the checkpointer
2. BOnly through create_deep_agent
3. CBy pasting their schemas into the system prompt
4. DUsing the MCP adapters, such as MultiServerMCPClient, to convert them into LangChain toolsCorrect answer

Why: LangChain's MCP adapters adapt MCP server tools into LangChain tools that create_agent can use.

Sourced from Docs by LangChain (MCP)

1. AWhen you need a checkpointer
2. BWhen you need PII masking
3. CFor a short FAQ chat with two tools
4. DFor long multi-step tasks that need a filesystem, subagents and summarizationCorrect answer

Why: Deep Agents pre-assemble filesystem, summarization, subagents and prompt caching, which suits long tasks rather than simple chat.

Sourced from Docs by LangChain (MCP)

1. Awrap_tool_callCorrect answer
2. Bwrap_model_call
3. Cbefore_model
4. Dafter_model

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

Sourced from Docs by LangChain (MCP)