AI Agent Frameworks Compared

Should you build your agent on a framework or straight on the model API? The honest answer is that neither is the right default — it depends on how much infrastructure the framework would save you from writing yourself. A framework earns its place when it removes real work: prebuilt tool integrations, a retrieval stack, multi-agent orchestration, durable state. It costs you when all it adds is an abstraction layer between you and a loop you could have owned in fifty lines. This piece compares the main approaches fairly, on the dimensions that actually decide the call.

I build agents for a living, on the raw API by default and reaching for framework pieces when the plumbing justifies it. So this is a builder's comparison, not a vendor pitch. First, what an agent even is under all these tools — because it's the same thing in every one of them.

The thing every approach is wrapping

An agent is a loop: the model looks at the situation, picks an action, a tool runs it, the result feeds back, and it repeats until a stopping condition fires. Model, tools, memory, stopping condition, run in a circle. That's it, and I cover the mechanics in full in building AI agents that actually work. Every framework below is a different set of wrappers around that same loop. None of them invent a new kind of intelligence. They differ in how much of the loop they write for you, how much they hide, and how much they decide on your behalf.

Keep that in mind as the north star. The question is never "which framework is smartest" — the model supplies the intelligence, the framework supplies plumbing. The question is how much plumbing you need and what you'll pay in control and visibility to get it prebuilt.

The approaches, described honestly

Direct on the model API means you write the loop yourself against the provider's SDK. You own the message list, the tool-call dispatch, the stopping condition, everything. Maximum control, minimum abstraction, one dependency.

Provider agent SDKs are the thin, official agent layers the model vendors ship on top of their own APIs. They give you a supported loop, tool registration, and often session and hand-off helpers, staying close to the underlying API. Less to write than raw, still relatively transparent, but tied to that provider's shape.

LangChain is the broad, general-purpose toolkit: a large library of integrations, chains, and abstractions for composing LLM calls, tools, and memory. Its reach is the selling point — a huge catalog of prebuilt connectors — and also the critique, since that breadth is a lot of abstraction to see through. LangGraph is the related library for building agents as explicit graphs of nodes and edges, which buys back much of the control and inspectability by making the state machine visible. Treat them as different tools from the same ecosystem, not one thing.

LlamaIndex is centered on data: indexing, retrieval, and querying over your own documents. If your agent is really a retrieval problem — answer questions grounded in a corpus — its strength is the ingestion and retrieval stack, with agent features built around that core.

CrewAI sits higher up, orchestrating multiple role-playing agents that collaborate — a "researcher" hands to a "writer" and so on. It's aimed at multi-agent workflows, so it does the most for you and, correspondingly, hides the most.

The dimensions that decide it

Read that as a map of trade-offs, not a scoreboard. The rows worth expanding are the ones people underweight until production.

Control and debuggability move together, and they're the ones you feel at 3 a.m. When an agent misbehaves, you need to see exactly what the model decided, which tool it called with what arguments, and what came back. On a direct loop that trace is just your own log lines — nothing between you and the truth. Every abstraction layer adds distance: more of the behavior lives in framework code you didn't write, so a misfire means learning the framework's internals before you can fix your bug. The heavier frameworks ship tracing and observability tooling precisely because this is the pain point, and it genuinely helps — but it's buying back visibility the abstraction took away. LangGraph's explicit-graph model is the interesting middle: you get orchestration help while keeping the control flow inspectable.

Lock-in here is framework lock-in, not model lock-in — and that surprises people. Most frameworks abstract over multiple model providers, so swapping the underlying model is usually easy; that's a real point in their favor. What's sticky is that your code gets written against the framework's own concepts — its chains, graphs, agent classes, memory objects. Leaving means a rewrite of the orchestration, even though the model call underneath is trivial. The mitigation is the same discipline regardless of path: keep your business logic and tool implementations as plain functions, and treat the framework as a thin layer you could unplug. If your tools are ordinary code, migrating is annoying; if your logic is fused into framework abstractions, it's a project.

Statefulness is where a framework can genuinely save you. A simple in-loop conversation you can hold in a message array yourself. But durable state across runs, resumable workflows, checkpointing, coordinating several agents — that's real infrastructure, and rebuilding it well is expensive. This is one of the clearest "reach for the framework" signals: LangGraph is built around explicit state, CrewAI manages it across collaborating agents. If you need that and would otherwise hand-roll it, the framework is earning its abstraction. The flip side of state is context — how much of the growing history you keep in front of the model each turn — and that's a discipline you own no matter what, covered in context engineering.

