Why this one is here

Most of what I write on this blog is about strategy. This post gets closer to the workbench, so it’s worth saying why.

Building AI systems is my day job. At Omnilogic Labs we design and run AI automation for banks and enterprises, and we do it for clients on a regular basis. That repetition is the part that matters for this post. When you build the same class of system over and over, for companies with real deadlines and real money at stake, you find out fairly quickly which tools hold up and which ones only look good in a tutorial. You don’t learn that from documentation. You learn it on the third client project, when the thing you picked turns out to be the wrong choice and you have to explain why.

What follows is that accumulated view, written down.

First, what a multi-agent framework actually is

If you’ve used ChatGPT, you’ve used a single AI agent. You ask, it answers, the conversation ends. You are the one deciding what happens next.

A multi-agent system is what you get when you stop asking one AI to do everything and instead hand narrow jobs to several of them, letting them pass work to each other. Think of a small agency rather than a single freelancer. One agent researches. Another writes a draft. A third checks that draft against the research and sends it back if it doesn’t hold up. Something has to decide when the work is actually finished.

A framework is the plumbing that makes that possible. How do agents hand work between them? What happens when one of them fails halfway through a job? How does the system remember what it was doing? And when something goes wrong at 3 a.m., how do you see inside it?

That last question is where the real cost sits. Getting two AI agents to talk to each other is a weekend project. Getting them to keep doing it for months, unattended, without producing nonsense, is the actual work. The framework you choose decides how hard that is.

Which is why picking the right one matters, and why a lot of the advice out there is wrong.

The state of things, as of this month

Most of the framework roundups on this topic are quoting GitHub star counts that are three to five times too low, still recommend a project Microsoft moved into maintenance mode, and point people at a repository that’s been archived. I know, because this morning I pulled every number in this post from the GitHub API instead of copying it from somebody else’s article.

That sounds like a small thing. It isn’t. If you’re choosing what to build your company’s agent stack on, the difference between “actively developed” and “archived, community-managed, no new features” is the difference between a two-year investment and a rewrite.

So this is the honest version, checked on 8 September 2026 by someone who has to live with these decisions rather than just write about them.

How I picked these

I’ll be straight about my criteria, because most listicles won’t tell you theirs.

Is it alive? Not stars. Stars are a popularity lag indicator and they never go down, which makes them close to useless for judging whether a project is healthy. I checked the archived flag, the date of the last commit, and what each project’s own README says about its status. Two of the most-recommended frameworks failed this test.

Would I put it in front of a client? I’ve spent 20 years shipping software into large organizations. A framework that’s delightful in a notebook and undebuggable at 2 a.m. is not a framework I can recommend to somebody whose quarter depends on it.

Does it solve a real coordination problem? Plenty of projects are a thin wrapper on a model API with the word “agent” in the README. The ones below actually do something about state, handoffs, or failure.

I also want to be honest about my own position. My production fleet doesn’t run on any of these. It runs on Google’s A2A protocol with direct calls to the model APIs, because when I built it the framework options were less mature than they are now. Take that as context rather than advice: I’ve already paid for the parts they abstract away, so I know exactly what each one is saving you.

The twelve worth your time

1. LangGraph (41,226 stars)

The one I’d reach for when the work has to survive contact with reality. LangGraph models your system as a graph with explicit state, which sounds academic until the first time a run dies halfway through and you need to resume it without redoing the expensive half.

Its checkpointing is the feature nobody appreciates until they need it. Human-in-the-loop approval steps are a first-class concept rather than something you bolt on. The tradeoff is that you have to think about your state shape up front, and people coming from simpler tools find that annoying for about a week.

Best for: long-running workflows, approval gates, anything where a crash can’t mean starting over.

2. CrewAI (58,224 stars)

The fastest way to get from an idea to something running. You describe agents as roles with goals, hand them tasks, and it works. You can have a usable prototype running in a morning.

The role metaphor is also its ceiling. It maps beautifully onto “a researcher, a writer, and an editor” and it strains when your actual problem doesn’t decompose into job titles. Note that the repository moved to crewAIInc/crewAI, so older links redirect.

Best for: prototypes, and production systems whose shape really is a small team with clear jobs.

3. OpenAI Agents SDK (29,258 stars)

This is the real successor to Swarm, and if you read an article recommending Swarm, that article is out of date. Swarm was always labeled educational. This is the production version of the same ideas: handoffs between agents, guardrails, and tracing that actually helps.

