In article 8 we built an agent from scratch, and I made a promise: once you’d seen the loop with your own eyes, you’d understand exactly what a framework does for you. Now it’s time to keep that promise. Because sooner or later you’ll face the question every agent builder faces, usually early and usually loudly: which framework should I use? There are a lot of them, they all claim to be the best, they churn constantly, and the honest answer is more interesting than any single recommendation.
I’m going to be deliberately careful in this article. The specific frameworks that are popular this year may not be the ones that are popular in two years, and I’d rather teach you how to choose than hand you a shopping list with a short shelf life. So we’ll talk about the categories frameworks fall into, the criteria that actually matter, and the one decision that trumps all the others: whether you need a framework at all.
What a framework actually gives you
Remember the from-scratch agent: a system prompt, some tool functions, a message list, and a loop. It worked. So what’s a framework adding on top?
Mostly, it’s adding the unglamorous production machinery you’d otherwise write yourself. Retries and error handling for when a tool call or model call fails. State management so a long-running agent can pause, persist, and resume. Streaming so you can show output as it’s generated rather than making the user wait. Logging and tracing so you can see what the agent did, which matters enormously for debugging. Tool integrations so common tools come pre-built. And often a cleaner way to express structure, especially for multi-step or multi-agent flows, so you’re not managing a tangle of loops by hand.
None of this is magic. Every bit of it is something you could write. A framework is a bet that someone else has already written it better than you will on a deadline, and that the time you save is worth the dependency you take on. Often that bet is correct. Sometimes it isn’t.
Figure 1: The bare agent loop sits at the centre. A framework wraps it in retries, state, streaming, tracing, and pre-built tools, the production machinery you’d otherwise build yourself.
Figure 1 makes the relationship clear. The loop you built in article 8 is still in there, at the core. The framework is the ring of conveniences around it. Understanding that ring-around-a-core structure is what stops frameworks from feeling like black boxes.
The spectrum of frameworks
Rather than name specific tools that’ll date, it helps to see that frameworks spread along a spectrum from low-level control to high-level convenience.
At the low-control, high-flexibility end sit lightweight libraries and SDKs that stay close to the raw model API. They give you helpers for tool calling and the loop but otherwise get out of your way. You write most of the logic, so you keep full control and there’s little to unlearn, at the cost of building more yourself. This end suits people who want to understand and shape every step.
In the middle sit graph-and-workflow frameworks that let you express an agent as an explicit structure of steps, branches, and state. These shine when your agent’s logic is complex enough that a plain loop gets unwieldy, and when you need to reason carefully about state, checkpoints, and control flow. You trade some simplicity for a lot of structure.
At the high-convenience end sit opinionated, batteries-included frameworks, often built around roles and multi-agent teams, where you describe agents and their jobs at a high level and the framework handles the coordination. These get you to a demo fastest. The trade is less visibility into what’s happening and more of the framework’s assumptions baked into your system.
Sitting a little apart from the spectrum are vendor-native agent SDKs, first-party toolkits published by the model providers themselves. They tend to sit near the low-control end in shape, but with production ergonomics like tool use, tracing, and streaming built in and tuned to the vendor’s own model. If you’re already committed to a single provider, these are often the smoothest path from prototype to production. The trade is portability: an SDK optimised for one provider’s model isn’t neutral about which model you use.
None of these is “best.” They’re suited to different situations, and knowing where a framework sits on the spectrum (or off to the side of it) tells you more than its marketing ever will.
The criteria that actually matter
When you’re weighing a specific framework, here’s what I’d actually look at, in rough order of importance.
How much control do you need? If you’re doing something novel or precise, favour the lower-control end so the framework isn’t fighting you. If you’re building something standard fast, the convenient end earns its keep.
How visible is the execution? When something goes wrong, and it will, can you see what the agent did, step by step? Frameworks with strong tracing save you days. Frameworks that hide the loop cost you those days back with interest.
How healthy is the ecosystem? Active maintenance, real documentation, a community solving the same problems you’ll hit. A brilliant framework with three contributors and no docs is a liability the moment you’re stuck.
How much lock-in are you taking on? If moving off this framework later means rewriting everything, that’s a real cost. Frameworks that stay close to standard patterns are easier to leave, which paradoxically makes them safer to adopt.
Does it speak MCP cleanly? This one is newer but increasingly matters. A framework that treats MCP as a first-class citizen (rather than an afterthought or a custom plugin) inherits the whole ecosystem of servers from the last article for free, and any tools you build stay portable if you switch frameworks later. It’s a portability check for the tool layer, and it’s a good tie-breaker between otherwise comparable options.
Does it match your team? A framework your team can read, debug, and reason about beats a technically superior one that only its author understands.
Figure 2: A simple decision path: start by asking whether you need a framework at all, then sort by how much control versus convenience the task calls for, then check ecosystem health and lock-in before committing.
Figure 2 turns those criteria into a path you can actually follow. Notice where it begins, with a question most framework comparisons skip entirely.
The decision that comes first: do you even need one?
Here’s the contrarian point, and I mean it seriously. For a lot of agents, especially early ones, the right framework is no framework. The from-scratch loop from article 8 is genuinely enough for a surprising range of real work. Starting without a framework has underrated benefits: you understand every line, you have zero dependencies to break, and you learn what you actually need before you go shopping for it.
The trap is adopting a heavy framework on day one, before you know your requirements, and then contorting your problem to fit the framework’s assumptions. I’ve watched simple tasks become complicated precisely because they were forced through a framework built for something else.
So my honest advice is this. Build your first version with little or no framework. Feel where it hurts, the retries you keep rewriting, the state you keep losing, the tracing you wish you had. Then adopt a framework that solves those specific pains, chosen with the criteria above. A framework adopted to solve pains you’ve actually felt is a joy. A framework adopted because a blog post was enthusiastic is usually a regret. Let the pain, not the hype, pick your tools.
In the next article we tackle a problem that gets harder the more capable your agents become: how do you evaluate and observe an agent once it’s running in production, where a single answer is now a whole chain of decisions, tool calls, and steps that can each go wrong?