GraphWorkflow: Our New Research Paper on a Compile-Once Engine That Runs Agent Graphs up to 62.5x Faster Than LangGraph

The Swarms research team has released a new paper: "GraphWorkflow: A Low-Overhead Compile-Once Graph Execution Engine for Multi-Agent Systems", authored by Kye Gomez, Adi Chaudhary, Ayaan Gazali, Steve-Dusty, and Wyatt Stanke. The paper is a full systems treatment of GraphWorkflow, the graph orchestration engine inside the open-source Swarms framework: a formal execution model with proofs, a cost model for agent orchestration, a detailed account of the engine's design, and an open benchmark suite comparing it head-to-head against LangGraph 1.0.4.

The headline numbers: across 15 topology and size configurations, GraphWorkflow executes compiled graphs with a geometric-mean speedup of 7.0x over LangGraph, rising to 62.5x on 200-node chains. It compiles graphs 21.6x to 31.3x faster and completes the cold build-compile-execute path 7.9x faster. Every number in the paper is a median of 9 samples with 95% confidence intervals, and the entire harness, raw data, and analysis pipeline are released alongside the paper so anyone can reproduce the results.

This article walks through the paper: why orchestration overhead matters at all, how the engine works, what the benchmarks measure, and what the results do and do not claim.

Why Orchestration Overhead Became a Systems Problem

Multi-agent systems have converged on the same structural abstraction: a directed acyclic graph (DAG) whose nodes are agent invocations and whose edges carry intermediate outputs forward. Dependencies are explicit, independent work is exposed for parallel execution, and the program structure can be validated, visualized, and persisted separately from the code that executes it.

Since a single agent step costs between 0.5 and 5 seconds of model latency, orchestration frameworks have historically treated their own overhead as a rounding error. The paper's starting observation is that this assumption fails in three specific regimes:

• Cold start of short-lived processes. A serverless deployment pays the full build-compile-execute cost on every cold start, and cold-start latency is a first-order operational concern.
• High-frequency re-execution. A service that executes a compiled workflow per incoming request pays the per-run overhead millions of times. An orchestration tax of 18 ms per request is 1.8% of a one-second budget, and it compounds under fan-out.
• Large graphs. When width or depth reaches hundreds of nodes, per-node and per-layer costs that were invisible at ten nodes dominate the run.

To make this measurable, the paper defines a cost taxonomy of four lifecycle phases: build (constructing the in-memory graph), compile (all preprocessing between construction and first execution), first run (the cold path: build plus compile plus one execution), and steady run (one execution of an already-prepared graph, the marginal cost a long-lived service pays per request). Reporting both ends keeps the comparison honest across deployment regimes: a one-shot script cares about the cold path, a long-lived service or evaluation sweep about the steady state.

The paper also explains why adjacent infrastructure does not fill this niche. Workflow managers like Airflow and Prefect schedule tasks through database-backed control planes at per-task latencies of hundreds of milliseconds. Dataflow systems like Dask and Ray bring per-task overhead down to roughly 100 microseconds to 1 millisecond, but assume a running scheduler or cluster and serialize arguments across process boundaries. Graph libraries like NetworkX provide algorithms but no execution semantics. The niche GraphWorkflow targets is the composition of all three: library-grade latency, dataflow semantics, and graph-library algorithms behind a single in-process object.

The Core Idea: Compile Once, Sweep Many

LangGraph, the most widely used graph orchestrator for agents, executes graphs on a Pregel-style superstep loop with channel-based state, reducer functions, and checkpoint hooks consulted on every step. That machinery buys real features: cycles, conditional edges, and durable execution. But it is charged to every node of every run, whether or not the workflow uses any of it. On a 200-node sequential chain of no-op nodes, LangGraph spends 18.15 ms of pure orchestration per execution, roughly 90 microseconds per superstep, even with checkpointing disabled.

GraphWorkflow takes the opposite position: the common case for agent workflows is a static DAG executed one or many times, and a static DAG can be prepared once and executed with almost no per-run machinery.

