PocketFlow: A 100-Line Graph Abstraction for LLM Workflows
Pocket Flow: 100-line LLM framework. Let Agents build Agents!
At a glance
- What is it?
- PocketFlow reduces LLM orchestration to a single 100-line Python file with no dependencies and no vendor wrappers. It is a reasonable fit if you want to own your control flow, and the wrong tool if you expect built-in tools, retrievers or tracing.
- Who is it for?
- Adopt PocketFlow if your team is comfortable writing its own LLM calls, tool dispatch and retry logic, and you want the orchestration layer to be a file you can read in one sitting. Do not adopt it if you need built-in retrievers, provider wrappers, tracing or a hosted control plane, because the README states the project ships none of those.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 51 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem PocketFlow is aimed at
Most LLM application frameworks bundle three separate things: a control-flow abstraction, a catalogue of app-specific helpers such as summarization chains or file readers, and a set of vendor adapters for model and vector-store providers. The README's comparison table counts those layers for LangChain, CrewAI, SmolAgent, LangGraph and AutoGen, and lists PocketFlow's abstraction as Graph with None for both wrapper columns. That is the whole pitch. If you have ever spent an afternoon reading framework source to find out why a retry fired twice, or why a chain re-ordered your messages, the appeal is obvious: the orchestration layer is 100 lines and you can read all of it. The target reader is an engineer who already knows how to call a model API and wants a small, inspectable structure for multi-step and multi-agent flows, not a platform. The repository also points to Typescript, Java, C++, Go, Rust and PHP ports, which suggests the authors treat the graph abstraction as the portable part and the Python file as one implementation of it.
What the 100 lines actually contain
According to the README, the framework's core abstraction is a graph, and the 100 lines in pocketflow/__init__.py are where that abstraction lives. The documentation describes design patterns layered on top of it: Agent, Multi-Agent, Workflow and RAG, each written as a tutorial rather than shipped as a library component. That distinction matters more than the line count. PocketFlow is not a runtime that executes your agents for you in a managed process; it is a set of base classes and a traversal rule that you subclass. The movement of data is therefore something you define: a node receives the shared state, does its work, and returns a signal that selects the next edge. Because the README lists no app-specific or vendor-specific wrappers, any model call, tool invocation, embedding lookup or persistence step inside a node is code you write and own. The upside is that there is no hidden retry policy, no implicit prompt template and no adapter layer between your function and the provider's SDK. The cost is that every one of those behaviours is now your responsibility, including the parts that are tedious to get right.
Installing and starting a flow
The README gives two installation routes. The first is pip install pocketflow. The second is to copy pocketflow/__init__.py directly into your project, which the README presents as a legitimate option because the file is only 100 lines. That second route is the more interesting one: vendoring the file removes the dependency from your manifest entirely and makes upgrades a manual diff rather than a resolver decision. The README does not spell out a minimal code example in the excerpt available here, so the concrete starting points are the cookbook directories it links: pocketflow-chat for a chatbot with conversation history, pocketflow-structured-output for extracting structured data from resumes by prompting, pocketflow-workflow for a writing pipeline that outlines, writes and applies styling, and pocketflow-agent for a research agent. Each is labelled by difficulty in the README's table, with chat, structured output, workflow and agent marked at the lowest tier. The accompanying documentation site at the-pocket.github.io/PocketFlow covers the design patterns, and the README also links a video tutorial. If you want to evaluate the framework before installing anything, reading the single source file is a realistic substitute for a trial run.
The dependency-free design is also the boundary
Zero dependencies is a real property with a real cost. Nothing in the described package gives you a retriever, a document loader, a token counter, a provider client, a cache, a tracer or a persistence layer. LangGraph, by contrast, is listed in the README's table with wrappers such as PostgresStore and SqliteSaver, which means checkpointing and durable state are part of that project's surface rather than something you add. With PocketFlow, resuming a long-running flow after a crash is a feature you would build on top of the shared state your nodes pass around. The same applies to observability: if you need a trace view of a multi-agent run, you either instrument your own nodes or accept print statements. There is a second boundary that is easy to miss. The README's comparison table lists line counts and package sizes for competing frameworks, but those numbers are the project's own framing, and size is not the same as fit. A team that needs a maintained catalogue of tool integrations will find PocketFlow's absence of wrappers to be the problem, not the feature. The framework assumes you already know which model you are calling and how.
Release history and what it says about stability
The repository shows a single release, v0.0.0, dated 2025-03-25. The last push is later, in July 2026, so the code is being touched, but there is no published train of versioned releases to read. For a 100-line file that may be fine: the surface is small enough that a breaking change is visible in a diff. It also means you have no changelog to consult when deciding whether to take an update. If you vendor the file, as the README permits, this concern mostly evaporates, because you decide when to re-copy it. If you install from PyPI, you are trusting that the version you pinned stays available and behaves the same, and the release list gives you little to reason about. The README's own framing, that the core is 100 lines and the patterns are tutorials, suggests the authors expect users to read the source rather than track versions. Treat that as the intended contract and plan accordingly.
Where a graph framework is the wrong choice
If your application is a single prompt with a fixed response format, PocketFlow adds a graph you do not need. The structured-output cookbook exists precisely because prompting alone can handle extraction, and the README labels it as a beginner example rather than a framework showcase. Similarly, if your team wants a managed execution environment with retries, queues and a dashboard, the framework's design works against you: there is no scheduler here, and the README lists no vendor wrappers, so every integration is yours to write. The harder case is a team that has already standardised on a provider-specific SDK and wants thin helpers around it. PocketFlow will not shorten that code; it will sit above it and require you to express the same logic as nodes and edges. The framework earns its place when the control flow itself is the complicated part, meaning branching, loops, multiple agents handing work to each other, or a pipeline whose steps need to be reordered without rewriting the whole script. Outside that, it is structure for its own sake.
How it differs from LangGraph and CrewAI
The README positions PocketFlow against LangGraph, CrewAI, AutoGen, SmolAgent and LangChain using a table of abstraction type, wrapper counts, lines and package size. The meaningful difference is not the size column. LangGraph is listed with Agent and Graph abstractions plus some app and vendor wrappers, which means it ships state stores such as PostgresStore and SqliteSaver alongside the graph model. CrewAI is listed with Agent and Chain abstractions and many app-specific tools such as FileReadTool and SerperDevTool. PocketFlow's column reads Graph with None and None. So the choice is between a graph primitive you extend with your own code and a graph primitive plus a pre-built ecosystem you configure. Neither is strictly better. If you want to reach for a tool integration and have it work, the wrapper-heavy projects save time. If you want to know exactly what happens between two nodes, and you are willing to write the ten lines that make it happen, PocketFlow's 100-line core is the smaller thing to reason about. The README's own framing, that the core abstraction is the graph and the patterns are built on top, is consistent with that reading.
Licence and the cost of keeping it current
PocketFlow is MIT licensed, which the README states in its badge line and which the repository metadata confirms. That permits commercial use and modification, but this is a description of the licence, not legal advice; check the LICENSE file in the repository for the operative text before relying on it. The maintenance cost is unusually low by design. There are no dependencies to patch, no transitive tree to audit, and the README explicitly offers copying the source file as an alternative to installing the package. If you vendor it, your upgrade path is a diff against a 100-line file, and you can defer that indefinitely. If you install it, you inherit whatever release cadence the project settles into, and the release list currently shows only v0.0.0. The larger ongoing cost is not the framework but the code around it: model calls, tool dispatch, error handling and state persistence all live in your nodes, so your maintenance burden scales with how much of that you build. PocketFlow does not reduce that work. It only decides who owns it.
Editorial conclusion
Adopt PocketFlow if your team is comfortable writing its own LLM calls, tool dispatch and retry logic, and you want the orchestration layer to be a file you can read in one sitting. Do not adopt it if you need built-in retrievers, provider wrappers, tracing or a hosted control plane, because the README states the project ships none of those. Before committing, open pocketflow/__init__.py and confirm that the node, flow and shared-store primitives match how you already think about your pipeline, and check the release list: the only tag shown is v0.0.0 from March 2025, so treat versioning and API stability as unproven until you see how the repository handles changes.
Community notes