# LangGraph: one install line, two release trains, and a Makefile that relocks on every run

> LangGraph is an MIT licensed Python framework for long-running stateful agents, distributed across a libs/ directory with a separate CLI package on its own version line. The repository is generous with examples and terse about the things that decide whether your agent resumes correctly.

**langchain-ai/langgraph** — Build resilient, stateful AI agents and agent workflows.

- Repository: https://github.com/langchain-ai/langgraph
- Website: https://docs.langchain.com/oss/python/langgraph/
- Stars: 42,274 · Forks: 7,155
- Language: Python
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/langchain-ai-langgraph

## The install line is one command, and the framework is deliberately below the abstraction you probably want

Installation is a single line:

```bash
pip install -U langgraph
```

Everything else about the project follows from how it describes itself, which is as a low-level orchestration framework for building stateful agents, not as an agent toolkit. That is why the first tip in the README points somewhere else. If you want agents that can plan, use subagents and work with file systems, the recommendation is Deep Agents, a higher-level package built on LangGraph. The same split exists across languages, with LangGraph.js as the equivalent JS and TS library. The lineage is stated too: LangGraph is inspired by Pregel and Apache Beam, and its public interface draws inspiration from NetworkX. Read that as a design brief. You are getting a graph abstraction with a familiar node and edge vocabulary, and everything above it is something you assemble.

## make all runs lint, format, lock, test, so every default run rewrites your locks

The repository root is a Makefile that fans out over a wildcard of the libs directory:

```makefile
LIBS_DIRS := $(wildcard libs/*)

.PHONY: all
all: lint format lock test
```

Read that dependency list as a fixed pipeline. Lint runs, then format, then lock, then test, every time, with no way to run only the first stage. The lock step is the one to notice, because for each library it shells into the directory and runs:

```makefile
(cd $$dir && uv lock)
```

That is a lockfile write, not a check. A contributor who runs a bare make to lint one file will end up with modified uv.lock files in their working tree, and on a CI machine it means the resolution step is coupled to the lint step. There is a separate lock-upgrade target that runs uv lock --upgrade if you actually want to move versions, which tells you the plain lock target is intended to hold steady rather than chase the index.

## A library with no Makefile of its own is installed but never linted or tested

The install target and the check targets disagree about what counts as a project. Install iterates over every entry in LIBS_DIRS and acts on any directory that has a pyproject.toml:

```makefile
@for dir in $(LIBS_DIRS); do \
    if [ -f $$dir/pyproject.toml ]; then \
        echo "Installing dependencies for $$dir"; \
        uv pip install -e $$dir; \
    fi; \
done
```

Lint, format and test all use a different guard, if [ -f $$dir/Makefile ], and then delegate with $(MAKE) -C $$dir lint. So a package added under libs/ with a pyproject.toml and no Makefile is editable-installed into your environment and then silently skipped by lint, format and test. Nothing warns you, because the loops are shell conditionals, not failures. The consequence lands in review: a new library can look green in CI simply because nothing ever ran against it. If you add a package, check that it has a Makefile, or the coverage you think you have is not there.

## Durable execution is a claim about resuming, and the state store behind it is not named

The headline capability is durable execution: agents that persist through failures, run for extended periods, and automatically resume from exactly where they left off. Paired with human-in-the-loop, where you can inspect and modify agent state at any point during execution, and with memory split into short-term working memory for ongoing reasoning and long-term persistent memory across sessions. The mechanism those claims rest on is a checkpointer, and the README never names one, never lists the available backends, and never says what happens if you have no checkpointer configured. Resume is therefore only as good as the store you wired up yourself. The second gap is sharper. Resuming from exactly where you left off describes graph state, not side effects: if a node already called a payment API or wrote a row before the crash, replaying from the checkpoint does not un-send that call. Nothing in this repository tells you how to make external effects idempotent, and for an agent that takes real actions that is the difference between a durable workflow and a duplicated one.

## The debugging and deployment story points at a different product

Three of the five reasons to use LangGraph are not about the library. Debugging is delegated to LangSmith, which is described as giving visibility with visualization tools that trace execution paths, capture state transitions and provide runtime metrics. Development, debugging and deployment of agents and LLM applications are all pointed at the same place, and deployment means LangSmith Deployment, a purpose-built platform for long-running stateful workflows where you can discover, reuse, configure and share agents across teams, with visual prototyping in LangSmith Studio. The framework itself is MIT licensed and installs from PyPI without an account. What the README does not state is which LangSmith capabilities are free and which sit behind a paid plan, so the tracing that makes a stateful agent debuggable and the hosting that makes it long-running may be where the budget conversation actually happens. Plan for that before you promise an operator a resume button.

## The examples directory reads like a survey of agent research, with no maturity labels

