AI Agent Frameworks
An AI agent is an LLM running in a loop: it decides on an action, a tool executes it, the result comes back, and the model decides again — until the task is done. An agent framework is the harness that runs that loop for you and gives you the surrounding machinery: tool wiring, state and memory, control flow, retries, streaming, and observability.
The hard part of agents was never the first prompt — it's everything around it. Frameworks exist because hand-writing a robust while stop_reason == "tool_use" loop, with context management, error recovery, and human approval gates, is more work than most teams want to own. But a framework is also a dependency and an abstraction: the wrong one hides the loop you most need to control. This page maps the landscape so you can pick deliberately.
TL;DR
- An agent is an LLM + tools + a loop. A framework supplies the loop, tool plumbing, state, and observability so you don't hand-roll them.
- The single biggest decision is who runs the loop and hosts the compute: your process (LangGraph, Claude Agent SDK, CrewAI) or a managed service (Anthropic's Managed Agents).
- Reach for an agent only when the task is genuinely open-ended. Most "AI features" are one good prompt plus, at most, RAG — not an autonomous agent.
- Tool use and MCP are the substrate every framework builds on; understanding them makes framework code far less magical.
- Framework value is highest for stateful, multi-step, multi-tool workflows and lowest for a single classification or extraction call.
- Watch out for the context window — long agent runs balloon token cost; context editing, compaction, and summarization matter more than the framework you pick.
Quick Example
The smallest real agent is a tool-use loop. Anthropic's Tool Runner runs it for you — you supply the tools, it handles the request → execute → loop cycle:
That is an agent: the model calls get_weather, reads the result, and answers. Every framework below is an elaboration of this loop with more structure around it.
Core Concepts
The Agent Loop
Every agent framework, however it dresses it up, runs the same cycle:
What a framework adds is everything around the loop: typed state passed between steps, branching and cycles, parallel tool execution, checkpoints you can resume from, human-in-the-loop pauses, and traces you can debug.
Harness vs Deployment
The clearest way to compare frameworks is by two independent questions:
- Who supplies the harness — the loop, context management, and tool orchestration?
- Who supplies the deployment — the infrastructure the agent actually runs on?
Most frameworks (LangGraph, CrewAI, the Claude Agent SDK) supply a harness only — you still host and deploy them. A managed offering supplies both: the provider runs the loop and hosts a sandbox where tools execute. Conflating these is the most common source of confusion when evaluating tools.
Tools, State, and Memory
Three things distinguish an agent from a chatbot:
- Tools — the actions the agent can take. Defined as functions with a name, description, and input schema. See AI APIs & Tool Use.
- State — data that flows between steps within a single run (the current plan, intermediate results, a scratchpad).
- Memory — data that persists across runs or sessions (user preferences, learned facts, prior outcomes).
Frameworks differ most in how opinionated they are about state and memory. A graph framework makes state a first-class typed object; a lighter framework leaves it to you.
The Framework Landscape
LangGraph
LangGraph models an agent as a directed graph: nodes are steps (call the model, run a tool, check a condition), edges define the control flow, and a typed state object flows through it. Cycles are first-class, which is exactly what agents need — "reflect, then try again" is just an edge back to an earlier node.
Its defining features are checkpointing (persist state after every node, resume or time-travel later) and human-in-the-loop interrupts (pause the graph, wait for approval, resume). This makes it strong for long-running, auditable workflows where you need to see and control every transition.
Reach for LangGraph when control flow is complex, you need durable state, or a human must sit in the loop. The cost is a steeper learning curve — you think in graphs, not scripts.
Claude Agent SDK
The Claude Agent SDK (claude-agent-sdk in Python, @anthropic-ai/claude-agent-sdk in TypeScript) is Claude Code packaged as a library. It ships the full coding/filesystem harness out of the box: built-in Read/Write/Edit/Bash/Glob/Grep/WebSearch tools, the agent loop, context management, subagents, permissions, and sessions. You call query(prompt, options) and it drives everything on your own infrastructure.
It's the batteries-included choice when you want a capable coding or filesystem agent without assembling tools yourself. It is a harness only — you host and deploy it. Note it's a distinct product from the Anthropic API's Tool Runner: the Tool Runner loops over tools you define with no built-in tools; the Agent SDK is the whole Claude Code harness.
CrewAI, OpenAI Agents SDK, and Multi-Agent
Lighter, role-oriented frameworks model agents as collaborating roles — a "researcher" hands off to a "writer," a "coordinator" delegates to specialists. CrewAI and the OpenAI Agents SDK sit here. They optimize for quick assembly of multi-agent teams and are attractive when the task decomposes cleanly into roles.
The caution with multi-agent systems is real: every extra agent multiplies context, cost, and failure surface. A single well-prompted agent with good tools beats a five-agent "crew" for most tasks. Reach for multiple agents when subtasks are genuinely independent (fan out and merge) or require isolated context — not because org-chart metaphors are appealing.
Managed Agents
A managed agent service (such as Anthropic's Managed Agents) runs the loop and provisions a sandboxed container per session where tools — bash, file operations, code execution — actually run. You define a persisted, versioned agent config (model, system prompt, tools, MCP servers) and start sessions against it; the service streams events back and you send messages and tool results in.
This is the simplest option when you want a hosted, stateful, possibly scheduled agent and don't want to run loop code, manage a sandbox, or build a scheduler yourself. The tradeoff is less low-level control and a dependency on the provider's runtime.
Best Practices
Start Without a Framework
Write the manual tool-use loop first. It's ~30 lines, and building it teaches you exactly what a framework abstracts. Adopt a framework when you hit a concrete need it solves — durable state, complex branching, human approval — not preemptively.
Design Tools Around Intent, Not Your API
search_orders(query) beats exposing fifteen raw CRUD endpoints. The model composes fewer calls and errs less. Return compact, structured results — dumping huge JSON blobs into context burns tokens and degrades reasoning.
Budget the Context Window
The dominant hidden cost of agents is the growing transcript. Every tool result stays in context by default. Use context editing (clear stale tool results) or compaction (summarize old turns) on long runs, and cap tool output sizes server-side. A framework won't save you here — this is an architecture decision.
Gate Irreversible Actions
An agent that can both read customer data and send email can be induced to combine them. Put a human-approval gate in front of anything hard to undo (sending, deleting, paying). Treat tool outputs as untrusted — a fetched web page can carry prompt injection.
Make Runs Observable
You cannot debug what you cannot see. Log every model call, tool call, and result with a trace ID. Frameworks that ship first-class tracing (LangGraph checkpoints, managed-agent event streams) earn their keep in production.
Comparison
They compose rather than compete: a LangGraph node might call the Anthropic API with custom tools plus MCP servers, and a managed agent can itself expose custom tools your app resolves.
Common Mistakes
Building an Agent When a Workflow Would Do
If the steps are known in advance, write a workflow (code you control that calls the model at fixed points), not an agent (the model controls the flow).
Letting the Transcript Grow Unbounded
Trusting Tool Output as Instructions
Rendering a fetched page or ticket into context without treating it as untrusted input is how agents get hijacked. Guard sensitive tools behind confirmation and prefer allowlisted actions.
FAQ
Do I need an agent framework at all?
Often no. If your task is a single call, a classification, or an extraction, a framework is pure overhead. Frameworks pay off for stateful, multi-step, multi-tool workflows. Start with the manual tool-use loop and adopt a framework when you hit a concrete need it solves.
LangGraph vs the Claude Agent SDK — how do I choose?
LangGraph is a general orchestration library: you define arbitrary graphs of steps and tools, for any task. The Claude Agent SDK is a batteries-included coding/filesystem agent with built-in tools. Pick LangGraph for custom control flow and durable state; pick the Agent SDK when you want a capable coding agent without assembling tools yourself.
When should I use multiple agents instead of one?
When subtasks are genuinely independent (so you can fan out in parallel and merge) or need isolated context. Otherwise a single well-prompted agent with good tools is simpler, cheaper, and easier to debug. Multi-agent systems multiply context, cost, and failure modes.
How is an "agent" different from a "workflow"?
In a workflow, your code decides the sequence of steps and calls the model at fixed points. In an agent, the model decides what to do next in a loop. Workflows are more predictable and cheaper; agents handle open-ended tasks you can't fully script. Prefer a workflow whenever the steps are knowable in advance.
How do I keep agent costs under control?
The transcript is the cost driver. Use a cheaper/faster model tier for simple sub-steps, cap and summarize tool outputs, enable context editing or compaction on long runs, and set an iteration limit. See Context Engineering.
Related Topics
- AI Agents — The conceptual foundation: what agents are and when to use them
- AI APIs & Tool Use — Tool/function calling, the substrate every framework builds on
- Model Context Protocol (MCP) — The standard for giving agents reusable integrations
- Context Engineering — Managing the context window over long agent runs
- AI Guardrails — Defending agents against prompt injection and unsafe actions
- Prompt Engineering — Writing system prompts and tool descriptions that steer behavior
- LLM Evaluation — Measuring whether your agent actually works