Practice: Choosing an agent framework

Self-check

Seven short questions. Answer each before opening the collapsible.

1. What is the first decision, before “which framework”?

Show answer

Whether to use a framework at all. Lessons 1 and 2 showed the loop is buildable yourself, so the honest first question is hand-roll versus adopt. Reaching for a framework reflexively is a common mistake.

2. What does a framework actually give you?

Show answer

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.

3. When does hand-rolling the loop win?

Show answer

When you want full control, minimal dependencies, and the loop is small (two or three tools). Your own code is then easy to write, read, and debug, with no framework behavior to fight.

4. Name the four framework categories and what each is built for.

Show answer

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).

5. Why is “which framework is best?” the wrong question?

Show answer

There is no best, only best-for-a-job. The categories do different jobs: orchestration is built for multiple agents, retrieval-first for answering from data, and so on. Asking which is best is like asking whether a hammer is better than a screwdriver. Replace it with “which is built for what I am doing?”

6. The most-starred framework: is that a good reason to pick it?

Show answer

No. Popularity is not fit. The right framework is the one whose category matches your task’s shape. Match the shape, not the hype.

7. Why understand the underlying loop even after you pick a framework?

Show answer

Frameworks change fast (APIs shift, names rise and fade); the loop and the tool-call exchange are stable. If you understand the loop, you can see what any framework is doing underneath, debug it, and survive a breaking change as an inconvenience rather than a rewrite. A framework you understand is a tool; one you treat as magic is a liability.

Try it yourself: hand-roll or adopt?

For each, decide hand-roll the loop or adopt a framework, and say why in one line. There is no universally right answer; there is a right answer for the task.

A. A weekend prototype: one agent, one weather tool, a simple loop.
B. A production app wiring an agent into a dozen data sources, with several
   cooperating agents and a need for observability.
C. A script that calls two tools in sequence and you want zero dependencies.

Show answer

A: hand-roll. One tool, small loop; a framework is more weight than the task needs.
B: adopt. The boilerplate, the multi-agent coordination, the connectors, and the observability are exactly what a framework provides; building all that yourself is the waste here.
C: hand-roll. Minimal dependencies is the explicit goal, and two sequential tools is a small loop.

The rule: match the weight of the tool to the weight of the task. Small and controlled, hand-roll; large with hard patterns and integrations, adopt.

Try it yourself: match the task to a category

For each task, name the framework category that fits (not a “best” framework, a fit). Categories: orchestration/multi-agent, retrieval-first, graph/state-machine, managed service.

1. "Answer support questions from our 500-page product manual."
2. "A planner agent hands subtasks to a researcher and a writer agent."
3. "We need to inspect and shape every step and branch the agent takes."
4. "We want deployment and scaling handled for us, not run on our own servers."

Show answer

Retrieval-first (answering from a body of documents is the core job). Or hand-roll with one retrieval tool if the rest is simple.
Orchestration / multi-agent (several cooperating agents).
Graph / state-machine (explicit, inspectable control flow).
Managed service (a hosted runtime, a different shape from a library).

Notice every answer is “which category fits this task,” never “which framework wins.” That is the only kind of comparison that survives a real project.

Flashcards

Ten cards. Click any card to reveal the answer. Use the Print flashcards button for one card per page.

Q. What is the first decision when 'choosing a framework'?

Whether to use one at all: hand-roll the loop versus adopt a framework. The loop is buildable yourself (Lessons 1 and 2), so this comes before “which framework.”

Q. What does an agent framework provide?

The loop plumbing (schema, tool-call parsing, running tools, feeding results back, looping) plus opinionated building blocks (memory, planning, multi-agent, connectors, observability). The building blocks are usually the real reason to adopt one.

Q. When should you hand-roll the loop instead of adopting a framework?

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.

Q. What are the four framework categories?

Orchestration/multi-agent, retrieval-first, graph/state-machine, and managed service. Each is built for a different job.

Q. Why is there no 'best' framework?

There is only best-for-a-job. The categories do different jobs, so the right framework is the one whose category matches your task. ‘Which is best’ is like ‘is a hammer better than a screwdriver.’

Q. How should you choose among frameworks, if not by popularity?

By fit: the shape of the task (one agent, several agents, retrieval-heavy, fine control), the control you need, where your data and infra already live, and who maintains it after you ship.

Q. Which framework category fits 'answer from our document base'?

Retrieval-first (retrieval as a first-class primitive). Or hand-roll with one retrieval tool if the rest is simple.

Q. Which category is a managed service, and how is it different?

It is a different shape entirely: a hosted runtime that runs and scales the agent for you, not a code library you run. A fit when you want deployment and scaling handled.

Q. Why understand the loop even after adopting a framework?

Frameworks move fast; the loop is stable. Understanding it lets you see what the framework does underneath, debug it, and treat a breaking change as an inconvenience. A framework you understand is a tool; one you treat as magic is a liability.

Q. What is the single most common framework mistake?

Reaching for one reflexively. A single-tool agent does not need a multi-agent orchestration library any more than a one-page script needs a web framework. Match the weight of the tool to the task.