Pick the LangGraph primitive that triggers data dependent parallel fan out

MCQ·Medium·4.0 · 0·~1 min·Asked atEy Moveworks Pinecone

Attempt it

LangGraph offers several graph-building primitives, but only one of them does **data-dependent parallel fan-out**: the `Send` class. The other options build **static structure**: - `add_node` registers a node in the graph. One node at a time, no fan-out. - `add_edge` wires one static edge from node A to node B. One edge at a time. - `compile` finalises the graph into an executable. It does not control runtime branching. `Send` is different because it is **runtime-evaluated**. A conditional edge function returns a list of `Send` objects, each with two things: the name of the target node and a payload. The runtime spawns one parallel branch per `Send`, runs them concurrently, and merges results back into the state via the reducers you defined. The typical use case: a planner agent reads a task and decides 'this decomposes into five subtasks.' It returns `[Send('worker', subtask_1), Send('worker', subtask_2), ..., Send('worker', subtask_5)]`. The runtime spawns five parallel worker branches, each handling one subtask, and a reducer merges their outputs back into a single result. This is the LangGraph primitive that maps cleanly to map-reduce semantics in classic parallel processing.

**Send** is the LangGraph primitive for data-dependent parallel fan-out. It is the only one of the listed options that spawns multiple parallel branches at runtime based on what the data looks like. The shape is: a conditional edge function reads the current state, decides how many parallel branches to launch and what payload each should get, and returns a list of `Send` objects. Each `Send` carries (a) the name of the target node and (b) a payload that becomes that branch's input. The LangGraph runtime spawns the branches concurrently, executes them in parallel, and merges their state updates back through the per-key reducers. Why the other primitives do not work for this: - `add_node` registers a single node. Fan-out is about branching at runtime, not declaring nodes. - `add_edge` wires a fixed edge between two nodes. The graph is static; there is no place to express 'N branches where N depends on the data.' - `compile` finalises the graph. It is a build-time operation, not a runtime branching primitive. **Canonical use case**: a planner agent reads a research brief and emits subqueries. Instead of running them sequentially, the conditional edge returns `[Send('search_agent', q) for q in subqueries]`. The runtime fans out, the agents run in parallel, and a reducer (typically `operator.add` on a `results` list) merges their outputs. This is map-reduce for agents, and it is the difference between a 30-second sequential research run and a 6-second parallel one. Send is also the primitive that makes LangGraph genuinely concurrent, not just async. The branches actually execute on separate tasks and can return in any order.

TL;DR

Send is LangGraph's data-dependent fan-out primitive: return a list of Send objects from a conditional edge to spawn N parallel branches with distinct payloads.

Memory aid

Easy to grasp

Imagine a manager who reads a customer request and decides 'this needs three things done at the same time: order the parts, schedule the technician, and email the customer.' The manager writes three separate work orders, hands one to each team, and the teams work in parallel. Later the results come back together for the final report. In LangGraph, the work-order writing is the Send primitive. The manager does not know how many work orders there will be until they read the request - it could be one, three, or ten. Static graph edges cannot do that because the number of branches has to be known when the graph is built. Send decides at runtime, based on the data.

Key concepts

Multi-Agent Systems

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

LangGraph's Send is the primitive that makes the framework genuinely concurrent and not just async-friendly. Most graph orchestrators express static topology: each node has a known set of successors, edges are wired at build time, and execution follows the declared shape. That works for routing problems (pick one of N next nodes) but cannot express fan-out problems (run M parallel branches where M is decided at runtime by the data).

Send fills that gap. A conditional edge function returns a list of Send objects, each carrying a target node name and a payload. The runtime spawns one concurrent branch per Send, runs them in parallel, and merges their outputs back through per-key reducers. The pattern is map-reduce for agents, and it is what enables LangGraph's parallel research, multi-source RAG, and per-item evaluation patterns.

This walkthrough covers the runtime semantics of Send, why static edges cannot substitute, the reducer machinery that makes parallel writes safe, and the production patterns that use the primitive at scale.

Mental model: add_edge is graph wiring at build time. Send is graph wiring at runtime, with one wire per data item.

Why static edges cannot express fan-out

What add_edge and add_conditional_edges actually do

In LangGraph, the static-graph primitives are:

python

graph.add_edge('planner', 'worker')  # always go from planner to worker
graph.add_conditional_edges('planner', router_fn)  # router_fn returns one of N next-node names

Both primitives bind a node to a fixed (or fixed set of) successor. The router function returns one node name. After traversing, the runtime is at exactly one node.

The fan-out problem

Consider: a planner reads a research brief and decomposes it into N subqueries. N is not known at graph-build time; it depends on the brief. You want to run all N subqueries in parallel.

With static edges, you cannot express this. You could declare 10 worker nodes (worker_1 through worker_10) and have the router pick one, but that gives you routing among 10, not parallelism across N.

Why this matters

Without fan-out, parallel work in LangGraph becomes either:

A loop over subqueries calling a worker sequentially (no parallelism).
A custom async function outside the graph (loses observability, state-management, and checkpoint integration).

Neither is acceptable for the workloads that motivated multi-agent: parallel research, parallel evaluation, parallel retrieval. The framework needed a primitive that says 'spawn N branches now, one per data item.'

Send: runtime branch instructions

Reducers: making parallel writes safe

Production patterns and pitfalls

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

LangGraph documentation uses Send for the canonical parallel-research pattern: planner decomposes, search agents run in parallel, synthesis reduces.
Anthropic's research mode in Claude Opus 4.7 uses a Send-style fan-out internally to dispatch parallel web searches for complex queries.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does LangGraph merge results from Send-spawned parallel branches?

Each branch returns a state update; the runtime applies the per-key reducer to merge updates. For a 'results' list, the reducer is typically operator.add (concatenate). For a 'count' integer, it might be sum. For a key with no reducer, last write wins (and parallel writes raise unless you set a reducer).

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Trying to fan out with add_edge or add_conditional_edges alone. Those route to a single next node; Send is the only primitive that returns multiple parallel branches with distinct payloads.

60 second bullets to scan on the way to the call.

What Send returns and how the runtime interprets it
Why add_edge and add_conditional_edges cannot express data-dependent fan-out

Primary sources. Browse if you want the original framing.