Multi-Agent Patterns: LangGraph and CrewAI, Animated

1 · Coordination patterns, simulated

How agents hand work to each other

Eight ways agents hand work to each other, with no particular task: roles, messages, and in the right-hand panel what each agent gets to see. What an agent sees decides what it can get right.

00Pick a pattern

Agents0

Messages0

Tokens in context0

Human steps0

Context windows · what each agent sees

tokens

Transcript

0 messages

Next: the same patterns in code, on one real task: “Black running shoes, size 9, under ₹1,000”

2 · LangGraph, in code

A graph you draw: state, nodes, edges

Every excerpt is the real code in patterns/ and lab/. LangGraph’s model: one state object, nodes that read it and return updates, and edges that decide what runs next. Control flow is yours, explicitly.

A library for agents as state machines

LangGraph is an open-source, low-level orchestration library from the LangChain team, for Python and JavaScript. You describe your system as a graph: one shared state, nodes that read it and return updates, and edges that decide what runs next. It doesn’t write prompts or define agents for you, and it doesn’t need LangChain. This demo uses langgraph 1.x.

MEMORYStateA TypedDict (or pydantic model). Each key can have a reducer: Annotated[list, operator.add] appends, a plain key is overwritten.

WORKNodeAny Python function: state → update. It can call a model, a tool, an API, or just do arithmetic. Only the keys it returns change.

FLOWEdgesadd_edge (always next), add_conditional_edges (a function picks), Send (start N copies with their own payload). Cycles are allowed.

DURABILITYCheckpointerSaves the state after every step, per thread_id: resume after a crash, pause for a human with interrupt(), browse history and rewind.

Around those four: subgraphs (a compiled graph is a node), streaming of updates, values and tokens, Command (update state and jump in one return), a long-term store, and prebuilt agent loops when you don’t want to draw one. LangChain also sells a hosted platform and LangSmith tracing around it; neither is required.

What happens after `graph.invoke()`

Compile once. builder.compile(checkpointer=…) checks the graph and returns a runnable. invoke() takes the input and a thread_id.
Run in supersteps. Every node whose inputs changed runs; nodes in the same step run in parallel. That’s how Send fans out.
Nodes return updates, not state. Reducers merge them. Two parallel nodes writing a plain key is an error, by design.
Checkpoint every step. With a checkpointer the whole state is saved per thread: resume after a crash, list the history, rewind.
Edges pick what runs next. A fixed edge, a router function, or Send(node, payload) for each item. Back to step 2.
Stop or pause. END finishes. interrupt() pauses and saves; Command(resume=…) continues. recursion_limit stops runaway loops.

The idea to keep: you own the loop. Nothing runs that isn’t an edge, and a node is just a function, so the model is called only where you put a call.

Strengths: what the control buys you

01Exact control flowEvery branch, loop and join is an edge you drew, and the shape can be decided at run time with Send.

Here: the L1 planner reads the query and decides at run time which workers to start.

02Plain code where code is enoughFiltering by price doesn’t need a model. Only the judgment calls cost tokens and seconds.

Here: L0 makes one model call: search, filter and pick are plain Python, the model only writes the confirmation.

03Durable executionA checkpoint after every step: survive a crash, resume a thread tomorrow, browse the history, rewind and fork.

Here: the guardrails lab crashes, resumes and rewinds from SqliteSaver with get_state_history.

04Human in the loop, anywhereinterrupt() inside any node pauses and persists; the answer can come hours later, from another process.

Here: the approval guardrail in lab/guards.py is one line.

05Safe parallelismReducers say how parallel updates merge, so fan-out and fan-in are deterministic, not a race.

Here: L2’s three scouts append to offers through operator.add.

06No hidden promptsEvery prompt is one you wrote; stream updates, state or tokens as they happen.

Here: the Run log shows each LangGraph call’s context: exactly the dict the node built.

Weaknesses: what you pay for the control

01More code, more decisionsA state schema, nodes, edges and reducers before anything runs, and you decide every one of them.

Here: the L2 graph is 154 lines: state, nodes, routers and edges all spelled out.

