If you have read two blog posts about building durable AI agents this year, you have probably seen Cloudflare Agents and LangGraph in the same breath, framed as alternatives. They are not. Putting them on the same line is the category error that sends teams shopping for a winner when the honest answer is that they do different jobs — and that the most interesting architecture uses both.
The fastest way to see the difference is to ask what each one refuses to give you.
LangGraph gives you a graph and no server
LangGraph is an orchestration framework. Its core abstraction is a graph: nodes are steps or agents, edges are the transitions between them, and they all read and write one shared, typed state object. You wire the control flow yourself — the branches, the loops, the points where a human has to approve something before the run continues. That explicitness is the whole point; it is what lets you express logic a linear chain cannot, and inspect it before it runs.
Durability in LangGraph comes from checkpointers. After each step, the graph's state is serialized and written to a backing store, so a run interrupted by a crash, a deploy, or a pending approval resumes from the last checkpoint instead of starting over — the same durable-execution model we compared against Temporal. The catch is in the word "backing store": LangGraph does not include one. You supply Postgres or Redis, you operate it, and you keep it alive. The framework is deliberately infrastructure-agnostic — it runs on your laptop, your Kubernetes cluster, or the managed LangGraph Platform — which is exactly why it cannot assume anything about where your state lives.
LangGraph is happy to checkpoint your agent. It just expects you to bring the database, and the server, and the thing that restarts the server.
So LangGraph hands you a precise model of how the agent thinks and stays silent on where it lives. That silence is a feature if you need portability, and a bill if you don't.
Cloudflare Agents gives you a server and no graph
Cloudflare's Agents SDK — the agents npm package, launched in early 2025 and still on a pre-1.0 line as of mid-2026 — inverts the trade. It says almost nothing about control flow and almost everything about runtime.
The mechanism is the part worth understanding, because it is genuinely different from "deploy your framework to a container." Each agent is a Durable Object: a single-threaded, globally addressable micro-server with its own embedded SQLite database, its own WebSocket connections, and its own scheduler. State is not checkpointed to a database you run — the database is inside the agent, and it survives restarts, deploys, and failures by construction. You write this.setState() for small JSON that auto-syncs to every connected client, and this.sql for anything larger. There is no Postgres to provision because the persistence is the platform.
Two consequences fall out of that design, and they are the reason to care:
- Scheduling is native.
this.schedule()takes a delay, a date, or a cron expression, implemented on Durable Object alarms. An agent can wake itself up next Tuesday without a separate queue or worker. - Idle is nearly free. Hibernation means an agent that is doing nothing incurs no duration billing while hibernated, then wakes on the next request, message, or alarm. That changes the economics of the "one stateful agent per user" pattern from frightening to obvious — you can spin up a million of them and pay for the handful that are actually awake.
What you do not get is a graph. There is no node-and-edge abstraction, no built-in branching or cycle model, no first-class human-in-the-loop gate. You bring your own agent loop, or you reach for Cloudflare Workflows for durable multi-step pipelines. The SDK is a place to run and persist an agent, not a description of how it should reason.
The line that actually divides them
Strip away the feature lists and one sentence sorts it: LangGraph gives you control flow but not a place to run it; Cloudflare gives you a place to run and persist but not a control flow. Their durability stories look similar on a slide and are opposite underneath — LangGraph serializes graph state out to a store you manage, Cloudflare keeps state in a runtime object you never have to host. One is portable and infrastructure-hungry; the other is locked to an edge network and infrastructure-free.
That framing also tells you when to combine them rather than choose. The composable move — bring your own loop, after all — is to run LangGraph.js inside a Cloudflare Agent: the graph owns the reasoning, the Durable Object owns the hosting, the state, and the global low-latency delivery. (Treat that as an architecture pattern, not an officially blessed integration; nobody ships a one-line adapter for it yet.) You get the explicit control flow and the scale-to-zero runtime, and you stop paying the Postgres tax for durability you could have gotten from the platform.
The wrong question is "Cloudflare Agents or LangGraph?" The right one is "do I have a control-flow problem or a where-does-this-live problem?" — and most teams building real agents discover, a few weeks in, that they have both.
