Resilient agent with model fallbacks & retries

I'd treat the model like any unreliable dependency. First, every model is created with init_chat_model and a short timeout plus low SDK retries, so failure is detected fast. Then I add ModelFallbackMiddleware to create_agent with models from at least two providers, tried in order, all tested against the same tools and response_format. Conversation state lives in a checkpointer keyed by thread_id, so a switch mid-thread keeps context. Call-limit middleware caps runaway loops, and if everything fails the customer gets a clear apology and a human handoff, not a spinner. Finally, I trace which model served each turn and alert on fallback rate, because a silent fallback hides a primary outage and changes cost.

Sourced from Docs by LangChain (MCP)

The Chat API receives the message with a thread_id and invokes an agent built with create_agent. The checkpointer loads that thread's short-term memory. Before every model or tool call, ModelCallLimitMiddleware and ToolCallLimitMiddleware check per-run and per-thread caps. A custom wrap_model_call middleware classifies the turn and swaps in a smaller model for simple turns. Fallback middleware calls the chosen model, which has an explicit timeout and low SDK retries. If it fails, the next model in the chain is tried, ideally on another provider. Tools run under retry middleware, and side-effecting tools carry idempotency keys. If limits are hit or every model fails, the customer gets a pre-written apology and a human handoff. Every run is traced.

Sourced from Docs by LangChain (MCP)

Fallback only helps if failure is detected quickly. SDK defaults can wait a long time and retry several times internally. A hung or degraded provider would then hold the customer for a long time before fallback middleware even sees an error. With a tight timeout and one or two SDK retries, a slow provider fails fast and the fallback model takes over while the customer is still waiting patiently. The retries also stack: SDK retries multiply with fallback hops. Keeping them low keeps the worst-case latency bounded and predictable. I set the timeout from observed latency percentiles for the use case, with separate budgets for streaming and non-streaming calls.

Sourced from Docs by LangChain (MCP)

The key must be stable across retries of the same intent and different for genuinely different refunds. I derive it from business identity, such as order ID, refund line or amount, and thread_id. A per-attempt random value would change on every retry and defeat the purpose. Enforcement belongs in the payments or refunds service, not in the agent. That service stores the key with the result, and a repeated key returns the original outcome instead of executing again. The agent-side retry middleware then becomes safe by construction. I also make the tool return a clear result, such as already processed with reference ID, so the model can tell the customer accurately rather than attempting again.

Sourced from Docs by LangChain (MCP)

I split tools into read-only and side-effecting. Read-only tools like order lookup get ToolRetryMiddleware with bounded retries, exponential backoff and jitter, and only for transient errors such as timeouts or 503s, never for validation errors. Side-effecting tools like refunds either get no automatic retry, or the backend accepts an idempotency key derived from the thread and action, so a second call returns the first result instead of acting twice. I also set a tool call limit so the model can't loop on a failing tool. Each tool has its own timeout, and retries count against the turn's latency budget so the customer isn't left waiting.

Sourced from Docs by LangChain (MCP)

I'd put the routing in a custom wrap_model_call middleware, so it's one place in the agent rather than scattered logic. A cheap rule set or small classifier labels turns like greetings, order status or FAQ as simple and swaps in a smaller model; disputes, multi-step requests or upset customers stay on the primary model. The small model's output is validated, and if it fails or needs a complex tool, the turn escalates. I'd roll it out behind a flag, compare resolution rate, re-contact rate and cost per resolved conversation against a control group, and only widen routing when quality holds. Optimising cost per call alone is misleading.

Sourced from Docs by LangChain (MCP)

Order matters because middleware wraps calls in layers. Call limits should sit outermost so a looping agent is stopped before any routing or fallback work spends tokens. The router comes next, because it decides which model the request should use. Fallback middleware sits inside that, so it retries the routed request on the next model in its chain. Tool retry wraps tool execution separately, since tool failures and model failures are different problems. I would also confirm in tests that the router's swap and the fallback chain interact as intended. For example, a simple turn on the small model should fall back to a sensible alternative, not jump to an expensive model nobody planned for.

