Search nomadLab

Agent Frameworks in 2026: LangGraph, CrewAI, Agents SDK, Pydantic AI, Mastra

They have converged on the same loop, so the choice is about the shape of orchestration you want and whether the project is still where its vendor invests. One popular answer has already been superseded.

Updated

Every one of these frameworks wraps the same loop: send messages, get a tool call, run the tool, send the result back, repeat until the model stops asking. You can write that loop yourself in an afternoon, and for a single agent with three tools you probably should.

What the frameworks sell is everything around the loop: state that survives a crash, a way to describe control flow that is not a pile of if statements, retries, streaming, tracing, and human approval steps. Which of those you need is the actual question, and it has more to do with how your agent fails than with which model you call.

Repository activity and licenses below were checked on 21 August 2026.

Check who is still investing before you check features

AutoGen is the cautionary tale of this cycle. It shows up on most recommendation lists, and Microsoft has since folded it and Semantic Kernel into Microsoft Agent Framework, which reached release candidate in February 2026 for both .NET and Python. Microsoft publishes a migration guide from AutoGen, and the AutoGen repository has not seen a push since April. Existing projects keep working; new ones should start on the successor.

The rest are all active and permissively licensed. LangGraph, CrewAI, the OpenAI Agents SDK, and Pydantic AI are MIT, and all four have commits from the last few days.

What each one is shaped like

LangGraph models an agent as a graph with explicit state. You declare nodes, edges, and what the state object looks like, and the runtime moves between them. That verbosity is the feature: when an agent takes a wrong turn on step nine, a graph tells you which node it was in and what the state held, and it can resume from there rather than starting over. It is the right shape for long workflows with branching and human approval steps, and it is more machinery than a simple tool loop deserves.

CrewAI models agents as roles collaborating on tasks. You describe an agent’s goal and backstory, hand a crew a task list, and let delegation happen between them. It gets a prototype running faster than anything else here, and the abstraction stops helping at the point where you need to know exactly why one agent handed work to another. It is the most popular by stars, and popularity is a real advantage when you are searching for an error message.

The OpenAI Agents SDK is deliberately minimal: agents, handoffs, guardrails, sessions, and tracing, with almost nothing else. If your work is on OpenAI models and your orchestration is simple, the thin layer is a virtue and there is very little to learn.

Pydantic AI comes at it from validation. Tool arguments and outputs are Pydantic models, so the shape of what crosses the boundary is enforced rather than hoped for, and type checking works properly in an editor. For a Python team that already lives in Pydantic and FastAPI, it fits the existing code without importing a new worldview.

Mastra is the TypeScript answer, with workflows, agents, and evaluation in one package and a development server for inspecting runs. If your product is a Next.js application, keeping the agent in the same language and the same deployment is worth more than any feature comparison, because the alternative is standing up a Python service to hold one loop.

The choice that actually matters

Nearly every framework decision reduces to one question: when this agent fails halfway through, what do you want to happen?

A short loop of cheap idempotent steps can simply be rerun from the start when step four fails, while a workflow with slow or side effecting steps needs durable state so it can resume from step four Step 4 of 6 fails. What happens next? Cheap, fast, idempotent steps Slow or side effecting steps rerun the whole thing, no state needed resume at step 4, state must be durable 1 2 3 4 5 6 1 2 3 4 5 6 everything runs again from step 1 picks up here, not at step 1 Durable state is the feature you are buying. If a full rerun is harmless, you do not need it.
If step 3 sent an email and step 4 charged a card, restarting is not an option and resumption is the whole product.

If a full rerun is cheap and nothing was written to the outside world, you do not need durable state, and the thin frameworks or your own loop are enough. If step three sent an email and step four charged a card, restarting is not an option and you want the framework that can resume, which in practice means LangGraph or a workflow engine underneath whatever you use.

That question also settles the multi agent argument. Agents delegating to agents is worth it when subtasks genuinely need separate context, and it is a liability when it means five models discussing a problem one model could have solved, at five times the token cost and with no clear place to put a breakpoint.

Picking

Long running workflows with approvals and resumption: LangGraph, and accept the graph declarations as the price.

Prototype this week, several cooperating roles, willing to rewrite later: CrewAI.

Simple orchestration on OpenAI models, minimal new concepts: the Agents SDK.

Python service where correctness at the boundary matters and the team already uses Pydantic: Pydantic AI.

TypeScript product where the agent should live in the same deployment as the app: Mastra.

Existing AutoGen or Semantic Kernel code: read Microsoft’s migration guide and plan the move rather than starting new work on either.

Whatever you pick, write the agent loop once without the framework first, even if you throw it away. It takes an hour and it is the only way to know which of the framework’s features you are actually buying and which ones are covering for a loop you never understood.

Keep reading