Part 8 · Building Real-World Agents

Chapter 38Agent Frameworks Overview: LangGraph, CrewAI, and Agent SDKs

You have built agents from scratch in Part VII — the loop, tools, memory, planning. That foundation is exactly what lets this part go faster, because now we meet the **frameworks** that package all of that machinery for you. This chapter is a tour of the major framework families, what each is good at, and how to choose among them without getting swept up in hype. Because this is a fast-moving area, we focus on durable patterns rather than today's exact APIs, and we lean on a reassuring truth: every framework is built from the concepts you already understand.

Why Use a Framework at All?

In Part VII you wrote the agent loop, handled tool calls, managed memory, and bounded the whole thing — by hand. That was the right way to learn, but for real projects, rewriting all that plumbing every time is tedious and error-prone. A framework gives you that machinery prebuilt: the loop, tool integration, memory, state handling, error recovery, and often observability, all ready to use. It lets you focus on what makes your agent special rather than on plumbing you have already seen a dozen times. Crucially, because you built it from scratch first, you now understand what the framework is doing for you — which is what separates someone who can debug a framework from someone mystified by it.

What Frameworks Provide

Though they differ in style, most agent frameworks offer the same core conveniences, each corresponding to something from Part VII.

  • The agent loop — the perceive–reason–act–observe cycle, run for you with sensible stopping conditions (Chapter 31).
  • Tool integration — easy ways to define tools and wire up the tool-calling mechanism (Chapters 29 and 33).
  • State and memory — built-in handling of the conversation history and longer-term memory (Chapter 34).
  • Multi-agent coordination — support for several agents working together (Chapter 41).
  • Observability — tracing and logging so you can see what the agent did, step by step (Chapter 44).

The Major Families

Frameworks come in a few broad styles. Knowing the families matters more than knowing any single product, because the families represent durable ways of thinking about agents.

Graph-based frameworks

Frameworks in this family model an agent as a graph: nodes are steps (call the model, run a tool), and edges are the transitions between them. This makes the agent's control flow explicit and controllable — you can see and shape exactly how it moves from step to step. They shine for complex, stateful agents where you want fine control. LangGraph is the prominent example, and we build with it in the next chapter.

Role-based multi-agent frameworks

This family makes it easy to define multiple agents with distinct roles that collaborate — a researcher, a writer, a reviewer — and to coordinate them. They are built for team-of-agents tasks. CrewAI is a well-known example, and we explore the multi-agent ideas they embody in Chapter 41.

Provider agent SDKs

Model providers increasingly offer their own lightweight agent SDKs — official toolkits tightly integrated with their models. These tend to be simpler and well-supported, and are a natural choice when you are committed to one provider and want minimal friction. They favor ease over the deep control of a graph framework.

These three are representative paradigms, not an exhaustive list — there are many frameworks, and new ones appear regularly. But almost all fall into thinking about agents as graphs, as teams, or as a provider's managed loop.

How to Choose

Cut through the noise with a few practical questions. How much control do you need over the agent's flow? Complex, branching logic favors a graph framework; simple flows do not need one. Is it one agent or a team? A collaborative task points to a multi-agent framework. How tied to one provider are you? If you are committed, a provider SDK is frictionless; if you want flexibility, a provider-neutral framework keeps your options open. And how much do you value simplicity versus power? Match the tool to the job rather than reaching for the most powerful option by default.

You Don't Always Need One

Here is advice that runs against the grain of the hype: for a simple agent, you may not need a framework at all. The raw loop from Chapter 31 — a model call, a tool execution, a bit of state — is clear, dependency-free, and easy to debug. Frameworks earn their keep when complexity grows: many tools, intricate control flow, multiple agents, production observability. Reaching for a heavy framework to build a simple agent adds complexity you do not need. Start with the simplest thing that works, and adopt a framework when you feel the genuine pain it solves.

Frameworks Implement What You Already Know

The most reassuring fact in this chapter: under the hood, every agent framework is built from the concepts of Part VII. A graph framework is the agent loop with explicit nodes and edges. A multi-agent framework is several agent loops coordinated. A provider SDK is the loop, tool calling, and memory wrapped in a tidy package. The vocabulary and syntax differ, but the concepts are identical to what you have already built by hand. This is precisely why we built from scratch first — so that no framework can ever be a black box to you. Learn the patterns, and any framework becomes readable.

The Landscape Changes Fast

Like the model landscape of Chapter 14, the framework landscape moves quickly. New frameworks emerge, popular ones change their APIs, and today's favorite may not be next year's. This is exactly why this chapter teaches families and patterns rather than memorizing one framework's interface. If you understand graphs, teams, and managed loops — and the agent concepts beneath them — you can pick up any specific framework's documentation and be productive quickly. Invest in the durable understanding, not the transient syntax.

Summary

Agent frameworks package the machinery you built by hand in Part VII — the loop, tools, memory, state, coordination, and observability — so you can focus on your agent's purpose. They fall into broad families: graph-based frameworks for explicit, controllable flow; role-based multi-agent frameworks for teams of collaborating agents; and provider agent SDKs for simple, tightly integrated single agents. Choose based on the control you need, whether you have one agent or many, your provider commitment, and the simplicity-versus-power trade-off — and remember you often do not need a framework at all for a simple agent. Above all, every framework is built from the concepts you already know, and since the landscape changes fast, learn the durable patterns rather than any single API.

Concepts are best understood by building, so Chapter 39 takes one framework — LangGraph — and builds a complete single agent with it, turning the agent loop you know into an explicit, controllable graph.

Practice

Exercises

  1. 1List the three framework families from this chapter and, for each, describe the kind of agent or task it is best suited to.
  2. 2Make a table comparing three frameworks (or the three families) across at least four dimensions: control, ease of use, provider-independence, and multi-agent support.
  3. 3For each of these projects, recommend a framework family and justify it: a simple single-tool assistant; a complex agent with branching logic and human-approval steps; a team of specialists writing a report together.
  4. 4Explain why you might choose *not* to use a framework at all for a given agent. What signs tell you it is time to adopt one?
  5. 5Explain the claim that 'every framework is built from the concepts you already know.' Pick one framework feature and map it to a concept from Part VII.
  6. 6Take the raw agent loop you built in Chapter 31 and describe, in words, what a framework would add to it and what plumbing it would remove from your code.
View detailed solutions for all chapters →