Streaming tutor app

Each mode answers a different UI question. Messages mode gives LLM tokens as they are generated, along with metadata saying which node produced them, so the chat feels live and I can filter to the tutor node only. Updates mode gives the state delta after each node finishes, which maps neatly onto a progress indicator like diagnosing, explaining or checking. Custom mode lets a node push its own structured payload through get_stream_writer, which suits hint cards because the UI gets typed data, not text to parse. Values mode would resend full state each step, which is heavier and still lacks tokens. Streaming all three in one run keeps a single connection while separating concerns cleanly on the client.

Sourced from Docs by LangChain (MCP)

The browser sends the message with the session's thread_id and opens a run stream with messages, updates and custom modes. The Agent Server loads the latest checkpoint for that thread from Postgres, and add_messages appends the new turn. The diagnose node reads the profile from PostgresStore under ('students', student_id) and writes intent and level. A conditional edge then routes to the tutor, hint or answer-checker node. The tutor streams tokens, the hint node writes hint cards through get_stream_writer, and the checker may call interrupt to ask a follow-up. The progress writer updates mastery in the store. Every super-step is checkpointed, so the thread is durable, resumable and replayable for review.

Sourced from Docs by LangChain (MCP)

I treat it as a server-side guarantee, not a UI convention. Messages mode emits tokens from any chat model call in the graph, including the grader's, and updates mode emits every node's state delta, including any grading notes kept in state. So I put a thin backend gateway between the Agent Server and the browser. The gateway forwards messages only when metadata langgraph_node is the tutor node, forwards only allowlisted update keys such as intent and step name, and forwards custom events only if they match a hint schema. I also keep grading notes out of the tutor's prompt, so prompt injection cannot get the model to repeat them. Tests then assert that no grader text appears in the student-facing stream.

Sourced from Docs by LangChain (MCP)

The client should never be the authority on ownership. The server creates the thread_id when a session starts and records the authenticated student as the owner in the thread's metadata. Every request to run, stream, get state or get history passes through an authorization check that compares the caller's identity with that owner. I use the Agent Server's custom auth handlers or a gateway for this. Thread IDs are random UUIDs, never sequential numbers, but unguessability is only a second layer of defence. Teacher access to history is a separate, explicit permission. Store namespaces are built from the authenticated student_id, never from a field in the request body.

Sourced from Docs by LangChain (MCP)

I compile the graph with a Postgres checkpointer and run every turn with a thread_id tied to that session. LangGraph saves a checkpoint at every super-step, so after a refresh the client calls get state for the thread and redraws the conversation, including any pending interrupt question. If a server restarts mid-run, the thread still has its last completed checkpoint and the run can be resumed from there instead of starting over. Long-term data such as mastery goes into PostgresStore under a namespace per student, so it outlives individual threads. I avoid InMemorySaver outside development because it is lost on restart and is not shared across replicas.

Sourced from Docs by LangChain (MCP)

Inside a node I call interrupt() with the question payload. The run pauses, the state is checkpointed on the thread, and the client sees the interrupt in the stream, so the UI shows it as a prompt. When the student answers, the client sends Command(resume=answer) on the same thread_id, and the node continues with that value as the return of interrupt(). One subtlety is that the node re-executes from its start on resume, so any side effects before the interrupt must be idempotent or moved to a later node. This approach is better than ending the run and parsing the next message, because the pending step is explicit and durable.

Sourced from Docs by LangChain (MCP)

Messages mode yields (chunk, metadata) pairs for every LLM call in the graph. The diagnose node and the answer checker may also call models, so without a filter their tokens would show up in the chat. Filtering on langgraph_node equal to the tutor node keeps the chat to tutor output only. The limit is that a browser filter only hides data that has already been delivered. Anyone with dev tools can read the raw stream, so it is not a security control. The same filter must run server-side before the stream leaves the backend. Model tags are a useful extra signal, and the node name must also cover subgraph namespaces if the tutor is ever moved into a subgraph.

