Anthropic Building Effective AI Agents – Practical Patterns and Guidance

TL;DR

Anthropic released a guide that distills a year of experience building LLM‑based agents, showing that simple, composable patterns—augmented LLMs, prompt chaining, routing, parallelization, orchestrator‑workers, evaluator‑optimizer, and autonomous agents—outperform heavyweight frameworks, and providing concrete advice on when to use each pattern and how to design tools.

What qualifies as an "agent"?

Agents are systems where the LLM dynamically decides which tools to invoke and how to sequence actions, retaining control over the process. In contrast, workflows follow a fixed code path that orchestrates LLM calls and tools. This distinction frames the rest of the guide.

When to adopt agentic systems

  • Start simple: Prefer single‑LLM calls with retrieval and in‑context examples. Only add complexity when it demonstrably improves outcomes.
  • Trade‑off awareness: Agents increase latency and cost but can boost task performance for open‑ended problems.
  • Choosing between patterns:
    • Workflows → predictable, consistent handling of well‑defined tasks.
    • Agents → flexible, model‑driven decision‑making at scale.

Frameworks vs. direct API use

  • Popular SDKs (Claude Agent SDK, Strands Agents SDK, Rivet, Vellum) lower the entry barrier by abstracting LLM calls, tool parsing, and chaining.
  • Caution: Abstractions can hide prompts and responses, making debugging harder and encouraging unnecessary complexity.
  • Recommendation: Begin with raw LLM APIs; if a framework is used, maintain visibility into the underlying code.

Core building block: the augmented LLM

An augmented LLM combines the base model with retrieval, tool use, and memory. Anthropic’s models can generate search queries, select tools, and decide what to retain. The Model Context Protocol provides a standard client implementation for integrating third‑party tools.

Common workflow patterns

1. Prompt chaining

  • What it is: Decompose a task into sequential LLM calls, optionally inserting programmatic gates.
  • When to use: Fixed subtasks where higher accuracy outweighs added latency.
  • Examples: Generate marketing copy → translate; outline → validate → write full document.

2. Routing

  • What it is: Classify input and dispatch to specialized downstream prompts or tools.
  • When to use: Tasks with distinct categories that benefit from tailored processing.
  • Examples: Route customer‑service queries to different handlers; send easy questions to Claude Haiku 4.5 and hard ones to Claude Sonnet 4.5.

3. Parallelization

  • Variations:
    • Sectioning – split independent subtasks and run them concurrently.
    • Voting – run the same prompt multiple times to collect diverse answers.
  • When to use: Speed gains from concurrency or higher confidence via multiple perspectives.
  • Examples: Guardrails (separate model for safety screening); code‑vulnerability review with multiple prompts; content moderation voting.

4. Orchestrator‑workers

  • What it is: A central LLM dynamically breaks a problem into sub‑tasks, delegates to worker LLMs, and synthesizes results.
  • When to use: Complex, unpredictable tasks where sub‑tasks cannot be predefined (e.g., multi‑file code changes, multi‑source search).

5. Evaluator‑optimizer

  • What it is: One LLM generates output; a second LLM evaluates and provides feedback, forming an iterative refinement loop.
  • When to use: Clear evaluation criteria exist and iterative improvement yields measurable value.
  • Examples: Literary translation with nuanced critique; multi‑round search where the evaluator decides whether further probing is needed.

Autonomous agents

  • Lifecycle: Receive a command or interactive prompt → plan → execute tool calls in a loop → optionally pause for human feedback → terminate on completion or after a max‑iteration limit.
  • Key requirements:
    1. Robust toolset with clear documentation (see Appendix 2).
    2. Ground‑truth feedback from the environment after each tool call.
    3. Guardrails and sandbox testing to mitigate compounding errors.
  • When to use: Open‑ended problems with unpredictable step counts where trust in the model’s decision‑making is acceptable.
  • Real‑world examples:
    • Coding agent that solves SWE‑bench tasks by editing multiple files.
    • "Computer use" demo where Claude controls a desktop to accomplish user‑specified goals.

Combining and customizing patterns

The presented patterns are building blocks, not strict recipes. Developers should:

  • Measure performance at each stage.
  • Add complexity only when it yields a measurable improvement.
  • Iterate on prompts, tool definitions, and orchestration logic.

Core principles for reliable agents

  1. Simplicity – keep the agent’s design minimal.
  2. Transparency – expose planning steps and tool calls in logs.
  3. Tool engineering – invest in clear, well‑documented tool interfaces (see Appendix 2).

Appendix 1 – Agents in practice (summary)

  • Customer support: Conversational flow plus tool integration (e.g., fetching order data, issuing refunds) enables measurable resolution metrics.
  • Coding agents: Automated tests provide objective verification; agents iterate using test feedback to solve real GitHub issues.

Appendix 2 – Prompt engineering your tools

  • Design tips:
    • Provide enough tokens for the model to think before it must emit a tool call.
    • Use formats familiar to the model (e.g., plain code rather than heavily escaped JSON).
    • Avoid unnecessary formatting overhead (no line‑count tracking, minimal escaping).
  • Human‑computer interface mindset: Treat tool specs like developer docstrings—include examples, edge cases, and clear parameter names.
  • Testing: Run extensive examples in Anthropic’s workbench to surface misuse patterns.
  • Poka‑yoke: Structure arguments to make mistakes hard for the model.
  • Case study: Switching from relative to absolute file paths in the SWE‑bench agent eliminated path‑resolution errors.

Final takeaway

Success with LLM agents is less about building the most sophisticated architecture and more about selecting the right composable pattern, rigorously testing tool interfaces, and only adding layers of complexity when they demonstrably improve results.

Sources

Related