Skip to main content

Chapter 08 · The Agent SDK Ecosystem

Part of Part II · Building Blocks

There are 47 agent frameworks on GitHub. You need maybe four. This chapter is a map through the jungle.

Search "agent framework" on GitHub and you get hundreds of results. Every week a new one launches on Hacker News with a Show HN post and a bold claim about "the future of autonomous AI." Most will be abandoned in six months. A few will survive. One or two will become genuinely useful. Your job is to know which is which -- and, more importantly, to know when the right answer is "none of them."

This chapter is not a tutorial for every framework. It is a map. You will learn what each major framework does, what it is good at, what it is bad at, and -- most importantly -- when you should use none of them and just write the loop yourself. By the end, you will have a decision framework that will still be valid when the next 47 frameworks launch.

Section 1: The Framework Decision Matrix​

Frameworks differ along two axes that actually matter. Everything else -- GitHub stars, Twitter hype, VC funding -- is noise.

Axis 1: Level of Abstraction. How much does the framework hide from you?

  • Low abstraction means a thin wrapper around the API. You still write the loop. You still manage messages. The framework handles authentication, retries, and streaming -- plumbing, not architecture. The Anthropic SDK and OpenAI SDK live here.
  • Medium abstraction means the framework provides building blocks -- chains, graphs, agents -- but you assemble them yourself. You understand the control flow because you built it. LangGraph and Smolagents live here.
  • High abstraction means the framework is declarative. You describe what you want, and the framework figures out how to do it. You lose visibility into the control flow. LangChain classic and CrewAI live here.

Axis 2: Scope. What kind of system is the framework designed to build?

  • Single-agent frameworks focus on one agent with tools and memory. The Anthropic SDK, OpenAI SDK, and Agno live here.
  • Multi-agent frameworks are built for agent-to-agent communication. CrewAI and AutoGen live here.
  • Workflow frameworks model agent behavior as graphs or state machines. LangGraph lives here.
  • Data frameworks focus on retrieval and grounding. LlamaIndex lives here.
  • Full platform frameworks try to do everything. LangChain lives here.

Here is the matrix, visualized:

                    HIGH ABSTRACTION
                          |
                    CrewAI | LangChain
                          |
    MULTI-AGENT ----------+---------- SINGLE-AGENT
                          |
              LangGraph   |   Agno
              AutoGen     |   OpenAI SDK
                          |   Anthropic SDK
                          |   Smolagents
                          |   Raw API
                          |
                    LOW ABSTRACTION

This is a simplification. Every framework is moving. LangChain is adding lower-level APIs. The Anthropic SDK is adding higher-level features. But the positions are directionally correct, and they tell you what each framework optimizes for.

The golden rule: The right framework is the simplest one that solves your ACTUAL problem, not the one with the most GitHub stars.

Stars measure popularity. Popularity measures what is trending, not what is stable, well-designed, or appropriate for your use case. The most-starred framework on this list has some of the most criticized abstractions in the ecosystem. Choose with your requirements, not with your Twitter feed.

Section 2: The "No Framework" Option​

Before you reach for a framework, ask yourself: do you actually need one?

What You Can Build with Just the Raw API​

You have already built an agent loop. In Chapter 4, you wrote 50 lines of Python that observe, think, act, and terminate. In Chapter 5, you gave it tools. In Chapter 6, you gave it memory. In Chapter 7, you taught it to plan. Every one of those capabilities was built directly on top of the OpenAI or Anthropic API, with no framework between you and the model.

Here is what the raw API gives you:

  • An agent loop. A for loop with a max-turns guard. You wrote it. You understand every line.
  • Tool use. Function definitions as JSON schemas. The model returns a function call. You execute it. You pass the result back. Three steps, fully transparent.
  • Memory. A list of message dictionaries. Append, truncate, summarize. You control exactly what goes into the context window.
  • Structured output. JSON mode or tool calling with a schema. The model returns structured data. You parse it.
  • Error handling. Try/except around API calls. Retry with backoff. Validation of model output. All standard Python.

