CRM sales copilot

I enforce it in the architecture, not the prompt. Write tools like log_activity and update_opportunity are listed in HumanInTheLoopMiddleware's interrupt_on, with allowed decisions approve, edit and reject. When the model calls one, the graph pauses before the tool runs and the checkpointer persists the state. The rep sees the typed arguments, can approve or edit fields, or reject with a reason. Only then does the run resume. There is no send-email tool at all, so drafts stay drafts. Tools also run with the rep's own CRM scope, and every executed write goes to an audit log. So even a prompt-injected model can at most propose a change that a human must accept.

Sourced from Docs by LangChain (MCP)

The API authenticates the rep, resolves their CRM permissions and attaches a thread_id so the checkpointer restores earlier turns. Middleware then runs in order. PIIMiddleware masks or redacts contact details, and SummarizationMiddleware trims long threads. create_agent runs the model-tool loop with a model from init_chat_model, guarded by model fallback and a model call limit. Read tools come from the CRM's MCP server through MultiServerMCPClient and run under the rep's own scope, with tool retry for transient errors. Follow-up emails are saved only as drafts. Proposed writes are typed tool calls, and HumanInTheLoopMiddleware interrupts on each one. Approved writes resume from the checkpoint as idempotent upserts, get audited, and traces go to LangSmith.

Sourced from Docs by LangChain (MCP)

The copilot should never see more than the rep could see in the CRM UI. A shared service account would let a well-crafted question, or a prompt injection hidden in a record, pull accounts, deals or notes the rep isn't entitled to. The model can't be trusted to enforce permissions. Passing the rep's own credentials or delegated token to the MCP server pushes authorisation down to the CRM, which already models territories, roles and sharing rules. It also makes audit trails honest, because each read is attributable to a real user. The cost is token management per rep and less caching across users, which I accept for correctness.

Sourced from Docs by LangChain (MCP)

First, the system prompt says to answer only from tool results and to cite record IDs for every claim. Second, I keep the tools narrow and well described, so the model fetches data instead of guessing. Third, I can add an after_model check that pulls the cited IDs from the answer and confirms each one appeared in a tool result in this run. If a claim has no citation, the answer is flagged or regenerated. If the tools return nothing, the agent should say so plainly, not fill the gap. Finally, I build LangSmith evaluation datasets of real questions with known answers and score groundedness and citation accuracy as part of regression testing.

Sourced from Docs by LangChain (MCP)

Resumes, network retries and double-clicks on Approve can all run the same write more than once. So the write tool does an upsert using an idempotency key built from the thread_id and the tool call ID. That pair uniquely identifies one proposal in one conversation. Before writing, the tool checks a small idempotency table or the CRM's external-ID field. If the key already exists, it returns the stored result instead of creating a second activity or applying a second change. The key comes from the proposal, not the timestamp, so it stays stable across resumes. This lets tool retry middleware help on transient failures without the risk of duplicate CRM records.

Sourced from Docs by LangChain (MCP)

I treat all tool output as untrusted data, not instructions, and the system prompt says so explicitly. The real protection is structural. The agent has no tool that can write without HumanInTheLoopMiddleware interrupting, so the worst case is a suspicious proposal that the rep sees and rejects. Read tools run with the rep's own scope, which limits what injected text could make the agent fetch. Writes are typed Pydantic tool calls, so the rep reviews exact field values, not vague prose. I'd also show the source record next to each proposal, and log rejections so injection attempts show up in LangSmith reviews. Emails are never sent, only drafted.

Sourced from Docs by LangChain (MCP)

This is a stale-read problem. When the agent proposes update_opportunity, it records the version or last-modified timestamp of the record it read. On approval, the write tool re-reads the record and compares versions before the upsert. If someone else changed it, the tool doesn't overwrite blindly. It returns a conflict result to the agent, which can show the rep the new values and re-propose, and that new proposal goes through approval again. For append-only writes like log_activity, conflicts rarely matter. For field updates such as stage or amount, optimistic concurrency is essential, because the rep approved a change against data that no longer exists.