02Steep conceptsSupersteps, channels, reducers, Send vs Command, threads vs store. It’s easy to misread when, and how often, a node runs.

03Batteries not includedNo roles, typed retries, memory or delegation out of the box. Validation, retry with feedback and critics are yours to build.

Here: the critic loop is two conditional edges plus a rejected list in state that you maintain.

04Wiring bugs show up at run timeA missing edge means a node never runs; two parallel writers to a plain key raise an error; a loop without an exit hits recursion_limit.

Here: lab/runner.py sets recursion_limit=24 as the last line of defence.

05Resume reruns the nodeAfter interrupt(), resuming runs the whole node again from its first line, so anything before the interrupt happens twice unless it’s idempotent.

06Checkpoints have a costEvery step writes the full state: storage grows, everything in state must serialize, and changing the schema can break old threads.

Here: the demo runs grew their checkpoint database to 27 MB.

Debugging is smoothest with LangSmith, LangChain’s paid tracing; without it you add your own (this project writes its own run log). The trade: you get control and durability, and you pay in code and concepts.

Gotchas and fixes

You see…	Because…	Fix
A node never runs	No edge leads to it	Every node needs an incoming edge. Draw it: `graph.get_graph().draw_mermaid()`
`InvalidUpdateError` at a fan-in	Two parallel nodes wrote the same plain key	Give the key a reducer: `Annotated[list, operator.add]`
`GraphRecursionError`	A cycle with no exit, or a limit set too low	Count turns in state and route to `END`; set `recursion_limit` in the config
An email sent twice after approval	Resume reruns the node that called `interrupt()`	Do side effects after the interrupt, in their own node, or make them idempotent
The run forgot everything	No checkpointer, or a new `thread_id`	`compile(checkpointer=…)` and reuse `{"configurable": {"thread_id": …}}`
A change to state didn’t stick	The node mutated `state` instead of returning an update	Return a dict with only the keys you changed

In this project: patterns/ has the four graphs from the live demo; lab/ has the guardrails (owner, budget, approval) with crash, resume and rewind on SqliteSaver.

The code: the same four patterns in patterns/ and lab/

3 · CrewAI, in code

A team you staff: agents, tasks, a crew

The same four patterns, built in crews/. CrewAI’s model: agents with roles, tasks with expected outputs, a crew that runs them, and Flows for events. You describe the work; CrewAI runs the loop.

A framework for teams of role-playing agents

CrewAI is an open-source Python framework for multi-agent systems. You describe who does the work (agents with a role, goal and backstory) and what needs doing (tasks with an expected output); CrewAI writes the prompts, runs each agent’s think → act loop, and passes results between them. It is its own framework, not built on LangChain. This demo uses crewai==1.15.28.

WHOAgentA role, a goal, a backstory, an llm and optional tools. That text becomes the agent’s system prompt.

WHATTaskA description, an expected_output, the agent that does it. Optionally typed (output_pydantic), checked (guardrail) and run in parallel (async_execution).

HOWCrew + ProcessRuns the tasks: sequential (in order, each output is the next one’s context) or hierarchical (a manager agent delegates).

WHENFlowThe deterministic layer: plain Python methods wired with @start, @listen, @router, sharing a pydantic state. Flows call crews where judgment is needed.

Around those four: tools (any function, or the crewai-tools package), memory and knowledge (retrieval over past runs and your documents), delegation between agents, checkpoints, and a CLI that scaffolds projects with agents.yaml and tasks.yaml.

What happens after `crew.kickoff()`

Inputs fill the placeholders. {query} in agent and task text is replaced by kickoff(inputs=…).
The process picks the next task. Sequential: the next in the list. Hierarchical: the manager chooses who does what.
CrewAI builds the prompt. Role, goal and backstory, then the task, its expected output, and the outputs of the tasks in its context.
The agent loops. The model thinks; if it calls a tool, the result comes back as an observation, until it gives a final answer or hits max_iter.
The answer is checked. Parsed into output_pydantic; then the guardrail. If it fails, the same agent runs again with the reason.
The output moves on. It becomes a TaskOutput, the context for later tasks. The last one is the CrewOutput.

