Travel booking with agent handoffs

Three layers. First, structure: the approval node only calls interrupt() and routes, and the payment call lives in a separate node after it, because interrupt() re-runs its node from the top on resume. Second, idempotency: the payment tool sends an idempotency key built from thread_id and quote_version, so a retry after a crash or a duplicate resume hits the gateway's dedupe. Third, state checks: before calling the gateway, the node reads state and skips capture if a payment_id already exists. The Postgres checkpointer saves after every super-step, so after a worker dies we resume at the last completed node, and the earlier layers cover the window between the gateway call and the checkpoint write.

Sourced from Docs by LangChain (MCP)

The traveller's request hits a graph deployed on LangSmith Agent Server, with one thread_id per trip. A single StateGraph holds a typed state: messages, trip constraints, flight_hold, hotel_hold, quote and approval. The flight agent reads preferences from PostgresStore, holds a fare, and hands off to the hotel agent with Command(goto, update). The hotel agent holds a room or hands back to flights if the dates fail. Payments re-checks both holds and writes a versioned quote, but does not charge. A dedicated approval node calls interrupt() with the exact itinerary and quote. On resume, a matching quote_version triggers capture with an idempotency key. Ticketing confirms the bookings and publishes an event. The Postgres checkpointer saves every super-step, so the graph can resume after a crash and support can use time travel.

Sourced from Docs by LangChain (MCP)

On resume, LangGraph re-executes the interrupted node from its beginning. It does not continue from the line after interrupt(). If the payments agent re-checked holds, called an LLM or wrote side effects before calling interrupt(), all of that would run again on every resume. That can produce a different quote than the one the traveller saw. A small approval node that only reads the stored quote, calls interrupt(), validates the answer and routes keeps re-execution cheap and deterministic. Capture then lives in a separate node after approval, so the money step runs only once the decision is persisted in state. This separation is also easier to test and to reason about in get_state_history.

Sourced from Docs by LangChain (MCP)

The interrupt payload contains the exact itinerary, total, currency and quote_version taken from state. The resume value must carry the same quote_version. Before capture, the node compares it with the current quote in state, and any mismatch routes back to payments for a fresh quote. The payment tool never takes an amount from LLM output. It reads total and currency from the persisted quote object that the approval matched. The tool also checks that the holds referenced by the quote are still the ones in flight_hold and hotel_hold. With this in place, a changed fare or room, or a hallucinated number, cannot reach the payment provider without a new explicit approval.

Sourced from Docs by LangChain (MCP)

When the thread resumes from the last checkpoint, the capture node runs again, because its result was never saved. That is why the capture call uses an idempotency key derived from thread_id and quote_version. On the retry, the provider sees the same key and returns the original result instead of charging again. The node then writes the payment reference to state, and that write is checkpointed. I would also record a pending-capture marker before the call and run a reconciliation job that matches provider transactions against thread state. That catches any provider that handles idempotency differently. In this design, a retry costs only latency and never causes a double charge.

Sourced from Docs by LangChain (MCP)

Treat ticketing as a saga step with its own retries. The hotel confirm call gets its own idempotency key, so a retry cannot create two bookings. If the hold has truly been lost, I would not leave the traveller charged with half a trip. The graph routes to a compensation path: either find an equivalent room, which needs a new approval if the price or itinerary changes, or refund or void the hotel portion and tell the traveller. Every step and its outcome is written to state and checkpointed, so support can see exactly where it failed. Refunds also carry idempotency keys. The aim is that money and confirmed bookings always end up consistent, even if that takes a human step.

Sourced from Docs by LangChain (MCP)

The quote holds references to the flight hold and hotel hold, line items, total, currency, the hold expiry times and a monotonically increasing version. The version ties an approval to one exact snapshot. If anything changes, such as a fare rise, a new room or new dates, payments writes a new quote with a higher version. An approval for an older version then no longer matches and cannot trigger capture. The version also feeds the idempotency key with thread_id. Two retries of the same approved quote therefore collapse into one charge, while a legitimately new, re-approved quote gets a distinct key. Without the version, you cannot tell 'same approval retried' apart from 'different amount approved'.

