2026 Open-Source AI Agent Frameworks: 10 Compared

A universal winner does not exist. For a new project, choose a lightweight SDK for a simple single-agent system, a graph or workflow framework for long-running stateful tasks, and a multi-agent framework only when role separation is a real requirement. This week, build a shortlist of three candidates and test them with the same task, model, dataset, and runtime before committing.

This guide is for:

• Developers building tool-using, coding, or knowledge agents from scratch.
• AI engineers moving a prototype into a continuously running service.
• Technical leads managing framework lock-in, maintenance risk, and infrastructure cost.

Last updated August 17, 2026. Framework status and capability claims were checked against official repositories, licenses, release pages, migration notes, and core documentation. Recheck the same sources before deployment because agent frameworks change quickly.

The shortlist is a candidate pool, not a popularity ranking

To qualify for this comparison, a framework must meet four conditions:

1. Its core code is publicly available under a declared license.
2. It has an official repository or documentation site with current maintenance signals.
3. It can run independently rather than existing only as a hosted console.
4. It provides agent-building capabilities such as tools, model interaction, orchestration, memory, evaluation, or deployment support.

The ten candidates are:

• LangGraph
• OpenAI Agents SDK
• Google ADK
• Microsoft Agent Framework
• CrewAI
• Pydantic AI
• Mastra
• smolagents
• Strands Agents
• LlamaIndex

The selection deliberately mixes different framework categories. LangGraph is a graph-oriented runtime. OpenAI Agents SDK, Pydantic AI, smolagents, and Strands Agents are comparatively thin SDKs. CrewAI emphasizes role-based collaboration. Google ADK and Microsoft Agent Framework cover agent construction, orchestration, and deployment patterns. Mastra is a TypeScript-focused application framework. LlamaIndex is strongest when agents must work with documents, retrieval, and structured data.

Official documentation confirms these distinctions. LangGraph describes itself as a framework for resilient agents, while OpenAI presents its SDK around a small set of primitives such as agents, tools, handoffs, and guardrails. Google ADK emphasizes code-first construction, evaluation, deployment, and hierarchical multi-agent composition. See the LangGraph repository, OpenAI Agents SDK documentation, and Google ADK repository.

Development cost: thin abstractions versus controlled workflows

The fastest first run is not always the cheapest path to production. A minimal agent can hide decisions about state, retries, permissions, and observability that later become application code.

Use the following comparison as a screening tool, not as a final scorecard.

The table shows why “easy to start” and “easy to operate” are different dimensions. smolagents states that its agent logic is intentionally small and close to raw code. That can be useful for learning and experiments. It does not automatically provide a production sandbox for arbitrary code execution. The smolagents repository documents the minimal design and code-agent approach.

Pydantic AI is a better fit when typed inputs and outputs are central to the product contract. Its MIT license and Pydantic-based validation model support a clear boundary between model output and application data. That does not remove the need for retries, idempotency, and persistence around the agent.

Mastra is the strongest candidate in this list for a TypeScript-first product team. Its official repository describes an Apache 2.0 core while identifying enterprise directories with separate licensing. You should inspect the exact packages used by your deployment rather than treating the whole repository as one license. The Mastra licensing and repository notes are the relevant source.

Tool execution: count control points, not integrations

Most frameworks can call a function. That is not the difficult part.

The important questions are:

• Can you validate arguments before execution?
• Can a human approve a sensitive call?
• Can you set a timeout?
• Can you prevent duplicate execution after a retry?
• Can you record the input, output, and authorization decision?
• Can you restrict filesystem, shell, network, and secret access separately?

For low-risk read-only tools, a lightweight SDK can be enough. For example, a weather lookup or database query may only need schema validation, timeout handling, and structured errors.

File writes and command execution require a different design. The agent should not receive unrestricted access to the host. Use a workspace directory, a restricted operating-system user, an allowlist of commands, bounded execution time, and explicit approval for destructive operations.

