State Machines & Execution Graphs

The one-page revision copy

Dense, hand-copyable. Fully derivable from the detailed notes below.

The full lesson

A frustrated customer writes: "My payment was deducted twice but my subscription still shows inactive. Fix it now or I'm disputing with my bank." That single message is three problems wearing one coat — a billing bug, a broken account state, and an escalation threat. A traditional pipeline classifies it once, routes it once, answers once, and gets it wrong. It has no way to notice its own mistake and try again. The gap between that pipeline and a system that could actually handle the message is the entire subject of this lesson.

Where we left off — the Phase Dos project

Before the theory, a recap of the working system this lesson extends. Phase Dos is a RAG pipeline that decides whether a content creator is safe to hire for a brand deal. It pulls from three data sources at once, reasons over them, and returns a verdict.

Think of it as a background-check firm for influencers. One clerk reads the numbers, one reads the gossip, one maps who's connected to whom, and a senior analyst reads all three reports before signing off.

The retrieval layer, rag_engine.py, exposes one query function per store and fires all three in parallel with a thread pool. The compiler.py layer wraps a DSPy signature — a "brutal PR risk analyst" — in ChainOfThought reasoning, then uses BootstrapFewShot to auto-generate few-shot demonstrations from a golden set of 30 examples (15 clean, 10 messy, 5 edge cases). The verdict is JSON: a HIRE/FIRE call plus a cancel velocity from 0 (untouchable saint) to 10 (already cancelled, just not announced).

What a DAG actually is

A DAG (Directed Acyclic Graph) is a one-way, no-loops, run-once flowchart of work. If you've built an Airflow pipeline, you've built a DAG. The name encodes three mathematical guarantees, and each one that makes DAGs great for data pipelines is exactly what makes them useless for agents.

The three places a DAG collapses

Three concrete failure modes show why agents need more than a pipeline. Each one is architectural — no amount of prompt engineering fixes it, because the capability simply doesn't exist in the shape of a DAG.

1 · Multi-step reasoning chains

Ask a financial agent: "Is Q4 cash strong enough for the proposed acquisition?" It must fetch the balance sheet, fetch the acquisition cost, reason about the two, then check outstanding liabilities. If at step 4 it discovers the liability data is incomplete, a DAG has no path back to step 1 to fetch it. It either fails outright or answers confidently on incomplete data.

2 · Multi-turn conversations

The agent asks "What error do you see?" The user replies "authentication failed on login." A DAG processes each message in isolation — when the second arrives, it has no memory of asking the first. It gives a generic answer about auth errors, having forgotten it was mid-diagnosis. This is statelessness, and for chatbots it's not an inconvenience, it's a disqualifier.

3 · Self-correction & error recovery

The LLM emits almost-valid JSON with a trailing comma. The parser node crashes and the user sees an error. A well-built agent instead writes a parse_error field to state; a conditional edge reads it, routes back to the LLM with the malformed text and a "fix the formatting" instruction, then re-parses. The user sees a slight delay, not a failure.

DAG vs state machine — the same ticket, two shapes

Put the two side by side on the customer-service example. In the DAG, the request flows input → classify → respond → output, each box firing once. In a state machine, the graph can loop: classify, validate, and if the output is bad, retry — routing back to classification; if it can't be solved, escalate to a human.

LangGraph vs LangChain — different jobs, different layers

LangChain is a component library; LangGraph is an orchestration layer. They operate at different levels of abstraction, and the most common mistake newcomers make is conflating them — reaching for one when the job needs the other.

LangChain gives you the atomic pieces: prompt templates that format messages, LLM wrappers that handle API calls, output parsers that turn raw text into structured data, retrievers that query vector stores. It's exceptional at the atomic level. LangGraph solves a different problem: how do I coordinate many LLM calls, tool invocations, and lookups over time — with memory, and with the ability to loop or branch?

The three pillars — State, Nodes, Edges

Every LangGraph system — from a two-node toy to a multi-agent production graph with human-in-the-loop checkpoints — is built from exactly three primitives. Master these and you can design any agentic system.

