AI Agent Frameworks Compared: When You Need One and When You Don’t

An AI agent framework runs the loop for you: call the model, run the tool it asks for, feed the result back, repeat until it answers. Around that loop it adds the parts that are tedious to build twice: conversation state, several agents handing work to each other, pauses for a person to approve something, tracing, and connections to MCP servers. The main frameworks today are LangGraph, CrewAI, the OpenAI Agents SDK, the Claude Agent SDK, Google’s Agent Development Kit and Microsoft Agent Framework, and every one of them can use MCP tools. Choose by the language you ship in, by whether you want to own the loop or hand it over, and by how much of the flow your code should decide. If one model calls a handful of tools and your code already knows the steps, you probably do not need a framework at all.

This page is about choosing. How the frameworks name agents and tasks is in agents vs tasks in multi-agent frameworks, and a first agent built end to end is in how to build an AI agent.

What a framework does for you

• The loop: calling the model, parsing tool calls, running them, appending results, and stopping at a turn limit.
• Tools: turning your functions into schemas the model can read, and connecting MCP servers so their tools appear beside your own.
• State: keeping a conversation across requests, and for some frameworks checkpointing a long run so it can resume after a crash.
• Several agents: handoffs, agents called as tools, or explicit graphs that decide who runs next.
• People in the loop: pausing before a risky tool call and resuming once someone approves.
• Visibility: traces of every model call and tool call, which is where most debugging time goes.

None of this is magic, and all of it can be written by hand. The question is whether you would rather maintain it yourself or accept a library’s shape for it.

The frameworks, one by one

LangGraph

LangChain describes LangGraph↗ (opens in a new tab) as a low-level orchestration framework and runtime for long-running, stateful agents. You model the work as a graph of nodes over shared state, and it gives you durable execution, human-in-the-loop interrupts and memory. It is available for Python and JavaScript. LangChain itself points newcomers to its higher-level prebuilt agents first, and to LangGraph when you need to mix hand-coded steps with model-driven ones. MCP tools now load through the langchain.mcp namespace; the older langchain-mcp-adapters package is deprecated, as MCP vs LangChain tools explains.

CrewAI

A standalone Python framework built around roles. Crews are teams of agents with a role, goal and backstory that work through tasks; Flows are the event-driven layer that holds state and control logic, and CrewAI recommends using the two together. CrewAI’s MCP guide↗ (opens in a new tab) offers an mcps field on an agent for the simple case and MCPServerAdapter for manual control, over stdio, SSE and Streamable HTTP. It suits people who think in job descriptions and deliverables.

OpenAI Agents SDK

A small set of primitives, agents, tools, handoffs, guardrails and sessions, with tracing on by default, in Python and TypeScript. MCP servers connect as a hosted tool that OpenAI calls for you, or over Streamable HTTP or stdio from your own process. It works with other providers’ models too. The detail is in the OpenAI Agents SDK in practice. Two OpenAI products around it have been retired: OpenAI’s deprecations page↗ (opens in a new tab) lists the Assistants API as shut down on 26 August 2026, with the Responses and Conversations APIs as its replacement, and Agent Builder as shutting down on 30 November 2026.

Claude Agent SDK

The loop that runs Claude Code, as a TypeScript or Python library. Unlike the others it arrives with working tools already built in: reading and editing files, running commands, searching, subagents, hooks and permission modes, plus MCP servers by URL, by command or in process. It is the shortest route to an agent that works on files and a shell, and it is built for Claude models. See the Claude Agent SDK for its options and three examples.

Google Agent Development Kit (ADK)

Google’s Agent Development Kit↗ (opens in a new tab) is open source and lists Python, TypeScript, Go, Java and Kotlin. It is model-agnostic, with native Gemini access and adapters for other providers, including local models. Beside model-driven agents it has workflow agents, sequential, parallel and loop, for the parts where you want a fixed shape, and it can both use MCP tools and expose an agent as an MCP server. It suits teams already on Google Cloud, and teams that want one framework across several languages.

