Key facts
- A node owns one coherent unit of work and separates prep, exec, and post behavior.
- Action strings make transitions explicit enough to review, test, and debug.
- Shared state is the contract between nodes; params are best kept for task identity.
A node is the unit of work
In a minimal orchestrator, a node should be boring. It takes the smallest coherent job in the system: classify an intent, retrieve documents, call a model, run a tool, validate JSON, summarize a chunk, or write a result. The node boundary is useful because it gives you a place to name the input contract, isolate the risky compute, and write the output contract.
Pocket Flow's lifecycle is a clean way to enforce that boundary. prep(shared) reads and shapes inputs. exec(prep_res) performs compute and should avoid touching shared state. post(shared, prep_res, exec_res) writes the result and returns an action. That separation is small, but it prevents a common agent failure: a single function that reads state, mutates state, calls models, catches provider errors, and decides routing all at once.
"prep->exec->post"
Node size test
A node is probably too large when its retry policy is hard to explain, when its output has multiple unrelated meanings, or when you cannot unit test it without constructing half the application. A node is too small when the next node always needs private context that was discarded by the previous one. The useful size is the smallest boundary with a stable input and output.
Edges are actions, not vibes
The transition between nodes is not hidden in an agent framework. It is a labeled edge. A planner can return search, answer, clarify, or fail; the flow maps those action strings to successor nodes. That single convention covers straight-line pipelines, branching, loops, and early exits.
This is why graphs are a natural fit for LLM systems. LLM calls often produce uncertain outputs, but the orchestrator needs crisp transitions. A tiny framework does not remove uncertainty; it forces you to decide which uncertainty is allowed to affect control flow.
The shared store is the state contract
In Pocket Flow's terminology, the shared store is usually an in-memory dictionary. In production, it might be a typed object, a database row, an event log, or a durable execution state. The important part is conceptual: every node can read from the shared store during prep and write to it during post, so the state contract becomes visible.
That visibility matters more than the data structure. A team can review a state schema. A team can write fixtures for it. A team can inspect a failed run and see whether the bug is retrieval, generation, validation, or routing. The shared store is not just a convenience; it is the debugging surface.
Params are for task identity
Params are useful when a batch flow calls the same node over many items. A filename, page number, account ID, or chunk number belongs in params because it identifies the work item. The actual content and results belong in shared state. That split keeps batch processing from smuggling business data through routing metadata.
A flow can become a node
Nested flows are the move that makes a tiny model scale without losing its shape. A retrieval subflow can become one node in a bigger answer-generation flow. A validation loop can become one node in a customer-support agent. A map-reduce summarizer can become one node in a document-review pipeline.
This is where minimal orchestration becomes more than a toy. You keep the runtime small, but composition still gives you hierarchy. The parent flow does not need to know every internal step of the child flow; it only needs to know the child flow's input, output, and action.
draft = GenerateDraft()
check = ValidateJson()
repair = RepairJson()
done = StoreResult()
draft >> check
check - "valid" >> done
check - "invalid" >> repair
repair >> checkWhere the model breaks
Minimal graphs do not magically solve long-running execution, distributed locks, observability, security, schema migrations, human approval, or deployment. They expose the control flow; they do not supply an operations platform. Once your graph needs persistence across worker restarts, per-node traces, resumable human-in-the-loop decisions, or managed deployment, a runtime such as LangGraph may become more appropriate.
The best use of the node graph model is often design-first: draw the graph, name the state, and implement the smallest runtime that proves the workflow. If the graph becomes stable and operational needs grow, migrate deliberately. If the graph is still changing daily, a small runtime keeps the system legible.
Sources used on this page
- Pocket Flow documentation The Pocket. Accessed July 6, 2026. Primary source for the 100-line claim, Graph + Shared Store abstraction, core patterns, and utility philosophy.
- Pocket Flow Node documentation The Pocket. Accessed July 6, 2026. Primary source for prep, exec, post, retries, and fallback behavior.
- Pocket Flow Flow documentation The Pocket. Accessed July 6, 2026. Primary source for action-based transitions, branching, loops, and nested flows.
- Pocket Flow Communication documentation The Pocket. Accessed July 6, 2026. Primary source for Shared Store and Params guidance.
- LangGraph overview LangChain. Accessed July 6, 2026. Primary source for durable execution, persistence, human-in-the-loop, memory, and production orchestration claims.
Cite this page
The node graph model. PocketFlow AI Guide. Updated July 6, 2026. https://pocketflowai.com/the-node-graph-model/
PocketFlow AI Guide. "The node graph model." Accessed July 6, 2026. https://pocketflowai.com/the-node-graph-model/