Choosing an Agentic AI Framework: LangGraph, CrewAI, OpenAI Agents SDK, Google ADK and Microsoft Agent Framework

There are now dozens of frameworks for building AI agents, and new versions arrive every few weeks. Rankings of the “top ten frameworks” date almost as soon as they are published: projects are renamed, merged into successors or move into maintenance mode. A better approach is to understand what a framework does for you, decide which properties matter for your product, and test a short list against your own tasks.

This guide explains the job a framework does, compares the most widely used options as of November 2026, and gives a scored method for choosing. If you are still deciding whether you need an agent at all, start with our guide to what AI agents are and where they fit.

What a framework gives you, and what it does not

At its core, an agent is a loop: a model chooses an action, your code executes a tool, the result goes back to the model, and the loop continues until the task is done. You can write that loop yourself in a few hundred lines. Frameworks earn their place by handling what becomes painful at scale.

Anthropic’s guidance on building agents makes a point worth repeating: frameworks make it easy to start but can add layers of abstraction that hide the prompts and responses underneath, which makes debugging harder. Whatever you choose, make sure you can see exactly what is sent to and returned from the model.

The two control models

The biggest practical difference between frameworks is how much of the control flow you define.

• Explicit control (graphs and workflows). You define nodes and edges — steps, branches, loops and where the model decides. The model operates inside a structure you can see, test and reason about. This suits regulated processes, long-running tasks and anything that must resume after a failure.
• Delegated control (agents and roles). You define agents, their instructions and tools, and let the model decide the sequence, including handing work to other agents. This is faster to prototype and suits open-ended work, but behaviour is harder to predict.

Most mature frameworks now offer both, so the question is which one is the native, best-supported path. Teams building customer-facing or high-risk workflows usually want explicit control with agentic steps inside it.

The main frameworks compared

The table below summarises the options we are most often asked about. Licences and status were checked against each project’s repository or official announcement on the date shown at the end of this article.

LangGraph

LangGraph models an agent as a graph of nodes that share state. You decide where the model makes choices and where deterministic code runs. Its strengths are durable execution — runs can be checkpointed, paused for human input and resumed — and fine-grained control. The trade-off is a steeper learning curve and more code than role-based frameworks. It works with or without the wider LangChain library, and is a strong default when reliability and auditability matter more than speed to first demo.

CrewAI

CrewAI is built around a team metaphor: you define agents with roles, goals and tools, and tasks for them to complete. It is independent of LangChain and quick to get running, which makes it popular for prototypes of research, content and analysis workflows. For production, teams typically add explicit flows around the crew so that sequencing, retries and approvals are predictable. Test carefully how it behaves when an agent loops or a tool fails.

OpenAI Agents SDK

The OpenAI Agents SDK is deliberately small. Its core concepts are agents (a model with instructions and tools), handoffs between agents, guardrails on input and output, sessions for conversation history, human-in-the-loop support and built-in tracing. It is provider-agnostic in principle but naturally best integrated with OpenAI’s models and tools. It suits teams that want a thin layer they can understand fully.

Google Agent Development Kit

Google’s ADK is code-first and open source under Apache 2.0, with frequent releases. It combines agents and multi-agent hierarchies with a graph-based workflow runtime that supports routing, fan-out and fan-in, loops, retries and human-in-the-loop steps, plus a tool-confirmation flow that can require approval before a tool runs. It integrates closely with Vertex AI and Cloud Run for deployment but can be used with other models.

Microsoft Agent Framework

Microsoft announced version 1.0 of Agent Framework on 3 April 2026 for .NET and Python. It brings together the agent abstractions of Semantic Kernel and the multi-agent orchestration ideas of AutoGen in one framework, with graph-based workflows for explicit control. AutoGen is now in maintenance mode, receiving bug fixes and security patches, and Microsoft provides migration guides from both predecessors. If a vendor proposes AutoGen for a new build, ask why.

Others worth knowing

LlamaIndex remains a strong choice when retrieval over documents is the heart of the agent. Some teams also use lighter libraries such as Pydantic AI or smolagents for small, typed agents, and cloud providers offer managed agent services. Managed services reduce operational work but increase dependence on one vendor’s runtime, so weigh them with the lock-in questions below.

Matching frameworks to common use cases

Rather than asking which framework is best, ask which is the natural fit for the kind of system you are building.

Interoperability: MCP and agent-to-agent protocols

