Plan-and-execute agent with replanning

I choose plan-and-execute when the task has several dependent sub-goals and I need visibility and control over them. A ReAct loop decides one action at a time, so on long tasks it drifts and its context fills with tool noise. An explicit plan gives me something to review, checkpoint and evaluate. The executor can use a cheaper model per step, while a stronger model plans and replans. The cost is extra LLM calls and some latency, so for short lookups or two-tool tasks I keep a plain ReAct agent. A good signal is this: if a human would write a checklist before starting, plan-and-execute usually fits.

Sourced from Docs by LangChain (MCP)

The analyst sends a goal with a thread_id to the Agent Server. The graph is compiled with a Postgres checkpointer. The planner pulls similar past plans from the PostgresStore and writes a short ordered step list using structured output. A review node calls interrupt() so a human can approve or edit the plan. The executor runs plan[0] through a tool-calling subgraph and appends (step, result) to past_steps. The replanner reads the goal, the remaining plan and all past_steps. It either returns the remaining steps or a final response. A conditional edge ends the run or loops back to the executor, and a step budget enforces a hard stop. State is checkpointed at every super-step, progress is streamed to the UI, and on END a summary goes to the store.

Sourced from Docs by LangChain (MCP)

The review node calls interrupt() with the draft plan. The checkpointer saves the state and the run pauses, so the client sees the pending interrupt payload. To continue, the client invokes the graph again with the same thread_id and Command(resume=value). The review node then re-executes from its first line, and this time interrupt() returns the resume value instead of pausing. If the value is an approval, the node routes to the executor. If it is an edit, the node returns Command(goto='planner', update=...) carrying the feedback so the planner can redraft. Because the node restarts, any code before interrupt() runs twice. That code must be deterministic or free of side effects. A checkpointer is mandatory, because interrupts cannot work without persisted state.

Sourced from Docs by LangChain (MCP)

Checkpoints are written at super-step boundaries. If the executor never finished, its update to past_steps was never committed. The last checkpoint is the state right after the previous node, typically the replanner, and the pending task is the executor. On resume with the same thread_id, LangGraph re-runs the executor for the same plan[0]. Committed history is not lost, and no partial result is appended, so past_steps gains exactly one entry when the step finally succeeds. The tool calls inside that step may run again, though. That is why tools are read-only or idempotent. Re-running a SELECT or a web search is harmless. Anything with side effects needs an idempotency key or must sit behind an interrupt.

Sourced from Docs by LangChain (MCP)

The state has four keys: input, plan, past_steps and response. plan is a list of strings with no reducer, so whatever the planner or replanner returns replaces it. That matters because the replanner returns only the remaining steps. past_steps is Annotated with operator.add, so the executor returns a one-item list and it appends, which gives an immutable history of step and result. response is optional and its presence signals completion to the conditional edge. I also add a step counter for budgets. Nodes return only the keys they change, and the checkpointer saves the merged state at every super-step, so I can replay or fork any step.

Sourced from Docs by LangChain (MCP)

I use layers. First, a step budget lives in state, and the replanner prompt says that at the budget it must return a response, partial if needed. Second, recursion_limit on the run is a hard backstop. Third, tool errors come back as step results rather than exceptions, so the replanner can route around them instead of retrying blindly. For crashes, the Postgres checkpointer saved state at the last super-step, so I can resume the same thread_id without redoing completed steps. For bad plans in production, I inspect get_state_history, fix the plan with update_state at an earlier checkpoint, and fork the run from there.

Sourced from Docs by LangChain (MCP)

On resume, LangGraph does not continue from the middle of the node. It re-runs the whole node, and interrupt() returns the resume value the second time. So anything before the interrupt runs again. That could be sending a notification, writing an audit row or calling a model to reformat the plan. Doing it twice causes duplicate messages, double writes or a different draft than the one the human approved. Keep the node minimal: read the plan from state, call interrupt(), then act on the answer. If you need side effects, put them after the interrupt, make them idempotent with a key, or move them into a separate node that runs before the review node. Then they are checkpointed once and not repeated.

Sourced from Docs by LangChain (MCP)