Sourced from Docs by LangChain (MCP)

CRM fields are typed: stage, amount, close date, activity type, contact ID. If the model writes prose, something still has to parse it, and that parsing is where errors creep in. I give write tools Pydantic argument schemas, so a malformed call fails validation and the model gets the error to fix. The final turn uses response_format to return a list of proposed updates, which the UI renders as an editable form. When the rep edits a field in the approval step, the edit is applied to validated arguments, not to text. This also makes evals simple: I can compare proposed fields with what reps actually approved and measure the edit rate per field.

Sourced from Docs by LangChain (MCP)

I separate short-term and long-term memory. Within a conversation, state is thread-scoped through a checkpointer keyed by thread_id, which also lets interrupts resume. Long threads get SummarizationMiddleware, for example triggering at about 4,000 tokens and keeping the last 20 messages, so older tool output is compressed rather than dropped. Things that should persist across threads, like a rep's email tone, signature or preferred follow-up cadence, go in a LangGraph store namespaced by rep ID. Account facts I deliberately do not memorise. They are always fetched fresh through CRM read tools, because the CRM is the system of record and cached deal data goes stale quickly.

Sourced from Docs by LangChain (MCP)

HumanInTheLoopMiddleware has paused the run at the write tool call. The rep chooses reject and gives a reason, for example 'the meeting was rescheduled, not completed'. The run resumes from the checkpoint, and the rejection plus the reason goes back to the agent as the result of that tool call. The write never runs. The agent can then revise its proposal, which triggers a fresh interrupt, or stop and explain. Nothing touches the CRM, so no audit entry for an executed write is created, though I'd still trace the rejection in LangSmith. Rejection reasons make good evaluation data for spotting systematic mistakes.

Sourced from Docs by LangChain (MCP)

Sending email can't be undone. It reaches a customer, so the bar is higher than for a CRM field edit. Saving as a draft keeps the rep as the actual sender, in their own mail client, where they can read the final text, change recipients and fix the tone. It also removes a whole class of risk: if the agent has no send tool, prompt injection or a model bug can't email anyone. An approve-then-send flow would add little over a draft, because the rep has to read the full email either way. The agent uses the rep's tone and signature preferences from the LangGraph store so the drafts need fewer edits.

Sourced from Docs by LangChain (MCP)

It depends on whether the model needs the value. Masking keeps part of the value or its shape, so the model can still tell two contacts apart. Redacting removes the value completely, which suits phone numbers in free-text questions where the model never needs them. Blocking rejects the input, which is right for sensitive data the copilot should never handle. The catch here is that drafting emails and logging activities sometimes need real contact details. So I mask in prompts and let tools resolve contacts by record ID inside the CRM, so raw addresses don't have to pass through the model. The policy should be agreed with privacy and compliance teams.

Sourced from Docs by LangChain (MCP)

Edited arguments are new input from a person, and people make mistakes too. So I validate them again against the same Pydantic schema: types, allowed stage values, required fields and value ranges. The write tool also re-checks that the rep has permission to update that record and field, because an edit could point to a different record ID. Only then does the idempotent upsert run. The audit log keeps both the original proposed arguments and the edited ones, along with the rep and the timestamp. That difference is useful data: frequent edits to the same field show where prompts or tools need work.

Sourced from Docs by LangChain (MCP)

Each executed write gets one append-only record. It holds the rep's identity, thread_id, tool call ID, tool name, target record ID, the original proposed arguments, the edited arguments if any, the approval decision, the CRM response and the timestamp. I'd also store the record version that was read, which helps when looking into conflicts. The log should be immutable to the application, for example write-once storage with restricted delete rights, and kept apart from LangSmith traces. Traces are for debugging and may be sampled or expire, while the audit log is a compliance record. A trace link in each entry connects the two. Access to the log is restricted because it holds customer data.

Sourced from Docs by LangChain (MCP)