Microsoft Agent Framework

The successor to both Semantic Kernel and AutoGen, from the same teams, released as 1.0 for .NET and Python in April 2026, with Go in public preview. It pairs agents with graph-based workflows, and offers local and provider-hosted MCP tools. It is the natural choice for .NET shops. What changed, and how to migrate, is in Microsoft Agent Framework and Semantic Kernel.

Others worth knowing

Pydantic AI is a Python framework built on type hints and validated output, with many model providers and built-in MCP support. Mastra is a TypeScript framework for agents and workflows that fits into Node web applications. Both are narrower than the six above and worth a look if their language and style match yours.

The same six, side by side

• LangGraph: Python and JavaScript. Built around a graph over shared state. Best when you want explicit control and durable runs.
• CrewAI: Python. Built around roles, tasks, crews and flows. Best when the work reads like a team with deliverables.
• OpenAI Agents SDK: Python and TypeScript. Built around agents and handoffs. Best when you want a light layer with tracing.
• Claude Agent SDK: TypeScript and Python. Built around Claude Code’s loop and tools. Best for agents that work on files and a shell.
• Google ADK: Python, TypeScript, Go, Java and Kotlin. Built around agents plus workflow agents. Best for multi-language teams and Google Cloud.
• Microsoft Agent Framework: .NET and Python, Go in preview. Built around agents plus typed workflows. Best for .NET and Azure teams.

How to choose

1. Start from your language. A framework in the language your service is already written in beats a better one that needs a second runtime.
2. Decide who owns the loop. A thin SDK leaves the loop visible and yours; a batteries-included one, like the Claude Agent SDK, gives you working tools on day one in exchange for its shape.
3. Decide how much your code should decide. If the steps are known, you want workflows: LangGraph graphs, ADK’s workflow agents, Microsoft’s workflows, CrewAI’s Flows. If the model should choose, you want an agent with tools.
4. Check model coupling. Most of these accept other providers’ models; a provider’s own SDK is usually most complete with that provider’s models.
5. Check the boring parts: resuming a run after a failure, pausing for approval, traces you can send where you already look, and a release status you are comfortable shipping on.
6. Check MCP. All six connect to MCP servers, but some let the provider call the server for you and others call it from your process, which changes what the server can see and where credentials live.

When you don’t need a framework

Anthropic’s guide to building effective agents↗ (opens in a new tab) suggests starting with the model API directly, because many patterns take a few lines of code, and warns that frameworks can add layers that obscure the prompts and responses and make debugging harder. The loop itself is short. In any provider’s SDK it has this shape:

messages = [system_prompt, user_request]
for turn in range(MAX_TURNS):
    reply = model.create(messages=messages, tools=TOOL_SCHEMAS)
    messages.append(reply)
    if not reply.tool_calls:
        return reply.text                      # the answer
    for call in reply.tool_calls:
        result = TOOLS[call.name](**call.arguments)   # your code runs it
        messages.append(tool_result(call.id, result))
raise RuntimeError("stopped at the turn limit")

Stay with plain code when one model calls a few tools you wrote, the run finishes in one request, and you log to your usual logs. Reach for a framework when you find yourself building the second of these: resuming a run after a restart, several agents passing work between them, a pause for approval that may last hours, or traces a colleague needs to read. Adding one later is easy when your tools are plain functions or an MCP server, because every framework here can call both.

Where the work gets recorded

A framework keeps state for as long as a run or a session lasts. The work the agent did, and the work still to do, needs to outlive that and be readable by people who never open a trace. fenbs is an MCP server at https://fenbs.ai/api/mcp with around thirty tools, so any framework above can reach it the way it reaches any other server. A script signs in with a token you issue by hand under Settings, with a name, the scopes it needs and an optional expiry. The agent then reads its task, comments what it did, and moves the task between To Do, Next Up, In Progress and Completed, and each change is recorded in the board’s history under the assistant’s name. Switching framework next quarter changes the code, not the record.