Email agent with middleware guardrails

I would make send_email the only tool that can send, and list it in HumanInTheLoopMiddleware's interrupt_on with approve, edit and reject allowed. The agent runs with a durable checkpointer, so when the model proposes a send the graph interrupts and the state is saved. Nothing executes until the API resumes that thread with a decision. I would audit the tool list so no MCP server or helper tool can also send, enforce at the provider layer that the agent's credentials only send through this tool, and log every decision with the final arguments. The metric I watch is sends without a matching approval, which must be zero.

Sourced from Docs by LangChain (MCP)

The API starts or continues a run on the user's thread_id, so the checkpointer loads only that conversation's state. The agent, created once with create_agent, enters the model-tool loop. Before each model call, PIIMiddleware redacts, masks or blocks sensitive types. SummarizationMiddleware compacts old turns if the token trigger is crossed. The call limit middleware checks the per-run and per-thread caps. The model can then call read_inbox, search_mail and create_draft freely. When it emits send_email, HumanInTheLoopMiddleware raises an interrupt and the checkpointer persists the paused state. The review UI shows recipients, subject and body. The user approves, edits or rejects, and the API resumes the same thread. The tool runs only on approve or edit, and every step is written to the audit log.

Sourced from Docs by LangChain (MCP)

Yes. Middleware is applied in list order, so the order decides what each layer sees. I want PII handling to run before anything sends content to a model, and that includes the summarizer, which makes its own model call. Otherwise raw PII could reach the summarization prompt and then be kept in the summary. The call limit should count every real model call. Human-in-the-loop acts on the model's tool calls, so its position relative to the before-model layers matters less, but it must cover send_email on every path. I would not trust my reading of the docs alone. I would write tests that capture the exact messages each model call receives and confirm that no raw PII appears and that send_email always interrupts.

Sourced from Docs by LangChain (MCP)

Duplicates usually come from retries: a network failure after the provider accepted the message, a double-clicked approve button, or a worker crashing before it records completion. I derive an idempotency key from the thread_id and the pending tool call's id. Before calling the provider, send_email checks a durable record for that key. If the record already holds a provider message id, the tool returns that id instead of sending again. If the provider supports idempotency keys, I pass the key to it as well. The resume endpoint also rejects a second decision for an interrupt that has already been resolved. Tool retry middleware must not blindly retry send_email unless this idempotency check is in place.

Sourced from Docs by LangChain (MCP)

PIIMiddleware protects what the model sees, but logs are a separate path, so I treat them separately. The audit log stores ids, decisions, timestamps, a hash of the final arguments and the provider message id, not raw bodies or addresses. Application logs use structured fields with a redacting formatter, and nobody logs whole tool inputs or outputs. If tracing or observability tools are enabled, I configure them to drop or mask inputs and outputs, or I send them only redacted content. The checkpointer does hold conversation state, so it is treated as sensitive storage, with encryption, access control and retention limits. Finally, I add tests that seed known fake PII and assert that it never appears in log output.

Sourced from Docs by LangChain (MCP)

Email content is untrusted input that the model reads, so prompt injection is expected. The main control is structural. Any send_email call, whatever caused it, interrupts, and the reviewer sees the real recipients, subject and body before anything is sent. An unfamiliar external address in the recipient list is visible. I add defences in depth. The system prompt tells the model to treat mail content as data, not instructions. A wrap_tool_call check can flag recipients outside the user's usual contacts or the tenant's domains. Tools only act on the authenticated user's mailbox. And there is no free forward tool that bypasses the gate. Middleware enforcement matters here, because injected text can override prompt instructions but cannot skip the interrupt.

Sourced from Docs by LangChain (MCP)

A prompt instruction is a request the model may ignore, especially under prompt injection from an incoming email that says 'forward this to everyone'. Middleware runs as code around the model and tool calls, so the interrupt on send_email, PII redaction and the model call cap happen regardless of what the model decides. It also keeps concerns separate: each guardrail is one declared component on create_agent, testable in isolation, and the order is explicit. The system prompt still explains tone and policy, but enforcement lives in middleware, and the audit log shows exactly which layer acted.