Sourced from Docs by LangChain (MCP)

I would use a TypedDict state. messages uses the add_messages reducer so turns append and can be updated by ID. intent and level are plain overwrite keys set by diagnose. current_problem holds the exercise reference. submission holds the student's latest answer. grading is a structured result with score, verdict and internal notes, kept apart from messages and never streamed. hints_shown is a list with operator.add so hint history accumulates. If multi-part grading fans out with Send, part_results also needs operator.add so parallel branches merge. Long-term data such as mastery belongs in the store, not in thread state. Keeping the state small matters because it is checkpointed at every super-step.

Sourced from Docs by LangChain (MCP)

Without a reducer, any node that returns messages replaces the whole list, so a node returning only its new reply would erase the conversation. add_messages appends new messages and, when an ID matches an existing message, updates that message in place. This keeps earlier turns from the loaded checkpoint and makes resume and fork behave predictably. It also lets parallel branches each contribute messages in the same super-step without losing each other's writes. The cost is that history grows without limit, so I pair it with trimming or summarisation before model calls. I also delete old messages deliberately by ID instead of relying on overwrite.

Sourced from Docs by LangChain (MCP)

The checkpointer holds short-term, per-thread state. It saves a snapshot at each super-step under the thread_id, which gives resume after a refresh or crash, interrupts, and time travel inside one session. The store holds long-term memory that outlives any one thread, such as a student's profile and mastery, organised by namespace tuples like ('students', student_id). A new session starts a new thread with an empty conversation, but diagnose can still read mastery from the store. If everything lived in the checkpointer, cross-session memory would mean reading other threads. If everything lived in the store, we would lose per-step durability and replay.

Sourced from Docs by LangChain (MCP)

Every key sits under a namespace that starts with the authenticated identity, for example ('students', student_id) for the profile and ('students', student_id, 'mastery') for skills. The namespace is built server-side from the auth context. Nodes never accept a student_id from model output or from the request body. Semantic search is always scoped to that student's namespace prefix, never run across the root, so similar content from another student cannot come back as a match. Shared content such as a curriculum goes in a separate namespace like ('curriculum', subject), and nodes only read from it. I add tests that try cross-namespace reads and assert they return nothing.

Sourced from Docs by LangChain (MCP)

Two concurrent runs on one thread could interleave writes and confuse the stream. The Agent Server supports multitask strategies for this double-texting case: reject the new run, enqueue it after the current one, interrupt the current run, or roll it back and start fresh. For a tutor I would usually choose enqueue, so the second message is answered with full context. If the product wants 'latest message wins', interrupt is the better fit. On the client I also disable send while a run is streaming, or show the queued message as pending. Whatever strategy we choose, one thread should have only one active run at a time.

Sourced from Docs by LangChain (MCP)

On resume, LangGraph re-runs the interrupted node from its beginning, and this time interrupt() returns the resume value instead of pausing. Any code before the interrupt call therefore executes twice. If that code calls an LLM, writes to the store or sends a notification, the work is repeated or duplicated. So I keep the ask node minimal. Expensive or side-effecting work, such as generating the follow-up question, goes in an earlier node whose result is already checkpointed, and the ask node only calls interrupt with it. Any unavoidable side effects must be idempotent. When one node contains several interrupts, they must always be called in the same order, because resume values are matched by position.

Sourced from Docs by LangChain (MCP)

Checkpoints are written at super-step boundaries, so the tutor node's partial output was never committed. The last durable state is the checkpoint taken before the tutor ran, which already contains the student's message and diagnose's result. On recovery the run resumes from that checkpoint and re-executes the tutor node, producing a fresh, possibly different reply. The UI has to discard the partial tokens it already showed and render the new stream, or reload thread state if no run is active. Completed nodes such as diagnose are not re-run, which is why a side effect belongs in its own node, where it becomes durable once that node's step commits.

Sourced from Docs by LangChain (MCP)

