Agent Frameworks & SDKs

The previous pillars of this site described the building blocks — the agent-loop, tool-use, memory — and the wire protocols (MCP for agent-to-tool, A2A for agent-to-agent) that let those pieces interoperate. A framework is what you actually pick up to assemble an agentic system out of those blocks. This page surveys the major ones, drawing each description from its official documentation, and ends with a comparison table.

There is no single "best" framework; they sit at different points along a few axes. The most useful way to read the landscape is to notice what each one makes the first-class abstraction: a graph, a crew of roles, a conversation, a handoff, or a tool-equipped agent object.

flowchart LR
    subgraph control["More explicit control"]
        LG[LangGraph
graph of nodes]
        SK[Semantic Kernel
kernel + plugins]
        ADKb[Google ADK
workflow agents]
    end
    subgraph emergent["More emergent / autonomous"]
        CR[CrewAI Crews
role-playing agents]
        AG[AutoGen / AG2
conversing agents]
    end
    subgraph minimal["Minimal primitives"]
        OAI[OpenAI Agents SDK
agents + handoffs]
        CLA[Claude Agent SDK
the Claude Code loop]
        LI[LlamaIndex
FunctionAgent + RAG]
    end

Diagram framework-axes: a rough placement of the frameworks by how much the developer specifies control flow explicitly versus how much is left to the model. Placements are approximate — most of these frameworks can be pushed toward either end.

LangGraph — a graph of stateful nodes

LangGraph models an agent as a graph: you declare a typed shared state, add nodes (functions that read and write that state) and edges between them, and the runtime executes the graph. The headline abstraction is StateGraph, built up with add_node and add_edge. Crucially, the graph may contain cycles, so an agent can loop, retry, and reflect — the structure you need when information flows back and forth between a model and its tools, rather than the strict directed-acyclic flow of a pipeline.

Its official docs describe LangGraph as a "low-level orchestration framework for building stateful agents," and that low-level framing is the point: it does not abstract away your prompts or architecture. The four pillars its docs emphasize are durable execution (agents "persist through failures … automatically resuming from exactly where they left off"), human-in-the-loop (inspect and modify agent state at any point), comprehensive memory (short-term working memory plus long-term memory across sessions), and debugging/observability via LangSmith. LangGraph is MIT-licensed, and its repository lists production users including Klarna, Replit, and Elastic.

For teams that want a faster on-ramp, LangGraph ships a prebuilt agent constructor (create_react_agent) that wires up a ReAct-style tool-calling loop for you; you graduate to a hand-built StateGraph when you need bespoke control flow, conditional branching, or graph visualization.

• Model / abstraction: a directed graph with a shared, typed state and possible cycles.
• Strengths: precise control over branching and loops; first-class persistence/checkpointing and human-in-the-loop; strong observability.
• Pick it when: your workflow is complex enough that you want to draw it — explicit states, retries, approvals, long-running runs that must survive restarts.
• MCP / A2A: integrates MCP tools through the surrounding LangChain ecosystem; not an A2A framework itself.

CrewAI — role-playing crews plus event-driven flows

CrewAI is a Python framework whose docs describe it as "built entirely from scratch — completely independent of LangChain or other agent frameworks." Its mental model is a crew: a team of role-playing agents that collaborate. An Agent is defined by three required attributes — role, goal, and backstory — which together shape its behaviour. Agents are assigned Tasks, and the crew runs them under a process: sequential (tasks in order) or hierarchical (a manager agent plans and delegates).

CrewAI deliberately exposes two complementary paradigms. Crews are "teams of autonomous agents that collaborate to solve specific tasks," optimizing for emergent, role-based collaboration. Flows are "structured, event-driven workflows that manage state and control execution" — the deterministic backbone you use when you need granular control, and which can in turn delegate work to a Crew. The combination lets you mix autonomous collaboration with precise orchestration in one app.