If your stack is already committed to OpenAI models, starting anywhere else costs you integration work for benefits you may not need.

Best for: OpenAI-native builds that want handoffs and guardrails without much ceremony.

4. Microsoft Agent Framework (13,379 stars)

The lowest star count in this section and the one I’d bet on hardest if you’re an enterprise. This is where AutoGen went. Microsoft has stated that AutoGen is in maintenance mode and that new users should start here, with a documented migration path from AutoGen and a commitment to long-term support.

Thirteen thousand stars looks unimpressive next to AutoGen’s sixty thousand. Those sixty thousand stars are a monument to a project that stopped taking new features. Start where the work is happening.

Best for: Azure, .NET, and anywhere procurement asks who supports this.

5. Google ADK (21,451 stars)

Google’s Agent Development Kit is code-first, which I appreciate. It deploys to Agent Engine without you rewriting your agent for production, and Gemini and Vertex are wired in rather than adapted.

Same logic as the Microsoft entry. If your data already lives in Google Cloud, the framework that shortens the distance to your data usually wins over the one with a nicer API.

Best for: Google Cloud shops, and teams who want evaluation built in rather than added later.

6. Pydantic AI (19,781 stars)

The one I’d point a team to after they’ve been burned. Pydantic AI puts type validation at the boundary of every agent, which means malformed model output fails in your test suite instead of quietly corrupting something three steps downstream.

If your team already uses Pydantic, and in Python most do, the learning curve is close to zero. This is the least glamorous framework on the list and the one most likely to save you a bad week.

Best for: teams that want agents to fail loudly and early.

7. Agno (42,093 stars)

Agno has grown quickly by being fast and staying out of your way. It leans hard on performance and low overhead per agent, and it bundles memory and knowledge without requiring you to assemble four libraries first.

I’d call it the pragmatist’s pick. Less opinionated than LangGraph, more structured than rolling your own.

Best for: many lightweight agents where per-agent overhead actually shows up in your bill.

8. LlamaIndex Workflows (52,067 stars)

If your agents mostly answer questions about your own documents, start here rather than at a general orchestration framework. LlamaIndex was a retrieval system that grew agents. The ordering matters: retrieval is the hard part of that problem and it’s the part LlamaIndex has been solving longest.

Workflows added event-driven orchestration on top, so you’re no longer choosing between good retrieval and decent coordination.

Best for: document-heavy and knowledge-base agents.

9. Haystack (26,447 stars)

deepset’s framework, and the most production-minded of the retrieval-first options. Pipelines are explicit and inspectable, which makes Haystack pleasant to operate and slightly less pleasant to write. That’s a trade I’ll take on anything that has to run unattended.

Best for: search and question-answering systems that need to be auditable.

10. CAMEL-AI (17,683 stars)

Built to study how agents behave when they talk to each other, and very good at it. If you’re exploring negotiation, role-play, or emergent behavior between agents rather than shipping a product next quarter, this is a research instrument rather than a factory tool.

Best for: research, simulation, and agent-behavior work.

11. MetaGPT (70,262 stars)

The most-starred framework here, built on the idea of simulating a software company: a product manager agent, an architect, engineers. When the metaphor fits, the structured output is impressive.

One caution I’d give honestly: its last significant commit activity is older than most of this list. High stars, slowing pace. Watch it before you commit a roadmap to it.

Best for: code generation and structured multi-role output, with your eyes open about velocity.

12. AgentOps (5,811 stars)

Not an orchestration framework, and the one I’d argue hardest for you to install anyway. AgentOps is observability for agents: what each one did, what it cost, where it went wrong.

I put it last on the list and first in the build order. Every painful failure I’ve had in production was invisible before it was obvious.

Best for: every project on this page.

Side by side

Framework	Stars	Status	Learning curve	Where it wins
MetaGPT	70,262	Active, slowing	Medium	Structured code generation
CrewAI	58,224	Active	Low	Speed to first prototype
LlamaIndex Workflows	52,067	Active	Medium	Retrieval-heavy agents
Agno	42,093	Active	Low	Low per-agent overhead
LangGraph	41,226	Active	Medium-high	Stateful, resumable workflows
OpenAI Agents SDK	29,258	Active	Low	OpenAI-native handoffs
Haystack	26,447	Active	Medium	Auditable search pipelines
Google ADK	21,451	Active	Medium	Google Cloud and Vertex
Pydantic AI	19,781	Active	Low	Type safety at the boundary
CAMEL-AI	17,683	Active	Medium	Agent-behavior research
Microsoft Agent Framework	13,379	Active	Medium	Enterprise and .NET support
AgentOps	5,811	Active	Low	Observability for all of the above