Retry transient failures: timeouts, connection resets, rate-limit responses and temporary server errors from the CRM's MCP server. Use exponential backoff with jitter and a small cap on attempts. Don't retry permanent failures such as permission denied, validation errors or record not found. Return those to the agent so it can explain or change course. Writes deserve extra care. Retrying a write is only safe because it's an idempotent upsert keyed by thread and tool call ID. Without that key, a timeout after the CRM committed would create duplicates. Retries also eat into latency budgets, so the cap should keep the rep's wait reasonable.

Sourced from Docs by LangChain (MCP)

Tool retry middleware handles short blips. If failures continue, the tool returns a clear error to the agent instead of hanging. The system prompt says to answer only from tool results, so the agent should tell the rep that live CRM data is unavailable rather than answer from memory or old thread context. Pending approvals stay safely checkpointed. When the rep approves later, the write tool runs once the server recovers, and idempotency prevents duplicates if earlier attempts partly succeeded. I'd add a circuit breaker so the app stops calling a known-down server, plus alerts from LangSmith traces and service metrics. Drafting an email from content the rep provides can still work.

Sourced from Docs by LangChain (MCP)

A thread_id is an identifier, not an authorisation. When the API creates a thread, it stores the owning rep and tenant. On every request, including resume calls that carry an approval, it checks that the authenticated rep owns that thread before the checkpointer restores any state. Thread IDs should be random and hard to guess. Approval endpoints must check that the person approving is the rep the interrupt belongs to, or someone with explicit delegation. Long-term store namespaces include the tenant and rep ID, so preference lookups can't cross users. These checks live in the API layer, outside the model, where they're testable and can't be bypassed by prompt text.

Sourced from Docs by LangChain (MCP)

I'd use delegated per-rep credentials, typically an OAuth token for the rep obtained through the CRM's own flow, which the API attaches when calling MCP tools. The token stays outside the model's context. The model never sees credentials, and tool arguments contain only business fields. Tokens are stored encrypted, refreshed server-side and scoped to the minimum the copilot needs. Write scopes are used only by approved write tools. Where possible I'd use separate read and write grants so read-only sessions can't write even through a bug. Revoking the rep's CRM access then cuts off the copilot automatically.

Sourced from Docs by LangChain (MCP)

I'd build datasets from real, anonymised rep questions: account summaries, open opportunity lookups, follow-up drafts and update proposals. Each has expected tool calls or reference answers. Metrics include groundedness and citation accuracy, correct tool choice, schema-valid proposals, and whether proposed updates match what a reviewer would approve. In production, approve, edit and reject rates are strong signals. A rising edit rate on one field points to a prompt or tool issue. I'd run these evaluations as regression tests on every prompt, model or middleware change, especially when changing the fallback model, and review sampled traces of rejected proposals and model-call-limit hits.

Sourced from Docs by LangChain (MCP)

I'd build a model from parameters rather than guess numbers. Inputs are active reps, questions per rep per day, peak-hour concentration, average model calls per question, tokens per call, tool calls per question and the CRM API rate limits. Model calls times tokens gives LLM cost and throughput needs. Tool calls times peak concurrency, compared with the CRM's documented API limits, often turns out to be the real bottleneck. I'd also estimate checkpoint storage per thread and how long threads are kept. Then I'd check every assumption against a pilot group's LangSmith traces and adjust. SummarizationMiddleware and the model call limit put upper bounds on tokens and calls per question.

Sourced from Docs by LangChain (MCP)

Fallback models are tried in order when the primary fails, but they aren't drop-in equivalents. Check that each fallback supports tool calling reliably and handles your response_format schema, or proposals may break. Context windows differ, so summarization settings must suit the smallest model. Data residency and provider terms matter too: falling back to a provider your privacy policy doesn't allow is a compliance failure. Fallbacks should cover outages and rate limits, not mask bad prompts. Every fallback should be visible in traces, and the evaluation datasets should run against each fallback model so quality drops are known before an outage happens.

Sourced from Docs by LangChain (MCP)