CrewAI consumes MCP servers as tools through an MCPServerAdapter (in the crewai-tools[mcp] extra), which manages the connection lifecycle and supports stdio, sse, and streamable-http transports.

• Model / abstraction: crews of agents with role/goal/backstory, running tasks under a sequential or hierarchical process; plus event-driven Flows.
• Strengths: intuitive role metaphor; quick to stand up a multi-role team; clean separation of autonomous Crews from deterministic Flows.
• Pick it when: the problem decomposes naturally into human-like roles (researcher, writer, reviewer) and you want collaboration with optional structured control on top.
• MCP / A2A: MCP via MCPServerAdapter; not itself an A2A protocol implementation.

AutoGen / AG2 — agents that converse to solve tasks

AutoGen frames multi-agent work as a conversation: capable, customizable, "conversable" agents exchange messages — with each other, with tools, and with humans — to jointly finish a task. The fundamental building block in this lineage is the ConversableAgent. Coordination happens through patterns like group chat (GroupChat driven by a GroupChatManager), swarms, and nested conversations, and human-in-the-loop is built in — a UserProxyAgent can inject human input and execute code, with human_input_mode set to ALWAYS, NEVER, or TERMINATE.

The project has split into two actively developed lines, which is essential context when choosing it. Microsoft's AutoGen was rearchitected around v0.4 into a layered, asynchronous, event-driven design: a Core API ("an event-driven programming framework for building scalable multi-agent AI systems"), an AgentChat high-level conversational API built on Core (with agents like AssistantAgent), and an Extensions API for external integrations. Separately, AG2 (explicitly "formerly AutoGen") is a community fork that markets itself as an open-source "AgentOS" and keeps the ConversableAgent / GroupChat programming model. Both require Python 3.10+.

• Model / abstraction: agents that solve tasks by exchanging messages; orchestration via group chat / swarm patterns.
• Strengths: natural fit for dynamic, open-ended multi-agent dialogue and code execution; flexible conversation topologies; strong human-in-the-loop story.
• Pick it when: you want agents to negotiate a solution conversationally rather than follow a fixed graph — and you're comfortable choosing between the Microsoft AutoGen and AG2 lines.
• MCP / A2A: both lines support tool integration including MCP servers; conversation, not A2A, is the native coordination mechanism.

OpenAI Agents SDK — minimal primitives: agents, handoffs, guardrails

The OpenAI Agents SDK is the production successor to the experimental Swarm project. Its docs distill the design into three core primitives — Agents (an LLM equipped with instructions and tools), Handoffs (which let one agent delegate to another), and Guardrails (which validate inputs and outputs) — with tools and sessions (automatic conversation history) as the supporting capabilities those agents draw on. It is deliberately small — most logic lives in plain Python plus these primitives — with built-in tracing.

A handoff is how one agent delegates to another, and the SDK's key implementation detail is that handoffs are exposed to the model as tools. If you hand off to an agent named "Refund Agent," the tool the model sees is named transfer_to_refund_agent (via Handoff.default_tool_name()); the handoff() helper lets you override the name/description, attach an on_handoff callback, or accept structured handoff input. Guardrails run validations alongside the agent: input guardrails run only for the first agent in a chain, and output guardrails only for the agent producing the final output, and a tripwire can halt execution.

sequenceDiagram
    participant U as User
    participant T as Triage Agent
    participant R as Refund Agent
    U->>T: "I want a refund on order #123"
    Note over T: model decides to delegate
    T->>R: tool call transfer_to_refund_agent
    Note over R: Refund Agent now owns the conversation
    R-->>U: processes the refund

Diagram handoff-flow: a handoff in the OpenAI Agents SDK is just a tool call. The triage agent emits transfer_to_refund_agent; control (and the conversation) passes to the specialized agent.