The routing function should only read state, for example state['intent'], and return a node name. It should never call a model. That keeps routing deterministic, testable and cheap. Diagnose does the classification and writes a constrained value, ideally from structured output validated against an enum of explain, stuck and answer. For low confidence or an unknown value, I route to the tutor by default, because a clarifying explanation is the safest fallback. Alternatively I route to an ask node that interrupts with 'Do you want a hint or should I check your answer?'. I also log the routing decision so mis-routes show up in traces and evaluations.

Sourced from Docs by LangChain (MCP)

A hint card is structured UI data, such as hint type and hint level, not chat text. Sending it through get_stream_writer in custom mode gives the UI a typed event it can render as a card. The UI can track the hint level, and hints cannot be mixed into the conversation the model later reads. It also avoids the messages-mode filter, because hint text is not tokens from the tutor node. The trade-off is that custom events are transient stream output, not persisted state. If hints must reappear after a refresh or be counted for mastery, the hint node should also write them to a state key such as hints_shown.

Sourced from Docs by LangChain (MCP)

Replaying or forking re-executes nodes after the chosen checkpoint, and that includes the progress writer, which writes to the store. A teacher testing a different tutoring path could therefore overwrite the student's real mastery. I separate the effects. Review runs carry a flag in config, or run against a separate sandbox store namespace, and the progress writer skips real writes or redirects them when the flag is set. Forks made with update_state go to a copy of the thread where possible. History reads through get_state_history are read-only and safe. I also remember that re-executed LLM calls are not deterministic, so a replay shows a plausible path, not an exact recording.

Sourced from Docs by LangChain (MCP)

I build a formula and fill it in with measured values later. Checkpoint writes per turn roughly equal the super-steps per turn: here, diagnose, one routed node, possibly ask, and the progress writer. Writes per second are about concurrent active students, divided by the average seconds between their turns, multiplied by super-steps per turn. Storage per thread grows with turns times checkpoint size, and message history dominates. The Postgres checkpointer stores channel values by version, so unchanged keys are not rewritten each step, but long histories still add up. I would load-test with representative sessions, then size Postgres, decide retention, and decide whether old checkpoints can be pruned once a session ends.

Sourced from Docs by LangChain (MCP)

There are two separate concerns: model context and checkpoint size. For context, the tutor node trims or summarises before calling the model. For example, it keeps the system prompt, a running summary and the last N turns, and a summarise step updates the summary when history passes a threshold. Trimming at call time does not shrink stored state. To shrink state, a node can return RemoveMessage entries for old messages through add_messages, keeping the summary in a separate key. Durable facts such as weak topics go to the store rather than staying in chat history. I also set a retention policy for finished threads so checkpoint storage does not grow without limit.

Sourced from Docs by LangChain (MCP)

The checkpoint and the store write are not one atomic transaction. The progress writer could update the store, and then the process could crash before the step's checkpoint commits. On resume the node runs again. So I make the write idempotent. Instead of 'increment mastery by one', I write a record keyed by thread_id and attempt ID, or recompute mastery from recorded attempt results. A repeated write then overwrites the same value. Placing the progress writer last, after grading is committed, means it only writes confirmed outcomes. For reporting, a periodic job can rebuild mastery from attempt records if drift is ever suspected.

Sourced from Docs by LangChain (MCP)

I would use map-reduce with Send. A conditional edge after the answer checker's setup returns one Send per part, targeting a grade_part node with that part's question, the student's answer and the rubric reference. LangGraph runs these branches in the same super-step. Each branch returns its result under a part_results key that has an operator.add reducer, so results append instead of overwriting each other. A combine node then computes the overall verdict and decides whether a follow-up interrupt is needed. Grading output stays in state and is never streamed to the student. Per-part LLM tokens from grade_part are filtered out of messages mode like any other non-tutor node.

Sourced from Docs by LangChain (MCP)

