---
name: langgraph-fundamentals
description: "INVOKE THIS SKILL when writing ANY LangGraph code. Covers StateGraph, state schemas, nodes, edges, Command, Send, invoke, streaming, and error handling."
---
<overview>
LangGraph models agent workflows as **directed graphs**:
- **StateGraph**: Main class for building stateful graphs
- **Nodes**: Functions that perform work and update state
- **Edges**: Define execution order (static or conditional)
- **START/END**: Special nodes marking entry and exit points
- **State with Reducers**: Control how state updates are merged
Graphs must be `compile()`d before execution.
</overview>
<design-methodology>
### Designing a LangGraph application
Follow these 5 steps when building a new graph:
1. **Map out discrete steps** — sketch a flowchart of your workflow. Each step becomes a node.
2. **Identify what each step does** — categorize nodes: LLM step, data step, action step, or user input step. For each, determine static context (prompt), dynamic context (from state), retry strategy, and desired outcome.
3. **Design your state** — state is shared memory for all nodes. Store raw data, format prompts on-demand inside nodes.
4. **Build your nodes** — implement each step as a function that takes state and returns partial updates.
5. **Wire it together** — connect nodes with edges, add conditional routing, compile with a checkpointer if needed.
</design-methodology>
<when-to-use-langgraph>
| Use LangGraph When | Use Alternatives When |
|-------------------|----------------------|
| Need fine-grained control over agent orchestration | Quick prototyping → LangChain agents |
| Building complex workflows with branching/loops | Simple stateless workflows → LangChain direct |
| Require human-in-the-loop, persistence | Batteries-included features → Deep Agents |
</when-to-use-langgraph>
---
## State Management
<state-update-strategies>
| Need | Solution | Example |
|------|----------|---------|
| Overwrite value | No reducer (default) | Simple fields like counters |
| Append to list | Reducer (operator.add / concat) | Message history, logs |
| Custom logic | Custom reducer function | Complex merging |
</state-update-strategies>
---
## Nodes
<node-function-signatures>
Node functions return partial state updates. Signatures for configuration and runtime access differ by language; use the applicable implementation reference.
</node-function-signatures>
---
## Edges
<edge-type-selection>
| Need | Edge Type | When to Use |
|------|-----------|-------------|
| Always go to same node | `add_edge()` | Fixed, deterministic flow |
| Route based on state | `add_conditional_edges()` | Dynamic branching |
| Update state AND route | `Command` | Combine logic in single node |
| Fan-out to multiple nodes | `Send` | Parallel processing with dynamic inputs |
</edge-type-selection>
---
## Command
Command combines state updates and routing in a single return value. Fields:
- **`update`**: State updates to apply (like returning a dict from a node)
- **`goto`**: Node name(s) to navigate to next
- **`resume`**: Value to resume after `interrupt()` — see human-in-the-loop skill
<command-return-type-annotations>
**Python**: Use `Command[Literal["node_a", "node_b"]]` as the return type annotation to declare valid goto destinations.
**TypeScript**: Pass `{ ends: ["node_a", "node_b"] }` as the third argument to `addNode` to declare valid goto destinations.
</command-return-type-annotations>
<warning-command-static-edges>
**Warning**: `Command` only adds **dynamic** edges — static edges defined with `add_edge` / `addEdge` still execute. If `node_a` returns `Command(goto="node_c")` and you also have `graph.add_edge("node_a", "node_b")`, **both** `node_b` and `node_c` will run.
</warning-command-static-edges>
---
## Send API
Fan-out with `Send`: return `[Send("worker", {...})]` from a conditional edge to spawn parallel workers. Requires a reducer on the results field.
---
## Running Graphs: Invoke and Stream
<invoke-basics>
Call `graph.invoke(input, config)` to run a graph to completion and return the final state.
</invoke-basics>
<stream-mode-selection>
| Mode | What it Streams | Use Case |
|------|----------------|----------|
| `values` | Full state after each step | Monitor complete state |
| `updates` | State deltas | Track incremental updates |
| `messages` | LLM tokens + metadata | Chat UIs |
| `custom` | User-defined data | Progress indicators |
</stream-mode-selection>
---
## Error Handling
Match the error type to the right handler:
<error-handling-table>
| Error Type | Who Fixes | Strategy | Example |
|---|---|---|---|
| Transient (network, rate limits) | System | `RetryPolicy(max_attempts=3)` | `add_node(..., retry_policy=...)` |
| LLM-recoverable (tool failures) | LLM | `ToolNode(tools, handle_tool_errors=True)` | Error returned as ToolMessage |
| User-fixable (missing info) | Human | `interrupt({"message": ...})` | Collect missing data (see HITL skill) |
| Unexpected | Developer | Let bubble up | `raise` |
</error-handling-table>
---
## Core boundaries
- Return partial state updates from nodes instead of mutating state directly.
- Route loops through a named node; `START` is entry-only.
- Define reducers for accumulated list fields; otherwise, the last write wins.
- Account for static edges when using `Command` with `goto`, because both routes execute.
## Implementation references
If writing, modifying, or debugging LangGraph code, determine the project's language from its existing files, then read the applicable reference before implementing:
- For Python, read [references/python.md](references/python.md).
- For TypeScript, read [references/typescript.md](references/typescript.md).
Read both only when the task covers both languages. For conceptual questions that require no code, do not load either reference.