Pick almost any agent framework and the first tutorial looks the same: you write some functions, you say which function runs after which, and you hand the wiring to a runtime that walks the steps. Burr and LangGraph both fit that description. You can build the same chatbot in either, and the diagrams you'd draw on a whiteboard would look interchangeable — boxes with arrows.
That surface similarity is exactly why the choice gets made for the wrong reasons. People pick on syntax, or on which logo they saw first. The decision that actually matters is hiding one level down, in a single word each project uses to describe itself. LangGraph calls its abstraction a graph. Burr calls its a state machine. Those are not two names for the same thing, and the difference is the whole point.
The graph is more expressive. The state machine is more legible.
LangGraph's model, in its own docs, is a directed graph: nodes are functions, edges define control flow, and a shared state object is updated as the graph executes. That's a deliberately general structure. A node can route to any node an edge permits; you can build cycles, branches, and fan-outs freely. Expressiveness is the feature. If you can draw the control flow, you can usually build it.
A state machine starts from the opposite instinct: constrain first. In Burr you define actions — Python functions decorated with @action that declare which state keys they read and which they write — an immutable state object that threads through them, explicit transitions that say which action may follow which, and an ApplicationBuilder that assembles the whole thing. That's the entire model: four primitives. The constraint that a transition has to be named means the set of places your agent can be, and the moves between them, is enumerable. You can look at the assembled application and read off every state and every legal edge before a single token is generated.
A graph lets you express any control flow you can draw. A state machine makes you say, up front, exactly which states exist and how you move between them — and that restriction is what you can later audit.
This is the non-obvious part. The two are not ranked — more expressive is not strictly better. They trade against each other. The graph buys flexibility at the cost of bounding: in a sufficiently large LangGraph app, "can the agent ever reach this node, and will it always terminate?" is a question you answer by reasoning about edges and reducers, not by reading a list. The state machine buys legibility at the cost of ceremony: you have to declare transitions you might have left implicit, and in exchange you get a structure you can inspect, test, and explain.
Why "explain" is the word that sells Burr
The reason this matters in production isn't theoretical elegance. It's the moment something goes wrong and someone — a customer, a regulator, your own on-call self at 2am — asks the agent to account for what it did.
Burr's answer to that is structural, not bolted on. Because every step is a named state with a recorded input, output, and transition, Burr ships a built-in telemetry UI that replays exactly which states the application moved through and why, running entirely on your own infrastructure. The state machine is the audit log; the observability falls out of the model instead of being a separate concern you remember to wire up. For agents that touch money, health, or anything with a paper trail, that legibility is the product.
LangGraph is not blind here — it integrates with LangSmith for tracing and evaluation, and its checkpointers persist state so you can pause, resume, and insert human-in-the-loop approval. But notice the shape of the difference: LangGraph's auditability comes from instrumentation layered over a flexible graph, while Burr's comes from the rigidity of the graph itself. One records what happened; the other constrained what could happen in the first place.
The other axis nobody compares: who owns the project
There's a second decision riding along with the technical one, and it's easy to miss because both projects are open source under permissive licenses.
LangGraph is built and stewarded by LangChain, a venture-backed company. That brings real advantages — velocity, a vast ecosystem of integrations, the gravitational pull that gives LangGraph something like 27,000 monthly searches against Burr's quieter ~2,400 GitHub stars. If you want the biggest tool catalog and the most Stack Overflow answers, that mass is a feature.
Burr is a different bet. It began as an open-source project from DAGWorks and, in May 2025, was accepted into the Apache Software Foundation's incubator, migrating from dagworks-inc/burr to apache/burr via a software grant. ASF incubation is slow and unglamorous on purpose: IP clearance, a project management committee, public mailing lists, a release process (the line is at v0.42.0-incubating as of May 2026) tuned for longevity over growth. The payoff is governance — a project under the ASF is far harder to abandon, relicense, or pull behind a paywall than one owned by a single company. That's not a better bet than LangChain's; it's a different one, and which you prefer depends on whether your worry is "will this keep up?" or "will this still be here, on these terms, in five years?"
So which one
The honest decision rule is short. If you're already in the LangChain ecosystem, want maximal graph-shaped control flow, and value mindshare and integrations, LangGraph is the path of least resistance and the safe default — most teams will land here, and they won't be wrong.
Reach for Burr when the constraints invert: when auditability and an explicit, inspectable state model are the point, when you want observability that comes from the framework itself rather than a hosted add-on, when you need to orchestrate decisions that aren't only LLM calls, or when ASF governance is the durability you care about. It's the smaller, quieter project — but "quiet" and "unreliable" are not the same word, and Burr is betting the entire difference on that.
The frameworks look alike because they draw the same boxes and arrows. They diverge on what the arrows are allowed to mean. Decide that first, and the syntax stops mattering.