Sourced from Docs by LangChain (MCP)

The booking flow has a natural order: flight first, because hotel dates depend on arrival, then payments. With handoffs, each agent decides its successor and writes its result in the same Command(update=...), so routing and state change happen atomically in one step. A supervisor would add an extra LLM call on every turn just to pick the next agent, which costs latency and adds another place to make routing mistakes. I would switch to a supervisor if the domain grew to many optional agents, such as visas, insurance or car hire, in any order. At that point central routing is easier to reason about than every agent knowing every other agent.

Sourced from Docs by LangChain (MCP)

The approval answer arrives through Command(resume=...) and carries the quote_version the traveller saw. Before capture, the payment path re-checks hold status and price with the airline and hotel tools. If a hold expired or the total changed, we do not charge. The node writes a new quote with an incremented version and routes back to the approval node, which interrupts again with the new price and a clear diff. Because the checkpointer persisted the thread, nothing about the earlier search is lost. We also track the hold-expiry rate as a metric. If it is high, we shorten the approval window or warn the traveller about the hold deadline in the interrupt payload.

Sourced from Docs by LangChain (MCP)

I would use a TypedDict or Pydantic model with these keys: messages, trip_constraints, flight_hold, hotel_hold, quote, approval, payment, bookings, plus control fields such as handoff_count and last_handoff_reason. Messages needs a list reducer, such as operator.add or add_messages, so each agent appends rather than overwrites the conversation. The holds, quote and approval should not have reducers. They have overwrite semantics, because only the latest hold or quote is valid, and appending old quotes would create ambiguity about which one was approved. If I wanted an audit trail of past quotes, I would keep a separate quote_history list with an append reducer. The authoritative quote would stay a single overwritten value.

Sourced from Docs by LangChain (MCP)

I keep a handoff_count, and possibly a list of tried date options, in state. Each hand-back from hotel to flight increments the counter and records a reason, so the flight agent can avoid repeating a combination that already failed. Once a threshold is reached, the graph routes to a node that asks the traveller for flexibility through interrupt(), instead of looping. LangGraph's recursion limit is a backstop. It raises an error after too many super-steps, but it should not be the primary control because it fails the run rather than degrading gracefully. Recording the reasons also helps support inspect the loop in get_state_history.

Sourced from Docs by LangChain (MCP)

The paused run costs nothing while it waits, because it is only a checkpoint in Postgres. The holds, however, expire on the supplier side. I would store hold expiry times in the quote and show them to the traveller. A scheduled job or reminder flow can notify the traveller before expiry. If they resume after expiry, the approval node, or the capture step right after it, re-validates the holds. When the holds are no longer valid, it routes back to the flight or payments agent via Command(goto=...) to re-hold and re-quote, which produces a new version that needs fresh approval. After a long timeout, the thread can be closed politely and the holds released.

Sourced from Docs by LangChain (MCP)

Thread state is per trip and short-lived: the messages, constraints, holds, quote, approval and booking results for this one thread_id. The checkpointer saves it at every super-step. PostgresStore holds long-term memory across threads, under namespaces like ("travellers", user_id). Examples are seat and airline preferences, loyalty numbers, preferred hotel chains and dietary or accessibility needs. Optional semantic search can find relevant preferences from free text. I would not put payment card data or one-trip details in the store. The flight agent reads from the store at the start of a trip. Updates to preferences should be deliberate, ideally confirmed by the traveller, so that one odd booking does not overwrite their long-term profile.

Sourced from Docs by LangChain (MCP)

They call get_state_history for the thread_id and find the checkpoint just before the bad hand-off, for example where the hotel agent used the wrong arrival date. They call update_state on that checkpoint's config to correct the field, which creates a fork. Then they resume from the fork. The risk is that every node after the fork point re-executes, including holds and possibly payment. So forks should be taken after the capture checkpoint when only ticketing needs fixing. If a fork must come earlier, the payment node relies on the idempotency key and the quote_version check. A changed quote forces a fresh approval. I would also restrict update_state to authorised staff and log every fork.