OpenAI Agents SDK includes tools, guardrails, handoffs, sessions, tracing, and human-in-the-loop features in its documented core concepts. Google ADK documents tool confirmation flows that can require explicit approval. Strands Agents provides native MCP support and supports multiple model providers. These capabilities can support a controlled design, but the framework does not decide your operating-system permissions for you. Review the Strands Agents repository and the official documentation for the other candidates before assigning production permissions.

A practical permission split looks like this:

• Level 1: Read-only information. Search, retrieval, calculation, and metadata lookup.
• Level 2: Reversible changes. Create a draft, open a pull request, or write to a temporary workspace.
• Level 3: External side effects. Send messages, publish content, change records, or call paid APIs.
• Level 4: Host control. Execute shell commands, install packages, access credentials, or modify production systems.

Start your POC at Level 1. Move upward only when the evaluation proves that approval, logging, and rollback work as intended.

State control: choose graphs when time and failure matter

A short conversation can keep state in the application layer. A long-running agent cannot rely on process memory alone.

LangGraph is the clearest choice when state transitions are part of the product. Its persistence model uses checkpointers to save graph state at super-steps. The documented capabilities include human interruption, memory, time travel, and fault recovery. A production design still needs a durable backend; an in-memory checkpointer is suitable for experiments, not process restart recovery. Review the LangGraph persistence documentation.

Choose a graph or workflow framework when your task includes:

• Branching based on validated results.
• Loops with a defined termination condition.
• Human approval before the next step.
• Resume after a worker or process interruption.
• Parallel tool calls with coordinated outputs.
• Audit requirements for each state transition.

Choose a thin SDK when the application already owns the workflow. This is common for a customer-support assistant, a coding helper with a bounded tool set, or a knowledge query endpoint. You can keep the control flow explicit in ordinary application code instead of introducing a graph runtime.

Role-based multi-agent frameworks solve a different problem. CrewAI is designed around role-playing agents and also exposes flows for more structured execution. That can make a research pipeline readable when you truly have separate researcher, reviewer, and editor responsibilities. It can also produce hidden coordination cost if every role adds another model call and context boundary. Use the CrewAI repository to verify current workflow and licensing details.

Observability and recovery: test the failures before the demo

A production POC should deliberately fail. Test at least these three cases:

1. A tool returns an invalid response or raises an exception.
2. The model request exceeds its timeout.
3. The process stops after a tool succeeds but before the next state is recorded.

For each case, check five outcomes:

• Is the failure visible in logs or traces?
• Can you identify the exact tool and arguments?
• Does the system retry safely?
• Can the task resume without repeating an irreversible action?
• Can an operator inspect and approve the next step?

OpenAI Agents SDK documents built-in tracing. Mastra documents logging and observability access through registered agents and workflows. Microsoft Agent Framework documents graph-based workflows with streaming, checkpointing, time travel, and human-in-the-loop patterns. Its repository also covers both Python and .NET, which matters for teams maintaining multiple application stacks. See the Microsoft Agent Framework repository.

Do not confuse a hosted dashboard with open-source core capability. A framework may expose tracing locally while offering richer retention, search, evaluation, or alerting through an external service. Record that distinction in your architecture decision record.

Sensitive data is another hidden cost. Traces can contain prompts, tool arguments, file paths, customer records, and model outputs. Before enabling persistent tracing, define retention, redaction, access control, and export rules. A framework that makes tracing easy can also make accidental data retention easy.

Maintenance and deployment: verify the project behind the label

“Open source” does not mean “low risk.” Check:

• The repository license and any subdirectory exceptions.
• Release frequency and recent commits.
• Migration notes for major versions.
• Supported runtimes and language versions.
• Whether the examples use stable APIs or development branches.
• Whether production deployment requires a hosted control plane.
• Whether your model provider is supported without an unofficial adapter.

The ten candidates are not identical in license terms. LangGraph, OpenAI Agents SDK, CrewAI, Pydantic AI, and LlamaIndex report permissive open-source licenses in their official repositories. Google ADK and Strands Agents document Apache 2.0 licensing. Mastra documents Apache 2.0 for its core while separating enterprise code. Always inspect the exact release you will ship.