The review node returns Command(goto='planner', update={...}). This routes to the planner and writes state in a single step. I add a dedicated key, such as plan_feedback, to the TypedDict, because the base state only has input, plan, past_steps and response. The update writes the reviewer's text into that key. The planner reads it alongside the goal and the retrieved past plans and produces a revised plan. The update is part of a checkpointed super-step, so a crash between review and replanning does not lose the feedback. After the redraft, the flow passes through review again, so the human approves the final version. I also cap the number of review rounds so the edit cycle cannot loop forever.

Sourced from Docs by LangChain (MCP)

Downstream nodes need a reliable list[str]. The executor indexes plan[0] and the replanner overwrites plan, so parsing prose with regex would be fragile. Structured output binds the model to a schema, for example a Plan object with a steps field. The node then returns {'plan': steps} directly and validation fails loudly if the shape is wrong. It also lets me add constraints in the schema description. Examples are 'each step must be self-contained' and 'keep it short and ordered'. Self-contained steps matter because the executor sees one step at a time. If a step says 'do the same for the other table', the executor lacks the context. On a validation failure I retry the call once, then surface an error rather than proceeding with a malformed plan.

Sourced from Docs by LangChain (MCP)

A single step such as 'find last quarter's churn by region' may need several tool calls. The agent might inspect a schema, run a query and then fix the query. A subgraph encapsulates that inner ReAct loop with its own message state. The outer graph stays clean, with planner, executor and replanner working on step-level results. The outer state only receives the compact (step, result) tuple, not every intermediate tool message. That keeps past_steps small and the replanner's context focused. The subgraph also gets its own scoped tool set and its own iteration limit, and you can test it in isolation. Streaming still works, because message tokens carry node metadata showing they come from inside the executor.

Sourced from Docs by LangChain (MCP)

The executor only gets what plan steps legitimately need: read-only SQL, web search and a vetted set of MCP tools. Read-only must be enforced in the database, through a role with SELECT-only grants on approved schemas, statement timeouts and row limits. Asking the model to only use SELECT is not enough. MCP tools are allow-listed per deployment, not discovered freely. Tools that write or send anything are excluded or placed behind an interrupt() approval. Scoping matters for three reasons. Steps are generated by a model and can be influenced by injected content, so the blast radius must be small. Read-only tools make retries after a crash safe. Fewer, clearer tools also improve the model's tool selection.

Sourced from Docs by LangChain (MCP)

I treat all tool output as untrusted data, never as instructions. The executor's prompt wraps results in clearly delimited sections and states that they cannot change the goal or the tools. The real defence is architectural. Tools are scoped and read-only at the database and credential level, so an injected instruction cannot write, delete or exfiltrate data through a privileged tool. The human plan review catches suspicious steps before execution. For replans, I can require re-review if the replanner introduces steps unrelated to the original goal. I also restrict outbound actions such as fetching arbitrary URLs with data in the query string. In LangSmith I monitor for steps that diverge sharply from the approved plan.

Sourced from Docs by LangChain (MCP)

The plan key has no reducer, so whatever the replanner returns overwrites it. The executor always runs plan[0]. If the replanner returned the full original plan, including steps already done, the executor would run step one again. That would produce duplicate work and duplicate entries in past_steps. Completed work lives only in past_steps, which is append-only through operator.add. The plan represents only the future. This clean split means history is never lost and finished steps are never re-run. In the prompt and schema I state explicitly: 'do not include steps already completed in past_steps'. In code I can add a guard that drops any returned step that exactly matches a completed one, as defence in depth.

Sourced from Docs by LangChain (MCP)

There are three rules. First, the executor returns only the new tuple, {'past_steps': [(step, result)]}. It never returns the existing list, because operator.add would concatenate it and double the history. Second, a node's update is applied only when the node completes. A failed or retried attempt contributes nothing, and only the successful attempt appends. Third, the replanner removes the finished step from plan, so the executor does not see it again as plan[0]. If you add a node-level retry policy for transient errors, it still produces one committed update. For extra safety, I can record a step index with each tuple and assert in the replanner that indices are contiguous. That catches bugs early in tests.

Sourced from Docs by LangChain (MCP)