Sourced from Docs by LangChain (MCP)

Agent Server sits behind authentication. Each thread is tied to the owning user's identity, and an authorization check confirms the caller owns the thread_id before accepting Command(resume=...). The approval node also validates the payload shape: approved must be a boolean, and quote_version must match the current quote. Free text from the traveller is never treated as approval. For higher-risk amounts, I would add step-up authentication or the payment provider's own strong customer authentication flow at capture. Thread IDs should be unguessable, but they are not a security boundary on their own. Each approval should be logged with the user, the time and the quote version for audit.

Sourced from Docs by LangChain (MCP)

Raw card numbers and CVVs must never enter state, messages, checkpoints or LangSmith traces. The traveller enters card details directly with the payment provider, and the graph only holds a tokenised payment method reference. That keeps the agent system out of most of the card-data compliance scope. Passport numbers and dates of birth needed for ticketing should be passed by reference or kept minimal, encrypted at rest, and redacted in traces. Checkpoints are full state snapshots, so whatever you put in state is copied many times. I would set retention policies on old checkpoints and handle deletion requests that cover both the checkpointer and the store.

Sourced from Docs by LangChain (MCP)

A random UUID generated inside the capture node would be regenerated every time the node re-runs, for example after a crash, a retry or a replay from a fork. Each retry would look like a new payment to the provider, which defeats idempotency. Deriving the key deterministically from thread_id and quote_version means every re-execution for the same approved quote produces the same key, so the provider deduplicates it. A genuinely new quote version produces a new key, which is correct because it is a new, separately approved amount. If you did use a UUID, you would have to generate it in an earlier node and persist it in state before capture.

Sourced from Docs by LangChain (MCP)

After interrupt() returns the resume value, the node checks that it is well-formed: approved is a boolean, and quote_version is present and an integer. If approved is false, it routes to the payments or flight agent with the traveller's reason, or ends politely. If approved is true but quote_version does not match the current quote, it routes back to payments to present the new quote. A malformed payload makes it call interrupt() again with an explanation. Only a matching approval writes approval={version, timestamp} to state and returns Command(goto="capture"). Routing should use Command with type hints listing the allowed destinations, so the graph structure stays explicit.

Sourced from Docs by LangChain (MCP)

There are several layers of protection. Agent Server runs one active run per thread, and a double-texting policy such as reject or enqueue decides what happens to the second submission. If both somehow reach capture, they carry the same thread_id and quote_version, so they produce the same idempotency key, and the provider charges once and returns the same result to both. The second approval also finds approval already recorded for that version and can route straight to the existing result. The traveller sees one charge and one confirmation. I would test this case explicitly, because concurrency bugs around approvals are exactly where double charges come from.

Sourced from Docs by LangChain (MCP)

If capture has not happened yet, the change invalidates the current approval. The hotel agent holds the new room and payments writes a new quote with a higher version. The old approval no longer matches, so the traveller must approve again. If capture has already happened, it becomes a modification flow: a price difference means an additional charge or a partial refund, each with its own approval and idempotency key, and the original booking may need cancelling under supplier rules. The design principle stays the same. Any change in amount or itinerary creates a new quote version that needs explicit approval before money moves.

Sourced from Docs by LangChain (MCP)

I would combine stream modes. The 'updates' mode gives per-node state deltas, so the UI can show stages like 'flight held' and 'hotel held'. The 'messages' mode streams LLM tokens with node metadata, so the UI can label which agent is speaking. The 'custom' mode lets tools emit progress events such as 'searching 3 airlines'. When the run hits interrupt(), the client receives the interrupt payload and renders the approval screen with the exact itinerary and quote. I would avoid streaming raw tool outputs that might include supplier data or PII. 'debug' mode is for internal tooling, not end users.

Sourced from Docs by LangChain (MCP)

