Agent Orchestration — LangGraph vs Message Broker

The same research-assistant workflow — plan, three parallel researchers, synthesize, critique, loop back if rejected — run two ways. As a LangGraph state machine with a shared state object and a loop-back edge, and as event-driven agents coordinated through a broker. Watch both execute and weigh control, state, resilience and scale.

One research-assistant workflow, two orchestrators. Flip the switch and run it: watch the LangGraph state machine execute its graph (with a real loop-back edge), then watch the same agents coordinate as event-driven services on a broker.

🧭

Planner

🔎

Researcher 1

🔎

Researcher 2

🔎

Researcher 3

🧩

Synthesizer

🧪

Critic

✅

Finalizer

Shared state (one object)

{

plan: …

findings: …

draft: …

critique: …

answer: …

}

Every node reads and writes this one object, in memory.

Execution trace (one process)

// run the workflow

Dimension

🧭 LangGraph

📡 Message broker

Control flow

Explicit graph + conditional edges

Emergent from published events

State

One shared object, in memory

In event payloads / a store

Parallelism

Fan-out (Send) within the graph

Natural — independent consumers

Observability

One linear trace

Distributed tracing across services

Resilience

Process crash loses the run

Durable, replayable events

Latency

In-process (fast)

Network hops per event

Scaling

Scale the whole process

Scale each agent independently

Best when

Defined flow, control, debugging

Scale, resilience, loose coupling

What just happened

▹Same multi-agent workflow — plan, three parallel researchers, synthesize, critique, loop if rejected — orchestrated two completely different ways.
▹LangGraph is an in-process state machine: an explicit graph with conditional edges and a loop-back, one shared state object that every node reads and writes, and a single trace you can debug. Deterministic and easy to reason about — but it lives in one process, so a crash loses the run.
▹A message broker turns each agent into an independent event-driven service: agents react to events, run in parallel naturally, and the workflow advances through published events. State rides in event payloads or a store, events are durable and replayable, and each agent scales on its own — at the cost of distributed tracing and implicit control flow.
▹Rule of thumb: reach for the graph when the workflow is well-defined and you want control and observability; reach for the broker when you need scale, resilience, and loosely-coupled agents that evolve independently.