The base design is sequential, which is simple and lets each step use earlier results. If the planner marks steps as independent, for example by grouping them, a conditional edge can return a list of Send objects, one per step. Each Send fans out to the executor with its own per-item state containing just that step. All branches run in the same super-step. Each returns {'past_steps': [(step, result)]}, and because the key uses operator.add, the results are merged rather than overwritten. The replanner then runs once after all branches finish. The trade-offs are that ordering in past_steps across parallel branches should not be relied upon, load on the database and model rate limits increases, and the step budget must count each branch.

Sourced from Docs by LangChain (MCP)

It should be honest and useful, not a silent failure. When the budget is hit, I route to a final answer path, either the replanner forced into Response mode or a small finalize node. It summarises what was established from past_steps, states which parts of the goal remain unanswered, lists the steps that were still planned, and notes that the run stopped at its budget. The response key is set, so should_end routes to END cleanly and the run is checkpointed as finished, not errored. I tag the trace in LangSmith as budget-terminated. These runs are prime material for evaluating why plans did not converge. The analyst can then start a follow-up run or fork with a better plan.

Sourced from Docs by LangChain (MCP)

I build a formula and fill it with measured numbers from LangSmith rather than guesses. A run has one planner call plus one per review edit. Each executed step adds one replanner call and the executor subgraph's inner model calls, which is typically several per step depending on tool use. So model calls are roughly 1 + edits + N × (inner calls + 1) for N steps. Checkpoints are written per super-step, including inside the subgraph if it is checkpointed, so writes scale with the total node runs. Multiply by expected concurrent runs to get model rate-limit needs and Postgres write throughput. The step budget gives a hard upper bound per run, which is what makes capacity planning safe.

Sourced from Docs by LangChain (MCP)

Never losing results applies to state, not to the prompt. The full past_steps stays in checkpointed state untouched. The replanner receives a rendered view of it. Recent steps are shown in full, and older steps are condensed to the step text plus a short result summary. The executor can also return a concise result string and keep bulky data, such as a large query output, outside the prompt with a reference. The step budget naturally caps how long the history can get. If a final answer needs exact figures from an early step, the view keeps key numbers verbatim instead of paraphrasing them. That prevents the replanner from reasoning over a lossy summary of critical facts.

Sourced from Docs by LangChain (MCP)

I distinguish transient from semantic failures. Transient errors, such as timeouts or rate limits, are retried inside the executor, either by the subgraph's tool loop or by a node retry policy, with backoff and a cap. Semantic failures include a query error, a missing table or zero rows. These are recorded as the step's result, for example ('get churn by region', 'ERROR: table not found'), and appended to past_steps like any other outcome. The replanner then sees the failure and can rewrite the remaining plan: try another table, ask a narrower question or conclude that data is unavailable. This turns failures into information for replanning instead of crashing the run, and the step budget prevents endless retry plans.

Sourced from Docs by LangChain (MCP)

Traces capture each node run, so I evaluate at three levels. For plan quality, I build a dataset of goals with reference plans or rubrics and score whether steps are self-contained, ordered and minimal, often with an LLM judge checked against human labels. For process, I track replan counts, steps executed, budget-terminated runs and tool error rates per run, since high replan counts suggest weak initial plans. For outcomes, I score final answers against references or a rubric for correctness and faithfulness to past_steps. I run these evaluations on every prompt or model change before deploying, and compare experiments side by side. Production traces with human edits at plan review are a valuable source of new test cases.

Sourced from Docs by LangChain (MCP)

I use one structured-output model, for example Act, with a single field action that is a union of two types. Plan has steps: list[str], and Response has response: str. The model must pick exactly one, and the node branches on the type. A Response sets state['response'], and a Plan overwrites state['plan']. One call is cheaper and more consistent than asking 'are we done?' and then 'what next?' separately. Field descriptions guide the choice. 'Respond only when past_steps contain enough evidence to answer the goal' and 'Plan must list only remaining steps'. I validate edge cases. An empty Plan list is treated as a signal to produce a Response, so the executor never receives an empty plan and fails on plan[0].

Sourced from Docs by LangChain (MCP)

On END, each run writes a summary of its plan and outcome to the namespace (team, 'plans'). The planner runs a semantic search on that namespace with the new goal and injects the top matches as few-shot examples. This helps the planner reuse plan shapes that worked, such as which tables to query first, and avoid ones that failed. The risks are real. Bad plans can be reinforced if failed runs are stored without an outcome label. Stale plans can reference removed tables. One team's data could leak if namespaces are not scoped. Large summaries also inflate the prompt. I store the outcome and a quality signal with each summary. I prefer examples with good outcomes, limit retrieval to a few short items, and keep retrieval strictly inside the caller's team namespace.