Sourced from Docs by LangChain (MCP)

Short-term memory is thread-scoped and stored by the checkpointer, not inside any model provider. The conversation state, meaning messages, tool calls and tool results, lives in LangGraph state keyed by thread_id. When the fallback model takes over, it receives the same message history the primary would have received. The customer does not need to repeat themselves. This also covers a crash between turns: the next request with the same thread_id reloads the saved state. The requirement is a durable production checkpointer backed by a real database, not an in-memory one, and the API must always pass the correct thread_id so conversations never mix.

Sourced from Docs by LangChain (MCP)

A different provider protects you from a provider-wide outage, rate-limit event or regional incident. A sibling model on the same provider often fails at the same moment. The cost is behavioural drift. Tool-calling formats, adherence to the system prompt, structured output reliability, context window size and refusal behaviour all differ. You may also need a separate data processing agreement, separate keys and separate quota monitoring. I mitigate by running the same eval suite against every model in the chain and keeping prompts provider-neutral. I also verify that the same tools and response_format work everywhere. A reasonable chain is often a same-provider fallback first for capacity issues, then a cross-provider model for outages.

Sourced from Docs by LangChain (MCP)

Fallback is for transient or provider-side failures: timeouts, rate limits, server errors and connection failures. Trying another model there makes sense. It should not hide bugs. A malformed request, an invalid tool schema or an authentication error usually indicates our mistake. Falling back may fail again or mask the problem, so I want those to alert loudly. Content-policy refusals need a product decision. Silently retrying a refused request on a more permissive model is usually wrong for a customer-facing agent. I log the error class on every hop so the trace shows why each fallback happened. A rising fallback rate then becomes a clear signal for on-call engineers.

Sourced from Docs by LangChain (MCP)

That is a different risk: a new, deliberate tool call from the model, not a retry. Several layers help. The idempotency key derived from order and line items still blocks an identical refund. Business rules in the refunds service enforce that refunded amount cannot exceed the order value. A ToolCallLimitMiddleware cap on the refund tool per thread limits damage from loops. HumanInTheLoopMiddleware with interrupt_on for the refund tool can require approve, edit or reject for high-risk cases. The checkpointer keeps earlier tool results in the history, so the model can see a refund already happened. The system prompt should tell it to check before acting.

Sourced from Docs by LangChain (MCP)

The customer should get a pre-written, honest message quickly. Something like: we are having trouble right now and have passed your conversation to our team, with an expected next step. It should never be a stack trace, a blank reply or a spinner that never ends. Because it is static, it does not depend on any model being available. The human queue receives the thread_id so they can open the full checkpointed history, plus the classified intent. They also receive any tool actions already taken, especially side effects such as refunds and their status, and the failure reason. That stops the human from repeating a refund or asking the customer to start over.

Sourced from Docs by LangChain (MCP)

Per run: thread_id, routed intent, model actually used, fallback hops with error class, tool calls with retry counts, which limits fired, latency per call and end to end, and token usage per model. Alerts: fallback rate above baseline, which signals a provider incident; handoff-to-human rate; p95 or p99 latency; tool retry exhaustion; and call-limit hits, which often signal loops or a prompt regression. For finance, aggregate tokens by model into cost per conversation and cost per intent. Traces should not store raw PII unnecessarily, so I apply redaction before logging and restrict access to trace data.

Sourced from Docs by LangChain (MCP)

I measure it. Build a labelled set of real turns covering greetings, order status, FAQs, disputes and multi-step requests. Then measure routing accuracy, focusing on the costly error: hard turns sent to the small model. Run answer-quality evals for each route against the primary model as a baseline. In production, track signals per route: escalation to humans, repeated questions, negative feedback and tool errors. Shadow traffic or an A/B rollout helps before full launch. I bias the router toward the primary model when unsure, because a misrouted dispute costs more than the tokens saved on one turn.

