Agent frameworks in 2026: four camps, two protocols and how to choose

Nine agent frameworks are worth a serious look in September 2026, and they have sorted themselves into four camps that trade different things for convenience. The most useful way to compare them is no longer a feature grid, because every one of them now speaks the Model Context Protocol, streams tokens and offers some form of human approval. What still differs is control flow, where state lives between steps, how agents are wired to each other, and where the code runs.

Two things changed since we last mapped this category. Microsoft folded AutoGen and Semantic Kernel into a single successor, Microsoft Agent Framework, and Google’s Agent Development Kit moved to graph workflows in its 2.0 release, so the graph model has become the default shape for enterprise orchestration rather than one option among several. And the protocol layer matured: the Model Context Protocol published a stateless revision on 28 July 2026 and the Agent2Agent protocol reached v1.0 and joined MCP under the Linux Foundation’s Agentic AI Foundation on 27 August 2026.

This survey is for people who have to pick one. It defines the category, tables the contenders, walks through what actually differs, tests two scenarios against the options, takes the limits of the evidence seriously and ends with recommendations keyed to constraints rather than to popularity.

What an agent framework is, and who is in the running

The cleanest definition we found is in Hugging Face’s smolagents documentation: AI agents are “programs where LLM outputs control the workflow”. The same page makes the point that agency is a spectrum, not a switch. A model whose output selects an if/else branch is a router; a model whose output picks a function is a tool call; a model whose output decides whether to keep looping is a multi-step agent; a workflow that can start another workflow is multi-agent. The loop at the centre of every framework in this survey is the same four lines: keep a memory, ask the model for the next action, execute it, append the observation, repeat until the model says stop.

An agent framework is the code around that loop. It parses tool calls, holds memory, decides what to do when a step fails, exposes hooks for streaming and approval, and, in the more ambitious cases, persists the loop’s state so a run can outlive the process that started it. Microsoft’s documentation gives the one-line criterion for whether you need any of this: “If you can write a function to handle the task, do that instead of using an AI agent.” The framework question only arises when the workflow cannot be fixed in advance.

The nine contenders below are the ones with current official documentation, active releases and an identifiable design bet. Mastra, the Vercel AI SDK, Strands and AG2 exist and are used, but we did not read their documentation for this piece and do not characterise them.

Each of these projects is open source under a permissive licence, which matters less than it used to because the hosted runtimes around them are where vendors now differentiate. The table below is a snapshot from GitHub on 26 September 2026; star counts are a rough proxy for community size, not for quality.

One reading of that table: CrewAI has the largest community, LangGraph the most active core, and the three lab SDKs release weekly. smolagents has not tagged a release since May, which is consistent with its positioning as a small, stable library rather than a platform.

Control flow: graphs, loops, crews and typed agents

The first thing that differs is how a framework represents the path a run can take. Four answers exist, and they map onto the four camps.

Graphs. LangGraph describes itself as “a low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents”, and its primitives are exactly that: a StateGraph, nodes that read and write shared state, edges including conditional ones, and START and END markers. Microsoft Agent Framework’s workflows “connect typed executors through edges and conditions, supports fan-out and fan-in execution” and run in supersteps, a term borrowed from bulk-synchronous graph processing. Google’s ADK documentation now says that “Starting in ADK 2.0 for Python and Go, template workflows have been superseded by more flexible workflow structures, including graph-based workflows and dynamic workflows”, although the older SequentialAgent, ParallelAgent and LoopAgent templates remain and are described as “deterministic and predictable”. The graph camp’s bet is that explicit topology is worth its ceremony because it makes state inspectable and resumption possible.

Loops. The OpenAI Agents SDK, the Claude Agent SDK and smolagents all put a single agent loop at the centre. OpenAI’s primitives are “Agents”, “Handoffs” and “Guardrails” with “a built-in loop that continues until the task is complete”. The Claude Agent SDK gives you “the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript”; it is literally the Claude Code binary run as a supervised subprocess. smolagents’ CodeAgent takes the loop one step further by having the model write its actions as Python rather than JSON tool calls, citing research that code actions compose better; a ToolCallingAgent is available for the conventional style. The loop camp’s bet is that the model, not the developer, should plan, and that a small surface with good defaults beats a graph you have to draw.

