AI Agent Frameworks Compared: LangGraph vs CrewAI vs AutoGen

Why is the most-starred framework in this comparison the one you shouldn't start a new project on in 2026?

AutoGen holds roughly 60,400 GitHub stars, more than CrewAI's 57,100 and LangGraph's 39,800. It hasn't shipped a Python release in 320 days. Its last tagged version (python-v0.7.5) shipped on September 30, 2025. The repo hasn't had a commit pushed since April 15, 2026. And yet every "LangGraph vs CrewAI vs AutoGen" post being written right now is still treating it as a live option.

That gap, between stars and production reality, is what this post is actually about. Not a feature matrix. Not a benchmark that can't be audited. The evidence of where each of these frameworks breaks when you run it at scale, who maintains it, and what it actually costs when things go wrong.

Every fact here comes from the GitHub REST API, PyPI release history, official READMEs, vendor migration guides, and public issue trackers, all verified on 2026-08-16. Where evidence is one engineer's account rather than a measurement, it's labeled that way.

Key Takeaways

• AutoGen is in maintenance mode per its own README, and the Python package hasn't shipped a stable release in about 320 days. The successor is Microsoft Agent Framework, GA since 2026-04-03. New projects should start there. AG2 is a real option for legacy codebases, and it's a fork, not a rebrand.
• Stars lie; installs are closer to the truth. AutoGen leads on stars (~60K) and trails on monthly PyPI installs (~1M). LangGraph has fewer stars (~40K) and runs at ~71M installs, roughly 65x AutoGen. The gap survives every honest caveat.
• Treat the star-to-install ratio as a freshness signal in reverse. Stars accumulate at peak hype; installs track present-tense production dependence. A high ratio means a project was once exciting and now isn't load-bearing anywhere.
• Verified 2026-08-16 against LangGraph 1.2.11, CrewAI 1.15.16, AutoGen 0.7.5 and Microsoft Agent Framework 1.0. This category moves within weeks, so check those versions on PyPI before you act on any of it.
• Don't pick on star counts. Pick on what shipped, what broke, and what's still being maintained.

If you're scoping this for a real system rather than a spike, the framework choice is one input into building a production agent system, and it's rarely the input that decides whether the thing ships.

Which agent framework should you use in 2026?

The short answer, before the evidence.

Pick LangGraph if you need explicit, auditable control flow and durable state, and you can staff the persistence work it brings. Pick CrewAI if you're prototyping multi-agent workflows fast and you accept that delegation is model-mediated. Don't start on AutoGen: as of August 2026 its README carries a maintenance-mode banner directing new users elsewhere. If you're already on AutoGen, your target is Microsoft Agent Framework, GA since April 2026, and the move is a rewrite rather than an upgrade. And if your workflow is three LLM calls in a loop, use no framework at all.

