AI agent frameworks compared: which ones scale in production

LangGraph, CrewAI, AutoGen, the OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, and Pydantic AI all do the same three things: they call a model, they call a tool, and they decide what happens next. The framework you pick decides who controls that third step, and that single choice is what determines whether your agent survives contact with real traffic or burns through your API budget in a loop nobody notices until the bill arrives.

That is not a hypothetical. A static analysis of 6,549 real agent repositories found 68 confirmed cases of exactly that failure, spread across every major framework, and 95.6% of them caused API cost exhaustion before anyone caught it.

This blog covers seven frameworks that show up in real production stacks in 2026, what actually differs between them, where each one breaks, and how to pick without wasting three weeks running the same starter tutorial seven times.

Why does an AI agent framework matter at all?

A framework matters because "call a tool, look at the result, decide the next step" is not a solved problem the way a for-loop is. The decision of what to do next has to be made by something, and that something is either a human writing explicit rules, or the model itself, choosing token by token whether to continue. Every framework on this list is really just a different opinion about how much of that decision to hand to the model versus how much to pin down in code.

Get that balance wrong in one direction, and you write a brittle script that breaks the moment a user asks something outside the happy path. Get it wrong in the other direction and you get an agent that decides, on its own, to keep calling the same tool.

Sai Ashant, an AI research engineer who has shipped agents at an early-stage startup, put a number on what that costs: his team burned through $200 in API spend in under five days, against a $200 monthly budget, from agents stuck retrying steps they'd already failed. His fix wasn't a smarter model. It was treating the framework as what decides how much rope the model gets, not as a convenience wrapper.

Python installs are not where the framework debate is. LangGraph, Strands, and the OpenAI Agents SDK lead by a wide margin; Microsoft's unified successor is still a fraction of the two frameworks it replaced.

How does an agent framework actually decide what happens next?

Strip away the branding, and there are three real answers to that question, not seven. Every framework in this blog is a variant of one of them.

The graph model: you draw the flow

LangGraph, Google ADK, and Microsoft Agent Framework model an agent as nodes in a directed graph with explicit edges. You define exactly what happens after each step, including the routing logic for what to do when a step fails, or a human needs to approve something. Nothing is hidden. As one comparison of production coding-agent teams put it, this is "the opposite of let the LLM figure it out. You tell the graph what happens next."

The mechanism that makes this durable is checkpointing. LangGraph saves the graph's state at every "superstep," so a crashed process can, in principle, resume from the last saved point rather than starting over. That is a real capability, and it is also more limited than the marketing suggests, which the next section covers in detail.

The crew model: you assign roles

CrewAI models an agent system as a team. You write a researcher, an analyst, and a writer, each with a role, a goal, and a backstory, and task outputs move sequentially from one to the next. There is no shared state graph underneath it; each agent hands its output forward like a relay baton. This is the fastest framework to get a demo running in, and it is also the one where "fast to start" and "hard to debug at scale" are the same design decision showing up twice.

The handoff model: agents transfer control

The OpenAI Agents SDK models delegation as an explicit function call: transfer_to_agent(). One agent holds the conversation until it decides another agent is better suited, then hands over control and the conversation history moves with it.

Mateo, who runs comparative agent-framework teardowns at arcade.dev, traced this pattern across LangGraph, the OpenAI SDK, and Google ADK and found all three implement it as a tool call under the hood, even when the surface API looks different. His preference after inspecting the actual traces: LangGraph gives you the most control over exactly what context gets forwarded in a handoff, closely followed by the OpenAI SDK. Google ADK's transfer_to_agent is elegant but forwards the entire invocation context with less fine-grained control.

Three execution models, three different answers to who decides what happens next.

Which AI agent frameworks run in production, and how do you tell?

"Popular on GitHub" and "runs in production" are not the same claim, and most comparison content conflates them. Here is what each framework actually is, pulled from its own documentation and its current install numbers.

LangGraph