I test at three levels. Unit tests call node functions directly with fake state and a mocked model, and check routing functions against every intent value. Graph tests compile with InMemorySaver and a fake model, then assert the node path, the interrupt and resume cycle, and resume after a simulated failure. Streaming tests capture every event in all three modes and assert that no grader content, grading keys or non-tutor tokens reach the student-facing gateway output. Isolation tests use two student identities and confirm that cross-thread and cross-namespace access fails. Finally, LangSmith evaluations score tutoring quality and routing accuracy on a dataset of real-style student turns.

Sourced from Docs by LangChain (MCP)

Traces are valuable because they show every node, prompt and model output, including grading. That is also why they are sensitive. I restrict trace access to a small engineering group and choose the data region and retention to match our policy. I mask or omit personal fields such as names and contact details before they reach prompts or trace metadata. I use pseudonymous student IDs in metadata rather than emails. For high-volume production traffic I can sample traces rather than trace everything. Teachers review sessions through our own access-controlled history view built on get_state_history, not through raw trace access.

Sourced from Docs by LangChain (MCP)

India's Digital Personal Data Protection Act, 2023 applies. It requires verifiable parental consent for processing children's data and restricts tracking and behavioural monitoring of children, so I would confirm specifics with legal counsel. In the design, that means collecting only what tutoring needs, linking consent status to the student account, and not using session data for targeting. Deletion must be complete: delete the student's threads and their checkpoints, delete every key under the student's store namespaces, and purge related traces. Retention periods for finished sessions are explicit. Access to transcripts is role-based and logged.

Sourced from Docs by LangChain (MCP)

Today a single graph with a classifier node and a conditional edge is enough. The routes are few, deterministic and cheap, and the stream is easy to filter by node. A supervisor pattern makes sense if specialised agents grow, for example separate maths, coding and language tutors with their own tools. A supervisor model would then pick the agent, and handoffs could use Command(goto=...). The costs are an extra LLM call per turn, more latency before the first token, less predictable routing, and more nodes whose tokens must be filtered from the stream. I would move to it only when one tutor prompt can no longer cover the subjects well.

Sourced from Docs by LangChain (MCP)

On reconnect the UI first loads the thread's current state and renders committed messages by their IDs. That state is the source of truth. If a run is still active, the client rejoins its stream. If the server re-executed the tutor node after a failure, the reply arrives as a new stream. The UI discards any partial bubble whose message was never committed and builds the live message from chunks with the same message ID. When the run finishes, it reconciles against state again. Pending interrupts also appear in thread state, so a refresh during the ask step shows the follow-up question instead of losing it.

Sourced from Docs by LangChain (MCP)

I serve them as two clients with separate authorisation, not one stream with UI-side hiding. The student path keeps messages, updates and custom, filtered at the gateway to tutor tokens, allowlisted update keys and hint events. The teacher path, available only to users with a teacher role for that student's class, may receive updates with grading summaries, or read state after the fact through get_state_history. The gateway applies a role-based policy per mode and per key. Debug mode stays limited to developers, because it exposes a lot of internal detail.

Sourced from Docs by LangChain (MCP)

I start with traces to see where time goes before the tutor's first token: loading the checkpoint, the store read in diagnose, diagnose's own LLM call, then the tutor model's time to first token. Diagnose is a full model call in series before the tutor, so it is usually the biggest cost. Options include a smaller, faster model or a rules-first classifier for diagnose, and trimming context. Updates mode already shows a progress step, which improves perceived latency. I would measure each change against routing accuracy so speed does not cost correctness.

Sourced from Docs by LangChain (MCP)

InMemorySaver keeps checkpoints in process memory. A restart or deploy wipes every student's session, which breaks the requirement to survive a refresh after a server restart. With several server replicas, each holds its own memory, so a reconnect routed to another instance cannot find the thread. It also grows without bound and has no retention controls. It is good for unit tests and local development because it is fast and needs no setup. Production uses the Postgres checkpointer, which is durable, shared across replicas and queryable, and InMemoryStore is likewise replaced with PostgresStore.