State — the memory layer

State is a typed dictionary that holds all data shared across every node in the graph. Its engineering analogy is RAM in a running process: every function reads from it and writes back to it. A poorly designed state schema corrupts the agent's memory and causes silent failures; a well-designed one makes behavior transparent and predictable.

from typing import TypedDict, Literal, Annotated
from operator import add

class TicketState(TypedDict):
    query: str
    category: Literal["billing", "technical", "escalation"]  # not bare str
    retry_count: int                        # overwrite reducer
    messages: Annotated[list, add]          # append reducer

Three principles for a good state schema:

Nodes — the workers

A node is a Python function that takes the current state, does one computation, and returns a partial dictionary of only the keys it changed. The computation can be an LLM call, a DB query, an API call, or pure logic. The contract has three parts:

1. Accepts exactly one argument — the current state. No extra args, no global variables, no external mutable state. Whatever's in state is all it knows about the world.
2. Performs its computation — it has full read access to every field in the state it received.
3. Returns a partial dict — only the changed keys, not the whole modified state. LangGraph merges it in; untouched keys keep their values.

def classify(state: TicketState) -> dict:
    result = llm.invoke(state["query"])     # a LangChain op, inside a node
    return {"category": result.category}    # only the changed key

Edges — the wiring

Edges connect nodes. There are two kinds, and the second is where an agent's intelligence lives.

def route_by_category(state: TicketState) -> str:
    return state["category"]   # returns a node NAME, not state

builder.add_edge("classify", "log")            # standard: always
builder.add_conditional_edges(                 # conditional: depends
    "log", route_by_category,
    {"billing": "billing_node", "technical": "tech_node"},
)

The execution cycle — from invoke to END

Understanding what happens between graph.invoke(state) and the final returned state is essential for debugging. The loop is the same every time.

1. graph.invoke(initial_state) — LangGraph validates the input against the TypedDict schema. A missing or wrong-typed key raises an error before any node runs. This is the first line of defense.
2. Execution begins at the entry point; LangGraph passes the full current state to the node.
3. The node runs and returns a partial dict.
4. LangGraph merges the returned dict into the global state, applying each field's reducer (overwrite or append).
5. It evaluates the outgoing edge — a standard edge goes to the fixed next node; a conditional edge calls the router and uses its returned string to look up the next node.
6. Repeat until execution reaches the END sentinel.

Reducers — overwrite vs append

A reducer is the rule for how a node's returned value merges into the existing state. Every field has one, and picking the wrong one corrupts the agent's memory in ways that are painful to diagnose.

def chat_node(state: TicketState) -> dict:
    trimmed = state["messages"][-20:]        # keep last ~10 exchanges
    reply = llm.invoke(trimmed + [user_msg])
    return {"messages": [user_msg, reply]}   # append reducer adds these

Cycles — the core innovation

A cycle is a path in the graph that leads back to an already-visited node. Forbidden in a DAG, this is exactly what LangGraph adds — and it enables three things a pipeline can't do.

The most common cycle is the reasoning loop: the LLM proposes an action, a validator evaluates it, and the validator either approves the output or — once a max_retry count is hit — routes to an escalation or fallback node.

Interview & practice questions

Read each answer aloud in a couple of sentences.

Key takeaways

• DAG = script, agent = decision system. The pipeline picks its path at build time; the agent picks it at runtime.
• DAGs collapse in three ways — multi-step reasoning that needs missing data, stateless multi-turn conversations, and unrecoverable self-correction. All three are architectural, not fixable by prompting.
• LangChain is components; LangGraph is orchestration. LangChain ops live inside LangGraph nodes.
• Three pillars: State (shared TypedDict memory), Nodes (partial-return functions), Edges (standard = fixed, conditional = runtime routing).
• TypedDict is non-negotiable — it converts silent, days-long typo bugs into instant KeyErrors.
• Reducers: overwrite for single values, append for accumulating lists; trim memory to avoid state explosion.
• Cycles are the innovation — iteration, feedback, self-correction — always bounded by max_retries.