AI agent frameworks to use like a library

Strip any AI agent down and you find a loop. You send the model a goal and a list of tools. It asks for a tool, you run it and send back the result, and round it goes until the model says it is done. You can write that in an afternoon.

The frameworks exist for everything around the loop: keeping state when a run lasts an hour, retrying the step that failed without repeating the ones that worked, pausing for a person to approve something, remembering across sessions, and recording what happened so you can work out why it went wrong. That is the part worth importing, and it is why choosing a framework is a product decision as much as an engineering one.

There is a second distinction this year has made expensive. A library is code you own that calls a vendor. A platform is a vendor that holds your logic. Agent Builder, the visual canvas OpenAI launched in October 2025, stops working on 30 November 2026, and OpenAI's own advice to the people who built on it is to rebuild in code. Everything below is something you import, and that is the point of the list. If you want agents to use rather than to build, start with the library of ready-made ones.

The vendor SDKs

Each of the big model companies now ships two things: an open-source library for the loop, and a hosted service that runs agents for you. The libraries are the shortest path once you have chosen a model, and the most opinionated about which model that is.

OpenAI Agents SDK

Open source, in Python and TypeScript, with a deliberately small surface: agents, tools, handoffs between agents, guardrails and tracing. It is where OpenAI points everyone leaving Agent Builder. The small surface is the selling point. You write more of the plumbing yourself than with the heavier frameworks, and you understand all of it. The hosted counterpart arrived at DevDay on 29 September as an Agents API in public beta, with hosted execution, memory and computer use. The SDK itself is a short read.

Claude Agent SDK

Anthropic took the loop that runs Claude Code and published it as a library for Python and TypeScript. File access, shell commands and web search come built in, along with the context management that stops a long task drowning in its own history. It is strongest when your agent's job looks like a developer's: read things, run things, check the result. If you would rather not run the sandbox yourself, Claude Managed Agents, in public beta since April, hosts it for you. The Python package is the place to start.

Google Agent Development Kit

Google's ADK comes in Python, Java, Go and TypeScript, the widest spread of any kit here. Version 2.0, generally available for Python since May, added a graph-based workflow runtime, so the same kit covers a simple tool-calling agent and a multi-step process with branches. It runs anywhere, and it is most at home on Google Cloud. ADK for Python is the reference version the others follow.

Microsoft Agent Framework

Microsoft merged AutoGen and Semantic Kernel into one framework and shipped it as 1.0 in April, for .NET and Python. Both predecessors are now in maintenance mode, so if you have a project on either, this is your migration. For a .NET team it is the obvious default, and on Azure the hosting comes with it: Foundry's hosted agents reached general availability in August. One repository holds both languages.

The independent frameworks

These work with any model, which matters more than it sounds. The model that is best for your task this quarter is unlikely to be the best one next year, and an independent framework turns that switch into a line of configuration.

LangGraph

LangGraph is the most widely proven option for agents whose work has a shape. You draw the process as a graph of steps with explicit state, and in return you get durable execution, pauses for human approval and the ability to replay a run that broke. It reached 1.0 in October 2025 alongside LangChain 1.0, whose new agent builder, create_agent, runs on LangGraph underneath, and Uber, LinkedIn and Klarna are among its published users. The cost is that you have to think in graphs, which is the right cost if your process really does branch.

CrewAI

CrewAI models a crew with roles (a researcher, a writer, a reviewer), each with its own goal. It is the quickest route from an idea to a multi-agent demo, often a few dozen lines of Python, and its Flows add the explicit control a demo leaves out. Be honest about whether your problem needs several agents at all. One agent with good tools usually beats three agents passing notes.

Pydantic AI

From the team behind Pydantic, for people who like their contracts typed: typed inputs, typed tools and typed outputs, validated at the edges. If your agent's output feeds another system rather than a person, that checking is worth more than any feature list.

smolagents

Hugging Face's library is small on purpose, and its agents act by writing and running Python rather than calling one tool at a time. For data work, such as loading a file, filtering it and plotting the result, that is quicker and easier to follow. Run it in a sandbox, because the agent is, by design, writing code you have not read.

Strands Agents

AWS's open-source SDK lets the model drive the loop and ships with OpenTelemetry tracing built in. It works with several model providers, and it is the natural choice if you already deploy on AWS.

For TypeScript teams

Most agent tutorials assume Python. If your product is a Next.js app, as this site is, two options fit better.

Vercel AI SDK

Version 6 of the AI SDK added an Agent abstraction: define the model, instructions and tools once, then use the agent anywhere in the app. Its real strength is everything around the agent on screen, from streaming responses to tool calls rendered as interface. Use it when the agent lives inside a product screen.

Mastra

Mastra reached 1.0 in January 2026 and bundles agents, workflows, memory, evaluations and a local studio for watching runs, all in TypeScript. A common pairing is the AI SDK underneath for the model calls and Mastra on top for the orchestration.

The protocols matter more than the framework

The most useful thing to happen to agents in the past year is not a framework. It is a small set of open standards that let you change frameworks without rewriting everything you connected to them.

The Model Context Protocol, MCP, is how an agent reaches tools and data. Anthropic introduced it in November 2024 and handed it to the Linux Foundation's new Agentic AI Foundation in December 2025, and every framework above can use MCP tools. A2A, Google's agent-to-agent protocol, covers agents talking to other agents and has sat with the Linux Foundation since June 2025. Agent Skills packages instructions and scripts as folders with a SKILL.md file that any compatible agent can load.

If your integrations are MCP servers and your know-how lives in skill files, the framework becomes the replaceable part. That is where you want to be when the next shutdown notice arrives.

How I would choose

Five questions, in the order I would ask them.

Which model are you betting on, and how sure are you?

Sure, and staying: the vendor's own SDK is the shortest path. Not sure, or planning to compare: an independent framework, so the model is a setting rather than a rewrite.

Is the work a loop or a process?

One agent working until a goal is met needs very little, and a vendor SDK or Pydantic AI is plenty. Work with branches, approvals and steps that must not run twice needs a graph, from LangGraph, ADK 2.0's workflows or Microsoft's orchestration.

What does the rest of your product run on?

Use the language your team already ships. TypeScript points to the AI SDK and Mastra, .NET to Microsoft Agent Framework, and Python to almost everything else. An agent written in a language nobody on call can read is a problem at three in the morning.

Where will it run, and who answers when it fails?

Every big vendor now offers to host your agent: OpenAI's Agents API, Claude Managed Agents, Foundry's hosted agents. That is a sensible trade for a first version, provided you know what it would take to leave.

What happens when it is wrong?

Check that pausing for a person is built in rather than bolted on. LangGraph's interrupts, LangChain's human-in-the-loop middleware and the approval hooks in the vendor SDKs all exist for this. The PRD for a feature that can be wrong gets written before the framework is chosen, and it should settle this question.

What I would measure

Not stars or downloads, which measure marketing. The time from an empty repository to the first useful run, and the time to the first failure you could not explain from the traces. The share of runs that needed a person. Cost per task that actually succeeded, rather than per call. And the portability tax: how much code you would have to rewrite to change framework next year. If that number frightens you, the framework is holding more of your product than it should.