• Model / abstraction: a few primitives — agents (equipped with tools), handoffs, and guardrails — over plain Python.
• Strengths: very small surface area; handoffs make routing between specialists trivial; guardrails and tracing are first-class.
• Pick it when: you want a lightweight, OpenAI-centric way to build a router/triage system or a small team of specialists without a heavy orchestration layer.
• MCP / A2A: supports MCP servers as tool sources; oriented around in-process handoffs rather than the A2A protocol.

Claude Agent SDK — the Claude Code loop as a library

Anthropic's Claude Agent SDK gives you "the same tools, agent-loop, and context management that power Claude Code," programmable in Python (claude-agent-sdk) and TypeScript (@anthropic-ai/claude-agent-sdk). The distinguishing idea is that the SDK runs the agent loop inside your own process: you call query(...) and Claude autonomously decides which tools to run, rather than you hand-coding the tool loop yourself. It ships built-in tools (Read, Write, Edit, Bash, Glob, Grep, WebSearch, WebFetch, and more) so an agent can act immediately.

Its other capabilities mirror Claude Code: a permission system that gates which tools an agent may call (with an allowed_tools / allowedTools allow-list), hooks that run custom code at lifecycle points (PreToolUse, PostToolUse, SessionStart, and others), subagents (specialized agents, defined via AgentDefinition, that the main agent spawns for focused subtasks and invokes through the Agent tool), and sessions for resuming context. MCP support is first-class: external MCP servers are configured via mcp_servers / mcpServers, and custom tools can be exposed as in-process MCP servers.

• Model / abstraction: a single autonomous loop (Claude + built-in tools + context management) that you steer with options, hooks, permissions, and subagents.
• Strengths: batteries-included coding/file/web tools; the same battle-tested loop behind Claude Code; strong permission and hook controls for safety.
• Pick it when: you want a capable autonomous agent — especially for code, filesystem, or computer-use tasks — without building tool execution and context management yourself.
• MCP / A2A: MCP is a primary extension mechanism (consume servers, or expose in-process tools); not an A2A framework.

Microsoft Semantic Kernel — kernel, plugins, and agents

Semantic Kernel is Microsoft's SDK for embedding LLM capabilities into applications, with a multi-language story (.NET, Python, Java). Its central object is the Kernel, into which you register plugins — groups of callable functions. Plugins can come from native code, an OpenAPI specification, or an MCP server, and the model orchestrates them through function calling. Notably, the early "planners" that prompted the model to assemble a plan of function calls are now deprecated in favour of native function calling, which the docs recommend as more flexible and simpler.

The Agent Framework layers agent abstractions on top. Its docs name concrete agent types including ChatCompletionAgent, OpenAIAssistantAgent, AzureAIAgent, and OpenAIResponsesAgent, plus an orchestration package for multi-agent coordination. Semantic Kernel is positioned as enterprise-grade — stable, secure, observable, and at home in the broader Microsoft/Azure stack.

• Model / abstraction: a Kernel hosting plugins (functions), with an Agent Framework and orchestration layer above.
• Strengths: enterprise focus and multi-language support; clean plugin model spanning native code, OpenAPI, and MCP; deep Azure integration.
• Pick it when: you're building in .NET/Java or an enterprise/Azure environment and want a well-supported, governable way to add agents and tools to an existing application.
• MCP / A2A: plugins can be imported directly from MCP servers; agent coordination is via the orchestration framework rather than the A2A protocol.

LlamaIndex — agents on top of a data/RAG stack

LlamaIndex comes from the retrieval-augmented-generation world, and its agent layer is designed to sit on top of that data stack. The core agent is FunctionAgent, which uses an LLM's native function/tool calling to invoke tools (for models without function calling, there is a ReActAgent). Agents run inside LlamaIndex's Workflow abstraction, so state lives in a Context that can be passed between runs even though a FunctionAgent is stateless by default. For multi-agent systems, AgentWorkflow coordinates several agents, "where each agent is able to hand off control to another agent," while managing shared state.

