Skip to main content
LangGraph and Smithers both say “orchestration,” persist state, and support humans in the loop: compared often, but solving different problems. Pick by unit of work. LangGraph’s unit of work is an LLM call. It wires model calls, tools, memory, and routing into a graph, checkpoints its state, and ships inside your product: support bots, RAG pipelines, and custom in-app agents are its home turf. Smithers’ unit of work is a coding agent doing a job. It runs Claude Code, Codex, Pi, or an AI SDK model as one durable step among many: implement, review, wait for a human, merge. You don’t rebuild the agent, you compose the ones you already use against a real repository.

​
The short version

​
Where the overlap is real

Chaining coding-agent CLI calls in LangGraph, with retries and a review gate? Smithers needs less machinery: harness integrations, worktree isolation, merge queues, approvals, and crash-resume are built in, and a workflow is a file your own coding agent can write. LangGraph’s named tutorial patterns (supervisor, reflection, plan-and-execute) ship here as readable twenty-line components. Building a customer-facing agent with fine-grained control over every model call and token stream? That’s LangGraph’s job, not Smithers’. A Smithers task can call a LangGraph agent like any process: they compose, not conflict.

​
The authoring bet

Both bet agents will write and maintain these definitions: LangGraph on an imperative graph API, Smithers on JSX (the densest tree-composition idiom in any model’s training data), keeping generated workflows reviewable by the humans auditing them. More: Why React.

​
See also