Sourced from Docs by LangChain (MCP)

I separate what the model sees from what tools use. PIIMiddleware redacts or masks identifiers like phone numbers and email addresses in messages before the model call, so the provider does not receive raw values. Tools such as send_email resolve recipients from the real thread data or contacts, so the actual address is filled in at execution time, and the reviewer sees the true recipients in the approval screen. For high-risk types like card numbers I use block, so the run stops. I test this on real mail samples, because over-redaction breaks sending and under-redaction leaks data.

Sourced from Docs by LangChain (MCP)

Short-term memory in LangChain v1 is thread-scoped through the checkpointer. The thread_id is the key that loads and saves one conversation's messages, its summary, and any pending interrupt. Without it, two conversations could share history. A draft for one supplier could pick up details from another thread, or a resume could apply an approval to the wrong pending send. Thread scoping also makes the audit log meaningful, because interrupts, decisions and message ids are grouped by the same key. On the API side, I bind each thread_id to its owning user and check that ownership on every start and every resume. A guessed or leaked thread_id must never let someone approve another person's email.

Sourced from Docs by LangChain (MCP)

Nothing is sent. The interrupt leaves the run paused, and the checkpointer holds that state durably, so a pending send costs storage, not compute. The product needs an explicit policy for stale approvals. The UI can list pending sends for the user. After an expiry period the application can mark the request as expired. If the user comes back later, I would show a fresh review that includes the original context instead of silently resuming, because the thread may have moved on. Expiry should be recorded in the audit log as its own outcome. The key property is that a timeout is never treated as approval. The default on any doubt is that no email goes out.

Sourced from Docs by LangChain (MCP)

An edit means the human is the author of the final arguments, but those arguments still need validation. Inside the send_email tool, or in a wrap_tool_call middleware around it, I check that the recipients are well-formed addresses and pass any tenant allowlist. I also check that the subject and body are within size limits and that attachments, if supported, refer to items the user owns. The tool sends exactly the edited arguments the reviewer saw, with nothing merged back in from the model's original version. I record a hash of the final arguments in the audit log so we can later prove what was sent. If validation fails, the tool returns an error to the agent and sends nothing.

Sourced from Docs by LangChain (MCP)

It is a trade-off between risk and friction. Reading, searching and drafting cause no external effect that cannot be undone. A draft sits in the user's mailbox and can be deleted. Sending is irreversible and visible to third parties, so it is where a mistake, a hallucination or a prompt injection causes real harm. Gating every tool would make the assistant tedious, and reviewers would start approving without reading, which weakens the one approval that matters. That said, free tools still need limits. They act only on the authenticated user's mailbox, their outputs pass through PII handling before the model sees them, and the call limit stops runaway loops. If tools are added later, such as delete or forward, each needs its own risk review and probably its own interrupt.

Sourced from Docs by LangChain (MCP)

It depends on whether the model needs any part of the value. Redact replaces the value with a placeholder. That suits phone numbers, which the model rarely needs in order to write a reply. Mask keeps part of the value, which helps the model refer to it without exposing the whole thing. Block stops the run, and I reserve it for types that should never be present in this workflow, such as card numbers, where continuing would be a compliance risk. I decide per type with the privacy or compliance owner and write the choice down. Blocking needs a clear user-facing message, otherwise users just see a failure. I also test detectors on real-looking samples, because both false negatives and false positives matter.

Sourced from Docs by LangChain (MCP)

I would build the estimate from variables rather than invented numbers. Model load equals active users, times requests per user per day, times model calls per run, times tokens per call. Summarization caps the history size per call and adds its own occasional summary calls, and the call limit puts a hard ceiling on calls per run. Paused approvals use no compute while they wait. They only take checkpointer storage, which scales with pending threads and state size. Mail provider API rate limits are often the real bottleneck, so I count tool calls per run too. Then I run a load test with realistic synthetic threads, measure the actual values, and revise the model. Provider quotas and pricing should come from the provider's current terms.

Sourced from Docs by LangChain (MCP)