Sourced from Docs by LangChain (MCP)

That is the case for a circuit breaker. Fallback middleware alone reacts per request, so each customer pays the primary's timeout before falling back. I would add custom middleware using wrap_model_call that tracks recent failures of the primary in shared state, for example in a cache visible to all workers. When failures cross a threshold, the breaker opens and requests go straight to the fallback model. After a cool-down, a small share of traffic probes the primary, and the breaker closes when it recovers. The trace should record breaker state so on-call engineers can see that traffic was deliberately shifted.

Sourced from Docs by LangChain (MCP)

Each mechanism is bounded, but their worst cases add up. Roughly, model latency is timeout times SDK attempts times models in the chain, plus tool retries with their backoff. I calculate that worst case explicitly and compare it to the product's latency budget. If it is too long, I cut SDK retries, shorten timeouts or shorten the chain. I also add an overall deadline at the API layer. If the run has not finished in time, it returns the pre-written apology and handoff. Call limits and that outer deadline together mean the connection always ends with a response.

Sourced from Docs by LangChain (MCP)

Each provider in the fallback chain is a data processor, so legal and security review must cover all of them, not only the primary. On the technical side, PIIMiddleware can redact, mask or block fields such as emails and phone numbers before they reach a model, where the task allows. Tools should fetch sensitive data from internal systems by ID rather than the model handling raw details. Traces and logs need the same redaction, with access controls and retention limits. For Indian customers I would also check obligations under the DPDP Act, including where data is processed.

Sourced from Docs by LangChain (MCP)

Assume the model can be manipulated and put controls outside it. The refund tool should validate everything server-side: the order belongs to this authenticated customer, the amount is within policy and the order is eligible. The customer's identity should come from the session, never from text the model produces. HumanInTheLoopMiddleware with interrupt_on for the refund tool can require human approval above a threshold or for unusual cases. ToolCallLimitMiddleware caps refund calls per thread. Untrusted content, such as retrieved documents or MCP tool output, should be treated as data, not instructions. Audit logs of every side-effecting call make abuse detectable.

Sourced from Docs by LangChain (MCP)

Untested fallbacks usually fail when needed. In unit and integration tests I use fake or stubbed chat models that raise timeouts, rate-limit errors and server errors on demand. I assert that the next model is used, context is preserved and the final apology path fires when all models fail. For tools, I inject transient failures and confirm retries happen with backoff. I also confirm the refund executes once, using the idempotency key. In staging I run chaos tests: block network access to the primary provider and watch latency, fallback hops and error rates in the traces. Game days with on-call engineers check that alerts and runbooks work.

Sourced from Docs by LangChain (MCP)

A per-run limit caps model or tool calls in a single invocation and stops a loop within one customer turn. A per-thread limit caps the whole conversation and protects against slow-burning abuse or a conversation that never converges. I set them from data: look at traces for the distribution of calls per run on real traffic, then set limits comfortably above normal behaviour. Tool-specific limits can be tighter. A refund tool might allow very few calls per thread, while a lookup tool allows more. When a limit is hit, the agent should end gracefully with the apology and human handoff, and the trace should record which limit fired.

Sourced from Docs by LangChain (MCP)

I work from measured inputs rather than guesses. First, expected conversations per day and peak concurrency from the existing support channel. Second, turns per conversation and model calls per turn, taken from traces of a pilot. Third, tokens per call, including system prompt, history and tool results; summarization caps how history grows. Then split traffic by route: the share of simple turns sent to the small model versus the primary. Multiply by each provider's current published pricing. For capacity, compare peak requests and tokens per minute to each provider's rate limits, including the fallback provider. The fallback must absorb primary traffic during an outage, not just a trickle.

Sourced from Docs by LangChain (MCP)