Because it grew out of indexing and retrieval, LlamaIndex makes it natural to turn query engines and indexes into tools an agent can call. It also consumes MCP servers: the llama-index-tools-mcp package provides McpToolSpec, which pulls tools from an MCP client and converts them into LlamaIndex FunctionTool objects via to_tool_list().

• Model / abstraction: FunctionAgent / ReActAgent running inside a Workflow, coordinated for multi-agent cases by AgentWorkflow with handoffs.
• Strengths: best-in-class for RAG and data-heavy agents; query engines become tools naturally; workflow-based state management.
• Pick it when: your agent's job is fundamentally about retrieving over your documents/data, and you want agents tightly integrated with a mature ingestion/indexing stack.
• MCP / A2A: MCP tools via McpToolSpec; coordination is via in-process workflow handoffs.

Google ADK — workflow agents, model- and deployment-agnostic

Google's Agent Development Kit (ADK) is an orchestration framework for building and deploying agents that its docs describe as model-agnostic (Gemini, Gemma, plus others such as Claude via LiteLLM) and deployment-agnostic (Cloud Run, GKE, and more). Alongside model-driven LlmAgents, ADK provides explicit workflow agents that compose sub-agents deterministically: sequential, parallel, and loop workflows, plus custom templates.

ADK is unusually protocol-forward, treating both interoperability standards as first-class. It consumes MCP tools, and it implements A2A directly: the to_a2a() helper exposes an ADK agent over the network (returning a Starlette app you serve with uvicorn), while a RemoteA2aAgent acts as a client-side proxy for a remote agent — so an ADK agent can both be an A2A endpoint and call other vendors' A2A agents. Google's framing is the now-common one that the two protocols are complementary: MCP for agent-to-tool, A2A for agent-to-agent.

• Model / abstraction: LlmAgents plus deterministic workflow agents (sequential/parallel/loop), composable into multi-agent systems.
• Strengths: explicit, mixable control flow; strong, native protocol support (MCP and A2A); smooth path to Google Cloud deployment while staying model-agnostic.
• Pick it when: you want to combine deterministic orchestration with model-driven agents and you care about cross-vendor interoperability over A2A out of the box.
• MCP / A2A: both are first-class — MCP tools, and A2A via to_a2a() / RemoteA2aAgent.

Comparison

A few caveats for this table. "Native MCP" means the framework's own docs describe a supported path to consume MCP servers; the exact mechanism differs (an adapter class, a tool spec, a plugin source, or a config field). "Native A2A" means the framework directly implements the A2A protocol — at the time of writing Google ADK is the standout here, while the others coordinate agents in-process (handoffs, conversations, graph edges) and would reach other vendors' agents by adding an A2A layer. Because the A2A spec is transport- and framework-neutral, any of these agents can in principle be wrapped as an A2A server; the table reflects what ships in the box.

How to choose

The decision rarely hinges on a feature checkbox; it hinges on which abstraction matches how you already think about the problem.

• Think in flowcharts and state machines → LangGraph (or Google ADK's workflow agents).
• Think in teams and roles → CrewAI.
• Think in conversations / debate → AutoGen or AG2.
• Want the smallest possible primitives and OpenAI models → OpenAI Agents SDK.
• Want a ready-made autonomous coding/computer-use agent → Claude Agent SDK.
• Building in .NET/Java or an enterprise Azure context → Semantic Kernel.
• The job is fundamentally retrieval over your data → LlamaIndex.
• You need cross-vendor A2A interop in the box → Google ADK.

Two cross-cutting points matter regardless of choice. First, MCP support is now nearly universal — so your investment in MCP tool servers is portable across most of these frameworks (see protocols-mcp.html). Second, A2A is the layer that lets agents built in different frameworks cooperate across organizational boundaries (see protocols-a2a.html); framework choice settles how you build a single agent or in-process team, while A2A settles how those agents talk to the outside world. For the orchestration patterns these frameworks implement — supervisor, hierarchical, sequential, and peer-to-peer — see orchestration-patterns.html.