No mandatory observability cloud
Keep PicoFlow, its session documents, and its bundled stores inside your approved application and database boundary. Your model endpoint remains your choice.
Decision guide
PicoFlow vs. LangGraph
Agent frameworks orchestrate model and tool calls. PicoFlow operates one layer up: a runtime for customer-facing conversational applications, with the durable session, business-stage, and storage machinery included. This page compares the two honestly for teams evaluating both.
Choose PicoFlow when you are building customer-facing conversational applications and want the application layer supplied. Choose LangGraph when your team specifically prefers to own a graph/state runtime directly.
The operational advantage
Your operational record stays with your application.
Every PicoFlow conversation persists one human-readable session document: the active business stage, durable state, model history, transition sequence, effective model details, token totals, status, and structured diagnostics together.
Customer conversation
One durable case
Application-owned session document
state · history · cursor · diagnostics
model metadata · tokens · logs · errors
Inspect an incident
Query internal metrics
Redact and replay safely
Debug from one record
See what the customer and model said, which stage ran, which facts were saved, what failed, and what the run cost without first correlating several systems.
Reproduce the hard failures
Copy and redact a production document into isolated test storage, sandbox side effects, select the resumption stage, and replay the triggering request.
Build operations from data you own
Because every flow has the same outer schema, ordinary document-database aggregation can surface failures, stuck stages, tokens, session duration, and recurring warnings.
PicoFlow's session document is an embedded operational baseline, not a replacement for every distributed trace, alert, or retention policy. Direct LangGraph can be self-hosted and instrumented too; its team chooses and standardizes the corresponding state, observability, and replay conventions.
The direct answer
Both orchestrate complex work. PicoFlow removes the graph-shaped application plumbing.
PicoFlow packages the repetitive engineering around a multi-turn, tool-calling conversation: shared session documents, a durable step cursor, tool dispatch, provider adapters, response contracts, token and operational metadata, and same-session concurrency safeguards. Flow authors keep the business rules, prompts, validation, and transitions in their own code.
PicoFlow composes nested, sequential, parallel, and tool-driven work through ordinary steps and the program stack. A direct LangGraph graph is a different authoring model: it suits teams that prefer to own graph state, topology, reducers, checkpointing, and surrounding application architecture directly.
At a glance
Compare the application boundary, not just the graph API.
The difference is where repeated conversation infrastructure lives. Both options still require application-owned prompts, tools, schemas, validation, and business rules.
| Decision area | PicoFlow | Direct LangGraph |
|---|---|---|
| Authoring model | A named Flow and domain-oriented Step modules own topology, prompts, tools, state, and routing. |
An application-owned StateGraph owns the graph and its state model directly. |
| Progression contract | go(), stay(), and direct() express a transition while the shared runtime owns the durable current-step cursor. |
Application code updates the graph's state and maintains fields such as phase, route, messages, and input-consumption invariants across nodes and conditional edges. |
| Session and HTTP boundary | One versioned session shape, shared storage adapters, operational metadata, and a shared controller/response envelope can serve each flow. | The compared implementation uses a graph-specific input object, session document, and custom store adapters. A direct graph can instead use a configured checkpointer when that better suits the architecture. |
| Where flexibility sits | Steps compose sequential, parallel, nested, and tool-driven work in ordinary application code; the lifecycle adds a shared durable conversation contract. | State reducers, topology, and checkpointing remain closer to the application for teams that prefer a graph-first runtime. |
| Best fit | Long-lived customer conversations, plus one-turn or background orchestration that benefits from named steps and normal program composition. | A team that wants graph/state primitives as its primary authoring model, or already owns the surrounding runtime and operations layer. |
Make the trade-off explicit
Choose the option that reduces your actual risk.
Choose PicoFlow when
- You want graph-level orchestration without requiring every workflow to be modelled as nodes and edges.
- You are building customer-facing, multi-turn conversations that need a durable session and clear business stages.
- Those flows should share one HTTP contract, session shape, storage policy, and operational metadata model.
- Your team wants to work in named, domain-oriented stages rather than repeatedly reconstructing a graph-level session runtime.
- Shared memory compaction, token accounting, provider adapters, tool dispatch, and same-session concurrency protection are useful infrastructure.
- You can accept PicoFlow's lifecycle, release process, and licensing terms.
Choose LangGraph when
- Your team prefers graph/state primitives as the primary authoring model.
- You need to own graph topology, state reducers, or checkpointing directly.
- Your organization already owns sessions, observability, concurrency, and the surrounding operations layer.
- Your team already has strong LangGraph experience and no second multi-turn flow is planned.
- The workflow is unusual enough that a
Flow/Steplifecycle would fight its design. - Your organization requires permissively licensed dependencies. PicoFlow is commercially licensed; if that is a hard constraint, stop here.
Evidence, scoped
One hotel flow showed 65.8% less workflow/runtime code with PicoFlow.
It is useful implementation evidence—not a universal benchmark, a performance test, or a claim that every LangGraph application will have the same line count.
Same 14-turn hotel workflow
65.8% less workflow/runtime code 618 PicoFlow lines vs. 1,809 direct LangGraph lines · 1,191 fewer lines
618
PicoFlow HotelFlow application-boundary lines
1,809
Direct LangGraph hotel application-boundary lines
−1,191
workflow/runtime lines in this specific direct implementation
The two implementations cover the same 14-turn hotel-reservation conversation: collecting dates and search criteria, searching a local catalog, presenting priced results, comparing hotels, returning to booking, and confirming a reservation. The 618 versus 1,809 count isolates the application boundary, and both sides are nameable files you can open in the demo repository.
PicoFlow: hotel-flow.ts (64), explore-step.ts (178), present-step.ts (183), compare-step.ts (193). Direct LangGraph: hotel-langgraph.ts (1,374), hotel-session-store.ts (312), hotel-langgraph.state.ts (97), hotel-types.ts (26). The custom store remains useful evidence: it is a hand-written memory, SQLite, and MongoDB adapter set that PicoFlow supplies through its runtime.
These are wc -l counts, so imports, comments, and blank lines are included; framework source is excluded on both sides. The full project totals are context rather than a scorecard—the direct implementation includes a more compact chart helper, for example. Read the scoped HotelFlow benchmark and its trade-offs before treating the count as decision evidence.
Test the fit
Start with the workflow shape, then inspect the evidence.
Build the smallest flow that represents your real business boundary. The quickstart shows PicoFlow's Flow / Step model; the comparison resources document the architectural trade-offs in more depth.