What Frameworks Actually Buy You

Every framework is selling you the same list of things — and you have personally implemented all of them from raw SDK calls. That changes how you read the marketing. The question is never "can LangGraph do X?" but "is LangGraph's X better than the 40 lines I'd write myself, and what do I give up in debuggability to get it?" Frameworks are a trade: less plumbing code for more abstraction between you and the API calls. Sometimes that trade is excellent. Sometimes you spend a day discovering that a retry you didn't know existed was silently re-running a non-idempotent tool.

The LangGraph mental model

A LangGraph program is a directed graph. Nodes are plain Python functions that receive the current state and return a partial update. Edges say which node runs next — fixed edges always go the same way; conditional edges call a routing function that inspects state and picks a destination. A state schema (a TypedDict or Pydantic model) is the contract every node shares. You build the graph, compile() it, then invoke() or stream() it like any callable. Under the hood it's still the loop you wrote in Module 1 — call model, act, update state, decide what's next — but the control flow is now declared as data instead of buried in if-statements.

# Colab cell 1 — run once. No API key needed: the nodes are stubbed, so
# the whole graph runs on LangGraph's machinery alone.
!pip install -q langgraph

from typing import TypedDict

from langgraph.graph import StateGraph, START, END


class State(TypedDict):
    question: str
    draft: str
    approved: bool


def write_draft(state: State) -> dict:
    # call your model here (Module 1 skills); stubbed for clarity.
    # in real code: model = init_chat_model("anthropic:claude-sonnet-5")
    # or:           model = init_chat_model("openai:gpt-5.5")  # one-string swap
    return {"draft": f"Draft answer to: {state['question']}"}


def review(state: State) -> dict:
    return {"approved": len(state["draft"]) > 10}


builder = StateGraph(State)
builder.add_node("write_draft", write_draft)
builder.add_node("review", review)
builder.add_edge(START, "write_draft")
builder.add_edge("write_draft", "review")
builder.add_edge("review", END)

graph = builder.compile()
result = graph.invoke({"question": "What is a checkpointer?"})
print(result["draft"], result["approved"])

# Colab cell 2 — run cell 1 first (it defines graph).
# stream_mode="updates" yields each node's state delta as it executes —
# this is your first inter-agent trace, for free.
for step in graph.stream({"question": "What is a checkpointer?"},
                         stream_mode="updates"):
    print(step)

# {'write_draft': {'draft': 'Draft answer to: What is a checkpointer?'}}
# {'review': {'approved': True}}

# stream_mode="values" yields the FULL state after each step instead,
# which is handier when you want to inspect accumulated fields.

The abstraction tax, itemized

"Framework tax" isn't one cost — it's four, and a senior engineer names them individually instead of waving at "complexity." Debugging through layers: a bug can live in your node, in LangGraph's execution engine, or in the interaction between them, and the stack trace rarely tells you which. Prompt opacity: helper methods like structured-output wrappers or message-formatting utilities can append instructions, retries, or reformatting you never wrote — and you can't fix what you can't see the model receiving. If you can't produce the exact string of text and images sent to the API for a given call, you are debugging blind. Lock-in: your state schema, node signatures, and checkpoint format are now shaped by the framework's conventions; migrating off later means rewriting the graph, not just swapping an import. Version churn: the fan-out dispatch API and the interrupt API you'll use in this module have both changed shape across LangGraph versions — code from a six-month-old tutorial may not compile against your installed version.

Whiteboard drills