LangGraph vs CrewAI vs AutoGen: Which Agent Framework Behaves Like Software in Production

Pick the wrong agent framework and the cost arrives months later. A prototype that charmed the demo audience drops sessions under real traffic. Token bills drift upward with no clear owner. Every bug fix becomes archaeology through conversation logs. The three framework families most teams evaluate, LangGraph, CrewAI and the AutoGen line, look similar on the surface. They are not. They disagree on something foundational: what an agent run is.

That disagreement is the whole comparison. Once you see it, the right choice for your workload is usually obvious.

The field as of October 2026

Older comparisons describe a world that no longer exists, so three updates first.

AutoGen split. The AG2 project describes itself as "AG2 (formerly AutoGen)". The original AutoGen-derived code now lives on as AG2 Classic in its own repository. The AG2 team says its 1.0 release is not a drop-in upgrade from Classic. Microsoft, meanwhile, folded its agent work into Microsoft Agent Framework. Its documentation calls the framework "the direct successor" to both AutoGen and Semantic Kernel, "created by the same teams". It adds graph-based workflows for explicit control over multi-agent execution paths.

CrewAI added Flows. Flows is an event-driven layer with structured state and a @persist decorator, sitting beside the original Crews abstraction. It addresses several of the complaints below, though not all of them.

LangGraph reached 1.x. LangChain describes 1.0 as a stability-focused release for the agent runtime. The graph primitives are unchanged, and checkpointing, persistence and human-in-the-loop remain first class.

The architectural divide

LangGraph:      [State] --> (Node A) --> [Updated state] --> (Node B)
CrewAI Crews:   [Task]  --> (Agent A) --> [Output]        --> (Agent B)
CrewAI Flows:   [Event] --> (Handler) --> [State update]  --> (Event)
AutoGen line:   (Agent A) <-- [Messages / typed events] --> (Agent B)

LangGraph treats a run as a state machine. There is one typed state object. Nodes are plain Python functions that read it and return the fields they want to update. Edges, including conditional edges, are code you write. Nothing routes itself from a hidden prompt.

CrewAI treated a run as a role-play. You declare agents with a role, a goal and a backstory, hand them tasks, and let the framework drive the loop. Flows is closer to an event-driven state machine and is the right starting point for anything production-bound. Crews on its own still suits linear content pipelines. It is not the tool for workflows with branches, approvals or long pauses.

The AutoGen line models a run as a conversation between agents. In AG2 the core concepts are the conversable agent and the group chat. Microsoft Agent Framework keeps the agent abstraction and adds workflows with explicit execution paths, which is a real step toward the state-machine column. At the agent level, though, the mental model is still agents talking to each other. Who speaks next is often decided by another model call.

For a business reader the translation is simple. A state machine behaves like software: the same inputs produce the same path. A conversation behaves like a meeting: directionally useful, hard to budget, hard to audit. Systems that touch money, patient data or legal records should behave like software.

Production comparison

The human-in-the-loop row carries more weight than it looks. The ability to pause, inspect, edit and resume a run days later, from another process, turns an approval step from a UX feature into a control. A framework that makes you build that yourself has handed you the hardest part of the job.

Where unstructured frameworks break

Three mechanisms recur in systems built on conversational or role-play abstractions. These are mechanisms, not war stories.

• ▸Retry storms. A tool call fails with a transient error. A conversational agent sees the error, apologises and tries again. If the service is still down, the loop runs until a token cap or a wall-clock timeout stops it. On a graph, the node catches the exception, increments a counter in state, and routes to an error node after N attempts. The ceiling is in the code.
• ▸Polite loops. Two agents exchange acknowledgements ("Thanks for the context." "Happy to help, anything else?") until a chat manager stops them. This belongs to the older group-chat model and is mostly fixed in the successors, provided you set termination conditions.
• ▸Hidden prompt bloat. Role-based frameworks inject long system prompts to make a model act like a "senior analyst". You pay for those tokens on every call. You also cannot swap in a cheaper model family without re-tuning, because the framework's prompts assume a level of instruction-following. If your margin depends on routing easy calls to small models, the prompts belong in your repository.

None of this makes CrewAI or the AutoGen line bad software. They were designed for different problems than running one workflow at scale on a fixed budget. Whether the work should be split across several agents at all is a prior decision. Four tests decide when splitting into several agents is worth it.

Checkpoint and resume, the feature most comparisons skip

Real workflows pause. A patient intake agent waits for a nurse to confirm a flag. A procurement agent waits for a manager's approval. A customer-service agent waits for the customer to come back after lunch. Keeping a Python process pinned in memory for those pauses is not viable.

LangGraph's checkpointer saves the full state after every node. A run can therefore stop, move to another machine, be inspected and edited, and resume from the same point under the same thread_id. The pause is declared in the graph rather than improvised in a prompt, and the human edit is an ordinary state update. The code for that, and for the other four controls a production graph needs, is in the five production patterns, with code.

When each framework is the right call

Reach for LangGraph when the workflow has branches, approval gates, long pauses or a hard cost ceiling. The same applies when auditability matters, in healthcare, finance, legal work or regulated Gulf deployments. It applies again when you need to swap model families per node to control cost, and when the system has to survive process restarts.

CrewAI Flows is reasonable when your team already knows CrewAI and the workflow is mostly linear with a few branches. It also helps when you want faster scaffolding than LangGraph gives you. The classic Crews abstraction on its own is best left to internal content and research tools.

The AutoGen line is the right call when the point of the system is the multi-agent interaction itself. Examples: simulated debates to stress-test a plan, code-execution loops where one agent writes and another critiques, open-ended research. Between the successors, Microsoft Agent Framework is the safer bet for new work tied to the Microsoft stack. AG2 is the pragmatic choice if you have existing code on the pre-rewrite AutoGen API.

Reach for none of them when your "agent" is a scheduled script with two API calls and a branch. That is a workflow tool or a cron job. n8n vs custom agents shows where that line sits.

Frequently asked questions

We built our pilot on CrewAI. Do we need to rewrite everything? Not everything. Tool definitions, prompts and domain logic port cleanly. What changes is the orchestration layer: how tasks are sequenced, how data moves between steps, how errors and pauses are handled. If your pilot is linear and the budget is predictable, CrewAI Flows may close the gap without a framework switch. If it has branches, approvals or long pauses, moving to LangGraph is usually less work than hardening the existing structure.

AutoGen split into AG2 and Microsoft Agent Framework. Which one do we pick? If you are starting fresh and your organisation is on Azure or .NET, Microsoft Agent Framework is the forward path. If you have production code against the older AutoGen API and need stability without a rewrite, AG2 is the practical fork. For anything that needs strict workflow control rather than open-ended multi-agent exploration, neither is the best fit. A state graph is.

Can we run these frameworks on open-weight models to keep data in-house? Yes, for all three families. Each will talk to a local inference server (vLLM, SGLang, Ollama) serving Qwen, Llama or similar families. The framework choice is independent of the model choice. What matters for on-prem deployments is whether your orchestration layer can checkpoint state to a database you control. The on-prem LLM speed guide covers the inference side.

This week: write down the pauses, branches and irreversible writes

Take the workflow you are about to automate and make three lists. Where does it pause for a person? Where does it branch on a result? Which steps write something that cannot be undone, such as an email, a payment or a record change? If any of the three lists has an entry, choose the state-machine column before writing code. If all three are empty, you may not need an agent framework at all.