I would avoid guessing and build it from assumptions you can measure. Storage per trip is roughly the number of super-steps per trip multiplied by the average checkpoint size. The steps include agent turns, tool loops, hand-backs, approval, capture and ticketing. Size grows with the message history, since each checkpoint snapshots state. Multiply by trips per day and the retention period. I would measure real sizes in staging, then plan Postgres capacity, indexes on thread_id, and a retention or pruning policy for completed trips. Trimming or summarising long message lists and keeping large supplier payloads out of state both reduce growth.

Sourced from Docs by LangChain (MCP)

Each trip is an independent thread_id, so trips do not share mutable state. Agent Server workers can scale horizontally, because the state lives in the Postgres checkpointer rather than in worker memory. Any worker can pick up a resumed thread. Paused approvals consume only storage, not compute. The practical bottlenecks are Postgres write volume from checkpoints, LLM rate limits and supplier API limits. I would size Postgres for checkpoint writes, use connection pooling, and apply per-supplier rate limiting and backoff in tools. Parallel searches via Send improve latency per trip, but they multiply supplier calls, so concurrency limits matter.

Sourced from Docs by LangChain (MCP)

This is the double-texting problem, and Agent Server offers strategies for it. Reject refuses the new run. Enqueue runs it after the current one finishes. Interrupt stops the current run and starts the new one, keeping its progress. Rollback stops the current run and discards its progress. For a booking flow I would generally choose enqueue or reject around the payment section. Interrupting or rolling back mid-capture is risky, although idempotency keys still protect the money. Before approval, interrupting a slow search to apply a changed constraint can be fine. The choice should depend on which node is running.

Sourced from Docs by LangChain (MCP)

Search is the natural fit. The flight agent's planning step can return Send objects from a conditional edge, one per airline or date option, each with its own per-item state. A search node runs them in parallel, and a reducer on a results key such as operator.add collects the outcomes for the agent to rank. The hotel side can do the same across properties. I would not fan out holds or payments. Holding several fares at once wastes inventory and can incur fees, and payment must stay a single, sequential, idempotent step. Send is for read-mostly exploration, not for side effects.

Sourced from Docs by LangChain (MCP)

Making each agent a subgraph gives encapsulation. The flight agent's internal tool loop, its retries and its private scratch state stay inside it. Separate teams can develop and test it on its own, and it can be reused elsewhere. The costs are more careful state mapping between parent and child schemas, and handoffs that must navigate to the parent graph rather than to a sibling node directly. Debugging also becomes more nested. For three agents in one product, I would start with flat nodes in one StateGraph and move to subgraphs when an agent's internals grow, or when a hierarchical-teams structure becomes necessary.

Sourced from Docs by LangChain (MCP)

Unit tests cover each node with mocked tools, using InMemorySaver for checkpoints. Interrupt tests run to the approval node, assert the payload matches the quote, then resume with approved, declined, wrong-version and malformed values. Fault injection kills the run after capture but before the checkpoint, then resumes and asserts exactly one provider charge. Hand-back tests force impossible dates and assert the loop stops and asks the traveller. Replay tests fork from earlier checkpoints and confirm no second charge. Finally, I would run end-to-end tests against supplier and payment sandboxes, plus LLM evaluations on agent decisions using LangSmith datasets.

Sourced from Docs by LangChain (MCP)

Publishing directly after writing state risks two failures: losing the event if the worker crashes in between, or sending duplicates on replay. I would use an outbox pattern. The ticketing step writes the confirmation and an outbox record in the same database transaction, and a relay publishes the outbox records to the message bus. Every event carries a stable booking or thread ID, so the email and SMS consumers deduplicate and the traveller gets one notification. If the graph re-executes ticketing, the deterministic event ID makes the duplicate harmless. Notification failure must never roll back a confirmed booking.

Sourced from Docs by LangChain (MCP)

I start with the thread_id. get_state_history shows each checkpoint: which node ran, what it wrote, and where hand-offs went. LangSmith traces show the LLM prompts, tool calls, inputs, outputs and latencies for each agent turn, so I can see why the hotel agent handed back or which tool errored. The payment provider's records, looked up by idempotency key, confirm whether money actually moved. If a fix is needed, support forks from the right checkpoint with update_state. I would also emit structured logs and metrics per node, such as hand-back rate, approval latency and capture failures, to spot patterns across trips.