Two developments reduce how much the framework choice locks you in. The Model Context Protocol (MCP) has become a common way to expose tools and data sources to models, and several of the frameworks above, including the OpenAI Agents SDK and Google ADK, list MCP tool support among their core features; others support it through adapters. If you implement your tools as MCP servers, they can be reused by a different framework, a desktop assistant or a coding agent without rewriting.

Agent-to-agent protocols aim to let agents built on different frameworks delegate tasks to each other. They are useful when separate teams or vendors own different agents, but they add network calls, authentication and failure modes. For a single product team, keeping agents in one framework and one process is usually simpler.

The practical rule is the same in both cases: put stable contracts at the boundaries — tool schemas, event formats, evaluation cases — and treat the orchestration framework as the most replaceable layer.

Selection criteria that matter in practice

A scored shortlist: worked example

Consider a team building a level 2 support agent — it prepares refunds and address changes for staff approval — on a Python and AWS stack, using models from two providers. They weight control, recovery and observability highest because staff approvals pause runs for hours.

Microsoft Agent Framework was excluded because the team has no .NET or Azure footprint. For a .NET team on Azure, the result would likely reverse. The scores narrow the field to two candidates for a hands-on bake-off; they do not replace it.

Run a two-week bake-off

1. Pick three real tasks of increasing difficulty, such as a simple lookup, a multi-step investigation and a task that requires approval and resumption.
2. Build the tools once, independently of any framework, as plain functions or MCP servers with their own permission checks.
3. Create a shared evaluation set of 30 to 50 cases with expected outcomes, including failures and adversarial inputs.
4. Implement each task in two frameworks with the same models and tools.
5. Measure task success rate, steps and cost per successful task, latency, and how long it took to diagnose three deliberately injected faults.
6. Review the code with the engineers who will maintain it. Readability and debuggability are real costs.

This usually produces a clear winner and, just as importantly, a team that understands how the framework fails.

Reduce lock-in by design

• Keep tools framework-independent. Tools exposed as plain functions, internal APIs or MCP servers can move with you.
• Store prompts and instructions as versioned files, not buried in framework-specific classes.
• Own your evaluation set and harness. It is the asset that lets you change frameworks or models safely.
• Export traces to your own observability stack where possible, rather than relying only on a vendor dashboard.
• Wrap model calls behind a thin interface so routing and provider changes do not ripple through the codebase.
• Be cautious with hosted runtimes. They are often where the real switching cost lies.

Production checklist, whatever you choose

Framework choice rarely decides whether an agent succeeds in production. These items do:

• Permissions inside tools. Every tool checks the caller’s identity, tenant and limits itself; it does not trust the framework or the model.
• Budgets per run. Maximum steps, tokens, time and cost, with a defined hand-over when a limit is reached.
• Versioned prompts, tools and models. Each release records exactly which versions ran, so a regression can be traced and rolled back.
• An evaluation gate in CI. Changes to prompts, tools, models or the framework version run against the evaluation set before release.
• Tracing with redaction. Full traces for debugging, with personal and secret data masked before storage.
• Upgrade discipline. Pin framework versions, read release notes and test upgrades against the evaluation set; fast-moving frameworks introduce breaking changes.
• A kill switch. Disable the agent or an individual tool without a deployment.

Common mistakes

• Choosing a framework from a popularity list before defining the use case and autonomy level.
• Starting new projects on frameworks that have moved to maintenance mode.
• Building a multi-agent system for a task one agent with good tools could handle.
• Relying on framework guardrails instead of enforcing permissions inside tools.
• Skipping evaluation because the demo worked.

Frequently asked questions

Do we need a framework at all?

Not always. A single agent with a handful of tools can be written directly against a model provider’s API. Adopt a framework when you need durable state, human approvals, multi-step orchestration or consistent tracing across many agents.

Is AutoGen still a good choice?

For new projects, no. Microsoft has positioned Agent Framework as the successor to AutoGen and Semantic Kernel, and AutoGen receives only maintenance updates. Existing AutoGen systems should plan a migration.

Which framework is best for multi-agent systems?

CrewAI, Google ADK, Microsoft Agent Framework and LangGraph all support multiple agents. The better question is whether you need several agents. Start with one and split only when you can show a benefit.

Can we switch frameworks later?

Yes, if tools, prompts and evaluations are kept independent of the framework. The orchestration code will need rewriting, but that is usually the smaller part of the system.

Are these frameworks free?

The libraries compared here are open source. Costs come from model usage, hosting, observability platforms and any managed runtime you adopt.