Functional API

Alternative to Graph API using @entrypoint and @task decorators. When to use Functional API vs StateGraph. Simpler syntax for common patterns.

Quick Reference

→@entrypoint: marks a function as a LangGraph workflow — handles checkpointing, streaming, and human-in-the-loop automatically
→@task: marks a function as an individual unit of work — checkpointed independently, returns a future
→entrypoint.final(value=X, save=Y): decouple what the caller receives from what gets saved to the checkpoint
→Injectable params: previous (last return value), store (long-term memory), writer (custom streaming), config (RunnableConfig)
→Determinism rule: wrap all randomness and side effects inside @task — not in the entrypoint body

@entrypoint & @task

Functional API: simple decorated functions. StateGraph: explicit graph definition.

A complete workflow with the Functional API

@entrypoint defines the workflow. @task marks individual steps. Each task is independently checkpointed -- if the workflow crashes after research() completes but before summarize() finishes, restarting resumes from the summarize() step. The key insight is that the Functional API gives you the same durability and checkpointing guarantees as StateGraph, but with plain Python function syntax. No state schema, no add_node, no add_edge -- just decorated async functions.

Functional API vs StateGraph

Feature	Functional API	StateGraph
Syntax	Decorated functions (@entrypoint, @task)	add_node() + add_edge() + compile()
State schema	Inferred from function params and returns	Explicit TypedDict or Pydantic BaseModel
Cycles (loops)	Not supported — linear and branching only	First-class: edges can loop back to earlier nodes
Conditional routing	Python if/else inside the entrypoint	add_conditional_edges() with path maps
Human-in-the-loop	interrupt() works inside @task functions	interrupt() + interrupt_before/interrupt_after
Subgraphs	Call other @entrypoint functions directly	Compiled graph added as a node
Best for	Linear workflows, simple branching, scripts	Complex agents with cycles, multi-agent systems

Automatic Checkpointing

Each @task is a checkpoint boundary -- if the workflow crashes, it resumes from the last completed task. The checkpointer stores the return value of each completed task. On recovery, completed tasks return their cached results instantly (no re-execution), and the workflow continues from the first incomplete task. This is identical to how StateGraph checkpoints at super-step boundaries.

Sign in to read this article

This is a premium article. Sign in with your Google account to continue.