For model failures, model fallback middleware tries the configured fallback models in order. Model calls have no external side effects, so switching models is safe, although I confirm that the fallback models meet the same data-handling requirements and behave acceptably with the tools. For tool failures, tool retry middleware helps with transient errors on read_inbox and search_mail, which are safe to repeat. send_email is different. Retrying it blindly risks duplicate sends, so either it is excluded from automatic retry or the retry goes through the idempotency check keyed by thread and tool call id. If a send keeps failing after approval, the agent should report that it was not sent, and the audit log should record the failure rather than a message id.

Sourced from Docs by LangChain (MCP)

Exactly one decision should take effect. The resume endpoint serialises work per thread_id, for example with a row lock or a compare-and-set on the interrupt's status in our own pending-approvals table. The first request moves the interrupt from pending to resolved and resumes the run. The second sees that it is already resolved and gets a clear conflict response without touching the agent. This matters most when one tab approves and the other rejects, because we must never send and also report a rejection. Even if the locking were imperfect, the idempotency key on send_email prevents a second delivery. Both requests are recorded in the audit log, and the losing one is marked as superseded.

Sourced from Docs by LangChain (MCP)

I write one append-only event per occurrence, keyed by thread_id. The fields are: event id, thread_id, user or tenant id, run id, tool call id, event type (interrupt raised, decision received, tool executed, send failed, expired), decision type (approve, edit or reject), reviewer id, a rejection reason if one was given, and a hash of the final arguments. They also include the provider message id on success and timestamps. I avoid storing raw bodies and addresses, so the log is useful for support and compliance without becoming a PII store. Rejection reasons are free text, so they should pass through the same redaction as other logs. The log should be tamper-evident and have its own retention and access policy.

Sourced from Docs by LangChain (MCP)

I test the guarantees directly, not just the happy path. With a fake model scripted to emit send_email, I check that an interrupt is raised and that the send tool's provider client is never called before a decision. I resume with approve, edit and reject and check each outcome, including that an edit sends exactly the edited arguments. I seed messages with fake phone numbers, emails and card numbers and check what each model call actually received, including the summarizer's call. I force the call cap and confirm a clean end. I replay resumes and duplicate approvals to confirm a single send. I add adversarial prompt-injection emails to an evaluation set and run all of this in CI.

Sourced from Docs by LangChain (MCP)

I would write a wrap_tool_call middleware that inspects calls to send_email. It checks the final recipients, including to, cc and bcc, against the policy for the user's tenant, for example approved domains or the user's known contacts. If a recipient fails, the middleware returns an error to the agent and the provider client is never called. This runs at tool execution time, which comes after the human decision, so it also catches a reviewer who edits in a disallowed address. A second check can flag unusual recipients in the review UI before the decision, so the human is warned early. The check is deterministic code, so model output or injected text cannot get around it.

Sourced from Docs by LangChain (MCP)

Identity comes from the authenticated session, never from the model. The tools are bound at request time to the user's server-side mail credentials, so read_inbox and send_email have no mailbox or account argument the model could change. The thread_id is tied to its owner, and every start and resume checks that the caller owns the thread, so nobody can approve someone else's pending send by knowing the id. Credentials use scoped OAuth tokens with the least permissions needed and live in a secrets store, never in messages, checkpoints or logs. The audit log records the tenant and user on every event, which makes cross-tenant mistakes detectable.

Sourced from Docs by LangChain (MCP)

When the reviewer rejects, HumanInTheLoopMiddleware does not run send_email. It returns the rejection, including the reviewer's message, to the agent as the outcome of that tool call. The model can then revise the draft, for example softening the tone or removing a recipient, which leads to a new send_email call and a new interrupt. It can also stop and explain that nothing was sent. The system prompt should tell the agent not to retry the same arguments after a rejection, and the reason should be used as guidance. The audit log records the rejection and its reason. Because every new send attempt interrupts again, a rejection can never turn into an unapproved send.

Sourced from Docs by LangChain (MCP)