The engine separates the graph lifecycle into an explicit compilation phase and a minimal execution phase. Compilation does all the work a run loop would otherwise repeat:

• Infers entry and exit points from node degrees, so the user never wires START and END edges.
• Computes topological generations with Kahn's algorithm, natively in Rust when the rustworkx backend is active. Generations are the canonical maximal-parallelism layering: layer zero is exactly the set of nodes executable immediately, and each subsequent layer is exactly the set executable once the previous layers complete.
• Materializes successor and predecessor maps in a single pass over the edge list, instead of issuing per-node backend calls.
• Runs structural validation from those maps: acyclicity in linear time, plus reachability in both directions via multi-source breadth-first traversals, so every node is reachable from an entry point and co-reachable from an exit point.
• Freezes a per-layer execution plan in which every node is already resolved to a tuple of node id, agent object, node type, and display name. The run loop performs no dictionary lookups into the node table, no attribute resolution, and no type dispatch beyond a tag comparison.

The paper proves that this entire pipeline runs in O(N + M) time and space for N nodes and M edges, and that the layered wavefront schedule respects dependency order: every node begins only after all of its predecessors have completed, with no locking required because the output map is append-only and layer barriers order all cross-layer access.

Execution is then deliberately unsophisticated: a double loop over a precomputed list. Each layer is dispatched as a wavefront onto a single thread pool that is created lazily, sized to the widest layer, and shared across the entire run. A layer containing a single node bypasses the pool entirely and runs inline on the calling thread, because submitting to a worker adds a queue handoff, a context switch, and a future wait to a call the scheduler must block on anyway.

That inline fast path turns out to matter enormously. On chain topologies it eliminates the pool entirely, which is why GraphWorkflow's chain overhead lands at roughly 1.5 microseconds per node, an order of magnitude below its own threaded per-node cost of about 10 microseconds, and two orders of magnitude below LangGraph's per-superstep cost.

Everything is cached with explicit invalidation. Every mutation (adding a node, adding an edge, changing entry points) clears the compiled artifacts, so a stale plan can never execute, and repeated runs or multi-loop refinement pay compilation exactly once.

A second architectural decision keeps the engine independent of any one graph library. All structural operations go through a small backend interface with two implementations: one over NetworkX and one over the Rust-based rustworkx, which lowers generation computation and reachability into native code. Because the frozen plan makes the runtime backend-agnostic, the backend affects only build and compile cost, a claim the benchmarks later verify directly.

The Programming Model: What Each Framework Asks of You

The performance argument has a usability counterpart, and the paper makes it concrete with side-by-side implementations of the same diamond workflow: one analyst fanning out to a writer and a researcher whose outputs an editor merges.

In GraphWorkflow, agents are nodes and edges are dataflow. The engine assembles each node's prompt from its predecessors' outputs, and results come back as a dictionary keyed by node identifier. In LangGraph, the same workflow requires a typed state schema, a reducer annotation for the fan-in (omitting it raises a concurrent-update error), wrapper functions that adapt each agent to the state interface, explicit START and END wiring, an explicit compile call, and a recursion-limit override for any graph deeper than 25 supersteps.

The paper summarizes the obligations in a table, reproduced here in compact form:

The paper is careful about scope here: workflows that need conditional edges or cycles cannot be expressed in GraphWorkflow at all, and there LangGraph's obligations buy capability rather than ceremony. The comparison covers the static-DAG common case, where those obligations are pure overhead.

The Benchmark: Five Topologies, No-Op Agents, Everything Released

The evaluation is built on an open harness that lives in the Swarms repository. Every node is a no-op function, so every measured microsecond is framework overhead by construction; there is no LLM latency anywhere in the data. Each configuration runs two discarded warmup iterations followed by 9 timed samples, with the garbage collector forced between samples and disabled inside timed regions. Medians are the headline statistic, and means, standard deviations, confidence intervals, and all raw samples are preserved in the released JSON.