Sourced from Docs by LangChain (MCP)

Store items are organised by namespace tuples, so the team identifier is the first element: (team_id, 'plans'). The important part is where team_id comes from. It must come from the authenticated request context on the Agent Server, never from the model or from user-supplied state. The planner's search call and the END writer both build the namespace from that trusted value. Then a prompt cannot redirect them to another team's namespace. Summaries should also exclude raw query results and personal data. They should hold the plan steps and a short outcome description, not customer rows. For deletion requests or team offboarding, the namespace structure makes it simple to find and delete everything under a team's prefix.

Sourced from Docs by LangChain (MCP)

The client calls stream with stream_mode=['updates','messages']. With multiple modes, each chunk arrives tagged with its mode. The updates chunks are the state deltas each node returned. The UI uses them to show the initial plan, each new (step, result) appended to past_steps, each rewritten plan from the replanner, and the final response. The messages chunks are LLM tokens paired with metadata that includes the originating node, such as planner, replanner or the executor subgraph. The UI labels the text and can render planner thinking differently from executor tool narration. I avoid streaming values for this UI, because sending the full state on every super-step repeats the whole history and gets heavier as past_steps grows.

Sourced from Docs by LangChain (MCP)

The workers are stateless. All durable state lives in the Postgres checkpointer and store, keyed by thread_id, so you scale horizontally by adding server instances behind the API, and any worker can resume any thread. The bottlenecks are usually elsewhere. Model provider rate limits, Postgres write volume from checkpoints and the analytics database behind read-only SQL are the usual suspects. I use connection pooling, statement timeouts and per-team concurrency caps. Runs should be executed as background runs, with the client streaming or polling, rather than holding long HTTP requests. I also decide what happens if a user sends a new message to a thread that is already running: reject it or queue it, rather than running two executions on the same state.

Sourced from Docs by LangChain (MCP)

Every super-step writes a checkpoint, and each holds the state, including the growing past_steps list. Long runs and many threads add up. I keep past_steps compact by storing summarised results rather than raw result sets. Large outputs go to object storage, and the tuple holds a reference. I then apply a retention policy. Active and recent threads keep their full history for resume and time travel. Older threads are pruned to their final checkpoint or archived, according to the team's audit requirements. Time travel needs history, so the retention window is a product decision: how far back should engineers be able to fork? I monitor table size and write latency as part of normal operations.

Sourced from Docs by LangChain (MCP)

Data appears in three places, and each needs a policy. Checkpoints hold full state, including results, so the Postgres database needs encryption at rest, restricted access and a retention period. LangSmith traces capture prompts and outputs, so I mask or redact sensitive fields before tracing, or disable input and output logging for sensitive projects. The long-term store is the riskiest, because it persists across threads and is fed back into future prompts. Summaries there should contain plan structure and outcome descriptions, not customer rows or identifiers. On the SQL side, the read-only role should only see approved, ideally de-identified views. For deletion requests, the thread_id and namespace layout let you locate and remove a user's data.

Sourced from Docs by LangChain (MCP)

A thread_id is an identifier, not a credential. If anyone who knows it can resume an interrupt, read get_state_history or call update_state, then one analyst could approve another's plan or read their results. I enforce authorization at the Agent Server. Each thread is recorded with an owner and team when it is created. Every run, resume, state read and state update checks the authenticated user against that record. Approving a plan via Command(resume=...) may require a specific reviewer role. Forking with update_state is an engineering action, so it is restricted to a support role and audited. The reason and the before and after state are logged for traceability.

Sourced from Docs by LangChain (MCP)

Plan-and-execute fits when the goal can be decomposed into an explicit step list up front and you want that plan visible, reviewable and revisable. A supervisor pattern fits when the work naturally splits by specialist role, such as a SQL agent, a research agent and a writing agent. In that pattern, a coordinator decides turn by turn which specialist acts next, without committing to a written plan. The supervisor is more adaptive but less transparent, and it is harder to gate with a human approval at the plan level. The two combine well. The executor here could be a supervisor subgraph over specialist agents, while the outer graph keeps the explicit plan, replanning and budget.