That is a complete agent system. You do not need a framework to build any of it.

When to Go Framework-Free​

You are learning. If your goal is to understand how agents work, frameworks are an obstacle. They hide the loop. They abstract the message management. They make decisions on your behalf that you do not see. Build it yourself first. Adopt a framework later, when you understand what it is doing under the hood.

Your agent is simple. A single agent with two tools and a straightforward loop does not need LangChain. The framework will add more lines of abstraction code than you save in application code. You will spend more time debugging the framework than building your agent.

You need maximum control. Frameworks make choices for you. How messages are formatted. How tool results are injected into the context. How the loop terminates. When those choices do not match your requirements, you fight the framework. With the raw API, you make every choice.

You have unusual requirements. Streaming tool calls interleaved with text? Custom message routing? Non-standard termination conditions? Frameworks optimize for the common case. If your case is uncommon, the framework works against you.

The Cost of Frameworks​

Frameworks are not free. You pay for them in ways that are not obvious when you run pip install.

Abstraction overhead. Every layer of abstraction is a layer you must understand when something breaks. The framework's elegant chain-of-abstractions becomes a stack trace with 15 frames between your code and the API call. Debugging a LangChain agent means understanding LangChain's class hierarchy, not just your own logic.

Debugging difficulty. When the raw API returns an unexpected response, you look at the messages you sent and the response you got. When a framework returns an unexpected response, you look at the messages the framework constructed, which may have been transformed by three intermediate layers you did not know existed.

Version churn. Agent frameworks are young. APIs change. Major versions ship with breaking changes every few months. Your production agent, built on framework version 0.1.x, stops working when 0.2.0 drops and renames half the classes. This is not hypothetical -- it has happened to every major framework on this list.

Lock-in. Your agent's architecture conforms to the framework's mental model. When you outgrow the framework, you rewrite. The more deeply you integrate, the more expensive the rewrite.

The "Start Framework-Free" Principle​

Here is the rule:

Build it raw first. Add a framework when it hurts. Keep the rest raw.

The pain points that justify a framework are specific and observable:

  • You are writing the same boilerplate message management code for the fifth time.
  • You need complex RAG pipelines with multiple retrieval steps, and you are reinventing chunking and embedding management.
  • You need multi-agent orchestration with state machines, and your hand-rolled coordination code is becoming unmaintainable.
  • You need human-in-the-loop approval steps, and your ad-hoc pause-and-resume logic is fragile.

When you hit one of these, adopt a framework for THAT specific problem. Do not rewrite your entire agent in the framework. Use the framework for the hard part and keep the rest in raw API calls.

A Concrete Comparison​

Here is the agent loop you built in Chapter 4, side by side with the equivalent in LangChain:

Your agent (raw API):

import openai

SYSTEM_PROMPT = """You are an autonomous agent. You operate in a loop:
OBSERVE -> THINK -> ACT. When given a task, reason step by step.
If you have a final answer, begin your response with FINAL_ANSWER:"""

def run_agent(task, max_turns=10):
    client = openai.OpenAI()
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": task}
    ]

    for turn in range(1, max_turns + 1):
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages
        )
        reply = response.choices[0].message.content

        if "FINAL_ANSWER:" in reply:
            return reply.split("FINAL_ANSWER:")[1].strip()

        messages.append({"role": "assistant", "content": reply})
        messages.append({"role": "user", "content": "Continue."})

    return "Agent did not finish within turn limit."

Same agent in LangChain:

from langchain_openai import ChatOpenAI
from langchain_core.messages import SystemMessage, HumanMessage, AIMessage
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain.agents import create_openai_functions_agent, AgentExecutor
from langchain_core.tools import tool

# LangChain requires you to define at least one tool,
# even if your agent doesn't use tools yet.
@tool
def noop():
    """Placeholder tool."""
    return ""

llm = ChatOpenAI(model="gpt-4o")
prompt = ChatPromptTemplate.from_messages([
    ("system", "You are an autonomous agent..."),
    MessagesPlaceholder(variable_name="chat_history"),
    ("human", "{input}"),
    MessagesPlaceholder(variable_name="agent_scratchpad"),
])