The metric that should matter (but doesn't show up in comparison posts)

Stars are a lagging indicator. They record what got bookmarked at peak hype, which for AutoGen was the v0.2 launch era in 2024. Stars accumulate indefinitely and are never removed, even when a project goes quiet. Installs are the opposite: a recurring production cost, paid every time CI runs or an image rebuilds.

The numbers have completely decoupled.

LangGraph ships roughly 71 million monthly PyPI installs. AutoGen ships about 1.08 million. That's 65x more installs for the framework with fewer stars. CrewAI sits at roughly 20.7 million monthly installs, real production usage by any reading, but a fraction of LangGraph's volume.

A 65x gap in installs against a lead in stars is a strong signal about where the production load actually is. It's not a popularity contest. It's a load map.

Here's the thing that makes it a procurement problem: PyPI counts include CI pipelines and container rebuilds, so they're not user counts. Treat them as a relative signal, not an absolute. And LangGraph benefits from being pulled in transitively by the wider LangChain ecosystem, which inflates its number relative to a standalone install. AutoGen has no such tailwind, and the gap is still enormous. A 65x gap survives both caveats. A 1.2x gap wouldn't.

Release cadence tells the same story from a different angle.

One more cadence note before we get to the frameworks. CrewAI shipped 1.15.16 on August 14, 1.15.15 on August 12, 1.15.14 on August 8, and two releases on August 5. That's roughly ten releases in nineteen days. Whether that signals fast fixes or fast churn depends on how much you trust their release process, but either way, lock your version before you start.

The mental models (and why the model matters)

LangGraph is a directed graph with a central state object. Agents are nodes. Edges define flow. Conditional edges handle branching. Reducers merge concurrent state updates. You draw the control flow; the LLM executes within it. The mental model is a state machine, and the framework enforces it in code.

Built-in primitives: durable execution (checkpointing, resume from interruption), human-in-the-loop (interrupt the graph, collect input, resume), short-term and long-term memory. It's the most explicit of the three about where control lives.

CrewAI is a role-based team. Every agent carries a role, a goal, a backstory, and tools. A Crew executes tasks sequentially or hierarchically. In hierarchical mode, an auto-generated manager agent delegates and reviews. The runtime provides the hierarchy; the delegation decisions inside it are model-mediated rather than encoded as developer-defined conditional edges. Flows, a newer primitive, are event-driven pipelines that offer more predictable production control: one LLM call per step, no autonomous delegation.

AutoGen, in its current maintained mode, is a conversation-driven multi-agent runtime. Two-agent chats, group chats with an LLM-powered speaker selector, sequential and nested conversations. The successor, Microsoft Agent Framework, has the same patterns but a different architecture. AutoGen itself is not being developed.

AutoGen's licence deserves a flag of its own, because it's a procurement problem rather than a technical one: GitHub detects the repo as CC-BY-4.0, the README describes a dual CC-BY-4.0 and MIT arrangement, and PyPI reports MIT. Your legal team will not enjoy that conversation.

Where LangGraph breaks in production

The failure point isn't the API. It isn't the tooling either.

It's the checkpointer, and specifically, what happens to your Postgres instance when nobody has planned for checkpoint growth.

Tadeo Donegana Braunschweig, an engineer at Tiendanube, published the clearest public account of this in April 2026. At more than 120,000 conversations per week, his team's checkpoint tables grew without bound. The open-source checkpointer ships no native TTL. An average conversation produced roughly 93 rows across four checkpoint tables after just two messages and three tool calls.

Two messages, and your database is ninety-three rows heavier.

In staging, checkpoint_blobs alone hit 56 MB after a single week of traffic. His summary: operational databases should store operational state, not historical exhaust.

This isn't one team's unlucky configuration. On the LangGraphJS tracker, issue #1138, "How do I keep data in Postgres checkpointer database from growing unbounded?", was opened in April 2025 and is still open. LangChain's own documentation suggests running a cron job to delete old checkpoints. That's a clear statement about where lifecycle management lives.

The vendor shipped a fix, and it's worth reading the numbers carefully because they get misquoted. PR #7586 introduced DeltaChannel, which stores a small sentinel value plus replay instructions instead of re-serializing the full accumulated state at every step.

The default reducer writes more than a hundred times what the tightest DeltaChannel configuration does, and the middle row is the setting most teams actually want.

Three caveats before you bank on it. It landed in LangGraph 1.2.0 on 2026-05-12, it's marked beta, and it's opt-in: upgrading does nothing until you actually annotate the channels you want it on. Bloat already written to your tables stays written.

Here's where it gets expensive for teams that didn't budget the operational work. LangGraph's checkpoint packages (checkpoint, checkpoint-postgres, checkpoint-sqlite) version separately from core. If you pin core and float the checkpointers, you've secured the wrong half of the stack.

The typed-state complaint

Separate from persistence, there's a recurring ergonomics objection about state typing, and it needs stating carefully because the strong version of it is wrong. StateGraph accepts a real schema: TypedDict, a dataclass, or a Pydantic BaseModel if you want recursive validation. LangGraph is not untyped.

The gap is one level up. LangChain's own documentation notes that the higher-level create_agent factory does not support Pydantic state schemas, and the factory is where most teams start. So the typing is available on the API you graduate to, not the one you begin on. One engineer on Hacker News put the frustration this way:

"My experience with langgraph is you spend so much time just fixing stupid runtime type errors because the state of every graph is a stupid JSON blob with very minimal typing, and it's so hard figuring out how data moves through the system."

That's one account. But it's not floating free of evidence, and the evidence points at the same seam. Issue #5891 (TypeError: Type is not msgpack serializable: Send) is a create_react_agent bug, which is exactly the factory path that can't take a Pydantic schema. Issue #740 (InvalidUpdateError on state writing) names the same root cause: state shape discovered at runtime rather than at definition time.

The practical read: LangGraph gives you the tools to keep state contracts honest, and it doesn't force you to use them. The risk isn't missing typing, it's contracts drifting across nodes because nothing made you declare them. Define the schema explicitly at the boundaries that matter, and most of this class of bug disappears.

Where LangGraph is actually strong

Explicit node structure makes execution topology predictable: the graph decides which nodes run and in what order, rather than the model deciding for itself. Token usage is a separate question, and it stays dependent on prompt size, retrieved context, tool outputs, retries and model behaviour. Predictable structure is not a predictable bill, which is why the cost section below argues what it does.

What the structure does buy you is auditability. LangGraph's control flow is enforced in code, not suggested in a prompt, so when a compliance reviewer asks which agent can call which tool under what condition, you can point at an edge instead of a paragraph of instructions.

Where CrewAI breaks in production

Delegation.

Not as a theoretical concern, but as a documented, reproducible failure mode that's been sitting in the issue tracker for over a year.

The 15,759-token incident. Partha Sarkar documented this in detail: a three-agent support crew (triage, technical, billing) running in hierarchical mode received a purely technical query. The manager invoked all three agents, including billing. The billing agent's response then overwrote the correct technical answer. The run consumed 38 seconds and 15,759 tokens to produce roughly 200 tokens of output. Nothing errored.

Root cause: hierarchical mode doesn't enforce conditional branching or true delegation. The manager decides, and when the model's judgment wobbles, the control flow wobbles with it. Look at what the failing workload actually was: routing a support question to the right specialist is ordinary chatbot routing, and it's the case a multi-agent crew is supposed to handle best. His fix was to replace the built-in manager with a custom manager agent carrying explicit step-wise instructions. After that change, technical-only runs took 24 seconds and about 10,000 tokens. You recover roughly a third of the cost by hand-rolling the orchestration the framework was supposed to handle.

Three delegation bugs in eleven months

They all show the same theme. Issue #2606 (April 2025): manager passes dicts while the schema expects strings. Issue #4783 (March 2026): manager executes tasks with its own tools and never delegates, collapsing hierarchical into sequential. Closed as not_planned. Issue #3925 (November 2025): with English task descriptions the manager delegates correctly; with Japanese descriptions the manager answers alone without delegating. Reproducible in both directions.

Sit with what that last one implies. The control flow of a production system changed because the natural language of its task descriptions changed. No framework that enforces orchestration in code can exhibit that behaviour, which makes #3925 the cleanest available proof that CrewAI's hierarchy is a request written into the prompt, not a rule the runtime enforces. If you run CrewAI in a non-English market, make this your regression test before you ship.

The open security issue

Issue #5057, "Memory content injected into system prompt without sanitization enables indirect prompt injection," has been open since March 2026 and was last updated in July. Mechanically, lite_agent.py concatenates retrieved memories straight into the system prompt. Anything written to memory inherits system-level instruction authority. It's rated Medium and cites the OWASP Agentic Security Index. Nearly five months on, it's still open. If you use CrewAI memory with any user-influenced content, apply the recommended mitigation (moving memory out of the system prompt and into user messages) before you ship.

The release cadence as a risk

CrewAI shipped its 1.0.0 rewrite on October 20, 2025, with breaking changes. Since then, the pace has been relentless, roughly a release every two days. That means your pinned version is end-of-life within weeks. It also means bugs get fixed fast. Weigh both.

Where CrewAI is actually strong

For teams that need to ship a multi-agent prototype quickly, CrewAI's higher-level abstractions are genuine. The role/goal/backstory model means you can get a working crew running in hours. The 20.7 million monthly installs reflect real production usage. And if something breaks, there's a good chance a fix is already in the next release.

Where AutoGen breaks (and why "migrate off" is the right starting point)

AutoGen is in maintenance mode. That's the sentence that should end the discussion for anyone starting a new project. But it's worth understanding what that means in practice, because there are teams already running on it who need to know the shape of their exit.

The README carries a maintenance-mode banner verbatim: "AutoGen is now in maintenance mode. It will not receive new features or enhancements and is community managed going forward. New users should start with Microsoft Agent Framework." Last tagged release: python-v0.7.5, September 30, 2025. Last repo push: April 15, 2026. That's roughly ten and a half months without a release, and no archive banner marks the repo, so at a glance the project doesn't look dead. It just is.

The lineage is worth knowing. Original authors Chi Wang and Qingyun Wu left Microsoft in November 2024 and forked the project to AG2 (ag2ai/ag2), now at v1.0.x under Apache-2.0. Microsoft shipped Microsoft Agent Framework (MAF) 1.0 GA on April 3, 2026, developed by the core AutoGen and Semantic Kernel teams. MAF ships for Python and .NET under MIT, supports A2A and MCP interop, and has stable APIs with an LTS commitment. Official migration guides exist for AutoGen to MAF and Semantic Kernel to MAF.

The migration is a rewrite, and one change is silent

Microsoft's own migration guide reads as a from-scratch guide, not an upgrade guide. AssistantAgent becomes Agent, and the state semantics invert underneath the rename. AssistantAgent maintained conversation history as part of its state. Agent is stateless and does not maintain history between invocations. Nothing errors when you port the code. Your agent doesn't throw an error, it just stops remembering, and you discover it from a customer complaint.

There's a second inversion in the same rename. AssistantAgent is single-turn unless you raise max_tool_iterations. Agent is multi-turn by default. So the migration turns one component from "remembers, but acts once" into "acts many times, but remembers nothing."

Both inversions hide inside a port that looks like a rename:

1# AutoGen: single-turn by default, and the agent holds the history
2agent = AssistantAgent(name="support", model_client=client, tools=[lookup])
3await agent.run(task="What did I order?")
4await agent.run(task="And when does it ship?")   # remembers the first turn
5
6# Agent Framework: the port compiles, runs, and errors on nothing
7agent = Agent(name="support", chat_client=client, tools=[lookup])
8await agent.run("What did I order?")
9await agent.run("And when does it ship?")        # no memory of turn one
10
11# Nothing raised. The agent just answers the second question blind,
12# and you find out when a customer complains. Thread state is now
13# yours to carry explicitly between invocations.

One more gap to scope before you commit: AutoGen supports local code execution tools, and Microsoft's guide states that this feature is planned for future Agent Framework versions. Today it's a hole.

Termination by string matching

AutoGen terminates when an LLM generates the exact token TERMINATE. Because models are sloppy with exact tokens, they emit terminate, Terminate., Task terminated, or wrap it in markdown. None of those match, so the loop continues and you pay for every turn. Speaker selection fails the same way: if the selector's output doesn't exactly match an agent name, the same agent gets re-selected repeatedly, producing a single-agent infinite loop.

Issue #12 ("force TERMINATE") dates to July 2023. On classic AutoGen, pair max_consecutive_auto_reply with a token ceiling at your gateway before you deploy anything. Note that the knob doesn't carry over to Agent Framework, which is one more reason to treat the migration as a rewrite. And a framework in maintenance mode isn't shipping fixes for any of it.

One honest caveat

AG2 is a real option for teams on classic AutoGen with heavy investment and no appetite for a Microsoft-shaped migration. The original authors maintain it. It's at v1.0.x under Apache-2.0, actively released, with the classic API preserved in a separate ag2-classic repo. It's a smaller ecosystem and a fork rather than a corporate-backed project, so weigh that accordingly.

What multi-agent orchestration actually costs

Roughly 2.3x a sequential baseline, if you pick the most accurate pattern.

Kulkarni and Kulkarni benchmarked multi-agent architectures on SEC filings (arXiv:2603.22651, March 2026). Reflexive self-correcting loops achieved the highest field-level F1 (accuracy per extracted field) at 0.943, at 2.3x the cost of a sequential baseline. Hierarchical supervisor-worker reached F1 0.921 at 1.4x cost, the best cost-accuracy point in the study. A hybrid recovered 89% of the reflexive gains at 1.15x baseline cost.

Those patterns map onto the frameworks directly. CrewAI's hierarchical process is the supervisor-worker row. LangGraph's cyclic graphs are how you build the reflexive loop. AutoGen's group chat is a third shape, less disciplined than either. Practically: if you're paying 2.3x for reflexion across every field in a document, you're overpaying, because the hybrid recovers most of the accuracy for a 15% premium.

None of these three will stop a run on spend

One finding that should shape how you budget this: across LangGraph, CrewAI and Microsoft Agent Framework, every available control knob bounds structure. None bounds money.

Two problems hide in that table.

Default ceilings differ by 50x and nobody compares them. LangGraph allows 1,000 supersteps. MAF allows 100 workflow iterations. CrewAI allows 20 iterations per agent. CrewAI's looks tightest until you notice it's per-agent, so a five-agent crew's effective ceiling multiplies, and max_retry_limit=2 multiplies it again.

A structural limit also treats a 200-token call and a 200,000-token long-context call as identical events. That's why teams file "we set max_iter, why was the bill still huge?" tickets. You capped the number of steps, but your bill is counting tokens, and the two move independently. Watching it happen isn't an option either: CrewAI's usage metrics are strictly post-hoc, available after kickoff() completes. The bill only shows up once the run has already finished and been paid.

If spend is a hard constraint, put the cap at your gateway or proxy layer, where you can actually count tokens as they're spent.

When to skip the framework entirely

Sometimes the right agent framework is none.

Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027 (press release, June 2025). Cost, unclear business value, and inadequate risk controls are the leading reasons. Cost and risk controls are exactly the two things these frameworks don't give you natively.

Anthropic Engineering's "Building Effective AI Agents" makes the case most directly: the most successful implementations weren't using complex frameworks but simple, composable patterns. If your workflow is a fixed sequence of three LLM calls with a retry, a framework adds an abstraction layer, a dependency tree, and a migration risk for very little. Plenty of production AI features never need orchestration at all, and finding that out early saves the migration you'd otherwise pay for later.

The verdict

Choose LangGraph if you need explicit, auditable control flow; you need durable execution or human-in-the-loop steps; your workflow has real branching and shared state; and your team will own the persistence work. Budget that work upfront: checkpoint TTL deletion, selective persistence on the supervisor graph only, and pinning the checkpoint packages separately from core. Its persistence is your problem, not the vendor's.

Choose CrewAI if you're shipping a multi-agent prototype this quarter, you want higher-level abstractions, and you can absorb the operational risk. Pin your version. Write delegation assertions into your test suite. Apply the #5057 memory mitigation before user content touches agent memory. Ten releases in nineteen days means your pinned version is end-of-life within weeks, so plan the upgrade cadence rather than discovering it.

Don't start on AutoGen if you're picking a framework today and have no legacy investment holding you there. If you're already on it, scope the MAF migration as a rewrite, put the stateless Agent behavior at the top of your test plan, and know that local code execution is a feature gap in MAF today. Its termination depends on string-matching a literal token, so pair max_consecutive_auto_reply with a token ceiling until you're off it.

Choose Microsoft Agent Framework if you're a Microsoft shop, you're migrating off AutoGen or Semantic Kernel, or a vendor-backed support path with an LTS commitment is what gets the project approved.

Choose no framework if your workflow is a few deterministic LLM calls and a plain function with retries is still readable. Write the function. Add a retry. Only reach for a framework when the function stops being readable.

The AutoGen lesson isn't that Microsoft abandoned a project. It's that a framework stuck at v0.x was never really a product: it's a research prototype that happened to get famous. Check the maintenance status, the release cadence, and the maintainer's roadmap before you commit. Everything in this post was accurate on 2026-08-16. For this kind of tool, that's not a long shelf life.

Frequently Asked Questions