LangGraph reached 1.0 in October 2025 with zero breaking changes, which is itself a signal: the team stabilized the API rather than continuing to reshape it. It leads on Python installs by a wide margin, at 57.7 million PyPI downloads in the 30 days to 9 September 2026.

Its defining feature is recursion_limit, a hard cap on graph steps that defaults to 25 and raises GraphRecursionError when exceeded. That default is low enough that teams doing anything beyond a simple ReAct loop routinely raise it, and issue trackers show cases where the limit stops functioning as a safety net entirely, silently absorbing every step until it fires with no warning beforehand (see langgraph#6731).

The most important thing to understand about LangGraph's durability story is a distinction most comparison posts blur: checkpointing is not the same thing as durable execution. LangGraph checkpoints state at every superstep, which means the data survives. But the open-source library runs in a single process. If that process dies mid-run, the execution itself dies with it; nothing automatically detects the failure, decides where to re-enter the graph, and restarts it.

That responsibility falls on you, unless you attach an external durable-execution layer like Temporal, whose plugin runs each LangGraph node as a Temporal Activity so the run itself, not just its data, survives a crash.

CrewAI

CrewAI sits second by adoption at 22.3 million monthly downloads, and it earns that position through onboarding speed. A three-agent crew, each with a role, a goal, and a task, runs in roughly 20 to 35 lines depending on which comparison you read. Its cost controls are also its simplest: max_iter caps how many reasoning loops one agent runs, max_rpm caps requests per minute across the whole crew, and max_execution_time sets a wall-clock cutoff. These are agent-level and crew-level settings you configure once, not something you have to build.

What CrewAI does not give you natively is durable execution. Its two built-in persistence mechanisms, task output caching and task replay, let you re-run a crew from a specific task after a failure, but neither survives a process crash the way a real durable-execution engine does; production deployments that need crash-survivability typically wrap CrewAI in Dapr Workflows, running each task as a durable activity.

The OpenAI Agents SDK

The OpenAI Agents SDK sits third by installs at 27.9 million monthly downloads, ahead of CrewAI, which tells you something about how much of the ecosystem is now building directly against a single-provider SDK rather than a model-agnostic layer. Its stop condition is max_turns, and exceeding it raises a typed MaxTurnsExceeded exception rather than failing silently.

The SDK's handoff pattern is its core abstraction: agents pass full conversation history to whichever agent they hand off to. A separate as_tool() pattern lets one agent call another as a subroutine that returns a result without taking over the conversation, a distinction worth understanding before you pick one over the other.

Google ADK

Google ADK crossed GA for its Java 1.0 release in 2026 and sits at 16.8 million monthly downloads. Its stop condition, max_llm_calls on RunConfig, defaults to unbounded when set to zero or below, and the documentation explicitly flags that as "not recommended for production."

There is a real operational gap worth knowing before you commit: teams deploying to Vertex AI Agent Engine through ADK's App object have reported that RunConfig, and by extension max_llm_calls, cannot currently be passed through that deployment path.

That means the safety cap that works locally may not carry into your production deployment target. If you're deploying through Vertex, verify this against the current ADK release before you assume the cap you tested locally is the cap running in production.

Microsoft Agent Framework

This is the newest entrant and the one with the most misleading momentum narrative. Microsoft merged AutoGen and Semantic Kernel, its two previously separate agent projects, into a single SDK that hit GA on 3 April 2026. Both predecessor frameworks moved to maintenance mode: bug fixes and security patches only, no new features.

Five months after that GA, the numbers tell a story most coverage of the merger doesn't mention: Microsoft Agent Framework pulls 927,000 monthly downloads, while AutoGen and Semantic Kernel combined still pull 2.39 million, meaning the deprecated frameworks are still outrunning their GA successor by more than two to one.

If your team is on either predecessor, Microsoft's own guidance is to migrate, since neither is receiving new capability. But "migrate eventually" and "the new thing has already taken over" are different claims, and the install data says the second one is not yet true.

Its differentiator is a genuinely well-designed checkpointing model: workflows execute in "supersteps" using the same Pregel computation model LangGraph uses internally, and it is, by one independent durability audit, "the most explicitly designed checkpointing system of any agent framework" reviewed. That audit's conclusion is worth sitting with, though: explicitly designed checkpointing is still checkpointing, not durable execution, and Microsoft Agent Framework repeats the same fundamental gap as LangGraph, CrewAI, and Google ADK: it saves state, but leaves failure detection, automatic recovery, and duplicate-execution prevention to you.

Pydantic AI

Pydantic AI is the one framework here built by a team, Pydantic, whose validation library already sits underneath the OpenAI SDK, the Anthropic SDK, Google ADK, LangChain, and most of the rest of this list. It sits at 9.4 million monthly downloads, smaller than the others by volume, but its cost-control story is the most complete of the seven.

UsageLimits lets you cap request_limit, total_tokens_limit, and, uniquely among the frameworks compared here, cost_limit in actual dollars, checked after every model response. None of the other six frameworks expose a first-class dollar-denominated ceiling in the base library; the closest any of them get is a token or turn count, which you then have to convert to a cost estimate yourself.

For durable execution, Pydantic AI is also the most honest about the boundary: it officially co-maintains integrations with four separate durable-execution engines, Temporal, DBOS, Prefect, and Restate, rather than claiming its own in-process checkpointing solves the problem.

Why do agents fail in production even when the demo worked?

Because the thing that made the demo work, the model deciding what to do next on its own, is the exact mechanism that produces runaway loops once nobody is watching every step. A large-scale static analysis of 6,549 real agent repositories with at least one GitHub star confirmed 68 infinite-loop failures across 47 projects, at 91.9% precision, using a tool built specifically to trace whether a repeated feedback path was actually covered by an effective stop condition, not just whether one existed somewhere nearby.

The finding that matters most for framework selection: LangGraph and AutoGen together account for 45 of the 68 confirmed failures, 66.2% of the total, across 31 projects. That is not because those two frameworks are worse engineered. It's because both encode looping behavior through framework APIs, add_conditional_edges and tools_condition in LangGraph, and GroupChat and initiate_chat in AutoGen, rather than through a visible while loop in your own code.

A cap that looks present in your code can be sitting on the wrong scope entirely, and nothing about the code review process catches that, because the loop itself is invisible in the diff.

68 confirmed runaway agent loops across 6,549 scanned repositories. Every one shares the same root cause: no strong bound covered the repeated path.

The distinction the researchers draw is the one that should change how you read your own agent's stop conditions: a bound is only effective if it constrains the actual repeated path, not just some scope adjacent to it. Their case study from a real repository shows the pattern precisely: an inner max_tool_calls cap on a nested tool call did nothing to stop an outer retry loop that kept calling the model, because the cap covered the wrong loop.

A stop condition only works if it covers the actual repeated path, not a scope next to it.

Why it works here: This is the single most actionable, underserved idea in the piece. No competing content explains bound coverage at this level of mechanism.

Three failure patterns account for 69.1% of all confirmed cases: retry feedback with no bound (17 cases), tool-call iteration with no bound (16 cases), and multi-agent chat with no turn bound (14 cases). And the impact is not abstract. API cost exhaustion and model denial of service each appear in 95.6% of confirmed failures. Another 27.9% risk exhausting the context window outright, because the same loop that keeps calling the model is also, in most cases, appending to a growing message history each time it runs.

This lines up with what Anthropic found in its own multi-agent research system. Multi-agent architectures use roughly 15 times more tokens than a single chat interaction, and agents alone use about 4 times more, and token usage explains 80% of the performance variance on their internal evaluations.

That multiplier is the price of admission for the architecture when the task genuinely decomposes into independent parallel work. It is a cost paid without being earned when the task does not decompose, and an unbounded loop is exactly the failure mode that turns a justified 15x multiplier into an unjustified 150x one.

When does the model itself decide continuation, and why does that matter?

The deepest reason this keeps happening across every framework, not just the ones with more findings, is that the exit condition is frequently controlled by the model's own output, not by deterministic code. The static-analysis paper classifies continuation control into six categories: deterministic, model-controlled, tool-controlled, external-state-controlled, exception-controlled, or mixed. A visible if statement that checks whether the model said "done" is not a deterministic bound; it's a bet that the model will eventually say the right word, and 26 of the 68 confirmed failures were exactly that bet failing.

That is the practical version of a rule the Databricks engineer Sandy stated at a recent architecture talk: agent failures are not usually a model problem; they're an evaluation and observability gap. In a case he described from a retail bank, an agent gave a customer the correct account balance while making three duplicate database calls to arrive at it. Nothing was wrong on the surface.

In production, at volume, duplicate calls at that rate become an expensive operation nobody notices without behavioral tracing that inspects what the agent actually did, not just whether the final answer was right.

What should you actually check before you trust an agent's stop condition?

You should verify, for the specific loop you're worried about, that the bound sits on the scope that owns the repetition, not on a step inside it. Concretely, that means checking four things for whichever framework you're using.

Does the bound cover the model call, or just the tool call?

If your framework exposes a per-tool call limit and a separate per-turn or per-run limit, set both, and confirm in your own tracing which one actually fires first when a loop occurs. A cap on tool calls alone does nothing if the model can keep calling itself with a different tool, or with no tool at all, each time producing another billable turn.

Is the exit condition deterministic, or is it reading the model's own output?

If your loop exits on a string match against something the model said, that is a model-controlled exit, and it is fragile by construction. Pair it with a hard, code-level ceiling that fires regardless of what the model says, the way LangGraph's recursion_limit or the OpenAI SDK's max_turns does, so the model-controlled exit is a nice-to-have rather than the only thing standing between you and an unbounded bill.

Does the cap survive your actual deployment path, not just local testing?

Google ADK's max_llm_calls is a real, documented safeguard, and it is also one that reportedly does not currently pass through the App object used for Vertex AI Agent Engine deployment. The general version of this check applies to every framework here: test your cap in the exact deployment configuration you'll run in production, not just in a local script, because the gap between "works locally" and "works deployed" is precisely where these failures hide.

Does checkpointing on its own solve your durability requirement, or do you need a real durable-execution engine underneath it?

If your workflow genuinely needs to survive a process crash mid-run, not just resume from a saved conversation, checkpointing is necessary but not sufficient in LangGraph, CrewAI, Google ADK, and Microsoft Agent Framework alike. All four save state; none of the four, on their own, detect a failed process, decide where to re-enter, and restart automatically. That is what Temporal, DBOS, Prefect, or Restate add, and Pydantic AI is the one framework in this comparison that treats those integrations as first-class rather than as an afterthought.

Start from what the workload actually needs to survive, then pick the execution model that matches.

How do you cut the model cost on top of picking the right framework?

Everything above governs whether your agent stops when it should. A separate, equally real cost sits underneath it even when your agent behaves correctly: which model answers which step. The default in every framework covered here is to route every step, classifying the user's intent, extracting structured fields, drafting the actual response, and verifying it against your evals, to the same frontier model, because that is the framework's out-of-the-box behavior and switching models per step is extra wiring nobody adds unless something forces the question.

That default has a real cost. Classification and extraction are narrow, well-specified tasks; verification against a fixed rubric is also narrow. None of them need the same model that handles open-ended drafting.

ML.ai Code, a coding agent that installs as a VS Code and Cursor extension, is built specifically around this observation. It runs four focused agents: an Explore agent that only reads and searches, a General agent that can edit and run commands, an Architect agent that plans without touching files, and a Plan agent that writes its plan to a file for review. Each one routes to the most cost-efficient model that still clears your quality bar for that specific step, rather than every step landing on the same frontier model by default.

Same four steps, same shipped answer. Routing the easy steps to a lighter model while keeping the hard step on the frontier model cuts the total from $0.70 to $0.43 per completed task.

On the published numbers, that per-step routing takes a four-step coding task from $0.70 with a frontier model on every step down to $0.43, without changing which model handles the step that actually needs frontier-level judgment. The same approach, tested against SWE-bench Verified, the industry-standard benchmark built from real, unmodified GitHub issues, resolved 86% of a 50-instance slice, 28 points ahead of a single frontier model working alone at 58%, because the gap comes from retries and test-driven verification built into the loop rather than one expensive single-shot guess.

None of this replaces the work covered above. A well-routed agent that loops without a bound still runs up an unbounded bill, just at a lower per-turn rate. Getting both right, a stop condition that actually covers the loop, and a router that doesn't send every step to the most expensive model, is what separates an agent that costs what you budgeted from one that doesn't.

What changes once you've read the trace, not just the demo

You now have the three execution models these frameworks actually implement, the specific stop-condition mechanism each one ships, and the one question: does the bound cover the actual repeated path that the research says explains the majority of production agent failures. The first thing worth doing with a live agent you already run is not picking a new framework. It's opening its trace log for the last loop it ran and checking whether the cap that's supposed to stop it actually sits on the step that repeats.

If you're building the routing layer for that agent's coding or engineering workflows next, ML.ai Code applies the same per-step model selection to your editor, so the frontier model only runs where the task actually needs it.

Frequently Asked Questions

Which AI agent framework is best for production?

There is no single best framework; the right one depends on what your workload needs to survive. LangGraph and Google ADK fit workloads that need explicit, auditable branching and pausing for human approval. CrewAI fits fast prototyping with clearly defined roles. The OpenAI Agents SDK fits workloads built around one agent explicitly handing off to a specialist. None of the seven frameworks compared here provide durable execution, meaning automatic crash recovery, out of the box; that requires attaching Temporal, DBOS, Prefect, or Restate on top.

What is the difference between checkpointing and durable execution in agent frameworks?

Checkpointing saves the agent's state at each step, so the data survives a crash. Durable execution goes further: it detects that a process failed, determines where to resume, and restarts automatically, without duplicating work already completed. LangGraph, CrewAI, Google ADK, and Microsoft Agent Framework all checkpoint. None of the four provide durable execution on their own; each requires a separate engine layered underneath it.

Why do AI agents get stuck in infinite loops?

Because the condition that stops the loop is frequently controlled by the model's own output rather than by deterministic code, and because the cap a developer sets often covers the wrong scope, an inner tool call rather than the outer loop that keeps re-invoking the model. A static analysis of 6,549 real agent repositories confirmed 68 such failures, and 95.6% of them caused API cost exhaustion before being caught.

Is CrewAI or LangGraph better for a production system?

CrewAI is faster to get a working prototype running, typically in 20 to 35 lines for a three-agent crew, and its cost controls, max_iter, max_rpm, and max_execution_time, are simple to set once at the agent or crew level. LangGraph gives more granular control over branching, retries, and exactly what happens at each step, at the cost of more code to write. One pattern that shows up repeatedly in production teardowns: prototype in CrewAI, then migrate to LangGraph once the workflow needs stricter control over execution order and error recovery.

Does Microsoft Agent Framework replace AutoGen and Semantic Kernel?

Officially, yes: both predecessor frameworks moved to maintenance mode after Microsoft Agent Framework's GA on 3 April 2026, meaning they receive security patches but no new features. In practice, adoption hasn't caught up to that migration guidance yet. As of September 2026, Microsoft Agent Framework pulls under a million monthly PyPI downloads, while AutoGen and Semantic Kernel combined still pull well over double that.

How much more expensive are multi-agent systems than a single agent?

Anthropic's own engineering data puts multi-agent systems at roughly 15 times the token cost of a single chat interaction, and single agents at roughly 4 times. Token usage alone explained 80% of the performance variance in their internal evaluations. That multiplier is worth paying when a task genuinely decomposes into independent parallel work; it is a cost paid without being earned when it does not, which is exactly the situation an unbounded loop creates by accident.