Crews. CrewAI’s signature abstraction is a crew of role-playing agents with goals and tools, executing tasks with delegation. But its documentation now tells you to “start with a Flow” and to “Use a Crew within a Flow step when you need a team of agents to perform a specific, complex task”. Flows are event-driven: @start() marks entry points, @listen() fires a method when another emits, @router() picks a branch from a method’s output, and @or_() and @and_() combine triggers. In practice CrewAI has become a flow framework that contains crews, which moves it closer to the graph camp than its reputation suggests.

Typed agents. Pydantic AI’s Agent is generic over two type parameters, a dependencies type injected through RunContext and an output type validated when the run completes. The documentation’s pitch is that “Your IDE, type checker, and coding agent all know what your agent returns”, and that a validation failure is fed back to the model for another attempt. Control flow beyond the loop is plain Python; a companion pydantic-graph library exists for those who want a typed graph. The bet is that structured output and type checking catch more bugs than orchestration abstractions do.

Microsoft’s documentation offers the crispest guidance on when to leave the loop for a graph: use an agent when “The task is open-ended or conversational” or “You need autonomous tool use and planning”; use a workflow when “The process has well-defined steps” or “Multiple agents or functions must coordinate”. Microsoft also ships a “Harness Agent”, described as “an opinionated agent with batteries-included capabilities for long, multi-step tasks”: planning and todo tracking, context compaction, file access and memory, don’t-ask-again tool approval, and observability. It is a direct answer to the Claude Agent SDK’s packaging of Claude Code.

Figure 1: Each camp trades a different thing for its convenience, and the trade, not the feature list, is what a team is really choosing.

State and durability: who survives a restart

The second difference is the one that matters most in production. An agent run that takes minutes or hours will outlive a deploy, a pod eviction or a provider outage. Whether it can be resumed, and from where, depends on where the framework keeps state.

The three models in that table are worth separating because they fail differently.

Checkpoint the graph. LangGraph’s persistence layer has two parts: checkpointers, which are thread-scoped and save state at each step, and stores, which hold long-term memory across threads. You pass a thread_id in the run configuration, and production is expected to use PostgresSaver. Human review is built on the same mechanism: interrupt() pauses a node and returns a JSON-serialisable payload; Command(resume=value) continues it. The documentation is explicit about a subtlety that catches people: “The node restarts from the beginning of the node where the interrupt was called when resumed, so any code before the interrupt runs again.” Side effects therefore belong after the interrupt or must be idempotent.

Microsoft Agent Framework takes the same approach at superstep boundaries. A checkpoint “captures the entire state of the workflow”, including executor state, pending messages, pending requests and shared state, and since Python 1.13.0 an entry checkpoint recorded before the first superstep makes “the complete workflow run replayable”. The Python package ships three storage providers, and the code to enable durable checkpoints is short:

from agent_framework import FileCheckpointStorage, WorkflowBuilder

checkpoint_storage = FileCheckpointStorage("/var/lib/agent-framework/checkpoints")

builder = WorkflowBuilder(start_executor=start_executor, checkpoint_storage=checkpoint_storage)
builder.add_edge(start_executor, executor_b)
builder.add_edge(executor_b, executor_c)
workflow = builder.build()

async for event in workflow.run(input, stream=True):
    ...

Two warnings from the same page deserve repeating. A rehydrated workflow “must preserve the topology and executor identities of the workflow that created the checkpoint”, so agents need stable ids rather than generated ones. And the Python file and Cosmos stores use pickle for non-JSON state behind a restricted unpickler, which is why the documentation calls checkpoint storage “a trust boundary” and tells you never to load checkpoints from untrusted sources.

Serialise the run. The OpenAI Agents SDK does not checkpoint a graph because it does not have one. Instead, a tool marked needs_approval=True pauses the run, RunResult.interruptions surfaces the pending calls, and the application converts the result into a RunState, calls state.approve(...) or state.reject(...) and resumes with Runner.run(agent, state). RunState.to_json() and RunState.from_json(agent, stored) let that pause span hours in a database. For crash tolerance rather than approval, the SDK’s answer is Temporal: the integration, which Temporal documents as generally available in the temporalio-openai-agents package, runs “the agent loop, tool selection, and handoffs” inside a Temporal workflow “while model calls run as Activities”, so calls retry durably and are not repeated on replay. The price is Temporal’s determinism rule: workflow code cannot do I/O directly, and the documentation notes SQLiteSession is unsupported in distributed deployments.

