When (and When Not) to Build Agents

Anthropic's single most repeated piece of advice, gathered from working with dozens of teams across industries, is this: find the simplest solution possible, and only increase complexity when needed. (source)

"This might mean not building agentic systems at all."

The trade you're making

Agentic systems trade latency and cost for better task performance. Before you accept that trade, ask whether you need to:

For many applications, optimizing a single LLM call with retrieval and in-context examples is enough.
When you need more, workflows offer predictability and consistency for well-defined tasks.
Agents are the right choice only when you need flexibility and model-driven decision-making at scale.

Complexity (and cost) →

  single LLM call  →  workflow  →  agent
       ↑                ↑            ↑
   cheapest,         predictable,   flexible,
   most debuggable   composable     autonomous

Climb rightward only when the rung you're on demonstrably fails.

When a workflow beats an agent

Reach for a workflow when the task is well-defined and you want predictability:

The steps can be enumerated in advance.
You want consistent, repeatable behavior.
Debugging matters — workflows are code, and code is inspectable.

When an agent beats a workflow

Reach for an agent when the task is open-ended:

You can't predict the number of steps.
You can't hardcode a fixed path.
The model needs to react to what it finds at each step.

Agents compound errors

An agent that runs for many turns also makes mistakes for many turns. Anthropic recommends extensive testing in sandboxed environments plus appropriate guardrails (max iterations, human checkpoints) before letting an agent operate where it can do real damage. The autonomy that makes agents useful is the same property that makes them expensive and risky.

A word on frameworks

There are many frameworks that make agentic systems easier to implement — Claude Agent SDK, Strands Agents SDK by AWS, drag-and-drop GUI builders. They simplify the low-level work: calling LLMs, defining and parsing tools, chaining calls.

But frameworks add abstraction layers that obscure the underlying prompts and responses, making bugs harder to find. They also tempt you to add complexity a simpler setup didn't need.

Anthropic's recommendation: start by using LLM APIs directly. Most patterns can be implemented in a few lines of code. If you do use a framework, make sure you understand the code underneath — incorrect assumptions about what's happening under the hood are a common source of failure.

# The augmented LLM, in a few lines — no framework needed
response = client.messages.create(
    model="claude-sonnet-4-5",
    tools=[search_tool, calculator_tool],
    messages=[{"role": "user", "content": task}],
)
# The model decides which tool to call, if any. That's the seed of every pattern that follows.

The principle to take with you

"Success in the LLM space isn't about building the most sophisticated system. It's about building the right system for your needs."

Every chapter that follows is a pattern. None of them is mandatory. The skill is knowing which one your problem actually needs — and being willing to use none of them when a single prompt will do.

Next: Workflow Patterns — chaining, routing, and parallelization, the three patterns that cover most real tasks.