How to document a LangGraph project

A LangGraph application is a graph defined in code. Documenting it means reading that definition carefully.

LangGraph is a Python library for building stateful, multi-step applications, often with language models, as a graph of functions. The good news for anyone documenting one is that the structure of the application is declared in a few places. The work is finding them and writing down only what they say.

1. Find where the graph is built

Search for StateGraph. The file that constructs it is the centre of the project. Often a function such as build_graph() creates the graph, adds nodes and edges, and calls compile(). Note where the compiled graph is used: a web handler, a command-line entry point or a worker. That tells you what starts a run.

If you find more than one StateGraph, you have subgraphs or several workflows. Document each one separately and say how they connect.

2. Read the state schema

The first argument to StateGraph is the state: usually a TypedDict, a dataclass or a Pydantic model. Each field is something nodes read or write. List them with a sentence each.

Look for reducers. A field annotated with Annotated[list, operator.add], for example, is merged across parallel branches instead of overwritten. This is easy to miss and it changes behaviour, so write it down. Also note what is deliberately kept out of the state, such as database handles or clients passed in through a runtime context, because the state is what gets saved at checkpoints.

3. List the nodes

Each call to add_node registers a function under a name. For each node write what it reads from the state, what it returns, and any side effects such as model calls, tool calls or database writes. Check whether the function is wrapped, for example for tracing, since the registered name and the function name may differ.

4. Trace the edges

Calls to add_edge give fixed transitions. add_conditional_edges takes a routing function that returns the next node, so read that function to learn the conditions. START and END mark where a run begins and finishes. A node that returns Send objects fans out into parallel branches, one per item, which you should document as a fan-out with its fan-in point.

Draw this as a flowchart. It is the most useful single diagram of a LangGraph project, and you can build it directly from the edges.

5. Find interrupts and human steps

Search for interrupt(. A call to it pauses the graph and hands a value to the caller, and the run continues when the caller resumes it with a response. Each one is a place where a person or another system decides something. For each interrupt, document what is shown, who answers, and what happens for each answer. Also note how the caller resumes: through a Command with a resume value or through a similar mechanism.

6. Document checkpoints and persistence

Look at what is passed to compile(checkpointer=...). In-memory savers lose state on restart; database-backed savers do not. The checkpointer, together with a thread identifier, is what makes a paused or crashed run resumable. Write down which saver is used in development and which in production, what identifies a run, and what state is saved after each step.

7. Verify every claim

Documentation about a graph goes wrong in small, specific ways: a node that was renamed, an edge removed, an interrupt moved. For each statement you write, find the line that supports it.

A node exists: search for the add_node call with that exact name.
An edge exists: find the add_edge or the routing function that can return it.
A field is in the state: find it in the schema class.
A step pauses for approval: find the interrupt( call, and the code that resumes it.

Keep citations to files and line numbers in your notes. If the code changes, the citation tells you which paragraph to recheck.

Where RepoLantern helps

RepoLantern, an application that is itself built as a LangGraph graph, reads a repository at one commit and writes a guide to it with architecture and data-flow diagrams. It looks up every file, function and class name the guide mentions in the real code, links claims to exact lines and lists names it could not find. For a LangGraph project this gives you a first draft of the node list and the flow to check against the steps above. It does not execute the graph, so conditions that depend on runtime values still need your reading.

See how it works, how a guide is checked and the documentation.