Production-readiness: the part no framework hands you

Here's the thing that cuts across every option: production-readiness is mostly what you build around the agent, not which framework runs it. Any real deployment needs the same guardrails — a hard budget on steps and tokens so a confused loop can't run up a bill, verification that checks whether the agent actually finished instead of trusting its own "done," logging of every decision and tool call, and error recovery when a tool fails. The mature frameworks are used in production and give you scaffolding for some of this. None of them give you all of it by default, and none absolve you of owning it. A framework can make you feel production-ready faster than you are, which is its own risk. Whichever path you take, budget the loop, verify the result, and instrument everything yourself.

When to reach for a framework vs roll your own

My honest recommendation, the way I actually decide:

• Roll your own on the API when the loop is simple — a single agent calling a handful of tools, which is most agents — and you value control, easy debugging, and few dependencies. This is my default. The loop is small, you understand every line, and there's nothing between you and the model when something breaks.
• Use the provider SDK when you want the official, supported path close to the API, you're comfortable on one provider, and you'd rather not maintain the loop plumbing yourself. A reasonable middle ground with modest abstraction.
• Reach for a framework when it removes infrastructure you'd otherwise build: many prebuilt tool and data integrations (LangChain), a serious retrieval stack (LlamaIndex), explicit durable state and complex control flow (LangGraph), or multi-agent orchestration (CrewAI). The test is whether it saves more work than the abstraction and lock-in cost you.

The mistake in both directions is the same: picking based on hype instead of need. Don't roll your own to prove a point when a framework would save you weeks of rebuilding retrieval. Don't pull in a heavy framework for a fifty-line loop because it's what the tutorials use. And whichever you choose, the surrounding decisions matter more than the framework logo — whether you even need an agent versus a single prompt or a workflow, whether you're really building an agent or a chatbot or copilot, and how reliably you handle structured output and tool use. Get those right and the framework question gets small. For the wider build context around all of it, I keep the building with LLMs field guide.

FAQ

Do I need a framework to build an AI agent? No. A working agent is a loop around a model API — call the model, run the tool it asks for, feed the result back, repeat until a stopping condition — and you can write that in a few dozen lines against the raw SDK. Frameworks add prebuilt tool integrations, memory, and orchestration on top of that loop, which saves time on plumbing but adds an abstraction layer between you and the model. Reach for one when you'd otherwise rebuild that plumbing yourself, not by default.

What's the difference between LangChain, LangGraph, LlamaIndex, and CrewAI? They cover different jobs. LangChain is a broad toolkit of integrations and chains; LangGraph is its graph-based library for explicit stateful control flow. LlamaIndex is centered on data indexing and retrieval — the RAG side of an agent. CrewAI is a higher-level framework for orchestrating multiple role-playing agents. The provider SDKs give you a thin, official agent loop close to the API. Broadly: more abstraction means faster to start and harder to see inside.

Is it better to use a framework or build on the model API directly? Build direct when you need tight control, easy debugging, and minimal dependencies, and when your agent loop is simple enough to own — most single-agent tool-use loops qualify. Reach for a framework when it saves you from rebuilding real infrastructure you'd otherwise write yourself: dozens of tool integrations, a retrieval stack, multi-agent orchestration, or durable state. The deciding question is whether the framework removes more work than the abstraction it adds costs you.

Do agent frameworks lock me into a vendor? Somewhat, but it's framework lock-in more than model lock-in. Most frameworks abstract over multiple model providers, so swapping models is usually easy. What's sticky is your code being written against the framework's own concepts — its chains, graphs, or agent classes — so leaving means a real rewrite. The mitigation is to keep your business logic and tool implementations in plain functions and treat the framework as a thin orchestration layer you could replace.

Are agent frameworks production-ready? The mature ones are used in production, but "production-ready" depends on what you add around them, not the framework alone. Any real deployment needs step and token budgets, verification of results, logging of every model decision and tool call, and error recovery — a framework gives you scaffolding for some of that but doesn't guarantee it. Whichever path you pick, you own observability and the guardrails; the framework choice mostly changes how much plumbing you start with.