LlamaIndex deserves a separate note. Its OSS framework is designed for data connectors, indexing, retrieval, and agent workflows. That makes it a strong candidate for document and knowledge agents. Its repository also distinguishes open-source components from separate hosted data services. Read the LlamaIndex repository before assuming that every document feature belongs to the same deployment model.

A decision matrix for your first three candidates

Use conditions rather than a global ranking:

• Fast prototype with one agent and a few tools: OpenAI Agents SDK, Pydantic AI, Strands Agents, or smolagents.
• Long-running task with approval, branching, and resume: LangGraph or Microsoft Agent Framework.
• Python and .NET enterprise team: Microsoft Agent Framework.
• TypeScript application with integrated workflows: Mastra.
• Role-based research or review pipeline: CrewAI, but validate coordination overhead.
• Document-heavy or retrieval-heavy agent: LlamaIndex.
• Google ecosystem or hierarchical agent design: Google ADK.
• Code execution experiments: smolagents, only inside a properly isolated sandbox.

Keep no more than three frameworks for the POC. A larger shortlist spreads the same test effort too thinly and makes the final decision less reliable.

First week: run a controlled POC

Step 1: Freeze the test contract

Write one task that uses a read-only tool, one structured output, one model, one dataset, and one expected result format. Do not change the task for each framework.

Step 2: Define the failure cases

Add a forced tool error, a delayed model response, a process restart, and a human approval checkpoint. These cases expose framework differences faster than a successful chat demo.

Step 3: Create isolated environments

Use separate virtual environments or containers. Pin framework versions. Store model keys outside the repository. Do not let one candidate reuse another candidate's dependencies or local state.

Step 4: Instrument the same events

Record start time, model call, tool request, tool result, retry, approval, checkpoint, final output, and error. Use the same event names where possible. This prevents a framework with more verbose default logs from appearing better automatically.

Step 5: Repeat the task

Run the same test enough times to expose intermittent failures. The exact number of runs should match your risk tolerance and available model budget. The important rule is consistency across all candidates.

Step 6: Inspect restart behavior

Stop the process after a successful tool call. Restart it. Confirm whether the framework resumes, repeats the tool, loses state, or requires application code to reconstruct the task.

Step 7: Record the migration cost

After the first successful run, add one more tool, one branch, one approval step, and one persistence backend. Note whether the original code extends naturally or needs a rewrite.

Step 8: Make the decision reversible

Keep the domain tools behind your own interfaces. Store prompts, schemas, and business rules outside framework-specific objects where practical. This reduces lock-in while the project is still changing.

For teams comparing local and remote development environments, the AI agent development modes guide can help separate framework decisions from runtime decisions. If several candidates must run in parallel, also review the local versus cloud high-end PC comparison.

FAQ

Use these answers as a final screening layer, not as a substitute for the POC. The framework that looks strongest on paper may lose once your tool permissions, restart behavior, and deployment constraints are included.

The practical conclusion for your shortlist

If you are starting a simple tool-using agent this week, begin with one lightweight SDK and one typed SDK. If you already know that the task must pause, resume, branch, or survive process failure, include LangGraph or Microsoft Agent Framework immediately. If the project is document-centered, include LlamaIndex. If the application is TypeScript-first, include Mastra.

Your current approach may be a local script, a collection of model calls, or a general cloud server. Those options are flexible, but they often leave isolation, persistent state, resource monitoring, and parallel test environments for you to build. They also make it harder to reproduce a failed run when several framework candidates are being evaluated at once.

For a short POC, renting a Mac environment from Hashvps can be a cleaner option when your local machine cannot support parallel test environments or a continuously running agent. It gives you a separate place to install candidates, run repeatable tasks, and validate deployment behavior without turning your everyday workstation into the test server. If you already have reliable hardware and the workload needs sustained heavy compute or physical device access, buying and operating your own machine may still be the better choice.