Wrap the agent for an engine. Pydantic AI generalises that idea. Its durable execution page lists seven engines, five of them “co-maintained with the vendor teams”: Temporal, DBOS, Prefect, Restate and AWS Lambda, plus Kitaru and Apache Airflow. Model requests and tool invocations become activities, steps or tasks in the engine’s vocabulary, and streaming and MCP keep working through the wrapper. The documentation also draws a distinction the other frameworks blur: “A durable engine keeps one run alive across crashes and restarts. It does not store your chat threads.” Conversation persistence is a separate, lighter concern.

The Claude Agent SDK sits apart. Its state is a JSONL transcript written by the claude subprocess, and the hosting guide is blunt that transcripts, CLAUDE.md memory and working-directory files “None of them survive a container restart, a scale-down, or a move to a different node” by default. A SessionStore adapter mirrors transcripts to your own object store, key-value store or database; memory files and artefacts need a mounted volume. Resumption is by session id, at the granularity of a turn. That is adequate for a coding agent and inadequate for a multi-hour approval workflow, which is the SDK’s own documentation’s reasoning for pointing longer-lived cases at Anthropic’s hosted Managed Agents.

Figure 2: Durability is not one feature. The three designs recover from a crash at different granularities and impose different rules on the code you write.

Multi-agent topology: handoffs, group chats and managers

The third difference is how a framework lets agents call other agents. The vocabulary has converged even where the mechanics have not.

Microsoft Agent Framework ships five named orchestrations: Sequential, Concurrent, Handoff (“Agents transfer control to each other based on context”), Group Chat (“Agents collaborate in a shared conversation”) and Magentic (“A manager agent dynamically coordinates specialized agents”). Microsoft’s overview credits AutoGen with the “simple abstractions for single- and multi-agent patterns” that these orchestrations carry forward. Every orchestration can pause for human review via approval-required tools or a request-info executor.

The OpenAI Agents SDK’s model is the handoff: an agent delegates to another and control moves with the conversation. Nested agents can also be exposed as tools with Agent.as_tool(), and the human-in-the-loop documentation notes that approvals raised “after a handoff or inside nested Agent.as_tool() executions” surface on the outer run. Google’s ADK composes a tree of sub-agents under workflow agents; CrewAI runs crews as steps in flows and lets a single agent be kicked off asynchronously as “a lightweight alternative to full crews”. Pydantic AI’s approach is to treat sub-agents as ordinary dependencies or tools of the parent, and to expose an agent as an A2A server through FastA2A. The Claude Agent SDK’s subagents are the same feature Claude Code users know: spawned specialists with their own tools and turn caps, run inside the same container. smolagents’ agency table puts “one agentic workflow can start another agentic workflow” at its top level, and its documentation includes a multi-agent tutorial.

The pattern that has fallen out of favour is the unstructured conversation. Microsoft still offers Group Chat, but the documentation of every framework now leads with explicit topology, and the evidence discussed later suggests that is right.

Tools and protocols: what MCP and A2A do and do not standardise

The most consequential change in the category is not inside any framework. It is that the boundaries between an agent and its tools, and between one agent and another, now have specifications with neutral governance.

The Model Context Protocol was released by Anthropic in November 2024 and contributed to the Linux Foundation’s Agentic AI Foundation when that body formed on 9 December 2025, alongside Block’s goose and OpenAI’s AGENTS.md; the foundation’s platinum members are Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. The Linux Foundation’s announcement counted “over 10,000 published MCP servers”. The Agent2Agent protocol was created by Google (the Linux Foundation’s April 2026 release marks its first year), donated to the Linux Foundation, reached v1.0 with the v1.0.1 tag on 28 May 2026, and was accepted as a Growth Stage project of the same foundation on 27 August 2026, by which point the project counted “over 150 organizations” and named LangGraph, CrewAI, Pydantic AI, AG2 and IBM BeeAI as supporting frameworks.

Two design principles from the specifications explain their shape. MCP’s architecture page states that “Servers should not be able to read the whole conversation, nor ‘see into’ other servers”, which is why the host process owns consent, aggregation and model access. The A2A specification says the protocol “intentionally does not standardize agent internals, reasoning, or tool implementations”, which is why a task is the only thing two agents share.