Agents can loop. They retry a failing search, repeat the same tool call or chase a vague question. A model call limit caps the number of model calls per run or thread, which bounds cost and latency and stops runaway behaviour. When the limit is hit, the run should end cleanly with a helpful message, for example saying it couldn't find a confident answer and suggesting a more specific question, rather than throwing a raw error. Any pending write proposals still need approval, so nothing is written. I'd log limit hits as a metric, because frequent hits usually mean poor tool descriptions or missing tools.

Sourced from Docs by LangChain (MCP)

The store holds JSON documents by namespace and key, so I'd namespace by tenant and rep, for example (tenant_id, rep_id, 'preferences'). Keys like 'email_style' and 'signature' hold small documents with tone, sign-off and formatting rules. Keeping it per rep prevents leakage and makes deletion easy when a rep leaves. Semantic search is optional. It helps only if you store many free-form notes, such as past phrasing examples, and a direct key lookup is enough for signatures. Preferences should be updated only from the rep's explicit choices or approved edits. Let the rep view and reset them, and never store customer PII there.

Sourced from Docs by LangChain (MCP)

I'd use a durable, database-backed checkpointer, not an in-memory one. Approvals may come hours later, after deploys or pod restarts, and the paused run must still be there to resume. Short-term memory is thread-scoped through the checkpointer, so it also holds conversation history that SummarizationMiddleware compacts. Plan a retention policy, because checkpoints contain CRM data and possibly masked PII. Expire old threads, encrypt data at rest and restrict access. Under load, checkpoint writes happen on every step, so the database must handle that write rate. Pruning old checkpoint versions keeps storage under control.

Sourced from Docs by LangChain (MCP)

Layer the controls. The Pydantic schemas for update_opportunity only include fields the copilot is allowed to change, such as stage, next step or close date. Sensitive fields like owner or commission aren't in the schema at all. At execution time, the write tool calls the CRM with the rep's own token, so the CRM enforces field- and record-level permissions anyway. For a better experience, the agent can check permissions while building the proposal, so it doesn't suggest updates the rep will just see fail. A custom wrap_tool_call middleware can centralise that check and log blocked attempts.

Sourced from Docs by LangChain (MCP)

One useful one is a wrap_tool_call middleware for write tools. Before the tool runs, it re-validates arguments, confirms the rep's permission on the target record, compares the stored record version for conflicts and injects the idempotency key from thread_id and tool call ID. After the tool runs, it writes the audit entry with original and edited arguments and the timestamp. Keeping this in middleware means every write tool gets the same guarantees without repeating code. Another option is an after_model hook that checks cited record IDs appeared in tool results. Middleware order matters: approval must happen before the write executes.

Sourced from Docs by LangChain (MCP)

Have the model issue independent tool calls together, such as opportunities and recent activities for Acme, instead of one at a time. Stream tokens and progress to the UI so the rep sees something right away. Keep tool results compact: return the fields the answer needs, not full records, which cuts tokens and model time. SummarizationMiddleware stops long threads from slowing every call. Choose a model that balances speed and tool-calling quality, and cap retries so a struggling API fails fast with a clear message. Measure the latency of each step in LangSmith traces to find the real bottleneck, which is often the CRM API, not the model.

Sourced from Docs by LangChain (MCP)

HumanInTheLoopMiddleware interrupts on each write tool call. The UI can group the pending calls into one review screen built from the response_format object that lists all proposed updates. The rep decides on each one separately: approve the activity log, edit the close date, reject the stage change with a reason. Decisions go back when the run resumes. Each approved call runs as its own idempotent upsert and gets its own audit entry, so a partial failure doesn't cause duplicates when retried. Avoid an 'approve all' button that hides details for field updates. It turns review into rubber-stamping, and that undermines the whole safety model.

Sourced from Docs by LangChain (MCP)

The CRM write itself can't be magically reversed, but the design makes correction easy. The audit log records the target record, the original values read before the write, and the arguments applied. An undo action can build a reverse update from that, and it goes through the same approval flow and is audited as its own write. This is a compensating action, not a rollback. Version checks matter here too: if someone changed the record after our write, the undo should flag a conflict instead of overwriting. Activity logs might be deleted or marked void depending on CRM policy.

