The state of AI agent frameworks in 2026: a survey

Two years ago “agent framework” meant a handful of Python libraries wrapping a while-loop around a model call. Today it is a crowded category with distinct schools of thought, backed by the labs themselves as well as startups and open-source communities. This survey maps the landscape as it stands, describes the design bet each camp is making and lists the questions that should decide your choice.

We deliberately avoid feature matrices. Features converge quickly; architectures do not.

Four camps

1. Graph orchestrators

Representative: LangGraph, and similar state-machine libraries.

The bet: an agent is a graph of nodes (model calls, tool executions, human checkpoints) connected by edges with conditions. State is explicit, persisted and inspectable. This makes complex topologies, cycles with exit conditions, parallel branches and approval gates tractable, and it makes durable execution (pause, resume, replay) natural.

The cost is ceremony. Simple agents become verbose, and the graph abstraction leaks into every part of the code. Teams with long-running, multi-step workflows and compliance requirements tend to land here.

2. Lab-native SDKs

Representative: the agent SDKs from OpenAI, Anthropic and Google.

The bet: the lab knows its own models best, and an SDK that exposes handoffs, tools, guardrails and tracing with a minimal surface will beat generic frameworks on reliability with that lab’s models. These SDKs are typically small, opinionated and well integrated with the vendor’s hosted tools (web search, code execution, file search) and observability.

The cost is portability. Most support other providers to some degree, but the idioms and the best-tested paths follow one vendor’s models. For teams committed to a provider, they are often the fastest route to a working system.

3. Multi-agent role frameworks

Representative: CrewAI, AutoGen (now AG2), and Microsoft’s Semantic Kernel agent features.

The bet: complex tasks decompose into roles, and agents with distinct personas, tools and goals collaborating through conversation produce better results than one agent with one long prompt. The mental model is a team, and the framework provides the meeting room.

The cost is unpredictability and tokens. Conversations between agents are expensive and hard to steer, and evaluation is difficult because failures are emergent. These frameworks shine for exploratory and creative workloads and struggle where determinism matters.

4. Typed minimalists

Representative: Pydantic AI, Mastra, the Vercel AI SDK.

The bet: the model call is the primitive, structured outputs and type safety are the main source of reliability, and everything else should be plain code in the host language. These libraries feel like ordinary application frameworks with a model client attached, and they integrate naturally with existing web stacks, especially in TypeScript.

The cost is that you build orchestration yourself. For many production agents, which have a small, fixed number of steps, that is a feature.

Figure 1: Each camp trades a different thing for its convenience.

Convergence at the protocol layer

The most important development of the last year is not a framework. It is that the boundaries between agents and their tools, and between agents and each other, are standardising. The Model Context Protocol has become the default way to expose tools and data to any agent, regardless of framework. Agent-to-agent protocols are earlier but moving in the same direction.

The effect is to make framework choice less consequential. A tool built once as an MCP server works from any camp. Switching frameworks used to mean rewriting integrations; increasingly it means rewriting only control flow.

The problems nobody has solved

Every camp struggles with the same three things:

1. Evaluation. Agents fail in long-tailed, path-dependent ways. Unit tests catch little; production traces catch everything too late. Trace-based evaluation with rubric-scoring models is the current best practice and is still immature.
2. Durable execution. Tasks that run for minutes or hours need to survive process restarts, provider outages and human delays. Graph orchestrators handle this best; the rest bolt it on.
3. Cost control. Agents spend tokens non-deterministically. Budgets per run, routing by difficulty and aggressive caching are necessary in every framework and native in none. Our analysis of test-time compute economics covers why this is getting harder, not easier.

Choosing

Ask, in order:

• Is my agent’s topology known and small? If yes, a typed minimalist library or a lab SDK is enough. If it is a large or evolving graph with human steps, a graph orchestrator.
• Am I committed to one model provider? If yes, that provider’s SDK is probably the most reliable path. If not, avoid anything whose best-tested path is single-vendor.
• Do I need durable, resumable execution? If yes, this narrows the field sharply.
• What does my team already write? TypeScript teams should look hard at the TypeScript-native options; Python teams have the most choice.
• How will I evaluate it? If the answer is “we will look at the logs”, stop and fix that first. It is framework-independent and it is the thing that will decide whether the agent ships.

Figure 2: Four questions narrow the field to one camp.

The frameworks will keep changing. The protocols and the evaluation discipline are the durable investments.