The 2026-07-28 revision of MCP is a larger change than its date suggests. It removed protocol-level sessions and the initialize handshake, so “every request now carries its protocol version and client capabilities”; it added server/discover; it replaced resource subscriptions with a single subscriptions/listen stream; it moved long-running Tasks into an official extension; and it deprecated Roots, Sampling and Logging with a twelve-month removal window, suggesting tool parameters, direct provider APIs and OpenTelemetry instead. The older HTTP+SSE transport is formally deprecated. Anyone who built against the 2025 revisions should read the changelog before upgrading a client or server.

Every framework in this survey is an MCP client, but not to the same depth. The OpenAI Agents SDK offers a HostedMCPTool that “push[es] the entire tool round-trip into OpenAI’s infrastructure” through the Responses API, alongside MCPServerStreamableHttp, MCPServerStdio and a deprecated MCPServerSse, with tool filtering, caching and approval policies. CrewAI connects through an mcps field on an agent or an MCPServerAdapter, but its documentation notes that “Other MCP primitives like prompts or resources are not directly integrated”. Pydantic AI is both an MCP client and an MCP server. smolagents loads tools with ToolCollection.from_mcp. The Claude Agent SDK inherits Claude Code’s MCP configuration. ADK, LangGraph and Microsoft Agent Framework all document MCP tools; ADK and Pydantic AI also document exposing an agent over A2A, and ADK documents consuming one.

Two third-party readings are useful here. Sarkar and Sarkar’s survey of agent communication with MCP (arXiv 2506.05364, revised May 2026) maps classical patterns, Mediator, Observer, Publish-Subscribe and Broker, onto MCP-compliant systems and argues that the design pattern, not the protocol, determines reliability at scale. Adimulam, Gupta and Kumar’s January 2026 paper on orchestrating multi-agent systems (arXiv 2601.13671) places MCP and A2A inside “a unified architectural framework that integrates planning, policy enforcement, state management, and quality operations”, which is a reasonable description of what a framework plus a runtime plus a gateway now amounts to.

That gateway layer is where MCP governance is increasingly enforced. When many agents share the same tool servers, teams put an MCP-aware gateway between agents and servers to filter tools and apply approvals centrally. Bifrost, an open-source Go gateway from Maxim AI, is one example: its documentation describes it as both an MCP client and an MCP server that lets “AI models discover and execute external tools dynamically” with tool filtering and approval controls, alongside an OpenAI-compatible API that “unifies access to 20+ providers”. We compared gateways more broadly in five LLM gateways compared.

Hosting, runtime and observability hooks

The fourth difference is where the agent runs and what you can see while it does. Here the open-source library and the vendor’s commercial runtime are two different products, and the second is where lock-in lives.

LangGraph’s runtime is LangSmith Deployment, described as “a workflow orchestration runtime purpose-built for agent workloads”. It comes in four shapes: cloud on LangChain’s infrastructure (Plus plan or above), self-hosted with a control plane on your Kubernetes (Enterprise), hybrid with LangChain running the control plane, and a standalone server with your own PostgreSQL and Redis. The documentation calls it “framework-agnostic” and lists Google ADK, the Claude Agent SDK, Strands, CrewAI and AutoGen among supported frameworks, which is a notable admission that the runtime, not the graph library, is the product.

Google’s answer is Agent Runtime on the Agent Platform, alongside Cloud Run, GKE and plain containers; the ADK documentation covers evaluation with custom metrics, user simulation and environment simulation as part of the same toolchain. Microsoft’s is Foundry: the quickstart on the overview page creates an agent against a Foundry project endpoint, and the checkpoint stores include a FoundryCheckpointStore for the hosted case. OpenAI’s is the Responses API itself, which hosts tools, and a sandbox agent feature for isolated workspaces. CrewAI AMP is the company’s managed platform: deployment from GitHub, a REST API, execution traces, webhook streaming and a no-code Crew Studio.

Anthropic’s split is the clearest. The Claude Agent SDK is for embedding the agent “in a process you operate”; Managed Agents is for having Anthropic host the loop, with tool execution in an Anthropic-managed or self-hosted sandbox. The hosting guide gives numbers the others do not: “1 GiB RAM, 5 GiB disk, and 1 CPU per agent is a reasonable starting point”, one session maps to one subprocess, concurrency is bounded by RAM, and “Anthropic token cost typically dominates container infrastructure cost by an order of magnitude or more”. It also states that the SDK needs outbound HTTPS to Anthropic or to “your provider’s regional endpoint when running on Amazon Bedrock or Google Cloud’s Agent Platform”, which is the SDK’s only path to a non-Anthropic bill.