The examples tree is the largest thing in the repository and it is worth reading as a catalogue of architectures rather than as tutorials. Alongside the obvious rag, extraction, chatbots, customer-support and tool-calling directories sit lats, reflexion, rewoo, reflection, self-discover, plan-and-execute, llm-compiler, multi_agent, human_in_the_loop and usaco, plus notebooks named react-agent-from-scratch, react-agent-structured-output, subgraph, and run-id-langsmith. Several of those names are research techniques rather than product patterns, and having react-agent-from-scratch sitting next to the framework that ships a react-agent example makes the point that LangGraph deliberately leaves the loop up to you. There is also a delta-channel-dump example and a chatbot-simulation-evaluation example, which suggests the repository is where evaluation harnesses get built. What is missing is any signal about which examples are current. Nothing in the tree marks an example as maintained, deprecated or research only, so a pattern you copy from reflexion may be older than the API it uses.

## The library is on 1.x while the CLI is still on 0.x with a dev tag

The three most recent releases are three different things. langgraph==1.2.12 shipped on 2026-09-21. langgraph-cli==0.4.32 shipped on 2026-09-23, and a langgraph-cli==0.4.32.dev0 prerelease was published the same day, five hours later. The main branch was pushed on 2026-09-23. Two observations follow. First, the CLI is a separate distribution with its own version line, so pinning langgraph does not pin the tool you deploy with, and a resolved environment can hold a 1.x library beside a 0.x CLI with no constraint tying them. Second, a .dev0 tag reaching the release feed on the same day as the stable 0.4.32 means the feed is not a list of things you should pin uncritically. Check which artifact you actually installed before assuming a version. For a framework whose whole pitch is reproducible long-running state, an unpinned CLI is the most likely source of a graph that behaves differently in production than in your notebook.

## What the README never tells you before you start

Several things a reader would want on the first screen are absent, and each absence costs an hour of searching. No minimum Python version is stated, so the version floor for a 1.x package is something you discover by resolving dependencies. No runtime dependency list appears, only the single pip line, so you cannot see what LangGraph pulls in or what it conflicts with. The README does not mention MCP, does not mention mounting a graph inside a web framework, and does not state any compatibility relationship between langgraph and langgraph-cli. Studio is a link away with no setup steps, so a reader cannot tell from this page whether Studio is local, hosted, or tied to a LangSmith account. Documentation is split across docs.langchain.com, a separate API reference at reference.langchain.com, a quickstart, guides on streaming, memory and persistence and patterns such as branching and subgraphs, a free structured course on LangChain Academy, and a chat endpoint for asking the docs questions. That is a real resource, and it is also an admission that the README is a signpost rather than a manual.

## Conclusion

LangGraph fits teams that want explicit control over agent state, want a human to be able to step into a running graph, and are prepared to own the durability layer themselves. It does not fit a team that wants a batteries-included agent framework on day one, or one that needs a single version number to reason about. Before you build on it, pick a checkpointer and test the resume path against a real failure, pin langgraph and langgraph-cli separately since they version independently, and read the Makefile, because a plain make run rewrites your lock files.

## FAQ

### When should I use LangGraph?

For long-running, stateful workflows and agents where execution must survive failure, where a human needs to inspect or modify state mid-run, or where memory has to persist across sessions. If you want planning, subagents and file systems handled for you, the README points you to Deep Agents instead, which is built on top of LangGraph.

### Is LangGraph paid or free?

The library is MIT licensed and installs with pip install -U langgraph, with no account needed. The debugging and deployment features it recommends are provided by LangSmith and LangSmith Deployment, and the README does not state which parts of those require a paid plan.

### What is the difference between LangChain and LangGraph?

LangGraph is the low-level orchestration framework for stateful agents, built by LangChain Inc, and it can be used without LangChain at all. LangChain is the separate layer of integrations and composable components for LLM application development that LangGraph integrates with.

### How do I install LangGraph in Python?

Run pip install -U langgraph. For JavaScript or TypeScript the equivalent library is LangGraph.js in a separate repository. The README does not state a minimum Python version, so check what your environment resolves to.

### how do I use the langgraph cli

The CLI ships as its own distribution, langgraph-cli, on an independent version line from the langgraph library, and recent tags include 0.4.32 alongside a 0.4.32.dev0 prerelease. The README does not document any CLI subcommands, so that has to come from the documentation site.

## Sources

- [Official documentation](https://docs.langchain.com/oss/python/langgraph/)
- [Official README](https://github.com/langchain-ai/langgraph#readme)
- [Project repository](https://github.com/langchain-ai/langgraph)
- [Release notes](https://github.com/langchain-ai/langgraph/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/langchain-ai-langgraph