agent = create_openai_functions_agent(llm, [noop], prompt)
executor = AgentExecutor(
    agent=agent,
    tools=[noop],
    max_iterations=10,
    verbose=True,
    handle_parsing_errors=True,
)

result = executor.invoke({"input": "What is 15% of 87?"})

The LangChain version is longer. It introduces six new concepts (ChatPromptTemplate, MessagesPlaceholder, agent_scratchpad, AgentExecutor, create_openai_functions_agent, @tool). It requires a placeholder tool even when your agent does not use tools. When it breaks -- and it will -- you will debug through LangChain's internal message formatting, prompt template rendering, and agent execution loop, none of which you wrote and none of which are obvious from the stack trace.

The raw API version is shorter, simpler, and fully transparent. You can read it in 30 seconds and understand exactly what it does. That is not a small advantage. That is the difference between shipping and debugging for three hours.

LangChain is not bad. It is bad for THIS use case. The framework's value emerges when you have complex RAG pipelines, multi-step tool chains, and production infrastructure requirements. For a simple agent loop, it is overhead with no benefit.

Section 3: The Major Frameworks -- Honest Assessments​

Every framework has strengths. Every framework has weaknesses. Frameworks that claim otherwise are lying. Here are the honest assessments.

LangChain​

What it is. The 800-pound gorilla. LangChain was the first major agent framework and remains the most widely used. It provides abstractions for chains, agents, tools, memory, retrieval, and callbacks. Its ecosystem is massive: hundreds of integrations, thousands of community contributions, and a documentation site the size of a small novel.

What it is best at. Complex RAG pipelines with multiple retrieval and reranking steps. Production systems that need to integrate with dozens of data sources, vector stores, and LLM providers. Situations where you need to swap between model providers without changing your application code. The ChatOpenAI to ChatAnthropic swap is one line.

What it is worst at. Simple agents. Transparency. Stability. The abstraction layers are deep and often change between versions. Documentation struggles to keep up with code changes -- you will find examples that reference classes that were renamed two versions ago. The AgentExecutor is a black box that makes decisions about message formatting, tool result injection, and termination that you cannot easily override.

When to use it. You are building a production RAG system with complex retrieval logic. You need to integrate with 10 different data sources and 3 different LLM providers. You have a team that has already invested in learning LangChain's abstractions.

When to avoid it. You are building a simple agent. You are learning how agents work. You need deep control over message formatting and loop behavior. You value debuggability over integration breadth.

LangChain is the React of AI frameworks. Ubiquitous, powerful, easy to misuse. The people who hate it most are the ones who used it for something it was not designed for.

LangGraph​

What it is. LangChain's agent orchestration framework. LangGraph models agent workflows as state machines -- nodes are steps, edges are transitions, and the state is a typed dictionary that flows through the graph. It supports branching, looping, parallelism, and human-in-the-loop interrupts. It is significantly better designed than LangChain classic.

What it is best at. Complex multi-step agent workflows. Systems that need conditional branching ("if the search returns no results, try a different query"). Human-in-the-loop systems where a human must approve an action before the agent proceeds. Stateful agents that maintain structured state across many turns.

What it is worst at. Simple linear agents. If your agent's control flow is a straight line -- think, act, think, act, done -- LangGraph is overkill. The state machine abstraction adds complexity without benefit for linear flows.

When to use it. Your agent workflow has branches, loops, or parallel execution. You need human approval steps. You need to persist and resume agent state. You are building a production system where the control flow is complex enough to warrant a state machine.

When to avoid it. Your agent is a simple loop. You are prototyping. You do not need conditional branching or human-in-the-loop.

CrewAI​

What it is. A multi-agent framework built around the metaphor of a "crew." You define agents with roles ("Senior Research Analyst"), goals ("Uncover cutting-edge developments in AI"), and backstories. You assign them tasks. The framework orchestrates their collaboration. The API is intuitive and the quickstart is genuinely quick.