Sourced from Docs by LangChain (MCP)

Use a fake or scripted model that returns fixed tool calls, plus mocked MCP tools. That makes tests deterministic. Test that every write tool triggers an interrupt and never executes without a decision. Test that approve executes exactly once, that edit re-validates and runs with the edited arguments, and that reject returns the reason to the agent without a write. Then resume the same thread twice with the same approval and confirm idempotency prevents duplicates. Restart the process between interrupt and resume to confirm the durable checkpointer works. Add integration tests against a CRM sandbox and LangSmith evaluations for behaviour.

Sourced from Docs by LangChain (MCP)

Live CRM tools fit facts that change, such as opportunities, stages, activities and owners. Indexing those into a vector store creates stale copies and permission headaches. RAG fits fairly static knowledge: sales playbooks, product sheets, pricing guidance documents or objection-handling notes. For those, I'd use document loaders, text splitters, embeddings, a vector store and a retriever exposed as a tool. The retriever must respect access controls, for example by filtering on metadata, if documents are restricted. The agent can combine both: pull Acme's open deals live, then retrieve the playbook for that deal stage to suggest next steps, citing both sources.

Sourced from Docs by LangChain (MCP)

Probably not for the core copilot. create_deep_agent pre-assembles a filesystem, summarization, subagents and prompt caching for long, multi-step tasks. Most rep questions are short: a few reads, an answer, maybe a draft and a proposal. create_agent with chosen middleware is simpler, cheaper and easier to reason about, especially for the approval guarantees. I'd consider Deep Agents for a separate long-running job, such as preparing a full quarterly account review across many records. Even then, the same rule holds: write tools stay behind HumanInTheLoopMiddleware and run with the rep's scope.

Sourced from Docs by LangChain (MCP)

It helps when the tool list grows large. If the CRM's MCP server exposes dozens of tools for accounts, contacts, cases, quotes and reports, sending every schema on every call wastes tokens and makes wrong tool choices more likely. The LLM tool selector picks a relevant subset for the current question before the main model call. With the handful of read and write tools described here, it adds latency and cost for little benefit. If I add it, I'd make sure write tools still sit behind HumanInTheLoopMiddleware whether or not they're selected, and I'd check selection accuracy in LangSmith evaluations.

Sourced from Docs by LangChain (MCP)

1. Acreate_react_chain
2. Bcreate_agentCorrect answer
3. Cinitialize_agent
4. DAgentExecutor.from_tools

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

Sourced from Docs by LangChain (MCP)

1. APIIMiddleware
2. BHumanInTheLoopMiddlewareCorrect answer
3. CTool retry middleware
4. DSummarizationMiddleware

Why: HumanInTheLoopMiddleware is configured with interrupt_on per tool, so every write tool waits for the rep's decision.

Sourced from Docs by LangChain (MCP)

1. AAn anonymous read-only key
2. BA shared admin service account
3. CThe rep's own CRM access scopeCorrect answer
4. DThe model provider's account

Why: Read tools run with the rep's own scope, so the copilot can't see data the rep isn't allowed to see.

Sourced from Docs by LangChain (MCP)

1. AThe thread ID and tool call IDCorrect answer
2. BThe current timestamp
3. CThe rep's email address
4. DA random UUID created on each attempt

Why: Keying by thread and tool call ID uniquely identifies the proposal, so resumes and retries don't create duplicates.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware deletes suspicious messages
2. BThe model call limit blocks the injected instruction
3. CEvery write tool is interrupted for rep approval and tool output is treated as dataCorrect answer
4. DPIIMiddleware removes instructions from tool results

Why: Writes can't execute without HumanInTheLoopMiddleware approval, so injected text can at most produce a proposal the rep can reject.

Sourced from Docs by LangChain (MCP)

1. AApprove, edit, rejectCorrect answer
2. BRetry, skip, abort
3. CAccept, defer, escalate
4. DCommit, rollback, replay