Sourced from Docs by LangChain (MCP)

I test in layers. Node unit tests call each node function with a crafted state and a fake or recorded model. I check that the executor returns exactly one tuple and that the replanner's Plan branch excludes completed steps. Routing tests confirm should_end goes to END when response is set, goes to the executor otherwise, and goes to finalisation when the budget is hit. Graph tests compile with InMemorySaver and exercise the interrupt flow by invoking, asserting the pause, then resuming with Command(resume=...) for both approve and edit. A crash test raises inside the executor, resumes, and asserts past_steps has no duplicates. Finally, LangSmith dataset evaluations run with real models before each release.

Sourced from Docs by LangChain (MCP)

Checkpoints persist state and the position in the graph. A paused thread resumed after a deploy will run against the new code. Changes to state keys must be backward compatible. Add new keys with defaults rather than renaming or removing keys, and have nodes tolerate missing values. Renaming or removing a node that a checkpoint points to is risky. It is better to drain or finish old runs first, or to keep a compatibility path. Schema changes for structured output only affect future calls, but downstream code must still accept older data already stored in past_steps. I version the deployment, record the version in trace metadata, and test resuming a checkpoint from the previous version before rollout.

Sourced from Docs by LangChain (MCP)

InMemorySaver keeps checkpoints in the process's memory. That is fine for local development and tests, but everything is lost when the process restarts, and it cannot be shared across server instances. This design relies on durable checkpoints for several things. Human review pauses can last hours, so the interrupt must survive deploys. Crashed runs must resume from their last checkpoint. Engineers need get_state_history and update_state for time travel. Any worker must be able to pick up any thread. Postgres provides durable, shared and queryable persistence. The same database type also backs the PostgresStore for long-term plan memory, which keeps operations simpler.

Sourced from Docs by LangChain (MCP)

When deployed on LangSmith's Agent Server, the agent is available over the API and as an MCP endpoint at /mcp. Other MCP-capable clients can then call it as a tool. Some points need care. The agent is long-running and has a human approval step, so callers must handle a run that pauses at interrupt() rather than expecting an instant answer. Alternatively, you offer a configuration that skips review only for low-risk goals. Authentication and team scoping must apply to MCP calls exactly as they do to API calls. Input descriptions should be clear so calling agents send well-formed goals. Budgets matter even more here, because an agent calling another agent can multiply cost quickly.

Sourced from Docs by LangChain (MCP)

1. Alist[str] with no reducer
2. BAnnotated[list, max]
3. COptional[list]
4. DAnnotated[list, operator.add]Correct answer

Why: operator.add is the reducer that concatenates the new update onto the existing list. Without a reducer, the key would be overwritten.

Sourced from Docs by LangChain (MCP)

1. AThe update is ignored until END
2. BThe new list is appended to the old plan
3. CThe new list overwrites the old planCorrect answer
4. DLangGraph raises a conflict error

Why: Keys without a reducer are replaced by the latest update. This is how the replanner swaps in only the remaining steps.

Sourced from Docs by LangChain (MCP)

1. AA checkpointer on the compiled graphCorrect answer
2. BA Send object
3. CA PostgresStore
4. DA streaming mode of debug

Why: An interrupt saves the paused state so it can resume later, and that requires a checkpointer.

Sourced from Docs by LangChain (MCP)

1. AWhen past_steps has an error
2. BWhen plan is empty
3. CWhen the response key is setCorrect answer
4. DAfter exactly three steps

Why: The design routes to END when response is set and back to the executor otherwise.

Sourced from Docs by LangChain (MCP)

1. AHistory is duplicated, because operator.add appends the whole list againCorrect answer
2. BThe plan is overwritten
3. CThe run raises a type error
4. DNothing, it is equivalent

Why: The reducer concatenates the returned value onto the existing list. Returning the full list doubles the history.

Sourced from Docs by LangChain (MCP)

1. Aplan uses operator.add; past_steps has no reducer
2. BNeither key has a reducer; nodes return the full lists
3. CBoth plan and past_steps use operator.add
4. Dplan has no reducer; past_steps uses Annotated[list, operator.add]Correct answer