Both are real risks. The summary is produced by a model, so it can drop facts such as an agreed delivery date, and it can copy any PII it was shown. For leakage, I make sure the summarizer receives content that has already been through PII handling, and I check this with tests. For lost facts, the keep setting preserves recent messages verbatim, and the tools can always re-read the original mail with read_inbox or search_mail, because the mailbox is the source of truth, not the summary. For important facts, I would tune the summary prompt to keep commitments, dates, amounts and open questions. The review step is the final safety net, because the user sees the exact body before anything is sent.

Sourced from Docs by LangChain (MCP)

I would not guess a number. I would measure how many model calls typical runs need from traces in staging, separately for simple replies, searches and multi-step tasks. Then I would set the per-run cap comfortably above the normal range, so that only runaway loops hit it. The per-thread cap protects against a long conversation building up unbounded cost. I track how often runs hit each cap. Frequent hits on legitimate tasks mean the cap is too tight or the prompt and tools are causing extra calls. Hits caused by loops mean the cap is doing its job. When the cap is reached, the run should end cleanly with a clear message, and no pending send is ever approved as a side effect.

Sourced from Docs by LangChain (MCP)

An in-memory checkpointer is fine for local development, but it loses state on restart and is not shared across instances. A paused approval could disappear, or a resume could land on a server that has never seen the thread. In production I would use a durable, shared database-backed checkpointer, for example one backed by Postgres, so any API instance can resume any thread. That store holds conversation content, so it needs encryption at rest, access controls, backups and a retention policy that matches the product's privacy commitments. I would also watch its size, because long-lived pending interrupts and long threads build up state. Summarization helps here, since compacted history keeps stored state smaller.

Sourced from Docs by LangChain (MCP)

The hash lets us prove what was sent without keeping a second copy of sensitive content. During a dispute, support can take the message from the user's sent folder or the provider record, normalise it the same way, hash it, and confirm that it matches what the reviewer approved. It also shows whether an edit happened, because the model's proposed arguments and the final arguments would hash differently. Storing raw bodies and recipient lists in the audit log would create a large PII store with a different access pattern and retention needs. One caution is that short or predictable values can be guessed from a plain hash, so I would use a keyed hash and protect that key.

Sourced from Docs by LangChain (MCP)

The review UI renders the pending tool call's arguments straight from the interrupt payload, meaning the recipients, subject and body, not a separately regenerated preview. On edit, the UI sends back the complete edited arguments, and the tool sends exactly those. On approve, the stored pending arguments are used without change. I include the tool call id and an arguments hash in the decision request, and the server checks that they match the current pending interrupt. That way a stale tab cannot approve a version that has since changed. The hash in the audit log ties the approval to what was sent. Rendering must also escape HTML, so a malicious body cannot alter what the reviewer sees.

Sourced from Docs by LangChain (MCP)

Each send is a separate action, so each needs its own decision. With HumanInTheLoopMiddleware, the interrupt carries the pending gated tool calls, and the resume supplies a decision for each one. The reviewer might approve one and reject the other. The UI must show them as separate cards with their own recipients and bodies, not as one bulk approve. Idempotency keys are per tool call id, so the two sends are tracked separately. The audit log records separate decision and execution events for each. If the product never needs more than one send per turn, I could also tell the model to send one email at a time, but the gate must work either way.

Sourced from Docs by LangChain (MCP)

For the guardrails, I track interrupts raised, the share of decisions that are approve, edit or reject, time to decision, expired approvals, and any send without a matching approval event. That last one should always be zero and should page someone immediately. For privacy, I track PII detections by type and strategy, blocked runs, and the results of log-scanning checks. For reliability, I track model errors, fallback activations, tool retries, send failures and duplicate-send prevention hits. For cost, I track model calls and tokens per run, summarization frequency, and call cap hits. A high edit or reject rate is a product signal that drafts need improvement. A sudden rise in unusual recipients could point to prompt injection.

Sourced from Docs by LangChain (MCP)