Sourced from Docs by LangChain (MCP)

A subgraph is added as a node, so the parent graph stays simple and the hint engine can be tested on its own. For streaming, events from inside a subgraph are only included when the stream is requested with subgraphs enabled. They then carry a namespace that identifies the subgraph path. The node name in metadata becomes the inner node's name, so a filter that checks langgraph_node equals 'hint' could miss events or match the wrong ones. I would base filtering and rendering on an explicit allowlist of namespace and node pairs. Custom events written with get_stream_writer inside the subgraph still arrive in custom mode, provided subgraph streaming is enabled.

Sourced from Docs by LangChain (MCP)

The /mcp endpoint lets MCP clients call the deployed agent as a tool. That is useful for integrations, but it is a second entry point into the same graph. Without the same authentication, an external client could start runs, choose thread IDs or read outputs, including grading data in final state. I would keep it disabled or behind the same auth and authorization handlers as the main API, and expose only what integrations need. Responses should be checked so internal keys such as grading notes are not part of any returned output. If the MCP surface is not used, turning it off is the simplest control.

Sourced from Docs by LangChain (MCP)

The strongest defence is structural: the tutor model never sees the grading notes. They live in a state key that the tutor node does not include in its prompt, and only a short, student-safe feedback summary, if any, is passed on. A model cannot reveal what it was never given. Second, the answer checker's own model output is never forwarded, because the stream gateway allowlists only tutor tokens and safe update keys. Third, the system prompt and output checks discourage revealing solutions early. I would add red-team test cases like this one to the evaluation set.

Sourced from Docs by LangChain (MCP)

A conditional edge is best when routing is a pure function of state that was already written, as with intent after diagnose. It keeps the graph diagram explicit and the logic easy to test. Command(goto, update) suits cases where the node that computes something should also decide where to go next, in one step. For example, the answer checker could write its grade and jump straight to ask or to the progress writer, without a separate router. The same mechanism powers handoffs between agents. The trade-off is that routes are less visible in the graph, so I declare the possible destinations to keep visualisation and validation useful.

Sourced from Docs by LangChain (MCP)

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

Why: Messages mode streams LLM message chunks paired with metadata such as the node name. Updates and values carry state, not tokens.

Sourced from Docs by LangChain (MCP)

1. AOnly debug
2. BupdatesCorrect answer
3. Ccustom
4. DNone, because state is never streamed

Why: Updates mode emits each node's state delta, so grading notes written to state would appear unless they are filtered server-side.

Sourced from Docs by LangChain (MCP)

1. AA browser cookie read by the node
2. BA field in the request body
3. CThe LLM's output
4. DThe authenticated identity, resolved server-sideCorrect answer

Why: Deriving the namespace from the server-side auth context stops a client from reading another student's memory.

Sourced from Docs by LangChain (MCP)

1. AReturn the hint in state and rely on values mode
2. BCall get_stream_writer() and stream with custom modeCorrect answer
3. CRaise an interrupt() containing the hint
4. DWrite the hint to the store and poll it

Why: get_stream_writer() emits arbitrary payloads that arrive in the custom stream mode without changing graph flow. interrupt() would pause the run instead.

Sourced from Docs by LangChain (MCP)

1. AA namespace tuple in the store
2. BA unique node name per student
3. CThe thread_id passed in the run configCorrect answer
4. DA separate StateGraph per student

Why: Checkpointers save and load state per thread_id. Store namespaces are for long-term memory across threads, not for per-session checkpoints.

Sourced from Docs by LangChain (MCP)

1. Aoperator.add on a string
2. Badd_messagesCorrect answer
3. CNo reducer, so the key is overwritten
4. DA reducer that keeps only the last message

Why: add_messages appends new messages and updates existing ones with a matching ID, so earlier turns are preserved.

Sourced from Docs by LangChain (MCP)

