In a LangGraph multi-agent graph, when should agents get isolated state instead of one shared message list?
answer
- overlapping keys are the whole interface
- shared transcript grows every hop
- one agent's errors become another's context
- private schema, summarized result back
- concurrent writers need a reducer
basics
~20 sShare one message channel when agents must see each other's reasoning; isolate when they must not. Isolation means giving an agent its own state schema in a subgraph and writing only a summarized result back to the parent — smaller prompts and no cross-contamination, at the cost of lost context.
solid answer
~50 sIn LangGraph, a parent graph and a nested agent communicate only through the state keys they both declare; keys declared solely by the child stay private to it. With one shared `messages` channel, every worker's tool calls, retries and stack traces land in every other worker's prompt. That is sometimes what you want — a debate or a critique loop needs the transcript — but usually it means prompts grow superlinearly, a failed worker's error text derails the next agent, and one agent's half-finished plan gets treated as fact. Isolation is the alternative: give the worker its own schema, run it behind a wrapper node, and write back a single summarized message. You lose detail the next agent might have needed, and debugging now spans two state objects. Also mind shared keys written by two agents in the same superstep — that channel needs a reducer, or the concurrent update is an error.
go deeper
Know that agents in one graph can share a message list, and that whatever one agent writes there becomes context for the next. Say plainly that this makes prompts grow.
Explain that a nested graph only sees the state keys it declares that also exist in the parent, and describe writing a summary back instead of raw output.
Show the tradeoff with costs on both sides: token growth and contamination versus lost detail and two-level debugging. Name the concurrent-write hazard on shared keys.
Own the state schema as an interface contract across teams — which channels are public, what each worker must publish, and how that contract is versioned when an agent's internals change.
## What "shared state" actually means here LangGraph state is a set of named channels defined by a schema (a `TypedDict` or Pydantic model), each with a reducer that says how a new value combines with the old one. A nested graph attached as a node does not automatically see the parent's state — it sees the keys its own schema declares, filled from the parent's state where the names overlap. Overlap is the entire interface. Keys only the child declares are the child's private working memory; keys only the parent declares are invisible to the child. So "shared vs isolated" is not a framework switch. It is a decision about how much of your state schema two agents have in common. ## The default: one messages channel The path of least resistance is `MessagesState` everywhere: parent and all workers share a `messages` channel with an appending reducer. Everything every agent says or does accumulates in one list, and every agent's next prompt is that list. The upside is genuine. Agents get full mutual context for free, handoffs need no translation code, the whole run is one readable transcript, and streaming or tracing shows a single coherent conversation. The downsides bite at scale: - **Prompt growth.** With H hops, each agent reads roughly all prior output, so total tokens grow with the square of the hop count. A ten-hop run can cost several times what the work itself needs. - **Contamination.** A worker's failed tool call, its raw JSON payloads, its retry chatter — all of it is now context for agents that never needed it. Models are suggestible; a stack trace in the history makes the next agent start debugging. - **Premature commitment.** One agent's exploratory hypothesis, once written into the shared transcript, reads to every later agent as an established finding. - **Context-window cliffs.** The run works fine in testing and dies mid-way on a long task, which is the worst possible failure timing. ## Isolation and what it costs Isolating an agent means giving it a schema of its own — say `query`, `notes`, `summary` — and running it behind a wrapper node in the parent. The wrapper translates parent state into the child's input, invokes the child, and writes back only what the rest of the system needs: usually one assistant message carrying a summary, plus perhaps a structured artifact key. What you buy: the parent's prompt grows by a paragraph per delegation instead of a transcript; a worker's internal failures never reach a sibling; and the contract between agents becomes explicit and reviewable, which makes it testable — you can unit-test the worker graph against its own schema without the parent existing. What you pay: information loss. If the writer needed the researcher's raw citations and the summary dropped them, you have introduced a bug that only shows up in output quality, not in an exception. Debugging is also two-level — the parent's state no longer contains the child's intermediate steps, so you need per-subgraph tracing to see what happened. And you now maintain translation code that drifts when either schema changes. ## Choosing Share state when the agents' value comes from seeing each other: critique and revise loops, debate, a reviewer that must judge the reasoning and not just the artifact, or short runs where growth never bites. Isolate when the worker is a *function* rather than a *participant*: a retrieval agent whose only interesting output is the retrieved facts, a code-execution agent whose stdout noise helps nobody, a worker whose tool traffic is bulky (search results, file contents, API payloads). Isolate also when the agents genuinely need different state shapes — forcing a shared schema so everything can be one graph is how a state object grows twenty optional keys nobody can reason about. A good middle setting is a shared `messages` channel used deliberately as the *public* channel — summaries and decisions only — plus private channels inside each worker for the raw material. That keeps the readable transcript and drops most of the growth. ## Concurrency, briefly If two agents can write the same shared key in the same superstep, that channel needs a reducer that can combine both values. A channel with a last-write-wins default receiving two concurrent updates is an error, not a silent merge. This is a real trap when a shared scratchpad key is introduced late and only fails under the parallel path. ## What interviewers listen for They want the tradeoff articulated in both directions, with a number attached to at least one side, and a concrete design: which keys are shared, what the worker writes back, and what you would do differently if output quality dropped after isolating.
- Your worker writes back only a summary and downstream quality drops. How do you diagnose it?Compare runs with the worker isolated against runs with its full output shared, on the same inputs, scoring the final answer. If the shared version wins, the summary is dropping something load-bearing — usually citations, identifiers, or uncertainty. The fix is normally a structured artifact key alongside the prose summary, not reverting to a fully shared transcript.
- Two agents write the same shared state key in one superstep. What happens?It depends on the channel's reducer. A channel with an appending reducer combines both writes. A channel using the default last-value behaviour cannot resolve two concurrent updates and the run errors instead of silently picking one. Any key that parallel branches can both write needs a reducer chosen deliberately for that merge.
- How do you keep a readable end-to-end transcript after isolating workers?Treat the shared messages channel as the public log: every worker writes one summarizing assistant message on the way out, so the parent transcript still reads as a coherent narrative. Keep the raw tool traffic in the worker's private channels and rely on per-subgraph tracing when you need the detail behind a step.
A shared message list is an open-plan room where every agent overhears every call; isolation is each team working in its own room and posting a one-paragraph memo on the shared board.
saying these in an interview costs you the question
- Assumes every agent must share one messages channel
- Ignores that shared history grows superlinearly with hops
- Thinks a nested graph automatically sees all parent state
- Says isolation is free and loses no useful context
- Adds a shared scratchpad key with no reducer for parallel writers