Why: HumanInTheLoopMiddleware is configured per tool through interrupt_on, with allowed decisions approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. APIIMiddleware
2. BA larger context window
3. CA durable checkpointer keyed by thread_idCorrect answer
4. DThe vector store retriever

Why: The checkpointer persists thread-scoped graph state, including the interrupt, so the same thread_id can resume the run later.

Sourced from Docs by LangChain (MCP)

1. ASaves them only as drafts for the rep to edit and sendCorrect answer
2. BQueues them for automatic sending at business hours
3. CSends them after the model is confident
4. DSends them after a HITL approval

Why: The agent saves emails only as drafts, and the rep edits and sends them, so the copilot never sends anything itself.

Sourced from Docs by LangChain (MCP)

1. AIt automatically blocks the rep's thread
2. BIt is discarded
3. CIt goes back to the agent, which revises its proposal or stopsCorrect answer
4. DIt is written into the CRM opportunity

Why: On rejection, the reason returns to the agent as feedback so it can revise its proposal or stop.

Sourced from Docs by LangChain (MCP)

1. Atool_choice
2. Bstructured_mode
3. Coutput_parser
4. Dresponse_formatCorrect answer

Why: Structured output in LangChain v1 agents is set with response_format.

Sourced from Docs by LangChain (MCP)

1. AAllow at most 20 tool calls
2. BDelete threads older than 20 days
3. CKeep the most recent 20 messages after summarizingCorrect answer
4. DSummarize every 20 messages

Why: trigger sets when summarization runs, for example at 4000 tokens, and keep preserves the recent context, here 20 messages.

Sourced from Docs by LangChain (MCP)

1. AIn the thread checkpointer only
2. BIn the system prompt hard-coded per deployment
3. CIn LangSmith traces
4. DIn a LangGraph store as JSON documents by namespace and keyCorrect answer

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

Sourced from Docs by LangChain (MCP)

1. AEncrypt and forward to the modelCorrect answer
2. BRedact
3. CMask
4. DBlock

Why: The listed strategies are redact, mask and block, applied to things like emails and phone numbers.

Sourced from Docs by LangChain (MCP)

1. ATries fallback models in order when the primary model call failsCorrect answer
2. BRuns all models in parallel and votes
3. CFalls back to cached answers
4. DRoutes each request to the cheapest model

Why: Fallback models are tried in order when the model call fails, which protects against provider outages.

Sourced from Docs by LangChain (MCP)

1. ATo enforce CRM rate limits on writes
2. BTo reduce PII exposure
3. CTo force summarization
4. DTo guard against runaway model-tool loopsCorrect answer

Why: A model call limit bounds the number of model calls, stopping loops that waste cost and time.

Sourced from Docs by LangChain (MCP)

1. AOverwrite with the approved values
2. BCheck the record version, and on conflict return to the agent to re-propose for fresh approvalCorrect answer
3. CSilently skip the write
4. DMerge the two versions automatically using the model

Why: Optimistic concurrency stops an approval made against stale data from overwriting someone else's change.

Sourced from Docs by LangChain (MCP)

1. AThe rep's password hash and session cookie
2. BThe original and the edited tool argumentsCorrect answer
3. COnly the final edited arguments
4. DOnly the model's reasoning text

Why: Every executed write is audited with the rep, the original and edited arguments, and the timestamp.

Sourced from Docs by LangChain (MCP)

1. AThrough SummarizationMiddleware
2. BBy pasting the MCP spec into the system prompt
3. CThrough the MCP adapters, such as MultiServerMCPClient, which convert them to LangChain toolsCorrect answer
4. DOnly by rewriting each one as a custom LLM

Why: The LangChain MCP adapters load MCP server tools and adapt them into standard LangChain tools that create_agent can call.

Sourced from Docs by LangChain (MCP)

1. A"provider/model/version"
2. B"provider:model"Correct answer
3. CA JSON object only
4. D"model@provider"

Why: Models are initialised with init_chat_model("provider:model").

Sourced from Docs by LangChain (MCP)

1. AMultiServerMCPClientCorrect answer
2. BToolNodeMCP
3. CMCPRetriever
4. DMCPToolkitLoader