Thread-scoped checkpointer memory disappears when a new thread starts, so preferences belong in long-term memory using a LangGraph store. I would save them as JSON documents under a namespace that includes the user id, for example a preferences key holding signature, preferred greeting and tone. The agent can read them at the start of a run, or a tool can load them on demand. Writes should be explicit: either the user sets preferences in settings, or the agent proposes saving one and the user confirms it. The store holds personal data, so it gets the same access controls and deletion support as the rest. Optional semantic search helps only if preferences grow into many notes.

Sourced from Docs by LangChain (MCP)

The tools would be loaded through the LangChain MCP adapters, for example MultiServerMCPClient, which turns the MCP tools into LangChain tools that create_agent can use. The guardrails stay the same, but I have to be careful about tool names. interrupt_on matches by tool name, so I must confirm the exact name the adapter exposes for the send tool. I must also make sure no other MCP tool, such as a forward or reply tool, can send mail without its own interrupt. I would allowlist which MCP tools get loaded, not expose everything the server offers. Authentication to the MCP server must be per user and handled server-side, never passed in through model arguments.

Sourced from Docs by LangChain (MCP)

It is useful when the application, not a human, consumes the agent's final answer. For example, a triage feature could return a typed object with a category, priority and suggested action, or the final message could report whether an email was sent along with the message id. response_format gives a schema the result must match, so the UI does not need to parse free text. I would not use it for the send itself. The send_email tool's arguments are already structured, and those are what the reviewer sees and approves. Structured output is for the final answer of the run, while tool arguments are for actions.

Sourced from Docs by LangChain (MCP)

create_deep_agent pre-assembles a filesystem, summarization, subagents and prompt caching for long, multi-step tasks. That fits work such as auditing a quarter's worth of supplier correspondence, building a report and drafting dozens of follow-ups, where a planner benefits from scratch files and delegating to subagents. For the core assistant, which handles one request and maybe one send per run, create_agent with an explicit middleware list is simpler and easier to reason about. Whichever builder is used, the send gate must still apply, including to any subagent that can reach a send tool. I would verify that the human-in-the-loop and PII middleware cover every path, not just the top-level agent.

Sourced from Docs by LangChain (MCP)

The run ends cleanly instead of looping, and the user gets a clear, honest message. The task could not be finished within the allowed steps, and nothing was sent unless they had already approved a send earlier in the run. Any drafts created are still in their mailbox. I would offer a simple next step, such as narrowing the request or continuing in a new run, while keeping the per-thread cap as a hard ceiling. Internally, the event is logged with the thread_id, the cap that was hit and the run's tool sequence, so engineers can tell whether the cause was a prompt or tool design issue or a real loop.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware with trigger set to send_email
2. BA system prompt telling the model to ask before sending
3. CModel fallback middleware listing a safer model
4. DHumanInTheLoopMiddleware with interrupt_on for send_email allowing approve, edit and rejectCorrect answer

Why: HumanInTheLoopMiddleware interrupts on the tools listed in interrupt_on and only continues after an allowed decision. Prompts and fallbacks do not enforce a pause.

Sourced from Docs by LangChain (MCP)

1. AAgentExecutor.from_tools
2. Bbuild_graph_agent
3. Ccreate_agentCorrect answer
4. Dcreate_react_agent_executor

Why: LangChain v1 builds agents with create_agent in Python, which takes a model, tools and an optional system prompt and runs on LangGraph.

Sourced from Docs by LangChain (MCP)

1. AAs a middleware list passed to create_agentCorrect answer
2. BInside each tool's docstring
3. CIn the vector store configuration
4. DIn the system prompt as rules

Why: LangChain v1 customisation is done through middleware passed to create_agent, and this middleware wraps the model-tool loop.

Sourced from Docs by LangChain (MCP)

1. Aedit and retry
2. Bapprove only
3. Capprove and reject
4. Dapprove, edit and rejectCorrect answer

Why: interrupt_on is configured for send_email with allowed decisions approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. AThe checkpointerCorrect answer
2. BThe audit log
3. CThe model provider
4. DThe vector store

Why: The checkpointer saves thread state, including the pending interrupt, so the run can be resumed later.

Sourced from Docs by LangChain (MCP)