The key difference from LangGraph: the loop is inside the framework. You configure it; you don’t draw it. That’s why each step in these crews is a model call: the unit of work is an agent turn.

Where CrewAI beats LangGraph

01Less code to a working teamNo state schema, no edges, no reducers. An agent and a task are a few lines of mostly English.

Here: the L2 crew has no State class, no edges and no routing functions.

02The critic loop is built inguardrail= plus guardrail_max_retries gives you retry-with-feedback. In LangGraph that’s two conditional edges and a counter in state.

Here: L2 rejects the fake seller and retries in one argument.

03Typed hand-offs by defaultoutput_pydantic validates every task’s answer before the next agent sees it. A bad answer is caught at the boundary, not three steps later.

04Roles read like the org chartProduct people can read and edit agents.yaml and tasks.yaml. The design conversation is “who should check the seller?”, not “which edge?”.

05Batteries includedDelegation between agents, memory, knowledge sources, a tools package, planning, training and testing commands: things you assemble yourself around LangGraph.

06Two layers, clearly splitFlows for the deterministic, event-driven part; crews for the parts that need judgment.

Here: L3 is a Flow (watch → router) that calls a crew only when the price drops.

Weaknesses: what you trade for the convenience

01Every step costs a model callThe unit of work is an agent turn, so even a fixed step (“filter by price”) goes through the model. More tokens, more latency, more places to go wrong.

Measured here: L0 is 3 calls vs 1 in LangGraph; with Claude haiku L1 took 44 s vs 12 s.

02Prompts you didn’t writeCrewAI generates the system prompt from role, goal and backstory, plus its own instructions. Hard to see, hard to tune, and backstory text costs tokens every turn.

Here: the Run log shows the full transcript CrewAI sent, much longer than the task.

03Control flow is coarseTopology is fixed when the crew is built: a plan can shape tasks but can’t add a worker. Loops, branches and joins beyond the built-ins mean dropping to Flows or plain Python.

Here: LangGraph’s L1 planner picks its workers at run time; the crew can’t.

04Hierarchical is fragileThe manager needs a tool-calling model, adds its own turns, and can re-delegate or loop. Many teams fall back to sequential plus guardrails.

Here: our tool-less Claude bridge can’t drive a manager, so the crews stay sequential.

05State and recovery are lighterNo reducers for parallel writers, and checkpoint/resume/fork is younger than LangGraph’s step-level persistence, interrupt() and time travel. Human input is mostly human_input=True or a Flow decorator.

06Moving fast, opinionated defaultsFrequent releases and API changes, console panels on by default, anonymous telemetry on by default.

Here: we silence the console, filter deprecation warnings, and set OTEL_SDK_DISABLED and CREWAI_TELEMETRY_OPT_OUT in crews/__init__.py.

LangGraph has its own costs: more code, you design every edge and state key, and a steeper start. The trade is convenience and conventions (CrewAI) against control and durability (LangGraph).

Which one, when

If you need…	Pick	Why
A working prototype this week, the work maps to roles (research, review, write)	CrewAI	Agents and tasks in English, typed outputs and retries for free
Exact control of every branch, loop and join	LangGraph	You draw the graph; nothing runs that isn’t an edge
Cheap, fast steps mixed with a few model calls	LangGraph	Nodes can be plain code; only the judgment calls hit the model
Long-running runs, crash recovery, a human approving mid-run	LangGraph	Checkpoint every step, `interrupt()`, resume and rewind
A critic that sends work back with feedback	Either	One argument in CrewAI; two edges in LangGraph
Event-driven: something in the world starts the run	Either	CrewAI Flow (`@start`/`@router`) or your code calling `graph.invoke()`
Non-engineers editing who does what	CrewAI	`agents.yaml` and `tasks.yaml` read like a job description

You don’t have to choose one. A crew can be a single LangGraph node, and a CrewAI Flow can call any Python, including a compiled graph. A common shape: LangGraph (or a Flow) for the skeleton, a crew where a step genuinely needs a team.

The code: the same four patterns in crews/