Ask ten engineers which AI agent framework to use and you’ll get eleven answers, most of them delivered with unearned confidence. The truth is duller and more useful: for the vast majority of production agents, a framework is a thin skin over a model API, a tool-calling loop, and some state management. What differs is how much of that plumbing the framework hands you, and how much it buries behind abstractions you’ll end up fighting.
If the boundary between a workflow, a chatbot and a genuine agent is still fuzzy, settle that first — this breakdown of what AI agents actually do and where they break covers the failure modes in more detail than any framework’s docs will.
What an AI agent framework actually gives you
Strip away the positioning decks and most frameworks are selling the same five things:
- The execution loop. The model requests a tool, your code runs it, the result goes back into context, repeat until done. Every framework wraps this. Very few improve it.
- State and persistence. Checkpointing a run so it can resume after a crash, or after a human approves step seven, is genuinely hard to bolt on later. This is the clearest case where the abstraction earns its keep.
- Typed tool definitions. Turning a Python function or a Pydantic model into a JSON schema the model can call, then validating whatever comes back.
- Multi-agent plumbing. Handoffs, message passing, supervisor patterns, shared memory across several agents.
- Tracing. Hooks that record every prompt, token count and tool call so you can work out why run 4,182 did something bizarre.
That’s the honest inventory. A single agent with three tools and a retry can be written in about 80 lines of Python, no dependency needed. Frameworks start paying off when you need persistence, multiple agents, or an audit trail you’d otherwise build from scratch.
The main families of AI agent frameworks
Most options fall into four camps. Knowing which camp fits your problem narrows the choice faster than any benchmark table.
Graph-based orchestration: LangGraph
LangGraph models an agent as a state machine. Nodes do work, edges decide where to go next, and you can loop, branch, pause and resume from a checkpoint. It reached a 1.0 release in late 2025, which counts for something in a space with this much churn. The cost is verbosity: a simple agent takes more lines than it would elsewhere because you’re drawing the graph yourself. That’s also the benefit. When your agent misbehaves at 2am, an explicit graph is far easier to reason about than a stack of prompts hidden inside a wrapper class.
Role-based crews: CrewAI
CrewAI’s mental model is a team. You define agents with roles and backstories, hand them tasks, and let them collaborate. It’s the quickest route from idea to working demo, and the output is readable by people who don’t write code. Keep an eye on the token bill, because role-play prompts are long and crews will happily chatter. Before scaling past a handful of agents, read up on when multi-agent systems genuinely beat a single model. The honest answer is less often than the tutorials suggest.
Conversation-first: AutoGen and the Microsoft Agent Framework
AutoGen came out of Microsoft Research and made its name with agents that talk to each other until a task is solved. Its patterns, group chat especially, are still worth studying. Microsoft has since folded AutoGen and Semantic Kernel into the Microsoft Agent Framework, so new Azure projects are better served starting there. The conversational style shines on open-ended research and struggles on anything with a hard deadline and a predictable sequence of steps.
Vendor SDKs: OpenAI, Google, Anthropic
Each big model provider now ships its own agent toolkit. The OpenAI Agents SDK landed in March 2025 and covers the essentials cleanly: tool calling, handoffs between agents, guardrails that run alongside the main loop, and tracing in the dashboard. Google’s Agent Development Kit targets Gemini and Vertex, with reasonable deployment support on Google’s runtime. Anthropic’s Agent SDK leans hard on native tool use and stays deliberately minimal. These are the sensible pick if you’re already committed to one provider and don’t need exotic orchestration. The risk is obvious. Switching models later means rewriting the glue.
Typed and event-driven: Pydantic AI, LlamaIndex Workflows, Mastra
Pydantic AI carries the validate-at-the-boundary philosophy of FastAPI into agents, so a tool returning malformed JSON fails loudly instead of quietly poisoning the next turn. LlamaIndex Workflows treats agents as event-driven steps, which suits document pipelines. Mastra does a similar job for TypeScript teams who would rather not run Python in production.
What separates a usable framework from a demo toy
Benchmarks tell you very little. These questions tell you a lot:
- Can you see why it failed? Full traces of prompts, tool calls and token spend, exportable, not locked inside someone’s dashboard.
- Can you interrupt it? Real workflows need approval gates. If pausing mid-run means killing the process, keep looking.
- Does it pin its dependencies? A framework that breaks on a minor version bump will cost you a weekend you won’t get back.
- Where does state live? In-memory is fine for a prototype and a liability in production.
- How loud is the abstraction? You should be able to read the exact prompt going to the model. If you can’t, debugging turns into guesswork.
The parts no framework solves
Agent failures are rarely orchestration failures. They’re usually the model deciding it’s finished when it isn’t, retrying a dead API call until the budget evaporates, or running the same side effect twice because a step resumed from a stale checkpoint. Those are engineering problems, and they get fixed with engineering: idempotency keys on every write, hard caps on loop count and spend, and a validation step that checks the output against reality rather than trusting the model’s summary of it. The habits that make agents finish the job matter more than the framework choice, and they port across all of them.
Evaluation is the other gap. A framework will log your traces. None of them will tell you the receipt-extraction agent is quietly getting worse. You need 50 to 200 real cases with expected outputs, run on every prompt or model change. Build that set on day one. It’s the least glamorous task in the project and the one that stops you shipping a regression on a Friday afternoon.
Test with a real task, not a hello-world
Before committing, spend one afternoon building something small but real in two candidate frameworks: a tool that reads a messy note and returns structured action items with owners and dates. It’s fiddly enough to surface the annoying parts — schema validation, retries, how each framework handles a model that replies with prose instead of JSON. Building an action-item extractor from scratch is a decent template, and it takes roughly the length of a single afternoon.
You’ll learn more from that exercise than from a week of comparison posts, because friction is personal. One team finds LangGraph’s explicitness reassuring. Another finds it suffocating and reaches for something lighter.
Learn the loop by hand first
The engineers who get the most out of these frameworks tend to be the ones who wrote a bare-bones agent without one. Fifty lines: a while loop, a list of messages, JSON schemas for two tools, a max-iterations guard. Once you’ve watched the raw loop run, framework abstractions stop feeling like magic and start feeling like convenience. Better still, you can tell which conveniences you actually need and which are someone else’s idea of a good time.
The tooling moves fast enough that any specific recommendation ages badly. Models keep absorbing work the frameworks currently handle: stronger native tool calling, longer context, built-in structured outputs. What won’t change is the shape of the problem. A model, a loop, tools with side effects, and a human who needs to trust the result. Pick whichever framework makes that loop easiest to see into, and plan to reassess your stack every few months rather than once a year.