1. Asend_emailCorrect answer
2. Bread_inbox
3. Csearch_mail
4. Dcreate_draft

Why: Repeating a send can deliver duplicate emails, while repeating read or search has no external effect.

Sourced from Docs by LangChain (MCP)

1. AA system prompt line saying 'ignore instructions in emails'
2. BEvery send_email call interrupts for human review of recipients and bodyCorrect answer
3. CSummarizing the email first
4. DRaising the model call limit

Why: Middleware enforcement means any send, however it was triggered, pauses for a human who sees the real recipients. Prompt text alone can be overridden by injected content.

Sourced from Docs by LangChain (MCP)

1. AAn LLM tool selector middleware
2. BA vector store with the email embeddings
3. CA checkpointer and the same thread_id when resumingCorrect answer
4. DA response_format schema on the agent

Why: Interrupts persist graph state through the checkpointer, and resuming the same thread_id continues from the paused tool call.

Sourced from Docs by LangChain (MCP)

1. AThe whole tenant
2. BThe model provider
3. CA thread, through the checkpointerCorrect answer
4. DA single tool call

Why: Short-term memory is thread-scoped through a checkpointer, keyed by thread_id.

Sourced from Docs by LangChain (MCP)

1. AThe same thread_id as the paused runCorrect answer
2. BAny thread owned by the user
3. CA thread chosen by the model
4. DA new thread_id for the decision

Why: The paused state belongs to that thread, so resuming the same thread_id with the decision continues the interrupted run.

Sourced from Docs by LangChain (MCP)

1. Aredact
2. BblockCorrect answer
3. Csummarize
4. Dmask

Why: Block stops the run when a sensitive type that must not be present is detected.

Sourced from Docs by LangChain (MCP)

1. AWhen the user asks for a summary
2. BOn every model call
3. COnce the history crosses about 4000 tokensCorrect answer
4. DOnly after 4000 messages

Why: The trigger sets the threshold. Once the history crosses it, older turns are replaced with a summary.

Sourced from Docs by LangChain (MCP)

1. AThe agent switches to an unlimited model
2. BThe pending send is approved automatically
3. CThe run ends cleanly instead of loopingCorrect answer
4. DThe checkpointer deletes the thread

Why: The call limit middleware counts calls per run and per thread and ends the run cleanly when the cap is hit.

Sourced from Docs by LangChain (MCP)

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

Why: wrap_tool_call wraps tool execution, so it can inspect the final send_email arguments and refuse to call the provider.

Sourced from Docs by LangChain (MCP)

1. ANone of them
2. Bsend_email only
3. Cread_inbox, search_mail and create_draftCorrect answer
4. DAll four tools

Why: Read and draft tools run freely, and only send_email is gated by human-in-the-loop.

Sourced from Docs by LangChain (MCP)

1. AA rejection message, after which it can revise the draft or stop without sendingCorrect answer
2. BAn automatic approval after a timeout
3. CThe raw PII of the recipient
4. DNothing; the run is deleted

Why: On reject, send_email does not run. The agent gets the rejection message and may revise or stop.

Sourced from Docs by LangChain (MCP)

1. AA merge chosen by the model
2. BThe arguments from the previous thread
3. CThe model's original arguments
4. DThe edited final argumentsCorrect answer

Why: On edit, the tool runs with the final arguments the reviewer supplied.

Sourced from Docs by LangChain (MCP)

1. AThe user's mail password
2. BThe full email body in plaintext
3. CA hash of the final arguments and the provider message idCorrect answer
4. DThe model's hidden reasoning

Why: The log records interrupts, decisions, a hash of the final arguments and the provider message id, keyed by thread_id.

Sourced from Docs by LangChain (MCP)

1. ASerialise per thread and apply only the first decision, refusing the second as already resolvedCorrect answer
2. BLet the model choose
3. CRestart the run from scratch
4. DApply both, sending and then reporting a rejection

Why: Exactly one decision must take effect for an interrupt, and idempotency on the send stops duplicates even under races.

Sourced from Docs by LangChain (MCP)