The three I’d avoid, and why

This is the section the other roundups don’t write, and it’s the one that will save you the most time.

Microsoft AutoGen (60,867 stars) is in maintenance mode. Its own README carries the notice: no new features, community-managed going forward, new users should start with Microsoft Agent Framework. Those sixty thousand stars will keep it at the top of search results and near the top of every listicle for another year. Don’t start a new project on it. If you already have one, Microsoft publishes a migration guide.

OpenAI Swarm (21,948 stars) was never meant for production. OpenAI describes it in its own words as an educational framework exploring lightweight multi-agent orchestration. It did its job, the ideas graduated into the Agents SDK, and that’s where you should be. Any 2026 article recommending Swarm for production was written by someone who didn’t check.

TaskWeaver (6,169 stars) is archived. The repository is flagged archived on GitHub, which means read-only, no fixes, no security patches. I still find it in “top frameworks for 2026” lists, sometimes recommended for data-intensive work. Building on an archived repository is taking on maintenance of a codebase you didn’t write and don’t understand.

Three things running these in production taught me

The framework you pick matters less than most people writing about frameworks want to admit. Here’s what actually decided whether my systems worked.

Your failure alarms matter more than your architecture. One of my pipelines stopped publishing for 47 days and I had no idea. A model I depended on had been quietly deprecated, my system kept calling something that no longer existed, and the alerting was pointed at a dead address. I found it by accident. An autonomous system without working alarms isn’t autonomous, it’s unsupervised, and no framework on this page fixes that for you.

Graceful degradation is often just shipping broken work quietly. My image pipeline was written to fall back through several providers and, if all of them failed, to publish anyway with a warning in the log. That’s textbook resilient design. In practice it meant articles going out with no image at all while the system reported success. Decide deliberately which failures should stop the line, because “keep going” is a choice with consequences.

A gate that fails open is not a gate. I had a duplicate-detection check that had been silently passing everything since the day it shipped, because of a bug in how it built its query. It ran, it logged, it reported clean, and it was doing nothing. It never crashed, so nothing ever told me. Now anything that guards quality gets a test that proves it can actually say no.

None of those three lessons are about LangGraph or CrewAI. They’re about operating autonomous systems, and they’ll be true whichever row of the table you pick.

Where this is going

The interesting movement in 2026 is happening underneath the frameworks, in the protocols. A2A for agent-to-agent communication and MCP for tool access are both being adopted across frameworks that otherwise compete, which points at a future where your orchestration choice stops being a lock-in decision.

That’s good news for anyone making this call today. Pick the one that fits the work in front of you, keep your business logic out of the framework’s abstractions where you can, and accept that you’ll probably migrate once. Everyone does.

Sources

Every star count and status in this post came from the GitHub REST API on 8 September 2026, using the stargazers_count and archived fields, plus each project’s own README for maintenance status.

• LangGraph: github.com/langchain-ai/langgraph
• CrewAI: github.com/crewAIInc/crewAI
• OpenAI Agents SDK: github.com/openai/openai-agents-python
• Microsoft Agent Framework: github.com/microsoft/agent-framework
• Google ADK: github.com/google/adk-python
• Pydantic AI: github.com/pydantic/pydantic-ai
• Agno: github.com/agno-agi/agno
• LlamaIndex: github.com/run-llama/llama_index
• Haystack: github.com/deepset-ai/haystack
• CAMEL-AI: github.com/camel-ai/camel
• MetaGPT: github.com/FoundationAgents/MetaGPT
• AgentOps: github.com/AgentOps-AI/agentops
• AutoGen maintenance notice: github.com/microsoft/autogen
• OpenAI Swarm: github.com/openai/swarm
• TaskWeaver (archived): github.com/microsoft/TaskWeaver

Numbers move. If you’re reading this months from now, check them yourself before you decide anything. That’s the whole point of this post.

A note on how this gets made: I run my own content pipeline, the same kind of system I build for clients. It drafts, I edit and fact-check every line, and I sign it. Claiming expertise in production AI and then hiding that I use it would be a strange way to make the point.

— Juan