The post opens by observing that "agent" was defined in several ways by the developers Anthropic worked with: some used it for fully autonomous systems that work for long periods with many tools, others for programs that follow predefined workflows (section "What are agents?"). This post, written by Erik Schluntz and Barry Zhang and filed under Product, draws on Anthropic's work with "dozens of teams" building such systems over the preceding year and on Anthropic's own agents. Its central claim is that the most successful implementations were not using complex frameworks or specialized libraries but were "building with simple, composable patterns" (opening paragraph). It is practical guidance for developers, not a research paper: it reports no experiments or measurements, and its evidence is the authors' experience.
For this library the post matters as the definition of an agent that later Anthropic documents point back to (see "How it connects"), and because its Appendix 2 treats tool descriptions as text that should be written and tested like a prompt.
A note on versions: this note summarizes the post as published in December 2024, checked against the Internet Archive's capture of December 20, 2024. The page has since been revised. The version fetched in May 2026 lists different example frameworks (the Claude Agent SDK and AWS's Strands Agents SDK in place of LangGraph and Amazon Bedrock's agent framework) and names Claude Haiku 4.5 and Claude Sonnet 4.5 in the routing example where the original named Claude 3.5 Haiku and Claude 3.5 Sonnet. The definitions, patterns, principles and appendices summarized below read the same in both versions.
Workflows versus agents
The post groups all these designs under the name agentic systems and then separates two kinds (section "What are agents?"):
- Workflows are "systems where LLMs and tools are orchestrated through predefined code paths." The developer decides the sequence of steps in code.
- Agents are "systems where LLMs dynamically direct their own processes and tool usage," keeping control over how a task gets done.
The post's first recommendation is to use neither unless needed. Agentic systems often trade higher latency and cost for better task performance, and for many applications a single, well-optimized model call with retrieval and in-context examples is enough (section "When (and when not) to use agents"). When more structure is needed, workflows give predictability for well-defined tasks, and agents suit cases that need flexibility and model-driven decisions.
On frameworks, the post says they make it easy to start but add layers of abstraction that hide the underlying prompts and responses, which makes systems harder to debug and tempts developers to add complexity. It suggests calling the model API directly at first, and notes that incorrect assumptions about what a framework does internally are "a common source of customer error" (section "When and how to use frameworks").
The building blocks and patterns
The section "Building blocks, workflows, and agents" moves from simplest to most autonomous.
The augmented model
The basic unit is a language model with augmentations: retrieval, tools and memory. The model generates its own search queries, chooses tools and decides what to retain. The post recommends tailoring these capabilities to the use case and giving them an easy, well-documented interface, and mentions the Model Context Protocol as one way to connect third-party tools.
Five workflow patterns
| Pattern | What it does | When the post recommends it |
|---|---|---|
| Prompt chaining | Splits a task into a fixed sequence of calls, each processing the last one's output, with optional programmatic checks ("gates") between steps | The task divides cleanly into fixed subtasks; trades latency for accuracy |
| Routing | Classifies an input and sends it to a specialized prompt, tool or model | Distinct categories are better handled separately and can be classified accurately |
| Parallelization | Runs calls at the same time: sectioning splits a task into independent parts; voting runs the same task several times | Subtasks can run in parallel, or several attempts give more confidence |
| Orchestrator-workers | A central model breaks a task down at run time, delegates parts to worker calls and combines the results | The subtasks cannot be predicted in advance, as in coding changes across many files |
| Evaluator-optimizer | One call produces a response, another evaluates it and gives feedback, in a loop | Clear evaluation criteria exist and iteration measurably improves results |
Examples given include translating marketing copy after writing it (chaining), sending easy questions to a smaller model and hard ones to a larger model (routing), screening user queries for inappropriate content in a separate call from the one answering them, which the post says "tends to perform better" than one call doing both (sectioning), and literary translation refined by an evaluator's critiques (evaluator-optimizer).
Autonomous agents
An agent starts from a user's command or a discussion with the user, then plans and acts on its own, possibly returning to the human for information or judgment. The post stresses that at each step the agent needs "ground truth" from the environment, such as tool results or code execution, to assess progress, and that stopping conditions such as a maximum number of iterations keep it under control (section "Agents"). In implementation, agents are "typically just LLMs using tools based on environmental feedback in a loop."
Agents suit open-ended problems where the number of steps cannot be predicted. Their autonomy brings higher costs and "the potential for compounding errors," so the post recommends extensive testing in sandboxed environments with guardrails. Anthropic's own examples are a coding agent for SWE-bench tasks and the computer-use reference implementation.
The instructions the post recommends writing
The post has no principles in the constitutional sense, but much of its advice is about text written for the model.
Tool definitions as prompts. Appendix 2 ("Prompt engineering your tools") says tool definitions and specifications deserve as much prompt-engineering attention as the main prompt. Its format advice: give the model enough tokens to think before it commits; keep formats close to text the model has seen naturally on the internet; avoid formatting overhead such as counting lines for a diff header or escaping code inside JSON.
The agent-computer interface (ACI). The post asks developers to invest as much effort in agent-computer interfaces as is usually put into human-computer interfaces. A good tool definition includes example usage, edge cases, input format requirements and clear boundaries from other tools. Developers should rewrite parameter names and descriptions to make use obvious ("Think of this as writing a great docstring for a junior developer on your team"), test the model on many inputs to see its mistakes, and change arguments so that mistakes are harder to make (poka-yoke, a manufacturing term for error-proofing).
An example from SWE-bench. While building the SWE-bench agent, the authors "spent more time optimizing our tools than the overall prompt." The model made mistakes with relative file paths once the agent had left the root directory; changing the tool to require absolute paths fixed this, and the post says the model then used the method "flawlessly" (Appendix 2). No numbers are given.
Three principles for agents. The summary lists the principles the authors try to follow: simplicity in the agent's design; transparency, by explicitly showing the agent's planning steps; and careful design of the ACI through tool documentation and testing.
Where agents have worked
Appendix 1 names two applications that customers found valuable. Customer support combines a conversation with tool access to customer data and actions such as refunds, and success can be measured by resolutions; the post notes that some companies charge only for successful resolutions. Coding agents benefit because code can be verified by automated tests, test results give feedback, and the problem is well defined; the post adds that human review is still needed to check solutions against broader system requirements.
Limitations and open questions
The post is guidance from experience. It reports no comparisons between patterns, no error rates and no cost or latency figures, so its recommendations (for example, that a separate guardrail call works better than a combined one, or that agents compound errors) are stated rather than measured. It does not discuss safety beyond sandboxing, guardrails, stopping conditions and human checkpoints. Because the live page has been revised since publication (see the note on versions above), a citation of a specific example or framework should say which version it refers to.
Research questions
- How much does tool-description wording change agent error rates? The post claims tool definitions deserve as much attention as prompts but gives one anecdote. A controlled comparison of the same tools with differently worded descriptions, measuring tool-call errors, would test the claim.
- When does a single augmented call match a workflow or agent? The post advises starting with one call. Benchmarks that run the same tasks as a single call, a fixed workflow and an agent, reporting accuracy, cost and latency together, would show where the trade-off turns.
- Do separate guardrail calls outperform combined ones? The post says screening in a separate call "tends to perform better." Measuring harmful-content detection and answer quality under both designs would show by how much and for which content.
- Does showing an agent's planning steps help users catch errors? Transparency is one of the three principles. A user study comparing error detection with and without displayed plans would test whether it serves oversight.
- How do errors compound across agent steps? The post names compounding errors as a cost of autonomy. Measuring failure rates as a function of the number of steps, with and without environment feedback at each step, would quantify it.
How it connects
- The SWE-bench agent. The coding agent and the tool lesson about absolute file paths come from the work described in Raising the bar on SWE-bench Verified with Claude 3.5 Sonnet (October 2024), which the post links.
- Later Anthropic documents. Trustworthy agents in practice (April 2026) links to this post for its definition of an agent as a model that directs its own processes and tool use, deciding for itself how to reach the user's goal rather than following a fixed script.
- Wiki. Routing is a classification problem; see Text Classification for the general setting.
References
- Schluntz, E., and Zhang, B. (2024, December 19). Building effective agents. Anthropic. https://www.anthropic.com/research/building-effective-agents. Version summarized: as published, Internet Archive capture of December 20, 2024, https://web.archive.org/web/20241220072956/https://www.anthropic.com/research/building-effective-agents; compared with the revised page as fetched in May 2026.