Why: A key without a reducer is overwritten by each update, which is right for the remaining plan. operator.add appends each node's update, which keeps a full step history.

Sourced from Docs by LangChain (MCP)

1. AThe checkpointer stops saving state
2. Binterrupt() is called with the final answer
3. CThe executor raises a StopIteration
4. DA conditional edge returns END when response is set, otherwise routes to the executorCorrect answer

Why: should_end is a conditional edge function that reads state and returns END or the next node name. Setting response is the replanner's signal that the goal is met.

Sourced from Docs by LangChain (MCP)

1. AFrom the beginning of the nodeCorrect answer
2. BFrom the planner node
3. CFrom START
4. DFrom the line right after interrupt()

Why: The node re-runs from its start, and this time interrupt() returns the resume value. Code before the interrupt therefore runs again.

Sourced from Docs by LangChain (MCP)

1. ARestart the Agent Server
2. BStart a new thread with the edited plan
3. CInvoke the graph with the same thread_id and Command(resume=value)Correct answer
4. DCall get_state_history

Why: Resuming means invoking on the same thread with Command(resume=...), which supplies the value that interrupt() returns.

Sourced from Docs by LangChain (MCP)

1. AAn edge to END
2. BCommand(goto='planner', update=...)Correct answer
3. Cstream_mode='custom'
4. DA Send object

Why: Command with goto and update combines routing and a state update inside a single node return.

Sourced from Docs by LangChain (MCP)

1. AOnly at END
2. BOnly when interrupt() is called
3. CAt every super-stepCorrect answer
4. DOnce per hour

Why: Checkpointers save state per thread at every super-step. This enables resume and time travel.

Sourced from Docs by LangChain (MCP)

1. Anode name
2. Brun_name
3. Cthread_idCorrect answer
4. Dnamespace

Why: Checkpoints are saved and loaded per thread_id.

Sourced from Docs by LangChain (MCP)

1. Ainterrupt
2. BSend
3. Cget_state_historyCorrect answer
4. Dupdate_state

Why: get_state_history returns the sequence of saved states for the thread.

Sourced from Docs by LangChain (MCP)

1. Aincrease recursion_limit
2. Bdelete the thread and rerun from scratch
3. Ccall update_state on the earlier checkpoint's config to fork, then continue from itCorrect answer
4. Dedit rows directly in the checkpoints table

Why: update_state applied to an earlier checkpoint creates a fork. The original history stays intact.

Sourced from Docs by LangChain (MCP)

1. Aupdates
2. BmessagesCorrect answer
3. Cdebug
4. Dvalues

Why: The messages mode streams LLM tokens together with metadata such as the originating node.

Sourced from Docs by LangChain (MCP)

1. AIn a PostgresStore namespace such as (team, 'plans')Correct answer
2. BIn the plan key of state
3. CIn the messages stream
4. DIn the checkpointer under the same thread_id

Why: Stores provide long-term memory across threads, organised by namespace tuples, with optional semantic search.

Sourced from Docs by LangChain (MCP)

1. ALangGraph raises a GraphRecursionErrorCorrect answer
2. BIt automatically writes a final response
3. CIt restarts from START
4. DIt silently returns the current plan

Why: Hitting the recursion limit raises an error rather than ending gracefully.

Sourced from Docs by LangChain (MCP)

1. ASo the graph can end cleanly with a best-effort answer instead of erroring outCorrect answer
2. BBecause recursion_limit only applies to subgraphs
3. CTo avoid needing a checkpointer
4. DTo make streaming faster

Why: The in-state budget lets routing force a final response and reach END. recursion_limit stays as a hard backstop.

Sourced from Docs by LangChain (MCP)

1. Aplan[0]Correct answer
2. BEvery step in plan at once
3. CThe last step in plan
4. DA random step

Why: The executor takes the first remaining step, and the replanner then removes it from the plan.

Sourced from Docs by LangChain (MCP)

1. AIt is restored from the PostgresStore
2. BIt contains a partial result from the crashed attempt
3. CIt is reset to empty
4. DIt holds only committed results, and the step re-runs and appends once on successCorrect answer

Why: A node's update applies only when the node completes, so resuming from the last checkpoint re-runs the step without partial entries.