What it is best at. Multi-agent simulations and role-playing systems. Quick prototyping of multi-agent ideas. Demos and hackathon projects where you need something working in an hour. Educational contexts where the role-based metaphor helps people understand agent collaboration.

What it is worst at. Production reliability. The framework is young and changing fast. APIs break between minor versions. Behavior is not always deterministic. The role-based abstraction, while intuitive, can produce unpredictable agent interactions when the roles are not carefully designed.

When to use it. You are prototyping a multi-agent system. You want to test whether a multi-agent approach adds value before investing in a production implementation. You are building a demo or an educational tool.

When to avoid it. You are building a production system. You need deterministic, reliable agent behavior. You are building a single-agent system (CrewAI's value is in multi-agent orchestration; for single agents, it is overhead).

AutoGen (Microsoft)​

What it is. A multi-agent conversation framework. Agents can chat with each other, debate, ask questions, and collaborate. The core abstraction is the conversation -- agents send and receive messages, and the conversation pattern determines who speaks when. AutoGen 0.4 introduced an event-driven, asynchronous architecture that is a significant improvement over earlier versions.

What it is best at. Multi-agent dialogue systems where agents need to debate, critique, or collaborate through conversation. Complex collaboration patterns like group chats with a moderator agent. Research on multi-agent communication strategies.

What it is worst at. Simple single-agent systems. The conversation abstraction is powerful but heavy -- you pay for it even when you do not need it. The framework has gone through multiple architectural rewrites, and the ecosystem of examples and tutorials is split across incompatible versions.

When to use it. You are building a system where multiple agents need to converse, debate, or negotiate. You are researching multi-agent communication patterns. You need an event-driven, asynchronous agent architecture.

When to avoid it. You are building a single-agent system. You need a stable, mature API. You are new to agents and want something simple to start with.

Anthropic SDK​

What it is. A thin, well-designed SDK for the Anthropic API. It provides the standard API client plus three higher-level features: Tool Runner (an agent loop that handles tool calling automatically), Managed Agents (server-hosted agents with a managed sandbox), and Computer Use (agents that can see and interact with a desktop). The SDK is Claude-only.

What it is best at. Claude-powered agents. Computer use -- the Anthropic SDK is the only first-party way to build computer-use agents. When you want minimal abstraction with just enough convenience to avoid writing boilerplate. The Tool Runner is essentially the agent loop you wrote in Chapter 4, packaged and maintained by Anthropic.

What it is worst at. Multi-model systems. It is Claude-only. If you need to use GPT-4, Gemini, or open-source models, you need a different SDK or an abstraction layer. The higher-level features (Managed Agents, Computer Use) are opinionated and not designed for customization.

When to use it. You are building agents with Claude. You need computer use. You want a thin, well-maintained SDK that does not over-abstract. You are building the kind of agent you built in Chapters 4-7 and want a production-grade version of the same pattern.

When to avoid it. You need multi-model support. You need complex multi-agent orchestration. You need a framework that handles memory, retrieval, and planning for you.

OpenAI SDK​

What it is. The official SDK for the OpenAI API, plus the Assistants API (hosted agents with managed state, tools, and threads) and the Responses API (a unified API for chat, tools, and structured output). The Assistants API is the highest-level offering: you define an assistant with instructions and tools, create a thread, add messages, and run the assistant. OpenAI manages the loop, the state, and the tool execution.

What it is best at. GPT-powered agents. Quick prototypes where you want hosted state management -- the Assistants API handles conversation threads, tool execution, and context management for you. The Responses API is a clean, modern interface that unifies chat, function calling, and structured output.

What it is worst at. Complex custom agent logic. The Assistants API is opinionated about how agents work. If your agent needs custom loop behavior, non-standard tool execution, or fine-grained control over message formatting, the Assistants API fights you. You end up working around it rather than with it.

When to use it. You are building with GPT models. You want hosted state management and do not want to manage conversation threads yourself. You are prototyping and want to move fast. The Responses API is your primary interface and you want a clean, unified API.

When to avoid it. You need custom agent loop behavior. You need multi-model support. You want to understand and control every aspect of your agent's execution. The Assistants API's managed approach hides too much.

Agno (formerly Phidata)​

What it is. A lightweight agent framework focused on quick setup and clean APIs. Define an agent with a model, instructions, and tools. Add memory with a single parameter. Add knowledge (RAG) with another. Agno optimizes for the "get something working in 10 lines" experience.

What it is best at. Quick agent prototypes. RAG agents where you need to ground responses in documents with minimal configuration. Single-agent systems where you want memory and knowledge without building the infrastructure yourself.

What it is worst at. Complex multi-agent orchestration. The framework is designed for single agents. Multi-agent support exists but is not the focus. Production systems at scale -- the framework is relatively young and the ecosystem is small.

When to use it. You need a working agent prototype in an afternoon. You want built-in memory and RAG without configuring vector stores and embedding models yourself. You are building a single-agent system and value API simplicity.

When to avoid it. You need multi-agent orchestration. You need production battle-tested infrastructure. You need fine-grained control over memory and retrieval behavior.

LlamaIndex​

What it is. A data framework for LLMs. LlamaIndex is not primarily an agent framework -- it is a framework for connecting LLMs to data. It provides ingestion pipelines (load data from 160+ sources), indexing strategies (chunking, embedding, tree indices, knowledge graph indices), and query engines (retrieval, synthesis, routing). It has agent capabilities, but they are built on top of the data layer.

What it is best at. Complex data ingestion and retrieval pipelines. RAG systems where the retrieval logic is sophisticated -- hybrid search, recursive retrieval, query routing, multi-step synthesis. Situations where you need to index and query structured data (SQL), unstructured data (documents), and semi-structured data (APIs) through a unified interface.

What it is worst at. Non-RAG agent tasks. If your agent does not need to retrieve and reason over external data, LlamaIndex adds complexity without benefit. The agent abstraction is secondary to the data abstraction -- it works, but it is not the framework's strength.

When to use it. You are building a RAG system with complex data requirements. You need to ingest data from many sources and query it through multiple strategies. You want a framework that treats data as the primary concern.

When to avoid it. Your agent does not need RAG. You need a general-purpose agent framework. You want the agent abstraction to be the framework's primary focus.

Smolagents (Hugging Face)​

What it is. A minimal agent framework from Hugging Face that emphasizes code generation. Smolagents can run open-source models (via Hugging Face's inference API or local models) and frontier models. Its defining feature is the "code agent" -- an agent that writes and executes Python code to solve tasks, rather than calling predefined tools.

What it is best at. Open-source model agents. Code-generating agents that solve problems by writing and running Python. Educational contexts where you want to understand agent internals with minimal abstraction. Research on code-based agent reasoning.

What it is worst at. Production systems needing frontier model reliability. The framework is minimal by design -- it does not provide memory management, complex orchestration, or production infrastructure. Open-source models, while improving rapidly, still lag behind frontier models on complex agent tasks.

When to use it. You want to run agents with open-source models. You are experimenting with code-generating agents. You want a minimal, transparent framework for learning or research.

When to avoid it. You need production reliability. You need complex multi-agent orchestration. You need built-in memory, RAG, or other infrastructure.

Section 4: The Comparison Table​

Here is the full comparison. Print this. Bookmark it. Refer to it when the next framework launches and someone tells you to rewrite your entire stack.

FrameworkAbstractionScopeMulti-AgentMemoryTool EcosystemMaturityBest For
Raw APINoneAnyManualManualManualN/ALearning, max control
Anthropic SDKLowSingleManualManualBuilt-in tool useHighClaude agents, computer use
OpenAI SDKMediumSingleManualBuilt-in (Assistants)Built-inHighGPT agents, quick prototypes
SmolagentsLowSingleManualManualCode executionLowOpen-source model agents
AgnoMediumSingleNoBuilt-inGrowingLow-MediumQuick agents, RAG agents
LlamaIndexMediumDataNoVia integrationsMassiveHighRAG pipelines, data ingestion
LangGraphMediumWorkflowYesManualLangChain toolsMedium-HighComplex workflows, human-in-the-loop
AutoGenMediumMultiYesManualGrowingMediumAgent conversations, debate
CrewAIHighMultiYesBuilt-inGrowingLow-MediumMulti-agent prototyping
LangChainHighSingle/MultiVia LangGraphBuilt-inMassiveHighProduction RAG, many integrations

A few observations from this table:

Maturity correlates inversely with abstraction level. The most mature options (raw API, Anthropic SDK, OpenAI SDK) are the lowest abstraction. The least mature options (CrewAI, Agno) are the highest abstraction. This is not a coincidence. High-abstraction frameworks are harder to build and take longer to stabilize.

Multi-agent support is still young. Every multi-agent framework on this list is either medium or low-medium maturity. The patterns for multi-agent systems are not yet settled. If you are building a production multi-agent system today, expect to invest significant engineering in reliability and error handling, regardless of which framework you choose.

Tool ecosystems are concentrated. LangChain and LlamaIndex have the largest tool ecosystems by a wide margin. If you need an integration with a specific vector store, data source, or model provider, one of these two almost certainly has it. The cost is that you must accept their abstraction model to access their ecosystem.

Section 5: The Decision Tree​

Here is a practical decision tree. Start at the top. Answer each question honestly. The tree tells you what to use.

START HERE: What are you building?
|
+-- "I am learning how agents work."
|   --> Raw API. No framework. Build the loop yourself.
|       You cannot understand what a framework does
|       until you have built it without one.
|
+-- "A simple single-agent system."
|   --> Raw API, Anthropic SDK, or OpenAI SDK.
|       You do not need a framework for this.
|       Pick the SDK that matches your model provider.
|
+-- "A complex RAG system with many data sources."
|   --> LlamaIndex for data ingestion and retrieval.
|       LangChain for orchestration if you need
|       multi-step chains beyond what LlamaIndex provides.
|
+-- "A multi-agent system."
|   +-- "I am prototyping / experimenting."
|   |   --> CrewAI. Fast to build, intuitive API.
|   |       Plan to rewrite for production.
|   |
|   +-- "I am building for production."
|       --> LangGraph. State machines give you
|           control, reliability, and debuggability.
|
+-- "A complex workflow with human-in-the-loop."
|   --> LangGraph. Built for this. State machines
|       with interrupt points are the right abstraction.
|
+-- "A computer-use agent."
|   --> Anthropic SDK. The only first-party option.
|       Computer use is not a bolt-on; it is built in.
|
+-- "An agent that runs open-source models."
|   --> Smolagents for code-generating agents.
|       Raw API with LiteLLM for general-purpose agents.
|       Expect to invest more in prompt engineering
|       and error handling than with frontier models.
|
+-- "I do not know what I am building yet."
|   --> Raw API. Start simple. Add complexity
|       only when the simple approach fails.
|       You can always adopt a framework later.
|       You cannot easily remove one once it is in.

The decision tree has a bias toward simplicity. That is intentional. The most common failure mode in agent development is not "I should have used a more powerful framework." It is "I adopted a framework too early and now I am debugging its abstractions instead of building my product."

Section 6: The "Start Simple" Rule​

The most common failure mode in agent development is reaching for LangChain before you understand the loop.

You have built the loop from scratch. You have given it tools, memory, and planning. You understand what happens when the model receives a message, how tool calls are formatted, how results are injected back into the context, and how the loop decides to terminate. You understand this because you wrote every line of it.

This is your superpower.

When you do adopt a framework, you will understand its abstractions because you have built them yourself. You will see AgentExecutor and recognize it as the loop you wrote in Chapter 4, wrapped in configuration options. You will see ChatPromptTemplate and recognize it as the system prompt you have been tuning since Chapter 3. You will see Tool and recognize it as the function schema you defined in Chapter 5. The framework will not be magic. It will be a packaged version of concepts you already own.

The developer who skips straight to LangChain does not have this. They see AgentExecutor and think it is a black box that "does agents." When it behaves unexpectedly, they have no mental model for why. They post on GitHub Issues. They try random configuration changes. They get frustrated and blame the framework. The framework is not the problem. The gap in understanding is.

Here is the framework adoption pattern:

1. Build it raw.
   Write the loop. Define the tools. Manage the messages.
   Get it working end to end.

2. Identify the pain.
   What part of this is tedious, error-prone, or
   difficult to maintain? Be specific. "Managing
   conversation history" is specific. "Building
   agents" is not.

3. Adopt a framework for THAT pain.
   If message management is the pain, use the
   Anthropic SDK's message helpers. If RAG pipelines
   are the pain, use LlamaIndex. If multi-agent
   coordination is the pain, use LangGraph.

4. Keep the rest raw.
   Do not rewrite your entire agent in the framework.
   Use the framework for the hard part. Keep the
   simple parts simple.

This pattern produces systems where the complex parts are managed by well-tested framework code and the simple parts are transparent, debuggable, and under your direct control. It is the best of both worlds.

The Turn​

You now have a map of the ecosystem. You know what each major framework does, what it is good at, what it is bad at, and -- most importantly -- when the right answer is "none of them."

Frameworks are tools, not identities. Your goal is building working agents, not being a "LangChain developer" or a "CrewAI expert." The framework that is right for your project today may be wrong for your project next year. The framework that everyone is using may be wrong for your specific requirements. Pick the right tool for the job, and never be afraid to use no tool at all.

The developers who build the best agents are not the ones who know the most frameworks. They are the ones who understand the loop, the tools, the memory, and the planning -- and who reach for a framework only when it demonstrably makes their system better, not when it makes their resume look more impressive.

You are now one of those developers. You built the loop. You understand what frameworks do under the hood. You can evaluate a new framework in 10 minutes by asking: "What abstraction level? What scope? What is it best at? What is it worst at?" Those four questions cut through the marketing and tell you what you actually need to know.

Close​

You have surveyed the landscape. You have a decision matrix, a comparison table, a decision tree, and a rule for when to use nothing at all. You are equipped to navigate the agent framework ecosystem without getting lost in the hype.

Now it is time to go deep.

The next two chapters are hands-on deep dives into the two SDKs that matter most. Chapter 9 is a complete guide to the Anthropic SDK -- Tool Runner, Managed Agents, Computer Use, and prompt caching. You will build Claude-powered agents that use tools, see screens, and operate autonomously. Chapter 10 is a production-grade deep dive into LangChain and LangGraph -- chains, agents, state machines, and the patterns that make complex agent systems reliable.

You know the map. Now you will walk the territory.

What you learned in this chapter:

ConceptWhat It Means
Abstraction axisLow (thin wrapper) to high (declarative). Lower = more control, higher = more convenience.
Scope axisSingle-agent, multi-agent, workflow, data, full platform. Match the scope to your problem.
The golden ruleThe simplest framework that solves your ACTUAL problem. Not the one with the most stars.
No-framework optionYou can build complete agents with the raw API. You already have.
Framework costsAbstraction overhead, debugging difficulty, version churn, lock-in. Frameworks are not free.
Start simple ruleBuild raw first. Add a framework when it hurts. Keep the rest raw.
Decision treeStart with what you are building. The tree tells you what to use.

Key takeaways:

  • There are 47 agent frameworks. You need maybe four. The rest are noise.
  • The raw API is a legitimate, often superior, choice for simple agents.
  • LangChain is powerful but heavy. Use it for complex RAG, not simple agents.
  • LangGraph is the right choice for complex workflows and human-in-the-loop.
  • CrewAI is great for prototyping multi-agent systems. Plan to rewrite for production.
  • The Anthropic SDK is the best thin SDK. Use it for Claude agents and computer use.
  • LlamaIndex is the best data framework. Use it for complex RAG pipelines.
  • Frameworks are tools, not identities. Pick the right one for the job.
  • Never adopt a framework before you understand what it does under the hood.
  • You have that understanding. You built the loop. That is your superpower.