Sourced from Docs by LangChain (MCP)

Holds are time-limited and owned by the suppliers, and some time has passed since the flight agent created the fare hold, especially if the hotel agent handed back. A hold may have expired, or its price or availability may have changed. Re-checking ensures the quote reflects what can actually be ticketed, so the traveller approves a real price rather than a stale one. If a hold has lapsed, payments hands back via Command(goto=...) to re-hold instead of quoting. The check happens again near capture, because the approval may arrive much later. Cheap validation is far better than charging for something that cannot be ticketed.

Sourced from Docs by LangChain (MCP)

Treat all tool output as untrusted data, not as instructions. Agents get only the tools they need: the hotel agent cannot call payment, and capture is not an LLM tool at all. Capture is a deterministic node gated by a matching approval. Amounts come from the structured quote, never from free text. Tool results are parsed into typed fields before entering state, and long descriptions can be summarised or stripped before going into prompts. Even if injected text convinced an agent to do something odd, the human approval and the quote_version check stand between the agent and any money movement.

Sourced from Docs by LangChain (MCP)

Flat peer-to-peer handoffs get harder to reason about as agents multiply, because each agent must know which agents it can hand to. I would group agents into hierarchical teams. A transport team handles flights and cars, a stay team handles hotels, and a shared payments and approval layer stays a single deterministic section. Each team could become a subgraph. The core invariant does not change: one combined, versioned quote, one explicit approval, and one idempotent capture. Adding products should add line items to the quote, not new payment paths. Typed state also needs schema versioning, so old paused threads still resume.

Sourced from Docs by LangChain (MCP)

MCP makes the agent callable as a tool by other AI clients, which widens the attack surface. Callers may be other agents acting on a user's behalf, so authentication and per-user thread ownership must apply equally at /mcp. The key risk is an external agent trying to answer the approval interrupt itself. Approval must come from the traveller through an authenticated channel. It should not be auto-filled by a calling agent unless the product explicitly allows that and records consent. I would expose search and quote capabilities over MCP, keep approval human-only, and apply rate limits and audit logging.

Sourced from Docs by LangChain (MCP)

1. AExecution continues from the line right after interrupt()
2. BThe whole node re-runs from the start, so the hotel-hold tool is called againCorrect answer
3. CThe graph restarts from START
4. DThe resume value is ignored unless update_state is called first

Why: On resume, LangGraph re-executes the interrupted node from its beginning, and interrupt() then returns the resume value. Side effects before the interrupt therefore repeat unless they are moved to another node or made idempotent.

Sourced from Docs by LangChain (MCP)

1. AAt the beginning of the node that called interrupt()Correct answer
2. BAt START of the whole graph
3. CAt the next node after the interrupted one
4. DAt the line immediately after interrupt()

Why: LangGraph re-executes the interrupted node from its start, and interrupt() returns the resume value on that re-run. Any code before interrupt() therefore runs again.

Sourced from Docs by LangChain (MCP)

1. AThe current timestamp
2. BA value derived from thread_id and quote_versionCorrect answer
3. CThe traveller's email address
4. DA random UUID generated inside the capture node

Why: A deterministic key is identical on every retry of the same approved quote. A new quote version gets a distinct key.

Sourced from Docs by LangChain (MCP)

1. ACapture the amount from version 3
2. BFail the thread with an error
3. CRoute back so the traveller sees and approves the new quoteCorrect answer
4. DCapture the amount from version 4

Why: An approval is valid only for the exact quote it names. A mismatch needs fresh approval, not a charge.

Sourced from Docs by LangChain (MCP)

1. ANo checkpointer, relying on retries
2. BInMemorySaver
3. CA local JSON file
4. DA Postgres checkpointerCorrect answer

Why: Postgres persists checkpoints durably across restarts and workers. InMemorySaver is for development and tests.