1. AOnly when interrupt() is called
2. BOnly when the run ends
3. CEvery few seconds on a timer
4. DAt every super-stepCorrect answer

Why: Checkpointers save state per thread_id at every super-step, which enables durable execution, resume and time travel.

Sourced from Docs by LangChain (MCP)

1. AThe state delta returned by that node, keyed by node nameCorrect answer
2. BNothing until the run finishes
3. CThe full state after the step
4. DOnly LLM tokens

Why: Updates mode streams the updates each node returned after each step, which the UI renders as progress.

Sourced from Docs by LangChain (MCP)

1. AIt loads the previous thread's checkpoint
2. BIt asks the student again every time
3. CMastery is copied into the thread_id
4. DIt reads from the PostgresStore namespace for that studentCorrect answer

Why: Stores give long-term memory across threads, organised by namespace, while checkpoints are scoped to one thread.

Sourced from Docs by LangChain (MCP)

1. ASending the reply through custom mode
2. BCalling update_state with the reply
3. CStarting a new thread
4. DInvoking the graph with Command(resume=...) on the same threadCorrect answer

Why: interrupt() pauses the node with state checkpointed, and Command(resume=value) on the same thread continues it.

Sourced from Docs by LangChain (MCP)

1. AAt the beginning of the nodeCorrect answer
2. BAt the START node of the graph
3. CAt the next node
4. DAt the line after interrupt()

Why: The node re-runs from its start and interrupt() returns the resume value, so code before the interrupt must be idempotent.

Sourced from Docs by LangChain (MCP)

1. AThe browser cannot read metadata
2. BThe data has already been delivered and can be seen in dev toolsCorrect answer
3. Clanggraph_node is only set in debug mode
4. DMessages mode never includes other nodes

Why: Client-side filtering only hides delivered data, so the filter must also run server-side before the stream leaves the backend.

Sourced from Docs by LangChain (MCP)

1. AThe Postgres checkpointerCorrect answer
2. BNo checkpointer, using the store instead
3. CInMemorySaver
4. DA local JSON file

Why: The reference notes recommend InMemorySaver for development and Postgres in production, for durability and sharing across replicas.

Sourced from Docs by LangChain (MCP)

1. Amessages
2. Bcustom
3. Cupdates
4. DvaluesCorrect answer

Why: Values mode streams the complete state value after each step, while updates streams only the deltas.

Sourced from Docs by LangChain (MCP)

1. ASend
2. Bget_state_historyCorrect answer
3. Cget_stream_writer
4. Dinterrupt

Why: get_state_history returns the thread's checkpoints, which can be replayed or used as fork points.

Sourced from Docs by LangChain (MCP)

1. AEdits the original checkpoint in place
2. BCreates a new checkpoint that forks from that pointCorrect answer
3. CRestarts the Agent Server
4. DDeletes all later checkpoints

Why: update_state writes a new checkpoint based on the chosen one, which creates a fork while the original history stays intact.

Sourced from Docs by LangChain (MCP)

1. AA custom payload dictionary
2. BA full state snapshot
3. CA (message chunk, metadata) pairCorrect answer
4. DA checkpoint ID

Why: Messages mode emits LLM token chunks together with metadata such as langgraph_node.

Sourced from Docs by LangChain (MCP)

1. Ainterrupt()
2. Bget_state_history()
3. Cadd_messages()
4. Dget_stream_writer()Correct answer

Why: get_stream_writer() returns a writer whose payloads arrive in custom stream mode.

Sourced from Docs by LangChain (MCP)

1. ANothing, because custom events are replayed automatically
2. BAlso write the hints to a state key so they are checkpointedCorrect answer
3. CSwitch the hint node to debug mode
4. DStore the hints in the thread_id

Why: Custom events are transient stream output, so persisting hints means writing them to checkpointed state.

Sourced from Docs by LangChain (MCP)

1. ACall a second LLM to decide
2. BRead intent from state and return the node nameCorrect answer
3. CPick randomly among the three nodes
4. DAlways go to the tutor, then let it decide