It depends on latency and accuracy needs. Rules and keyword patterns are cheap, fast and predictable, and work well for obvious greetings or order-status phrasing. They miss nuance, though; an angry customer asking about a refund is not a simple FAQ. A small LLM or a lightweight classifier handles nuance better but adds a call that can itself fail or time out. A common design is layered: rules catch the clear cases, a small classifier handles the rest, and anything uncertain or failing defaults to the primary model. The router must fail safe, so a classifier error never blocks the turn.

Sourced from Docs by LangChain (MCP)

Streaming changes what a timeout means. A total-request timeout can kill a slow but healthy long answer, while a missing first token is the real sign of a hung provider. I think in terms of time to first token and a gap between chunks, plus an overall ceiling. Fallback is simple before anything has been streamed: switch models silently. Once tokens have reached the customer, switching mid-answer can produce duplicated or contradictory text. So I either buffer until a safe point or, if the stream breaks midway, show a short notice and regenerate. That behaviour should be tested explicitly.

Sourced from Docs by LangChain (MCP)

Retries add load at exactly the moment a system is weakest. I keep them bounded with a small maximum count and exponential backoff. Jitter randomises the delays so thousands of clients do not retry in sync. I retry only transient errors, never validation failures. Retries at different layers multiply, so I avoid stacking SDK retries, middleware retries and client retries on top of each other. Call limits cap the total. For backends under real stress, a circuit breaker or rate limiter in front of the tool is better than more retries, and the agent should tell the customer politely that the action is delayed.

Sourced from Docs by LangChain (MCP)

The same response_format is passed regardless of which model answers, so the contract is defined once. Providers implement structured output differently, though. Some use native schema-constrained output, others rely on tool calling, and reliability varies. I keep schemas simple: flat fields, clear enums, few optional nesting levels. I validate every response against the schema and decide on failure behaviour, such as retrying once or falling through to the next model. Each fallback model runs the same structured-output eval set before it joins the chain, so a model that breaks the schema is caught in testing, not during an outage.

Sourced from Docs by LangChain (MCP)

Then the agent cannot load or save thread state, and model fallback does not help, because the dependency is ours. I treat the checkpointer store as critical infrastructure: a managed database with replication, backups and monitoring. If it fails, there are two options. One is to fail fast to the apology and human handoff. The other is to continue in a degraded stateless mode for simple turns while refusing side-effecting actions, since we could not record them reliably. I prefer refusing refunds while state is unavailable. The trace and alerts should separate checkpointer errors from provider errors, so on-call engineers do not chase the wrong system.

Sourced from Docs by LangChain (MCP)

Two runs could read the same checkpoint, act in parallel and then write conflicting state. Worse, both might decide to issue the same refund. I serialise runs per thread_id at the API layer, using a per-thread lock or queue so the second message waits or is merged into the next turn. The idempotency key on the refunds service is the final safety net, because it blocks a duplicate even if both runs reach the tool. Common UX patterns are disabling send while a reply is in progress or batching rapid messages into one turn.

Sourced from Docs by LangChain (MCP)

Fallback and routed models may have smaller context windows than the primary. A long thread that fits the primary could overflow the small model or a fallback, causing an error exactly when you need resilience. SummarizationMiddleware helps by compressing older history once a trigger, such as a token count, is reached, while keeping recent messages. I set the trigger based on the smallest context window in the chain, not the largest. The summary must keep facts that matter for safety, especially completed refunds and their references, so a later model does not lose track of side effects that already happened.

Sourced from Docs by LangChain (MCP)

They fail for different reasons and need different fixes. A model failure is usually provider-side, and the remedy is often a different model or provider. A tool failure is about our backend, such as an orders API timing out. Switching models does nothing for that; retrying the tool with backoff might. Safety also differs. Model calls have no external side effects, so repeating them costs only tokens. Tool calls may move money, so retries need idempotency and should only cover transient errors. Separate middleware lets each have its own policy, limits and tracing.