Sourced from Docs by LangChain (MCP)

1. AIt sends a message to a payments agent in a different thread
2. BIt applies the state update and routes to payments_agent in one stepCorrect answer
3. CIt forks a new checkpoint branch for payments
4. DIt only updates state; routing still needs a separate conditional edge

Why: Command combines a state update with control flow from inside a node. That is how agent handoffs pass both the work result and the next destination together.

Sourced from Docs by LangChain (MCP)

1. ADeduplicates messages by content
2. BSorts messages by timestamp
3. CAppends each node's returned messages to the existing listCorrect answer
4. DReplaces the list with the latest node's messages

Why: A reducer defines how updates merge into state. operator.add concatenates lists, so agents append to the conversation.

Sourced from Docs by LangChain (MCP)

1. ALangGraph raises an error
2. BThe update is appended to a list
3. CThe new value overwrites the old oneCorrect answer
4. DThe update is ignored

Why: Keys without a reducer use overwrite semantics, which suits a single authoritative quote.

Sourced from Docs by LangChain (MCP)

1. Aquote_version
2. Bnode name
3. Cthread_idCorrect answer
4. Duser_id

Why: The checkpointer stores state per thread_id, and this design uses one thread_id per trip.

Sourced from Docs by LangChain (MCP)

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

Why: Checkpoints are saved at each super-step, which enables durable execution and time travel.

Sourced from Docs by LangChain (MCP)

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

Why: get_state_history returns the thread's past checkpoints for inspection, replay or forking.

Sourced from Docs by LangChain (MCP)

1. ASend a new user message
2. BDelete the thread and start over
3. CCall update_state on that checkpoint's config, then resumeCorrect answer
4. DEdit the Postgres rows directly

Why: update_state against an earlier checkpoint creates a forked checkpoint, and execution can resume from it.

Sourced from Docs by LangChain (MCP)

1. AThe deterministic idempotency key and the quote_version check deduplicate captureCorrect answer
2. BForks are read-only
3. CForked runs never execute tool calls
4. DLangGraph automatically skips payment nodes

Why: Nodes after the fork re-execute, so safety comes from idempotent capture and version-matched approval.

Sourced from Docs by LangChain (MCP)

1. AIn the capture step after an approval matches the current quote versionCorrect answer
2. BInside the payments agent when it builds the quote
3. CInside the flight agent when holding the fare
4. DInside the approval node before interrupt()

Why: Payments only builds the quote. Money moves only after the approval for that exact version is recorded.

Sourced from Docs by LangChain (MCP)

1. ACommand(goto="flight_agent") with a reason in the updateCorrect answer
2. BCommand(resume=...)
3. CA Send to payments_agent
4. DAn exception that ends the thread

Why: The design hands control back to the flight agent with a reason, rather than failing.

Sourced from Docs by LangChain (MCP)

1. ACharge a different stored card automatically
2. BRetry the capture forever
3. CMark the thread failed and stop
4. DRoute back to the payments or flight agent via Command(goto=...)Correct answer

Why: Declines and expired holds are routed for recovery instead of failing the thread. A different card would need traveller consent.

Sourced from Docs by LangChain (MCP)

1. AThe messages list of each thread
2. BAn InMemorySaver
3. CThe quote object
4. DPostgresStore under a namespace such as ("travellers", user_id)Correct answer

Why: Stores give long-term memory across threads, organised by namespace tuples.

Sourced from Docs by LangChain (MCP)

1. AThe card number with the CVV removed
2. BThe card PIN
3. CThe full card number and CVV
4. DA tokenised payment method reference from the providerCorrect answer

Why: Checkpoints copy state many times and traces record it, so only provider tokens belong there.

Sourced from Docs by LangChain (MCP)

1. AThe messages streaming mode
2. BA Send object from a conditional edge
3. CInMemoryStore
4. DA checkpointer such as the Postgres saver, keyed by thread_idCorrect answer

Why: Checkpointers persist graph state per thread_id at every super-step, which gives durable execution and resumption. Stores hold long-term cross-thread memory, not the run's execution state.

