Building Effective Agents
TL;DR
Anthropic's (Dec 2024) field guide from working with dozens of teams: the most successful LLM agent systems use simple, composable patterns, not complex frameworks — find the simplest solution and add complexity only when it demonstrably improves outcomes (Agentic Simplicity). The core architectural fork is Workflows vs Agents: workflows run LLMs/tools through predefined code paths (predictable, for well-defined tasks); agents let the LLM dynamically direct its own process (flexible, for open-ended tasks you can't hardcode — at the cost of higher spend and compounding-error risk). Everything is built from one primitive, the The Augmented LLM (LLM + retrieval + tools + memory it drives itself). Between a single call and a full agent sit five Agentic Workflow Patterns — prompt chaining, routing, parallelization (sectioning/voting), orchestrator-workers, evaluator-optimizer. Whatever you build, the tools are the agent's interface: invest in the Agent-Computer Interface (ACI) (ACI) as much as teams invest in HCI. Three closing principles: simplicity, transparency (show the planning steps), and a carefully crafted, well-documented ACI.
Concepts introduced
- Agentic Simplicity — new page. The thesis: simplest solution first, complexity only when it demonstrably improves outcomes; frameworks help you start but obscure the internals you need for production.
- Workflows vs Agents — new page. The load-bearing distinction — predefined code paths vs. the LLM dynamically directing its own process — plus when to use each and when to build no agentic system at all.
- The Augmented LLM — new page. The foundational building block every pattern composes: an LLM actively driving retrieval, tools, and memory through a clean interface.
- Agentic Workflow Patterns — new page. The five composable workflow patterns and their fit conditions, ordered by increasing complexity.
- Agent-Computer Interface (ACI) — new page. Tool definitions deserve as much prompt-engineering as the main prompt; format + documentation + poka-yoke, found by watching real model misuse.
Held, not dropped (themes the capture touches that don't warrant their own page yet — spin out on demand):
- Framework abstraction tradeoffs — the specific case for/against Claude Agent SDK, Strands, Rivet, Vellum, GUI builders. Folded into Agentic Simplicity as the "understand the internals" claim; promote if a framework-comparison capture lands.
- Model Context Protocol (MCP) — named as one way to expose augmentations. Held inside The Augmented LLM; promote to its own page when an MCP-specific capture arrives.
- Human-in-the-loop checkpoints & stopping conditions — pausing for human judgment, max-iteration caps. Folded into Workflows vs Agents; a "human oversight" concept could spin out if more sources converge.
- Agent safety: sandboxing, guardrails, compounding errors — held inside Workflows vs Agents; a dedicated agent-safety page is warranted once a second witness lands.
- Transparency as a design principle — "explicitly show the agent's planning steps" is one of the three closing principles; currently a claim below, not yet its own page.
- Application domains: customer support & coding agents (Appendix 1) — concrete fit criteria (conversation + action, clear success criteria, feedback loops, human oversight). Held as application evidence, not concepts.
Key claims
- Find the simplest solution; add complexity only when it demonstrably improves outcomes — the best systems use simple composable patterns, not complex frameworks. (principle — Agentic Simplicity) — the article's thesis.
- Success is the right system for the need, not the most sophisticated one. (principle — Agentic Simplicity)
- Start from the LLM API directly; adopt a framework only if you understand its internals — abstraction obscures prompts/responses and is a common source of error. (best practice — Agentic Simplicity)
- Workflows = LLMs/tools on predefined code paths; agents = the LLM dynamically directs its own process. (principle — Workflows vs Agents) — the architectural axis.
- Prefer workflows for predictable, well-defined tasks; agents for open-ended tasks whose steps you can't hardcode and whose model decisions you can trust. (best practice — Workflows vs Agents)
- Agent autonomy means higher cost and compounding errors — bound it with stopping conditions, sandboxed testing, and guardrails; give it environmental ground truth each step. (best practice + principle — Workflows vs Agents)
- The augmented LLM (LLM + retrieval + tools + memory) is the building block of all agentic systems. (principle — The Augmented LLM)
- The five patterns — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — are composable building blocks, not prescriptive recipes. (principle + best practice — Agentic Workflow Patterns)
- For complex multi-consideration tasks, one LLM call per consideration beats one call doing everything. (best practice — Agentic Workflow Patterns)
- Give tool definitions as much prompt-engineering attention as the main prompt; invest in the ACI as much as teams invest in HCI. (principle — Agent-Computer Interface (ACI))
- Choose model-cheap tool formats, document tools like a junior-dev docstring, poka-yoke the arguments, and iterate by watching real model misuse. (best practice — Agent-Computer Interface (ACI)) — for SWE-bench, tool optimization outweighed prompt work.
- Three principles for implementing agents: simplicity, transparency (show planning steps), and a carefully crafted ACI. (principle — Agentic Simplicity + Agent-Computer Interface (ACI))
Why this is
novel (and where it corroborates)
The graph so far is entirely an evals /
continual-improvement spine (Eval-Driven Development, Error Analysis, LLM-as-Judge, Levels of Evaluation, Synthetic Data Generation).
This capture opens a second, orthogonal region — agent
architecture — that attaches to none of those concepts, so the
dominant stance is novel: five new pages, no existing
concept duplicated or subsumed.
Two genuine corroboration threads connect the regions (recorded as backlinks, not duplicated concepts):
- Evaluator-optimizer ↔︎ the eval flywheel. The evaluator-optimizer pattern — one LLM generates, another evaluates and feeds back in a loop — is Eval-Driven Development's generate→evaluate→refine flywheel collapsed to inference time. An independent witness that the loop works, now cross-linked from both Agentic Workflow Patterns and Eval-Driven Development.
- "Measure and iterate" ↔︎ "don't trust vibes." The article's repeated "add complexity only when it demonstrably improves outcomes" and "measure performance and iterate" is the same evidence-over-intuition discipline the eval graph insists on — here applied to architecture decisions rather than quality gates. Parallelization's "voting" and the "evaluator" call are also LLM-as-Judge applied online.
No contradicts tension surfaced: the two regions are
complementary, not in conflict.