What Is an Agent Framework? (and Do You Even Need One?)

// In plain English

An agent framework is a library that handles the repetitive plumbing of building an AI agent, so you can focus on what the agent should actually do. An agent is an LLM that runs in a loop: it thinks, picks a tool, runs it, reads the result, and repeats until the task is done. The framework gives you that loop, the tool wiring, and the message bookkeeping pre-built.

Think of building a custom car. You could forge your own engine, wheels, and brakes from scratch. Or you could start from a chassis kit that already has the engine mounted and the wiring run, and bolt on the parts that make your car yours. An agent framework is that chassis kit. The chassis isn't the interesting part of your car — but rebuilding it for every project is a waste of your time.

Popular examples include LangGraph, CrewAI, LlamaIndex, OpenAI Agents SDK, smolagents, and provider-native kits like the Claude Agent SDK. They vary wildly in size and philosophy, but they all answer the same question: what's the boilerplate I shouldn't have to write again?

// Why it matters

Calling an LLM API once is trivial: one HTTP request, one answer. But an agent is not one call — it's many, in a loop, with state carried between them. The first time you build one by hand, you discover how much surrounding code you need: maintain a growing message history, describe your tools in the model's schema, parse the tool call it returns, run the function, feed the result back, and decide when to stop. Then add retries, timeouts, logging, and streaming.

Every team was writing that same loop from scratch. Agent frameworks packaged it up. Instead of hand-rolling tool use plumbing for every project, you register a function and the framework handles the round-trip. What used to be a few hundred lines of careful glue becomes a dozen lines of intent.

Who should care

• Developers building anything multi-step — a research agent, a coding agent, a customer-support bot that calls real APIs — where the model loops and uses tools.
• Teams that want portability — frameworks let you swap the underlying model without rewriting your whole app.
• Anyone coordinating multiple agents — a multi-agent system needs orchestration, hand-offs, and shared state that a framework provides out of the box.

// How it works

Under the hood, every agent framework wraps the same core loop. The model never "does" anything itself — it just emits text or a request to call a tool. The framework is the runtime that acts on those requests and loops back. Here's the cycle a framework runs for you:

On top of that loop, frameworks add a fairly consistent set of building blocks. Different libraries name them differently, but the concepts repeat:

Frameworks split into two broad styles. Graph / workflow frameworks (like LangGraph) make you define explicit steps and transitions — more setup, but you can see and control exactly what runs next. Autonomous-loop frameworks (like smolagents or CrewAI) hand you a higher-level agent and run the loop with less ceremony. The trade-off is the eternal one: control versus convenience.

// The 'no framework' version (so you know what you're buying)

The best way to understand what a framework gives you is to write the loop by hand once. It's genuinely short. Here's a complete tool-using agent using only a provider SDK — no agent framework at all. Read it, and you'll see exactly which lines a framework would delete for you.

# pip install anthropic  — no agent framework, just the provider SDK
import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from your env

# 1. Describe the tool to the model (name, purpose, input schema).
tools = [{
    "name": "get_weather",
    "description": "Get the current temperature for a city.",
    "input_schema": {
        "type": "object",
        "properties": {"city": {"type": "string"}},
        "required": ["city"],
    },
}]

# 2. Your actual tool — a plain Python function.
def get_weather(city: str) -> str:
    fake_db = {"Paris": "19C", "Tokyo": "24C"}
    return fake_db.get(city, "unknown")

messages = [{"role": "user", "content": "What's the weather in Paris?"}]

# 3. The loop a framework would run for you.
while True:
    resp = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        tools=tools,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason != "tool_use":
        print(resp.content[0].text)  # final answer — stop looping
        break

    # The model asked to call a tool: run it and feed the result back.
    for block in resp.content:
        if block.type == "tool_use":
            result = get_weather(**block.input)
            messages.append({"role": "user", "content": [{
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": result,
            }]})

That while True block — sending messages, checking stop_reason, running the tool, appending tool_result, looping — is the agent. A framework hands you that loop pre-written, plus retries, parallel tool calls, streaming, and a tidier way to register tools. For one tool and one model, the raw version is honestly fine. For ten tools, three agents, and a need to swap providers, you'll want the framework.

// Do you even need one?

Here's the honest answer the marketing won't give you: often, no. A surprising number of "agents" are really a single well-crafted prompt, or a fixed sequence of two or three LLM calls with code in between. Those don't need an agent framework — they need good prompt engineering and a few lines of plain code. Anthropic's own guidance is to start with the simplest thing that works and add agentic complexity only when simpler approaches fall short.

Use this rough rule. The more uncertainty (the model decides what to do next) and the more moving parts (many tools, many steps, many agents), the more a framework earns its keep. The more deterministic and simple your task, the more a framework is overhead you'll fight.

// The landscape: which framework does what

"Agent framework" is a loose label covering tools with different centers of gravity. Knowing what each is best at saves you from forcing the wrong one onto a problem. This category at agent SDKs and frameworks covers each in depth; here's the map.

These aren't mutually exclusive. A common real-world stack uses LlamaIndex for ingestion, LangGraph for orchestration, and calls a provider SDK directly inside a node. And if portability across models matters to you, a major reason to use any framework is the model adapter layer — write your agent once, then point it at a different model by changing a string.

One more axis worth naming: provider-native vs. provider-agnostic. The Claude Agent SDK and OpenAI Agents SDK are tuned to one provider's models and patterns — often the smoothest path if you're committed to that provider. LangGraph, CrewAI, and smolagents aim to work across providers, trading a little polish for portability.

// Going deeper

Once the basics click, here's what separates a toy agent from one you'd trust in production — and where frameworks help, hurt, or simply can't save you.

Frameworks don't fix reliability

The hardest problem with agents isn't the loop — it's that errors compound. If each step is 95% reliable, ten steps in a row land near 60%. No framework fixes that for you. You still need solid evaluation, guardrails, and tight tool design. A framework can give you tracing hooks to see where a run derailed, but the reliability work is yours.

The abstraction tax, made concrete

Every framework sits between you and the raw model. When it works, that's a gift. When it doesn't, you debug two systems, and deep abstractions can obscure the actual prompt being sent — which matters enormously, because the prompt is where most agent behavior is won or lost. A good framework lets you drop down and inspect or override the raw messages. If a framework hides the prompt from you entirely, treat that as a red flag, not a feature.

Security is not optional

An agent that runs tools is an agent that can be hijacked. Prompt injection — malicious instructions hidden in a web page or document the agent reads — can trick it into calling tools you never intended. Frameworks add some guardrail hooks, but the discipline is on you: validate tool inputs, sandbox anything dangerous, and never let a tool do something irreversible without a check.

Standards are reducing lock-in

A newer reason the framework choice matters less than it used to: the Model Context Protocol (MCP) is becoming a shared standard for connecting agents to tools and data. As more frameworks speak MCP, the tools you build become portable across them — so you can change frameworks later without rewriting every integration. The honest mature take: learn the bare agent loop, pick the lightest framework that removes real pain, and never let any framework stop you from understanding what the model is actually doing.