Sourced from Docs by LangChain (MCP)

The agent workers are mostly stateless because state lives in the checkpointer, so they scale horizontally behind the Chat API. The pressure points become provider rate limits, the checkpointer database and shared state such as circuit breakers. I would spread quota across providers and accounts, and make sure fallback providers have capacity for a full primary outage. The checkpointer needs to scale and possibly sit in each region, with threads pinned to a home region. Circuit-breaker state should be regional, since outages are often regional. Idempotency enforcement stays in the refunds service, so it remains correct however many workers retry.

Sourced from Docs by LangChain (MCP)

MCP tools are adapted into ordinary LangChain tools through the MCP adapters, such as MultiServerMCPClient. So tool retry middleware and tool call limits apply to them like any other tool. The difference is an extra network hop and a server we may not own. I set timeouts on MCP connections, and I check whether each MCP tool is safe to retry, because the adapter does not make a side-effecting tool idempotent. If an MCP server is down, the agent should degrade by explaining that action is unavailable or handing off. MCP tool outputs are untrusted input and are covered by prompt-injection defences.

Sourced from Docs by LangChain (MCP)

First run it offline against the eval suite: routed intents, tool-calling accuracy, structured output validity and policy adherence, compared with the current models. Then add it in a low-risk position, or send it a small share of shadow traffic, and compare traces for quality, latency and cost. Check rate limits so it can absorb real failover volume. Keep the change behind configuration so it can be reverted without a redeploy. Finally, run a failover drill that sends traffic to it deliberately, because a fallback that has never served real requests is an untested assumption.

Sourced from Docs by LangChain (MCP)

Each trace already records token usage and the model used for every call, so cost is computed per call using that model's price and then summed per thread. Fallback hops matter. A failed attempt may still have consumed input tokens, so I include it rather than only counting the successful call. Reports break cost down by intent and route, so finance can see whether routing saves money and what outages cost in extra fallback traffic. Prices come from provider contracts or published rates held in configuration, and the price version is stored with each report for traceability.

Sourced from Docs by LangChain (MCP)

1. ATo enable structured output
2. BTo lower token prices
3. CSo failures surface quickly and fallback can take over instead of the SDK retrying for a long timeCorrect answer
4. DBecause fallback middleware requires max_retries=0

Why: SDK retries stack with fallback hops; keeping them low bounds latency and lets the fallback chain react fast.

Sourced from Docs by LangChain (MCP)

1. AIn the model's temperature settings
2. BIn the refunds or payments service that stores keys and resultsCorrect answer
3. CIn the trace exporter
4. DIn the system prompt

Why: Only the service executing the side effect can reliably detect and short-circuit a repeated key.

Sourced from Docs by LangChain (MCP)

1. AA key derived from the order, refund line and thread that stays the same across retriesCorrect answer
2. BThe current timestamp
3. CThe model name plus request number
4. DA new random UUID generated per attempt

Why: A key must be stable across retries of the same intent; a per-attempt value defeats deduplication.

Sourced from Docs by LangChain (MCP)

1. AA pre-written apology with handoff to a human queueCorrect answer
2. BAn empty response
3. CA request to retry later with no handoff
4. DThe raw provider error

Why: The workflow requires a static apology plus human handoff, not an error or a hung connection.

Sourced from Docs by LangChain (MCP)

1. ATries the configured fallback models in orderCorrect answer
2. BReturns a cached answer from the vector store
3. CInterrupts the run for human approval
4. DRetries the same model indefinitely until it succeeds

Why: Model fallback middleware wraps the model call and, on failure, tries the listed fallback models in order until one succeeds or all fail.

Sourced from Docs by LangChain (MCP)

1. Awrap_tool_call
2. Bwrap_model_callCorrect answer
3. CA checkpointer
4. Dafter_model

Why: wrap_model_call intercepts each model request, so it can inspect the turn and change the model before the call is made.

Sourced from Docs by LangChain (MCP)