Five topologies at 10, 50, and 200 nodes are chosen to separate the coefficients of the paper's overhead model, which decomposes steady-run cost into a per-node term, a per-layer term, and a fixed term:

• Chain maximizes depth (depth equals node count): the discriminating case for superstep-style runtimes.
• Wide is one root fanning out to all remaining nodes (depth 2): it isolates per-node dispatch cost.
• Diamond is fan-out then fan-in (depth 3): the map-reduce shape most common in agent practice.
• Layered stacks fully connected stages of four: depth and width together, with the densest edge count.
• Tree is a binary tree: logarithmic depth with geometric width growth.

Fairness controls are documented in detail. Both frameworks execute identical topologies node for node through their native construction APIs. LangGraph's recursion cap is raised so deep graphs complete. Its fan-in reducer choice is tested both ways: the headline runs use an appending list reducer that matches the information GraphWorkflow inherently retains, and a full ablation sweep with a constant-time counter reducer confirms the choice does not drive the results. No checkpointer is configured for either system.

The Results

Compilation separates the architectures. Both systems expose an explicit compile step, but they build different things: GraphWorkflow runs its linear-time pipeline of generations, one adjacency pass, reachability validation, and plan freezing, while LangGraph assembles its Pregel runtime of channels, write entries, and branch machinery. At 200 nodes, GraphWorkflow compiles the chain in 0.44 ms on NetworkX and 0.26 ms on rustworkx, against 12.57 ms for LangGraph: a 21.6x to 31.3x geometric-mean gap that reaches 60.7x at size 200.

The cold path compounds the gaps. First-run cost shows geometric-mean speedups of 7.9x on NetworkX and 8.7x on rustworkx, growing to 29.3x on the 200-node chain. On the heaviest cell in the suite, the 200-node layered topology, the totals are 4.40 ms versus 44.4 ms. For interactive construction in notebooks and request-scoped workflow assembly, this is the phase users feel.

Steady-state execution is where the design pays off per request. Three observations from the paper:

First, the two GraphWorkflow backends are statistically indistinguishable in every cell, which is the designed consequence of the frozen execution plan: after compile, no backend code executes. The paper treats this as a falsifiable check on its own architectural claim, and the data passes it.

Second, the gap to LangGraph is topology-dependent in exactly the direction the analysis predicts. On shallow graphs the ratio sits at 2.7x to 4x. As depth grows, the superstep loop compounds: on the 200-node chain, GraphWorkflow executes in 0.29 ms versus 18.15 ms, a 62.5x difference.

Third, the absolute numbers frame where this matters. At 200 nodes, GraphWorkflow's overhead is 0.3 to 3 ms per run against LangGraph's 17 to 25 ms. Neither is visible in a single small workflow next to agent calls that take seconds. The difference matters at request rates, in evaluation sweeps, and in cold-start-sensitive deployments: at 1,000 executions of the 200-node chain, cumulative orchestration totals roughly 0.3 seconds for GraphWorkflow against 18.2 seconds for LangGraph.

Attribution: Explaining Every Measured Gap

A distinctive feature of the paper is that it does not stop at reporting speedups; it attributes each one to a specific mechanism, using the topology suite as a set of probes.

The chain, where every layer is a singleton, prices GraphWorkflow's inline path at about 1.5 microseconds per node, essentially the cost of assembling a short prompt and two dictionary stores. The wide topology, where 199 nodes dispatch through the shared pool, prices threaded dispatch at about 10.5 microseconds per node, which quantifies exactly what the singleton fast path saves. For LangGraph, the same probes give 90.7 microseconds per superstep on the chain and 122.5 microseconds per node on the wide graph. A single-coefficient per-node model fits LangGraph's entire grid with R-squared of 0.97 at roughly 107 microseconds per node, consistent with overhead dominated by channel reads, task preparation, write application, and reducer invocation. No such single-coefficient model fits GraphWorkflow, because its inline and threaded paths differ by 7x, which is the measurable signature of the fast path.