On observability, OpenTelemetry has won. Pydantic AI describes its instrumentation as “OpenTelemetry-native” and works with any OTLP backend, with Logfire as the first-party option and Pydantic Evals for tests. The Claude Agent SDK “inherits OpenTelemetry configuration from the environment” and exports spans, metrics and logs, with prompt text excluded by default. Microsoft Agent Framework lists telemetry among the Semantic Kernel features it kept. The OpenAI Agents SDK has its own tracing model with span types and a TraceProvider, feeding OpenAI’s evaluation and fine-tuning tools; LangGraph traces into LangSmith. MCP’s July revision even added trace-context propagation conventions for traceparent, tracestate and baggage in request metadata, so a trace can cross the tool boundary.

Evaluation hooks are the least mature part of every stack. ADK’s user and environment simulation and Pydantic Evals are the two that are documented as first-class; the rest defer to their observability product. We would treat this as a selection criterion in its own right, for reasons the next two sections make plain.

Two scenarios tested against the options

Abstract comparisons flatter every framework. Two concrete cases show where the differences bite.

A claims-triage agent in an insurer. The task: read a submitted claim, pull policy data from an internal system, check three rules, draft a decision, and route anything over a threshold to a human adjuster who may not respond for two days. Constraints: Python, on-premises Kubernetes, audit log of every decision, no model-provider commitment.

The two-day pause eliminates anything that keeps state only in process. It favours a checkpointed graph, and LangGraph’s interrupt() with a PostgresSaver or Microsoft Agent Framework’s superstep checkpoints on a file or Cosmos store both fit; on non-Azure Kubernetes, Microsoft’s file store or a custom CheckpointStorage is the realistic path, so LangGraph with its standalone server edges it. Pydantic AI on DBOS or Temporal is the strongest alternative if the team already runs one of those engines, because model and tool calls would be recorded as activities, giving the audit log for free. The OpenAI Agents SDK could do it with serialised RunState, but only on OpenAI models, which the constraints exclude. CrewAI’s @human_feedback and @persist cover the mechanics but its SQLite default and managed-platform orientation are a poorer fit for on-premises audit requirements. Policy and rules lookups become MCP tools regardless of the choice, and would survive a later framework switch.

A code-modernisation agent for an internal platform team. The task: given a repository and a migration guide, update dependencies, run the test suite, fix failures, and open a pull request. Constraints: TypeScript team, runs in CI, Claude models preferred, budget capped per run.

This is the Claude Agent SDK’s home ground: file tools, shell, hooks and per-session cost tracking are built in, maxTurns caps the loop, and the ephemeral session pattern in the hosting guide (a container per task that exits on completion) is exactly a CI job. The OpenAI Agents SDK’s TypeScript package with its ShellTool and ApplyPatchTool is the equivalent on OpenAI models. LangGraph in TypeScript could express the same loop but would add a graph the team does not need. smolagents’ code-writing agent is philosophically closest but is Python only. The one thing to add is a session store if a failed job should be resumable rather than rerun.

Both scenarios illustrate the same rule: the pause length and the host language do most of the choosing before features enter the conversation. Our analysis of the real cost of an AI product covers why the per-run budget in the second scenario matters more than the framework’s list price.

The limits of the evidence

Everything above is drawn from vendor documentation, and vendor documentation describes what a framework can do, not how well. Independent measurement of agent frameworks barely exists, and what exists should make buyers cautious in three ways.

Multi-agent topologies are not free wins. “The Illusion of Multi-Agent Advantage” (arXiv 2606.13003, June 2026) compared multi-agent systems against a single model using chain-of-thought with self-consistency and found that “Automatic MAS consistently underperform CoT-SC despite being up to 10x more expensive”. Expert-designed multi-agent systems did win, but only on a diagnostic dataset built to have “explicit task decomposition, context separation, and parallelization potential”. The authors’ diagnosis is “architectural bloat that prioritizes superficial complexity which does not translate into functional utility”. Read against the frameworks above, this is an argument for the loop and typed camps as a default and for graphs only where the task genuinely decomposes.

Benchmarks measure a different thing from reliability. τ²-Bench (arXiv 2506.07982) is one of the few benchmarks that tests an agent against a simulated user who also acts on the world, and it reports “significant performance drops when agents shift from no-user to dual-control”. The benchmark separates reasoning errors from coordination errors, which is the right granularity, but it evaluates models, not frameworks, and no framework vendor publishes results on it. A framework’s contribution to reliability, through retries, checkpoints and approvals, is precisely what current benchmarks do not measure. We have argued elsewhere that benchmarks are marketing now; for agents the problem is worse, because the unit of failure is a whole trajectory.

