Summary: Choosing an agent framework

The first real question about agent frameworks is not which one, but whether you want one at all. Lessons 1 and 2 built the loop yourself; adopting a heavy framework when fifty lines of your own code would handle the job is a common mistake. This summary is the scan version of how to make that call, and then how to match a framework to your task if you decide you want one.

Core ideas

• A framework provides two things. The plumbing (building the tool schema, formatting and parsing tool calls, running tools, feeding results back, looping) and opinionated building blocks on top (memory, planning, multi-agent coordination, connectors, observability). The building blocks are usually the real reason to adopt one.
• Hand-roll the loop when you want full control, minimal dependencies, and the loop is small (a few tools). Your own code is then easy to write, read, and debug.
• Adopt a framework when you want the boilerplate gone, opinionated patterns for the hard parts (multi-agent, memory, planning), and ecosystem integrations. You trade some control for a large head start.
• The trap is reaching for a framework reflexively. A single-tool agent does not need an orchestration library any more than a one-page script needs a web framework. Match the weight of the tool to the weight of the task.
• If you adopt, choose by category, not popularity. The ecosystem sorts into a few shapes: orchestration/multi-agent (coordinating several cooperating agents), retrieval-first (answering from your own documents, retrieval as a primitive), graph/state-machine (explicit, inspectable control flow), and managed service (a hosted runtime that runs and scales the agent for you, not a library).
• There is no best framework, only best-for-a-job. Each category does a different job. Frame every comparison as “built for X” versus “built for Y,” never as a ranking. “Which is best” is like asking whether a hammer beats a screwdriver.
• Choose by a few fit questions: what shape is the task, how much control you need, where your data and infrastructure already live, and who maintains it after you ship. Familiarity is a real input, not a cop-out.
• The loop is stable; the libraries are not. APIs change and names rise and fade, but the loop and tool-call exchange from Lessons 1 and 2 endure. Understand the loop so any framework is a tool you can see through, not magic you are captive to.

What changes for you

You can now walk past the framework hype without anxiety. Faced with “everyone is using X,” you have two grounded questions: do I even need a framework for this task, and if so, does X’s category match what I am building? That reframes an intimidating, fast-moving landscape into a small, stable decision, one you can make on the merits of your task rather than the volume of the marketing.