Sourced from Docs by LangChain (MCP)

1. AThe interrupt is skipped
2. BThe checkpointer refuses to save
3. CThe hold is automatically confirmed
4. DThe hold call runs again each time the node re-executes on resumeCorrect answer

Why: Code before interrupt() re-runs on resume, so side effects there can be duplicated.

Sourced from Docs by LangChain (MCP)

1. AFans out to a node with separate per-item state, in parallelCorrect answer
2. BSends an email to the traveller
3. CPauses the graph for human input
4. DWrites to the long-term store

Why: Send enables map-reduce: each Send invokes the target node with its own input.

Sourced from Docs by LangChain (MCP)

1. ASearching multiple airlines
2. BSearching multiple hotels
3. CFetching reviews
4. DCapturing paymentCorrect answer

Why: Payment must be a single, sequential, idempotent step. Fan-out suits read-mostly search.

Sourced from Docs by LangChain (MCP)

1. ABy namespace tuples and keysCorrect answer
2. BBy node name
3. CBy super-step number
4. DBy thread_id only

Why: Stores use namespace tuples, such as ("travellers", user_id), and support optional semantic search.

Sourced from Docs by LangChain (MCP)

1. Avalues
2. Bupdates
3. CmessagesCorrect answer
4. Ddebug

Why: The messages mode streams LLM tokens tagged with the node that produced them.

Sourced from Docs by LangChain (MCP)

1. Amessages
2. Bvalues
3. CupdatesCorrect answer
4. Dcustom

Why: updates streams per-node deltas. values streams the full state after each step.

Sourced from Docs by LangChain (MCP)

1. AIt works normally
2. BThe interrupt is silently ignored
3. CThe run is saved to the Store instead
4. DThe run cannot be paused and resumed, because interrupts need a checkpointerCorrect answer

Why: Pausing and resuming rely on persisted state, so interrupt() requires a checkpointer.

Sourced from Docs by LangChain (MCP)

1. AA compiled graph used as a node in another graphCorrect answer
2. BA read replica of the checkpointer
3. CA stream mode
4. DA namespace in the Store

Why: Subgraphs compose graphs as nodes, which encapsulates an agent's internal logic.

Sourced from Docs by LangChain (MCP)

1. ADisable hand-backs entirely
2. BTrack a hand-off counter in state and ask the traveller after a thresholdCorrect answer
3. CRely only on supplier timeouts
4. DRemove the checkpointer

Why: An explicit counter degrades gracefully. The recursion limit is a backstop that fails the run.

Sourced from Docs by LangChain (MCP)

1. APublishing from the approval node
2. BTransactional outbox with idempotent consumersCorrect answer
3. CFire-and-forget HTTP call
4. DStoring events in the messages list

Why: The outbox writes the event in the same transaction as the booking. Stable event IDs let consumers deduplicate.

Sourced from Docs by LangChain (MCP)

1. AThe LLM noticing the duplicate
2. BThe messages reducer
3. CBrowser caching
4. DThe same thread_id and quote_version produce the same idempotency keyCorrect answer

Why: The provider deduplicates captures that share an idempotency key, alongside one-active-run-per-thread handling.

Sourced from Docs by LangChain (MCP)

1. AIt is faster
2. BLLM output cannot contain numbers
3. CThe checkpointer drops LLM output
4. DThe approved amount must match exactly, and LLM text can be wrong or manipulatedCorrect answer

Why: Reading total and currency from the approved, versioned quote ensures only the approved amount is charged.

Sourced from Docs by LangChain (MCP)

1. A/mcpCorrect answer
2. B/tools
3. C/agent
4. D/rpc

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

Sourced from Docs by LangChain (MCP)

1. AA single agent with no tools
2. BA supervisor that routes every step
3. CBatch map-reduce only
4. DSwarm-style handoffs via Command(goto=...)Correct answer

Why: Agents pass control directly to each other with Command handoffs over shared typed state.

Sourced from Docs by LangChain (MCP)