PocketFlow: The 100-Line LLM Framework Changing How Engineers Build AI Agents in 2026

Table of Contents

• What Is PocketFlow?
• Why It Was Built: The Problem With LangChain
• Core Architecture: How PocketFlow Actually Works
  • Nodes
  • Flows
  • Shared Store
  • Actions
• Key Design Patterns PocketFlow Supports
• Agentic Coding: AI Agents Building AI Agents
• PocketFlow vs. LangChain vs. CrewAI: A Direct Comparison
• When to Use PocketFlow — and When Not To
• Getting Started: Practical First Steps
• FAQs
• Conclusion

What Is PocketFlow?

PocketFlow is a minimalist Python framework for building LLM-powered applications and AI agents. Its entire core abstraction fits in roughly 100 lines of code — and that is a design constraint, not a marketing claim.

Created by Zachary Huang and hosted at github.com/the-pocket/PocketFlow, the project has crossed 10,300 GitHub stars in 2026. The attention is warranted. Most LLM frameworks have grown bloated, opaque, and genuinely painful to debug in production. PocketFlow pushes back against that directly.

The pitch is straightforward: give developers the smallest possible surface area that still handles the patterns they actually need — agents, RAG pipelines, batch processing, async workflows, parallel execution — without burying the mechanics under layers of abstraction.

If you have spent time fighting LangChain’s internals or trying to trace why a CrewAI agent made a particular decision, PocketFlow’s philosophy will feel immediately familiar.

Why It Was Built: The Problem With LangChain

LangChain started as a useful toolkit. By the time most teams hit production, it had become something else: a sprawling dependency tree, inconsistent APIs across versions, and a debugging experience that required reading framework source code more than your own.

The frustrations are well-documented across engineering forums and GitHub issues. Teams report spending more time understanding what LangChain is doing than building actual product logic. Prompt chains become hard to inspect. State management is implicit. When something breaks in a multi-step agent, isolating the failure means navigating abstractions you did not write and did not choose.

CrewAI addressed some of this by focusing on multi-agent orchestration, but it brought its own opinions about roles, tasks, and crew structures — opinions that do not always map cleanly to what you are actually building.

Zachary Huang’s starting point for PocketFlow was a direct response to this pattern: what is the minimum viable abstraction that lets an engineer build any LLM workflow without the framework getting in the way? The answer was a graph-based execution model with a shared data store, expressed in approximately 100 lines of Python.

Core Architecture: How PocketFlow Actually Works

PocketFlow has four components: Nodes, Flows, a Shared Store, and Actions. Understand those four things and you understand the entire framework.

Nodes

A Node is a unit of work. It runs a function — typically an LLM call, a tool invocation, or a data transformation — and returns an action string that determines what happens next.

Each Node has three lifecycle methods:

• prep(shared) — reads from the shared store and prepares inputs
• exec(prep_result) — runs the main logic, usually the LLM call or tool
• post(shared, prep_result, exec_result) — writes results back to the shared store and returns an action

The separation is intentional. It keeps side effects predictable and makes each step independently testable. You can unit test exec in isolation without running the full pipeline.

Flows

A Flow connects Nodes into a directed graph. You define transitions between nodes based on the action strings returned by each Node’s post method. The Flow handles traversal — it calls each Node in sequence, follows the returned action to the next Node, and continues until it reaches a terminal state.

This is where the graph model earns its keep. Branching, looping, and conditional routing are expressed as graph edges, not as nested Python control flow buried inside framework callbacks.

Shared Store

The Shared Store is a plain Python dictionary passed through every Node in a Flow. It holds all state: inputs, intermediate results, tool outputs, conversation history, final outputs — everything.

There is nothing magical about it. Every Node reads from and writes to the same dictionary, which means state is completely transparent at every step. That matters a lot when you are debugging a multi-step agent at 2am.

Actions

Actions are strings returned by a Node’s post method. They tell the Flow which Node to execute next. A Node might return "success", "retry", "clarify", or any string you define. The Flow maps those strings to the next Node in the graph.

This gives you explicit control over routing without a separate routing layer or a dedicated “router” agent.

