// 8 picks · reviewed August 2026
The Best Open Source AI Agent Frameworks in 2026
An agent framework exists to handle the plumbing you'd otherwise write yourself: keeping state across steps, retrying when a tool call fails, letting a human step in mid-run, and coordinating more than one LLM when one isn't enough. Every option here claims to do that, but they're not really substitutes for each other — some are libraries you import into a Python script, some are conversation protocols for multiple agents talking to each other, and two of them are full platforms with a web UI where you barely write code at all.
The real decision isn't which one is "best" in the abstract. It's how much control you want to keep. LangGraph and Pydantic AI want you writing Python and owning the state yourself. AutoGen, CrewAI, and MetaGPT hand you a multi-agent conversation model and ask you to define roles instead of code paths. OpenAI's own SDK is the vendor's bet on what an agent loop should look like. AutoGPT and Dify skip the framework question entirely and give you a workflow canvas instead.
How we picked these
Every repo here was read and assessed on its own before it was considered for this page: we pull the README, the directory layout and a key source file, and write the assessment from those rather than from the project's own marketing. Candidates for this list came from a full-text and topic search over the 316 reviewed repositories that matched this category. Anything with no commit in the last 12 months was cut, as were link collections, tutorials and boilerplates; the floor for inclusion was 800 stars. The ordering is a judgement call about who should pick what, not a ranking by stars. finds.dev is independent of every project listed here: nobody paid for a place on this page, there are no affiliate or referral links on it, and we have no commercial relationship with any of them. That is the point of writing down what each one is bad at as well as what it is good at.
// 1 of 8
★ 40,659 · Python · MIT · updated Aug 2026
teams building production agents who need fine-grained control over state, branching, and retries
LangGraph is what you reach for once "LLM call in a loop" stops being enough. Durable execution is the real feature: an agent can crash mid-run and resume from the exact last checkpoint, and the checkpoint backends — Postgres, SQLite, Redis — ship with a conformance test suite that actually proves they behave the same way, not just documentation claiming they do. Human-in-the-loop is built the same way: you can pause a graph, inspect its state, change it, and let it continue, which is rare to see done properly.
The cost is the LangChain gravity well. Standalone use is technically supported, but the docs and examples keep nudging you back toward LangChain abstractions, and the API has grown fast enough that older ways to define nodes and edges still sit next to newer ones in the same documentation. Want to actually see what happened inside a long-running graph? That mostly means paying for LangSmith — the open source observability story here is thin.
If you want the state-machine rigor without the ecosystem tax, Pydantic AI's graph support gets you partway there, though it makes you learn a second mental model on top of its regular agent API.
View on GitHub → Our full take →
// 2 of 8
★ 60,687 · Python · CC-BY-4.0 · updated Apr 2026
teams building multi-agent conversations with enterprise backing and a mature plugin ecosystem
AutoGen is the framework that started the current wave of multi-agent tools, and the layered architecture still shows the thinking: Core, AgentChat, and Extensions let you drop in at whatever level you actually need instead of fighting one rigid API. MCP support is properly built in, not bolted on, and the model-provider extensions mean swapping OpenAI for Anthropic or Gemini doesn't mean rewriting your agent logic.
The problem is timing. AutoGen is in maintenance mode — Microsoft has already shipped a successor, Agent Framework, and is steering new work there, so what you get here is bug fixes on a best-effort basis, not new capability. The v0.2 to v0.4 migration needed its own guide to survive, which tells you how stable the API actually was. State persistence for long-running agents is still something you build yourself; there's no durable store, so a crash loses the conversation unless you've wired that up.
Compare that to LangGraph, which treats crash recovery as the headline feature rather than a gap. If you're starting fresh today, that gap alone is reason to look elsewhere.
View on GitHub → Our full take →
// 3 of 8
★ 57,787 · Python · MIT · updated Aug 2026
teams that want role-based agent crews without LangGraph's steeper learning curve
CrewAI's real idea is the split between Crews (autonomous, role-based) and Flows (event-driven, backed by plain pydantic models) — it's the rare multi-agent framework that admits not everything should be free-form agent chatter, and lets you drop back into deterministic Python when that's what the task needs. It's also a standalone framework, not a LangChain wrapper, so there's less dependency weight underneath it than LangGraph carries.
The README spends nearly as much space pitching the paid AMP control plane as explaining the open source project, which is worth noticing before you build on top of it. The scaffold recently moved to a JSON-first format (agents/*.jsonc, crew.jsonc), which broke compatibility with the Python/YAML pattern most existing tutorials still use — expect friction if you're following anything written before the switch. Telemetry is on by default, opt-out only via an environment variable, which will get flagged in some security reviews. And when a Crew goes off the rails, debugging it without their paid tracing product is genuinely opaque — underneath the roles, it's still prompting and parsing logic.
Easier to pick up than LangGraph, but you're trading away some of that rigor to get there.
View on GitHub → Our full take →
// 4 of 8
★ 29,056 · Python · MIT · updated Aug 2026
teams standardized on OpenAI models who want the official, minimal-abstraction SDK
This is OpenAI's own answer to the question, and being first-party shows: it stays in sync with API changes the day they ship, in a way community wrappers never quite manage. Tracing is a real run-level UI, not console logging with extra steps, and MCP support is a first-class primitive instead of an add-on. The new sandbox agents give an agent an actual filesystem and shell, which is a meaningfully different thing from simulated tool calls.
"Provider-agnostic" is the pitch, but the abstractions still leak OpenAI's shape — context handling, tool-call formats, and streaming behavior all have edge cases that show up the moment you point it at Anthropic or Gemini instead. The handoff model expects you to know at configuration time which agents can delegate to which; dynamic agent graphs are awkward to express. Session persistence out of the box is SQLite or Redis only, so anyone on Postgres is writing their own adapter on day one, and the sandbox providers beyond the local one are thin enough that the issue tracker doesn't show much real-world mileage yet.
If your stack is actually OpenAI end to end, this beats retrofitting LangGraph or AutoGen for the same job. If it isn't, the "agnostic" label is doing more work than the code underneath it.
View on GitHub → Our full take →
// 5 of 8
★ 19,571 · Python · MIT · updated Aug 2026
Python teams that want validated, typed agent outputs instead of parsing raw text
Pydantic AI's pitch is that most of what goes wrong with agents is exactly the kind of problem Pydantic was built to catch: untyped, unvalidated data moving between steps. Tools get their dependencies through a typed RunContext, so they're testable without mocking global state, and structured outputs retry automatically on schema failure instead of leaving you to catch a malformed response yourself. Model coverage is unusually wide for a framework this young — the same agent code runs against OpenAI, Anthropic, Bedrock, and Ollama without changes.
The graph support for more complex workflows is powerful, but it's a genuinely separate programming model from the plain agent API — a team using both ends up maintaining two different mental models instead of one. Observability leans hard on Pydantic Logfire; the OTel path exists but is visibly the secondary option in the docs and examples. And the framework is still young enough that breaking changes show up in minor version bumps, a real cost if you need to pin a production dependency and forget about it.
It's the most disciplined option here if your team already thinks in Pydantic models. LangGraph gives you more control over execution; this gives you more confidence in what comes out the other end.
View on GitHub → Our full take →
// 6 of 8
★ 184,887 · Python · NOASSERTION · updated Jun 2026
anyone who wants the original fully-autonomous single-agent loop, still actively maintained
AutoGPT isn't the 2023 thing anymore. What's in the repo now is a visual workflow platform — you wire together typed blocks, the graph executor handles retries and parallelism, and it competes with n8n and Langflow more than with the other frameworks on this page. To its credit, agbenchmark gives you objective, automated scoring against agent-protocol-compatible agents, so you can measure whether a change actually helped instead of eyeballing it.
Read the license before you evaluate this for anything commercial: the actual current product, autogpt_platform, is under Polyform Shield, not MIT, and the README doesn't lead with that. Self-hosting means Docker Compose, 8GB of RAM, Node, and several running services, and the one-line install script pulls from setup.agpt.co with no checksum verification — the kind of supply chain shortcut that wouldn't survive a code review anywhere else. The hosted version is still a closed beta waitlist, so there's no easy escape from the self-hosting complexity. And the 185k stars are almost entirely a 2023 artifact; three years of pivots — classic agent, Forge, benchmark, platform — all still sit in the repo, and figuring out what's current takes real digging.
If you want the visual-builder experience, Dify is the more finished version of that idea, with a clearer stance on what's open and what isn't.
View on GitHub → Our full take →
// 7 of 8
★ 70,090 · Python · MIT · updated Jan 2026
simulating a whole software team — PM, architect, engineer roles — on one task
MetaGPT's angle is structure through role-play: a product manager, architect, engineer, and QA agent hand work to each other through defined SOPs instead of one agent trying to do everything at once, which genuinely catches failure modes that single-agent approaches miss. The Data Interpreter sub-project is the most useful thing to come out of it in practice — a solid code-execution agent for data analysis that works well inside Jupyter. AFlow, their workflow optimizer, was an oral presentation at ICLR 2025 (top 1.8%), a sign there's real research underneath the framework, not just a wrapper around GPT-4.
In practice, generated code quality is inconsistent — plausible on toy tasks, needing real rework past a simple CRUD app, which undercuts the "one line requirement" pitch on the tin. It's locked to Python 3.9–3.11, with 3.12+ explicitly blocked, a real constraint on any current toolchain. The codebase itself has become a sprawling research monorepo — actions, roles, providers, tools, RAG, memory, and an Android assistant all living together — so pulling out just the piece you want means dragging in most of the rest. And when a run goes wrong, tracing why the architect misread the PM's spec means reading message logs that were never designed for a human to debug.
This is the one to reach for if you specifically want the software-team simulation, not general-purpose agent infrastructure. For that, CrewAI and AutoGen are both more flexible about what a "role" even means.
View on GitHub → Our full take →
// 8 of 8
★ 144,817 · TypeScript · NOASSERTION · updated Jun 2026
teams who'd rather assemble agent workflows visually than write framework code
Dify skips the framework question and gives you a platform: a visual workflow canvas, RAG pipelines, and agent orchestration behind a web UI, aimed at teams that want to ship rather than write orchestration code. The canvas handles real complexity — branching, iteration, parallel execution, and human-in-the-loop nodes are first-class — and Docker Compose cold start really is just a .env copy and compose up, no multi-step config dance. The built-in LLMOps surface (token usage, latency traces, annotation-driven dataset improvement) saves bolting on a separate observability tool.
The backend is Flask and Celery, which is fine at low concurrency but doesn't scale horizontally without Redis and worker tuning the docs barely cover. The visual editor leaks abstraction constantly — complex graphs turn into a JSON DSL you end up hand-editing, with no real diff or version control beyond export-and-compare. Plugin and tool development is thinly documented, so third-party integrations break on minor version bumps more often than they should. And the split between community and enterprise features is opaque enough that you often only discover a feature is gated after you've already built a workflow depending on it.
Compared to AutoGPT's platform, this is the more mature version of "skip the code, use a canvas" — but the enterprise gating is the same pattern to watch for in both.
View on GitHub → Our full take →
Questions people ask
Do these all do the same thing?
No. LangGraph, AutoGen, CrewAI, OpenAI's Agents SDK, and Pydantic AI are libraries you import into your own code. AutoGPT's platform and Dify are deployed applications with a web UI where you build workflows visually instead of writing agent code.
Which one should I use for production, not a demo?
LangGraph, OpenAI's Agents SDK, and Pydantic AI are the three built with production failure modes in mind — checkpointing, tracing, and typed output validation respectively. AutoGen is in maintenance mode, so avoid it for anything new.
Is AutoGPT still the AutoGPT everyone remembers?
Not really. Most of the 185k stars predate the 2023 rewrite; what's in the repo now is a visual workflow platform under a non-MIT license (Polyform Shield) for the current product, competing with tools like n8n rather than being a standalone autonomous agent.
Do I need LangChain to use LangGraph?
No, standalone use is supported, but the documentation and most examples still assume LangChain conventions, so expect some friction if you're avoiding that ecosystem entirely.
None of these wins outright — "best" here really means "least wrong for what you're building," and that depends more on how much control you want than on raw capability. If you'd rather have repos like these picked for what you're actually working on instead of comparing eight READMEs yourself, that's what the weekly email does.
Get finds like these weekly →