The stacked breakdown at 200 nodes shows where the milliseconds go for each system: compilation dominates LangGraph's preparation cost, and execution dominates its recurring cost.

The paper also confronts the most natural objection head-on: does the appending list reducer inflate LangGraph's numbers by accumulating state across supersteps? A full ablation sweep with a constant-time counter reducer answers no. The geometric-mean ratio between the two reducer configurations is 1.05x, most cells move by less than 12%, and even scoring LangGraph with its counter numbers everywhere, the 200-node chain remains at 16.8 ms versus 0.29 ms, a 58x gap. The overhead is orchestration, not state accumulation.

Reproduce Every Number Yourself

The paper ships as a reproducible artifact. The full harness, raw samples, analysis scripts, and figures are published in the GraphWorkflow-Paper repository, and every number in the text is emitted as a LaTeX macro by the same analysis script that consumes the result JSON, so the paper cannot silently drift from the data.

# Get the paper, benchmarks, and analysis pipeline
git clone https://github.com/The-Swarm-Corporation/GraphWorkflow-Paper
cd GraphWorkflow-Paper

# 1. Run the full benchmark suite
python3 benchmarks/graph_workflow_bench.py

# 2. Reducer ablation (O(1) counter reducer for LangGraph fan-in state)
python3 benchmarks/graph_workflow_bench.py --lg-reducer counter

# 3. Regenerate the figures from the result JSON
python3 benchmarks/plot_results.py

GraphWorkflow itself is about 4,000 lines of Python in swarms/structs/graph_workflow.py, with no mandatory dependencies beyond NetworkX; rustworkx and Graphviz are optional and detected at import. Using it looks like this:

from swarms import Agent, GraphWorkflow

analyst = Agent(agent_name="Analyst", model_name="gpt-5.4")
writer = Agent(agent_name="Writer", model_name="gpt-5.4")
researcher = Agent(agent_name="Researcher", model_name="gpt-5.4")
editor = Agent(agent_name="Editor", model_name="gpt-5.4")

wf = GraphWorkflow()
for a in (analyst, writer, researcher, editor):
    wf.add_node(a)

wf.add_edge(analyst, writer)
wf.add_edge(analyst, researcher)
wf.add_edge(writer, editor)
wf.add_edge(researcher, editor)

results = wf.run("Produce a market report.")

No state schema, no reducers, no explicit entry and exit wiring, no recursion configuration. The engine infers the boundary, compiles on first run, and returns results keyed by agent name.

Use GraphWorkflow in the Cloud, With or Without Code

You do not have to run the engine locally to use it. GraphWorkflow is available on Swarms Cloud in two forms.

For builders who prefer a visual canvas, the Workflow Builder is a no-code version of GraphWorkflow: you lay out agents as nodes, draw the edges between them, and run the resulting graph directly from the browser, with saved flows you can persist, reload, and manage across sessions.

For programmatic use, GraphWorkflow is exposed through the Swarms Cloud API, documented in the GraphWorkflow section of the Swarms docs. The same compile-once engine described in the paper runs your graphs on managed infrastructure, and it scales to workflows with hundreds of agents, which is precisely the regime where the paper shows orchestration overhead matters most.

Conclusion

Agent workflows are executed often enough, from cold enough starts, and at large enough fan-outs that orchestration overhead has become a systems problem rather than a rounding error. The paper's answer is an old idea applied cleanly: move every analysis a static DAG permits into an explicit, cached, invalidation-safe compile step, and leave the run loop nothing to do but sweep a frozen plan with a single shared pool and an inline path for sequential segments.

Beyond the specific numbers, the cost taxonomy and released harness are intended to outlive them: they give the agent-infrastructure community a way to compare orchestrators by regime, cold path versus steady state, depth versus width, rather than by anecdote. If you build multi-agent systems, the paper is worth your time, and the benchmark is worth running on your own hardware.

Links and Resources