1. Ainitialize_agent
2. BAgentExecutor
3. Ccreate_react_agent_v1
4. Dcreate_agentCorrect answer

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

Sourced from Docs by LangChain (MCP)

1. AA long-term memory store keyed by user
2. BThe checkpointer storing thread-scoped state by thread_idCorrect answer
3. CRe-sending the system prompt only
4. DThe provider's server-side session

Why: Short-term memory is thread-scoped via a checkpointer, so any model in the chain receives the same saved history.

Sourced from Docs by LangChain (MCP)

1. ARandomly from a pool
2. BThe cheapest available model
3. CIt tries the configured fallback models in orderCorrect answer
4. DThe model with lowest recent latency

Why: Per the docs, fallback models are tried in order when a call fails.

Sourced from Docs by LangChain (MCP)

1. AA tool schema validation bug in our code
2. BAn invalid API request we constructed
3. CA customer asking an off-topic question
4. DA provider rate-limit or server errorCorrect answer

Why: Fallback targets transient, provider-side failures; our own bugs should alert rather than be masked.

Sourced from Docs by LangChain (MCP)

1. ALooping agents burning tokens or repeating actionsCorrect answer
2. BContext window overflow
3. CPII leakage
4. DPrompt caching misses

Why: Call limits cap calls per run and per thread so a runaway loop stops.

Sourced from Docs by LangChain (MCP)

1. ATo make retries faster
2. BTo desynchronise retries so many clients do not hit a struggling backend at onceCorrect answer
3. CTo change the idempotency key
4. DTo bypass call limits

Why: Jitter spreads retry timing and avoids synchronised retry storms.

Sourced from Docs by LangChain (MCP)

1. ANone; tools should never be retried
2. BAll errors, including validation errors
3. COnly transient errors such as timeouts or temporary unavailabilityCorrect answer
4. DOnly authentication errors

Why: Retrying permanent errors wastes time and load; only transient failures can succeed on retry.

Sourced from Docs by LangChain (MCP)

1. AAsk the customer to rephrase
2. BRoute to the primary modelCorrect answer
3. CSkip the model and send an FAQ link
4. DUse the smallest model

Why: Misrouting a hard turn such as a dispute costs more than the tokens saved, so uncertainty should favour the primary.

Sourced from Docs by LangChain (MCP)

1. AThe tools and response_formatCorrect answer
2. BThe model's context window size
3. CThe token price
4. DThe provider API key

Why: The fallback is tried with the same tools and response_format so behaviour and output contract stay consistent.

Sourced from Docs by LangChain (MCP)

1. ADifferent providers share checkpoints
2. BIt removes the need for timeouts
3. CIt is always cheaper
4. DA provider-wide outage or rate-limit event would also hit a same-provider siblingCorrect answer

Why: Cross-provider fallback removes the correlated failure of a single provider.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware
2. BPIIMiddleware
3. CHumanInTheLoopMiddleware with interrupt_on for the refund toolCorrect answer
4. DLLM tool selector

Why: HumanInTheLoopMiddleware interrupts on configured tools with approve, edit or reject decisions.

Sourced from Docs by LangChain (MCP)

1. ADisable tool retries
2. BIncrease the model timeout
3. CSerialise runs per thread_id at the API layer, with idempotency as a backstopCorrect answer
4. DUse a bigger model

Why: Per-thread serialisation prevents conflicting state writes, and idempotency still blocks duplicate side effects.

Sourced from Docs by LangChain (MCP)

1. ASetting a higher model call limit
2. BUsing SummarizationMiddleware
3. CAn idempotency key checked by the refund APICorrect answer
4. DAdding a second fallback model

Why: Retries can repeat a call that actually succeeded; an idempotency key lets the backend recognise the repeat and return the original result.

Sourced from Docs by LangChain (MCP)