Why: Routing as a pure function of state is deterministic and testable, and diagnose has already written intent.

Sourced from Docs by LangChain (MCP)

1. AThe END constant
2. BA list of Send objects, one per partCorrect answer
3. CA Command(resume=...)
4. DA call to interrupt() for each part

Why: Send objects fan out to a node with per-item state, which is LangGraph's map-reduce pattern.

Sourced from Docs by LangChain (MCP)

1. ACalling update_state after each branch
2. BRunning them on separate threads
3. CA reducer such as operator.add on part_resultsCorrect answer
4. DUsing values mode

Why: A list reducer like operator.add merges each branch's writes instead of the last write winning.

Sourced from Docs by LangChain (MCP)

1. AThe partial reply is restored token by token
2. BExecution resumes from the last checkpoint and the tutor node runs againCorrect answer
3. CThe whole session is lost
4. DThe run jumps to END

Why: Checkpoints are taken at super-step boundaries, so the unfinished tutor step re-executes from the previous checkpoint.

Sourced from Docs by LangChain (MCP)

1. ACreate a new thread for the second message
2. BDrop the first message
3. CStart a second concurrent run on the same thread
4. DUse an enqueue strategy so the second run waitsCorrect answer

Why: Enqueueing keeps one active run per thread and answers the second message with full context.

Sourced from Docs by LangChain (MCP)

1. AAdd 'never reveal notes' to the prompt
2. BNever include grading notes in the tutor's promptCorrect answer
3. CLower the model temperature
4. DStream the notes in custom mode

Why: A model cannot leak what it never sees, so keeping notes out of the tutor's context is a structural defence.

Sourced from Docs by LangChain (MCP)

1. AIt changes the thread_id
2. BIt cannot run during replay
3. CIt may write replayed outcomes into the student's real masteryCorrect answer
4. DIt deletes the thread

Why: Replay re-executes nodes, including store writes, so review runs need a guard flag or a sandbox namespace.

Sourced from Docs by LangChain (MCP)

1. AAcross all namespaces for better recall
2. BTo the authenticated student's namespace prefixCorrect answer
3. CTo the curriculum namespace only
4. DTo the thread's checkpoint

Why: Scoping search to ('students', student_id) stops similar content from other students being returned.

Sourced from Docs by LangChain (MCP)

1. AAs an increment, such as mastery += 1
2. BAs an idempotent write keyed by thread and attemptCorrect answer
3. COnly to the checkpoint
4. DTo a browser cookie

Why: Checkpoint and store writes are not atomic together, so an idempotent keyed write avoids double counting when the node re-runs.

Sourced from Docs by LangChain (MCP)

1. Avalues
2. Bcustom
3. Cmessages
4. DdebugCorrect answer

Why: Debug mode streams detailed execution information, so it is meant for developers, not end users.

Sourced from Docs by LangChain (MCP)

1. AIt becomes a separate deployment
2. BIt is composed into the parent graph as a nodeCorrect answer
3. CIt can no longer use custom mode
4. DIt shares the store namespace of all students

Why: Subgraphs compose graphs as nodes, which keeps the parent simple and lets the hint logic be tested on its own.

Sourced from Docs by LangChain (MCP)

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

Why: Deployment on Agent Server exposes agents over an API and an MCP endpoint at /mcp, which needs the same auth as the main API.

Sourced from Docs by LangChain (MCP)

1. ASend(goto=...)
2. Binterrupt(goto=...)
3. CCommand(resume=...)
4. DCommand(goto=..., update=...)Correct answer

Why: Command(goto, update) routes and updates from inside a node, which is how handoffs work.

Sourced from Docs by LangChain (MCP)

1. AA supervisor agentCorrect answer
2. BThe browser
3. CThe store's semantic search
4. DThe checkpointer

Why: In the supervisor pattern, a coordinating agent routes work to specialist agents.

Sourced from Docs by LangChain (MCP)