Lock-in has moved up the stack. The libraries are MIT or Apache licensed and MCP makes tools portable, so the switching cost of the code is lower than it was. The switching cost of the runtime is not. Checkpoints in LangGraph’s Postgres schema, Microsoft’s pickled workflow state, CrewAI’s flow state ids and the Claude Agent SDK’s JSONL transcripts are all proprietary formats, and a hosted runtime holds them. LangSmith Deployment’s claim to be framework-agnostic and the Claude Agent SDK’s support for Bedrock and Google Cloud endpoints soften this, but a team should assume that migrating a live, long-running agent between runtimes means draining it first.

A fourth limit is our own. This survey read each project’s documentation in September 2026 and did not run the frameworks against each other. The release cadence in the licence table above means the specifics will drift within weeks; the design bets will not.

Recommendations keyed to constraints

The question sequence below narrows nine options to one or two for most teams. It is deliberately ordered from the constraints that are hardest to change to the ones that are easiest.

You are committed to one model provider. Use that provider’s SDK. The OpenAI Agents SDK, the Claude Agent SDK and Google’s ADK each expose their vendor’s hosted tools, sandboxes and tracing with the least friction, and their loops are tuned to their own models’ tool-calling behaviour. The Claude Agent SDK is the narrowest of the three (Claude models on Anthropic, Bedrock or Google Cloud, and use under Anthropic’s Commercial Terms) and the most complete for file-system work; ADK is the widest on languages and the only one with first-class A2A on both sides.

You must avoid provider commitment. Take Pydantic AI if the team writes Python and values types, LangGraph if the workflow is a graph with human steps, Microsoft Agent Framework if the team writes .NET, and smolagents if you run open-weight models and want the smallest possible library. All four swap providers with a string or a client object. Route calls through a gateway so that the switch, when it comes, is a configuration change rather than a refactor.

Runs must survive restarts and wait on humans for hours or days. This is the sharpest filter. LangGraph and Microsoft Agent Framework checkpoint natively; Pydantic AI and the OpenAI Agents SDK reach the same outcome through Temporal or a sibling engine, at the cost of that engine’s determinism rules; CrewAI persists flow state to SQLite and can resume or fork by id. The Claude Agent SDK and smolagents are not designed for this, and Anthropic’s own documentation points such workloads at Managed Agents.

The host language is fixed. TypeScript teams choose among LangGraph, the OpenAI Agents SDK, ADK and the Claude Agent SDK. .NET teams have Microsoft Agent Framework and little else. Go teams have ADK and, in preview, Microsoft Agent Framework. Java and Kotlin teams have ADK. Python teams have everything.

The topology is small and known. Do not start with a graph. A typed agent, a lab SDK loop or smolagents will ship faster, and the multi-agent evidence says the extra structure is more likely to add cost than accuracy until the task proves it decomposes. Add a graph when a pause, a branch or a parallel fan-out appears in the requirements, not before.

The agent’s job is to write and run code. The Claude Agent SDK and smolagents’ CodeAgent are built around this; the OpenAI Agents SDK’s shell and patch tools are close behind. Sandboxing is mandatory for all three, and smolagents documents Modal, Blaxel, E2B and Docker as executors while Anthropic’s hosting guide covers Docker, gVisor and Firecracker.

You need evaluation before you need anything else. Pick the stack whose evaluation story you will actually use: Pydantic Evals with OTel traces, ADK’s simulators, or a lab SDK’s tracing feeding its own evaluation tools. If the plan is “we will look at the logs”, the framework choice is premature. Understanding what the model is doing between tool calls, which we covered in what reasoning models actually do, is the other half of that discipline.

Figure 3: Four questions narrow the field to one camp; the constraints in this section then pick the framework within it.

Our judgement, for whatever a documentation-based survey is worth: the graph camp has won the argument about where long-running agents should keep state, the protocol layer has won the argument about where tools should live, and the lab SDKs have won the argument about developer experience for single-provider teams. What nobody has won is evaluation. The framework you choose in September 2026 is a renewable decision; the traces, the tool servers and the test set you build around it are the assets that survive the next migration. Spend accordingly.

Feature claims are drawn from each project’s public documentation as of September 2026. Verify current specifics before deciding.