1. ASends only 20 emails per thread
2. BSummarises older history once it passes about 4000 tokens while keeping the latest 20 messagesCorrect answer
3. CLimits the agent to 20 model calls
4. DBlocks any message longer than 4000 tokens

Why: The trigger sets when summarisation starts and keep sets how much recent context is preserved verbatim; call caps belong to the model call limit middleware.

Sourced from Docs by LangChain (MCP)

1. AMask stops the run, while redact logs a warning
2. BRedact replaces the value with a placeholder, while mask hides only part of itCorrect answer
3. CRedact encrypts the value, while mask deletes the whole message
4. DThey are identical aliases

Why: Redaction removes the value and puts a placeholder in its place, while masking keeps part of the value visible and hides the rest.

Sourced from Docs by LangChain (MCP)

1. AThe maximum number of messages a thread may ever have
2. BHow many recent messages are preserved verbatim after summarizingCorrect answer
3. CHow many summaries are stored
4. DThe number of model retries

Why: keep sets how much recent context stays as-is while older turns are compacted into the summary.

Sourced from Docs by LangChain (MCP)

1. AIt asks the user to pick a model
2. BIt skips the model and calls tools directly
3. CIt tries the configured fallback models in orderCorrect answer
4. DIt retries the same model forever

Why: Model fallback middleware tries the fallback models in order when the primary model fails.

Sourced from Docs by LangChain (MCP)

1. Aafter_tool
2. Bbefore_modelCorrect answer
3. Cwrap_tool_call
4. Don_send

Why: before_model runs ahead of each model call, which is where content such as PII can be transformed.

Sourced from Docs by LangChain (MCP)

1. Acreate_model_middleware()
2. Binit_chat_model('provider:model')Correct answer
3. Cload_llm_from_hub()
4. DChatModel.auto()

Why: LangChain v1 initialises models with init_chat_model using a 'provider:model' string.

Sourced from Docs by LangChain (MCP)

1. AModel name
2. Bthread_idCorrect answer
3. CVector store id
4. DRecipient email address

Why: Audit events are written keyed by thread_id for support and compliance review.

Sourced from Docs by LangChain (MCP)

1. AIt blocks PII by default
2. BIt cannot store messages
3. CIt loses state on restart and is not shared, so paused approvals can vanish or fail to resumeCorrect answer
4. DIt is slower than a database

Why: Paused interrupts must survive restarts and be resumable on any instance, which requires durable, shared storage.

Sourced from Docs by LangChain (MCP)

1. ATo store tools in a vector database
2. BTo pick a relevant subset of tools for the model to considerCorrect answer
3. CTo approve tool calls automatically
4. DTo redact tool outputs

Why: The LLM tool selector narrows which tools are offered to the model, which helps when many tools are available.

Sourced from Docs by LangChain (MCP)

1. AmakeReactAgent
2. BcreateAgentCorrect answer
3. CnewAgent
4. DAgentFactory.build

Why: LangChain v1 provides createAgent in JS as the counterpart to Python's create_agent.

Sourced from Docs by LangChain (MCP)

1. Ainit_chat_model
2. BSummarizationMiddleware
3. CMultiServerMCPClient from the MCP adaptersCorrect answer
4. DPIIMiddleware

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

Sourced from Docs by LangChain (MCP)

1. Ainterrupt_on
2. Bresponse_formatCorrect answer
3. Ckeep
4. Dtrigger

Why: Structured output is requested with response_format.

Sourced from Docs by LangChain (MCP)

1. AIn the thread checkpointer only
2. BIn a LangGraph store under a user namespace and keyCorrect answer
3. CIn the model's system prompt cache
4. DIn the audit log

Why: Long-term memory uses LangGraph stores, which hold JSON documents by namespace and key, while checkpointer memory is thread-scoped.

Sourced from Docs by LangChain (MCP)

1. AOnly a vector store
2. BFilesystem, summarization, subagents and prompt cachingCorrect answer
3. CHuman-in-the-loop for every tool by default
4. DAn email provider integration

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

Sourced from Docs by LangChain (MCP)