Key Design Patterns PocketFlow Supports

PocketFlow’s documentation covers several patterns that handle the majority of production LLM use cases. Each one is implemented as a composition of Nodes and Flows — not a separate module bolted on.

Agent pattern. A Node calls an LLM, parses a tool-use decision, executes the tool, and loops back to the LLM with the result. The loop continues until the LLM signals completion. Because the loop is expressed as graph edges, every iteration is inspectable.

RAG (Retrieval-Augmented Generation). One Node retrieves relevant documents from a vector store. A second constructs a prompt with those documents and calls the LLM. The Shared Store holds both the retrieved context and the final response. Extending it with re-ranking or multi-hop retrieval is straightforward.

Batch processing. A BatchNode runs the same logic across a list of inputs, sequentially or in parallel. Useful for document processing pipelines, bulk classification, or any workload where you apply the same LLM operation to many items.

Async execution. AsyncNode and AsyncFlow variants support non-blocking execution for running multiple LLM calls concurrently without blocking the event loop.

Parallel execution. ParallelBatchNode runs batch items concurrently using async. For latency-sensitive pipelines where independent subtasks can run simultaneously, this cuts total wall-clock time significantly.

Workflow pattern. A structured sequence of Nodes where each step depends on the previous output. Useful for multi-step reasoning, document generation, or any pipeline where order and data flow matter.

All of these patterns compose. You can build a multi-agent system where each agent is a Flow and a parent Flow orchestrates them — all within the same 100-line core.

Agentic Coding: AI Agents Building AI Agents

One of the more interesting applications of PocketFlow is what Huang calls “agentic coding” — using AI agents to write, test, and iterate on code, including the code for other AI agents.

The PocketFlow-Tutorial-Codebase-Knowledge project demonstrates this concretely. It is a pipeline that takes a GitHub repository as input, analyzes the codebase, identifies the most important abstractions, and generates a structured tutorial explaining how the code works. The pipeline itself is built with PocketFlow.

This matters for a couple of reasons. First, it shows that PocketFlow’s architecture is expressive enough to handle complex, multi-step reasoning without requiring framework extensions. Second, it points to a practical workflow for teams that want to use LLMs to accelerate their own development — not just as a product feature, but as a tool inside the development process itself.

For teams building production AI agents, the implication is real. If your agents can help write and test the next version of themselves, iteration speed changes substantially. PocketFlow’s transparency makes this safer: because every step is inspectable, you can verify what the agent produced before it runs in production.

PocketFlow vs. LangChain vs. CrewAI: A Direct Comparison

The honest summary: LangChain gives you the most pre-built integrations, but you pay for them in complexity and opacity. CrewAI is useful when your problem maps naturally to a role-based multi-agent structure. PocketFlow wins when you want full control, fast iteration, and a codebase your team can actually read.

For teams building custom AI agents where the logic is specific to your domain, PocketFlow’s minimal surface area is a genuine advantage. You spend time on your problem, not on the framework.

When to Use PocketFlow — and When Not To

Use PocketFlow when:

• You are building a custom AI agent where the workflow logic is domain-specific and you need full visibility into every step
• Your team is comfortable with Python and wants to own the architecture without depending on framework abstractions
• You are prototyping quickly and need to iterate on agent logic without fighting framework conventions
• You are building agentic coding tools or meta-level pipelines where transparency is essential
• You want to minimize your dependency footprint in a production system

Consider a heavier framework when:

• You need extensive pre-built integrations with data sources, vector stores, or third-party APIs and do not want to write those connectors yourself
• Your team is less experienced with LLM architecture and benefits from opinionated structure
• You are building a role-based multi-agent system where CrewAI’s abstractions map naturally to your problem
• You need enterprise support, documentation, and a large community for a regulated or risk-sensitive deployment

The decision is not binary. Some teams use PocketFlow for core agent logic and pull in specific integrations from other libraries where needed. Because PocketFlow does not try to own the entire stack, that kind of selective composition is straightforward.

One practical note: PocketFlow’s minimalism means you write more explicit code. For experienced engineers, that is a feature. For teams that prefer convention over configuration, it can be friction. Know your team before you choose your framework.