Why: The MCP adapters use MultiServerMCPClient (MCPAdapter in JS) to turn MCP server tools into LangChain tools.

Sourced from Docs by LangChain (MCP)

1. Abefore_model
2. Bafter_model
3. Cwrap_model_call
4. Dwrap_tool_callCorrect answer

Why: wrap_tool_call wraps tool execution, so it can check, modify or log every tool call.

Sourced from Docs by LangChain (MCP)

1. AOnly in LangSmith traces
2. BOnly inside the CRM database
3. CIn the input, before the model sees itCorrect answer
4. DOnly in the final response to the rep

Why: Per the workflow, PII in the input is masked or redacted before it reaches the model.

Sourced from Docs by LangChain (MCP)

1. AThe CRM never times out on writes
2. BSummarizationMiddleware removes the duplicate call
3. CThe model call limit prevents duplicates
4. DThe write is an idempotent upsert keyed by thread and tool call IDCorrect answer

Why: Idempotency makes a repeated write return the existing result instead of creating a duplicate.

Sourced from Docs by LangChain (MCP)

1. AConnection timeout
2. BRate-limit response
3. CPermission denied on the recordCorrect answer
4. DTemporary server error

Why: Permission errors are permanent, so retrying wastes time and the error should go back to the agent.

Sourced from Docs by LangChain (MCP)

1. ALangSmith requires it
2. BIn-memory checkpointers can't store messages
3. CPaused approvals must survive restarts and deploys so runs can resume laterCorrect answer
4. DDurable checkpointers make the model faster

Why: Approvals may arrive hours later, so the interrupted state must persist beyond the process.

Sourced from Docs by LangChain (MCP)

1. ADrop the proposal without notice
2. BRe-validate the edited arguments against the Pydantic schema and reject invalid inputCorrect answer
3. CExecute it, since the rep approved it
4. DLet the model silently fix it

Why: Edited arguments are new human input and must pass the same schema validation before the write.

Sourced from Docs by LangChain (MCP)

1. ACreate a copy for the new rep
2. BRefuse to restore it after checking thread ownershipCorrect answer
3. CRestore it, since thread IDs are secret
4. DRestore it but mask PII

Why: A thread_id is not an authorisation, so the API must confirm the authenticated rep owns the thread.

Sourced from Docs by LangChain (MCP)

1. AOnly in LangSmith traces
2. BIn the model's context window
3. CIn an append-only audit log separate from tracesCorrect answer
4. DIn the rep's preference store

Why: Traces are for debugging and evaluation, while the audit log is a durable, immutable compliance record.

Sourced from Docs by LangChain (MCP)

1. AmakeAgent
2. BnewAgent
3. CcreateAgentCorrect answer
4. DAgent.build

Why: LangChain v1 uses createAgent in JS.

Sourced from Docs by LangChain (MCP)

1. AModel fallback, tool retry and call limit
2. BFilesystem, summarization, subagents and prompt cachingCorrect answer
3. CPII masking, HITL and audit logging
4. DVector store, retriever and splitter

Why: Deep Agents bundle filesystem, summarization, subagents and prompt caching for long tasks.

Sourced from Docs by LangChain (MCP)

1. AWhen there are only two tools
2. BWhen the agent must send emails
3. CWhen CRM data needs to be masked
4. DWhen many tools are available and only a relevant subset should go to the modelCorrect answer

Why: Selecting relevant tools cuts schema tokens and confusion when the tool list is large.

Sourced from Docs by LangChain (MCP)

1. ARetrievers
2. BDocument loaders
3. CText splitters
4. DCheckpointersCorrect answer

Why: RAG uses loaders, splitters, embeddings, vector stores and retrievers, while checkpointers handle thread memory.

Sourced from Docs by LangChain (MCP)

1. AThe rep's email drafts
2. BThe CRM activity timeline
3. CLangSmithCorrect answer
4. DThe LangGraph store

Why: Step 8 sends traces to LangSmith for review and evaluation.

Sourced from Docs by LangChain (MCP)