Sourced from Docs by LangChain (MCP)

1. AThey remove the need for a checkpointer
2. BThey allow skipping plan review
3. CThey make the model respond faster
4. DSteps may re-run after a crash or retry, and re-running read-only calls is harmlessCorrect answer

Why: Durable resume can repeat tool calls within a step, so idempotent, read-only tools avoid duplicate side effects.

Sourced from Docs by LangChain (MCP)

1. ARun queries only during business hours
2. BTell the model in the prompt to only write SELECT
3. CUse a database role with only SELECT grants on approved schemasCorrect answer
4. DFilter out the word DELETE from queries

Why: Enforcement in the database holds even if the model is manipulated. Prompt instructions alone do not.

Sourced from Docs by LangChain (MCP)

1. ACall Command(resume=...) on the finished run
2. BStart a new thread and rerun the whole graph
3. CFind the checkpoint with get_state_history, call update_state with the fixed plan, then invoke from that configCorrect answer
4. DDelete rows from the store

Why: Time travel lets you fork from an earlier checkpoint: update_state writes a new checkpoint with the edited plan, and execution continues from there on that thread.

Sourced from Docs by LangChain (MCP)

1. Avalues
2. BupdatesCorrect answer
3. Cmessages
4. Dcustom

Why: The updates mode emits only the delta that each node returned.

Sourced from Docs by LangChain (MCP)

1. AUsing stream_mode='debug'
2. BSetting recursion_limit to zero
3. CReturning Send objects from a conditional edgeCorrect answer
4. DCalling interrupt() in a loop

Why: Send objects returned from a conditional edge fan out to a node with per-item state, which is the map-reduce pattern.

Sourced from Docs by LangChain (MCP)

1. AThe checkpointer deduplicates them
2. BEach branch writes to a different thread
3. CThe operator.add reducer merges all branch updatesCorrect answer
4. DOnly the last branch's update is kept

Why: A reducer combines concurrent updates to the same key, so all tuples are appended.

Sourced from Docs by LangChain (MCP)

1. ARaising recursion_limit
2. BUsing stream_mode='values'
3. CA longer system prompt
4. DScoped tools with no outbound send capability, with tool output treated as untrusted dataCorrect answer

Why: If no tool can send data out, an injected instruction cannot cause exfiltration, whatever the model decides.

Sourced from Docs by LangChain (MCP)

1. AIt allows the plan and the response to be returned together
2. BOne call reliably yields either remaining steps or a final Response in a parseable formCorrect answer
3. CIt removes the need for should_end
4. DIt stores plans in the PostgresStore

Why: The union forces a single, typed decision that the node can branch on deterministically.

Sourced from Docs by LangChain (MCP)

1. AIt encapsulates the multi-call tool loop and returns only a compact (step, result) to the outer stateCorrect answer
2. BIt disables checkpointing for tools
3. CIt is required for streaming
4. DSubgraphs cannot use tools otherwise

Why: Subgraphs compose graphs as nodes. The outer graph stays at step level while the inner graph handles tool messages.

Sourced from Docs by LangChain (MCP)

1. AFrom the model's output
2. BFrom a field the user types in the goal
3. CFrom the authenticated request context on the serverCorrect answer
4. DFrom the thread_id string

Why: Taking the namespace from trusted auth context stops prompts or users from reading another team's plans.

Sourced from Docs by LangChain (MCP)

1. AN executor runs and N replanner runsCorrect answer
2. B2N executor runs and no replanner runs
3. CN executor runs and 1 replanner run
4. D1 executor run and N replanner runs

Why: Each loop iteration is executor then replanner, and the replanner on the last iteration returns the final Response.

Sourced from Docs by LangChain (MCP)

1. APostgres checkpointer
2. BInMemorySaverCorrect answer
3. CPostgresStore
4. DInMemoryStore

Why: InMemorySaver is for development. Production uses Postgres so state survives restarts and is shared across workers.

Sourced from Docs by LangChain (MCP)

1. A/agent/mcp-v1
2. B/stream
3. C/mcpCorrect answer
4. D/tools

Why: Agent Server exposes deployed agents over an API and an MCP endpoint at /mcp.

Sourced from Docs by LangChain (MCP)