1. APer-thread resets on every message
2. BPer-run applies only to tools; per-thread only to models
3. CPer-run caps one invocation; per-thread caps the whole conversationCorrect answer
4. DThey are aliases

Why: Run limits bound a single invocation, while thread limits bound the total across the conversation.

Sourced from Docs by LangChain (MCP)

1. Aafter_model
2. Bwrap_tool_call
3. Cwrap_model_callCorrect answer
4. Dbefore_agent_shutdown

Why: wrap_model_call wraps the model invocation and can change the model used for that call.

Sourced from Docs by LangChain (MCP)

1. AGenerated text is too long
2. BIt must work even when no model is availableCorrect answer
3. CPre-written text is required by LangChain
4. DIt reduces trace size

Why: The apology path runs exactly when models are failing, so it cannot depend on a model.

Sourced from Docs by LangChain (MCP)

1. Ainit_chat_model("provider:model")Correct answer
2. BChatModel.load("model")
3. Cget_llm(provider, model)
4. Dcreate_model("model@provider")

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

Sourced from Docs by LangChain (MCP)

1. AA circuit breaker that routes straight to the fallback once failures cross a thresholdCorrect answer
2. BMore SDK retries
3. CDisabling the checkpointer
4. DRaising the timeout

Why: A circuit breaker uses shared failure state to skip a known-bad primary until it recovers.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware
2. BPIIMiddlewareCorrect answer
3. CModelCallLimitMiddleware
4. DToolRetryMiddleware

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

Sourced from Docs by LangChain (MCP)

1. AIt does not matter
2. BThe largest in the chain
3. CThe smallest in the chainCorrect answer
4. DOnly the primary's

Why: History must fit whichever model ends up answering, including smaller routed or fallback models.

Sourced from Docs by LangChain (MCP)

1. ALower token usage
2. BRetries cancel each other out
3. CMultiplied attempts and much longer worst-case latencyCorrect answer
4. DAutomatic fallback to cheaper models

Why: Nested retries multiply, so worst-case attempts and latency grow quickly.

Sourced from Docs by LangChain (MCP)

1. AUnlimited fallback models
2. BA higher temperature
3. CLong-term memory stores
4. DAn overall deadline at the API layer that returns the apology pathCorrect answer

Why: An outer deadline bounds total time regardless of how retries and hops combine.

Sourced from Docs by LangChain (MCP)

1. AThey can only be called by subagents
2. BThey require create_deep_agent
3. CThey bypass all middleware
4. DThey are adapted into LangChain tools, so tool middleware applies to themCorrect answer

Why: MCP adapters turn MCP tools into regular LangChain tools, so wrap_tool_call-based middleware covers them.

Sourced from Docs by LangChain (MCP)

1. AFailed calls may still have consumed billable tokensCorrect answer
2. BFinance requires model names only
3. CThey improve routing accuracy
4. DThey are free

Why: An attempt that times out or errors can still incur input token costs, so excluding it understates spend.

Sourced from Docs by LangChain (MCP)

1. AA rise in thread count
2. BA sudden rise in fallback hop rateCorrect answer
3. CLower token usage per FAQ
4. DMore greetings routed to the small model

Why: Fallback hops are recorded per run, and a spike shows the primary is failing.

Sourced from Docs by LangChain (MCP)

1. AIn trace logs
2. BIn the checkpointer only
3. CIn LangGraph stores as JSON documents by namespace and keyCorrect answer
4. DIn the model provider

Why: Long-term memory uses LangGraph stores with namespaced, keyed JSON documents and optional semantic search.

Sourced from Docs by LangChain (MCP)

1. ANo; create_agent with middleware covers it, and Deep Agents targets long multi-step tasksCorrect answer
2. BYes, for checkpointing
3. CYes, for tool retries
4. DYes, fallbacks only work with Deep Agents

Why: Deep Agents pre-assembles filesystem, subagents and similar features for long tasks; fallbacks and retries are middleware on create_agent.

Sourced from Docs by LangChain (MCP)