63 packages give Python agents explicit control flow
Our measured install for libs/cli added 63 packages and used 84 MB, a modest footprint for one part of a much larger agent project. LangGraph's core idea is plain: keep agent state in a defined object, connect operations as nodes, and make transitions visible. That structure helps when an agent must stop for approval, retry a step, branch on a result, or resume after a process interruption. A normal chat loop can do some of this, but its control rules tend to scatter across prompts and callbacks.
LangGraph is intentionally low level. The project overview calls out durable execution, human interrupts, memory, and state inspection rather than a ready-made agent personality. You decide what state means, which nodes may run, how updates merge, and where checkpoints live. That is useful authority for a product team. It is extra design work for someone who only wants a model to call two tools, which is why the README directs quick-start users toward the higher-level Deep Agents package.
What happened when we ran it
In our 3 CPU, 8 GB container, the libs/cli project installed successfully in 30 seconds. It placed 63 packages and 84 MB in the environment, then completed its build in 7 seconds. The checkout held 672 files and about 188,148 lines of source across the repository. We also found 17 CI workflow files and a tests directory, though no Dockerfile. pip-audit reported 0 known vulnerabilities for the environment we measured.
Pytest did not execute the suite. After 10 seconds it collected 341 items, then exited with code 4 because asyncio_mode was an unknown configuration option. The log reports 0 passed and 0 failed out of 0 because execution never started. That result does not show whether the 341 collected tests would pass, and it does not show why the option was unavailable. It shows that the checked-out CLI project's test configuration did not run cleanly in our fresh Python 3.12 environment.
Durable execution is useful only with a defined checkpoint policy
LangGraph 1.2.x is designed around resumable work, but installing the library does not choose persistence semantics for your application. Teams still select a checkpointer, decide which state can be serialized, and define how external side effects behave when a node is retried. A payment call or email send cannot safely repeat just because graph state rolled back. The framework gives you an execution model and interruption points. Your application still owns idempotency, credentials, retention, and failure policy.
An open durability issue, updated on August 25, 2026, reports host-dependent replay versus re-execution ordering for one durability="sync" crash path. One report does not invalidate the framework, but it is directly relevant to teams choosing LangGraph for recovery. Write crash tests around every node with an external effect, and verify behavior with the same checkpointer and host arrangement used in production. The 0 executed tests in our CLI run give us no independent reassurance on that point.
Human interrupts are the clearest reason to choose it
The README makes human inspection and state modification a first-class operation. That fits approval-heavy agents better than bolting a yes-or-no prompt onto an opaque loop. A graph can pause before a risky node, expose the pending state, accept an edit, and continue from a checkpoint. The design also makes the approval location visible in code. For support automation, research workflows, or internal tools that touch customer data, this can be more important than how quickly the first demo answers.
That control comes with schema work. State fields need merge rules, interrupts need an interface, and the team must decide what a reviewer is allowed to change. LangGraph does not remove those product questions. It gives them named places. The current repository has about 188,148 lines of source and 722 open issues and pull requests combined, which reflects both its wide scope and the amount of behavior users discuss. Read the relevant guides and pin the packages that implement your checkpoint path.
Python is primary and deployment is a separate choice
The repository's primary language is Python, and our build used Python 3.12. JavaScript and TypeScript users are pointed to langchain-ai/langgraphjs, a separate codebase with its own releases and behavior. LangGraph itself can be used without LangChain, which keeps the core orchestration choice open. Model clients, vector stores, and tools remain application decisions. That separation is healthy, though examples across the wider LangChain ecosystem can make the boundaries feel less obvious than the core package really is.
Visual tracing and managed deployment are also separate decisions. The README recommends LangSmith for debugging, evaluations, and hosted agent deployment. Teams can use the MIT library without buying those services, but then they must supply their own tracing, runtime, scaling, and operational interface. The latest repository release was SDK 0.4.3 on August 19, while the release notes also referenced LangGraph 1.2.11. Pin by package, not merely by repository tag name.
40,440 stars come with an active queue
GitHub showed 40,440 stars, a last push on August 25, 2026, and 722 open issues and pull requests combined. Recent issue updates covered state updates, stream errors, and crash recovery, while SDK 0.4.3 had shipped 6 days earlier. Those signals show active maintenance and active complexity. The combined count should not be described as 722 bugs because GitHub includes pull requests, and feature requests also share the queue.
Choose LangGraph when your design already contains words such as checkpoint, interrupt, resume, or state transition. Its 7-second CLI build and 84 MB environment make source inspection approachable, while the failed test startup means you should reproduce the suite before changing the package. Pydantic AI is a cleaner fit for typed agent calls, AutoGen for conversational agent systems, and Prefect for non-agent jobs. LangGraph earns the extra graph design when recovery and human control are product requirements.