Getting Started: Practical First Steps

PocketFlow is on PyPI and installs with a single command:

pip install pocketflow

The GitHub repository at github.com/the-pocket/PocketFlow includes a cookbook with implementations of every major pattern: basic agents, RAG pipelines, multi-agent flows, batch processing, and the agentic coding tutorial. That cookbook is the fastest way to understand how the pieces fit together.

A minimal agent in PocketFlow follows this structure:

1. Define your Nodes, each with prep, exec, and post methods
2. Instantiate a Flow and connect Nodes with action-based transitions
3. Initialize a Shared Store dictionary with your input data
4. Call flow.run(shared) and inspect the results in the shared store

For production deployment, the same principles that apply to any LLM system apply here: instrument your Nodes to log inputs and outputs, set retry logic at the Node level for LLM call failures, and version your prompts separately from your Node logic so you can iterate without redeploying.

The framework choice is one decision in a longer set of architectural choices that determine whether an agent system holds up under production load. Teams at Oqtacore have worked through these decisions across 50+ AI, Web3, and enterprise projects — and the downstream consequences of getting the architecture wrong show up fast once you are running real traffic.

FAQs

What is PocketFlow and who built it?
PocketFlow is a minimalist Python framework for building LLM applications and AI agents. It was created by Zachary Huang with the goal of expressing the full range of LLM design patterns in approximately 100 lines of core code. The project is open source and available at github.com/the-pocket/PocketFlow.

How does PocketFlow compare to LangChain for production AI agents?
PocketFlow is significantly smaller and more transparent. It has no implicit state management and no large dependency tree. For teams that need full visibility into agent execution and want to own their architecture, it is easier to debug and maintain in production. LangChain offers more pre-built integrations but introduces considerably more complexity.

Can PocketFlow handle multi-agent systems?
Yes. You can nest Flows inside other Flows to create multi-agent architectures. Each agent is a Flow with its own Nodes and Shared Store, and a parent Flow can orchestrate multiple agents. The graph-based routing model handles coordination between agents without requiring a separate orchestration layer.

What is agentic coding in the context of PocketFlow?
Agentic coding means using AI agents to write, analyze, and iterate on code — including the code for other AI agents. The PocketFlow-Tutorial-Codebase-Knowledge project is a concrete example: a PocketFlow pipeline that analyzes a GitHub repository and generates a structured tutorial explaining the codebase. It demonstrates how PocketFlow’s transparency makes it practical to use LLMs as development tools, not just product features.

Is PocketFlow suitable for enterprise production deployments?
PocketFlow’s minimalism is an advantage for teams that want control and transparency, but it means you write more explicit code and own more of the infrastructure decisions. For enterprise deployments, you will need to add your own observability, retry logic, and integration layers. The framework does not prevent production use — it just does not abstract those concerns away for you.

What Python version and dependencies does PocketFlow require?
PocketFlow is designed to have minimal dependencies. It works with standard Python 3.8+ and does not require a specific LLM provider SDK — you bring your own LLM client. Check the GitHub repository for the current dependency list, as it may be updated.

When should I choose CrewAI over PocketFlow?
CrewAI is a better fit when your problem maps naturally to a role-based agent structure — for example, a research pipeline with distinct roles like researcher, writer, and reviewer. PocketFlow is a better fit when your agent logic is custom, domain-specific, or requires step-level transparency that CrewAI’s abstractions obscure.

Conclusion

PocketFlow is not trying to be everything. That is exactly why it is worth evaluating seriously.

If you are building AI agents in 2026 and you have spent time debugging opaque framework behavior, the 100-line constraint is a signal worth taking seriously. Smaller surface area means fewer surprises in production, faster iteration on agent logic, and a codebase your team can actually own.

Start with the cookbook, implement one pattern end-to-end, and evaluate whether the explicit control is worth the additional code you write. For most custom agent projects, it is.

If you are working on a production AI agent project and need engineering depth to get from architecture to deployment, the team at Oqtacore builds exactly this kind of system. Working on something similar? Let’s talk.