Anthropic's Official Agent Building Guide: A Complete Breakdown of Workflows vs. Agents

Anthropic (the company behind the Claude large language model) has spent the past year collaborating deeply with dozens of teams across industries, accumulating extensive hands-on experience in building LLM agents. They distilled these insights into a landmark article, Building effective agents. The most core—and counterintuitive—conclusion is: The most successful LLM agents are not built with complex full-stack frameworks, but assembled using simple, composable patterns.

Anthropic was founded in 2021 by former OpenAI Research VP Dario Amodei and his sister Daniela Amodei, and is currently one of the world's most influential AI safety companies. Their flagship Claude series of large language models is renowned for safety, controllability, and long-context handling, with Claude 3.5 Sonnet performing on par with GPT-4o across multiple benchmarks. Anthropic's proposed Constitutional AI training method—which has models self-correct based on a set of explicit principles—has become an important paradigm in the AI Alignment field. It is precisely this deep understanding of "controllability" that has shaped Anthropic's distinctive "simplicity-first" philosophy for agent building—they know that the more complex model behavior becomes, the greater the challenges for safety and reliability.

This article deconstructs the underlying logic of building effective agents layer by layer, covering concept clarification, technical architecture selection, and framework usage strategy.

Clarifying Concepts: Workflows vs. Agents

Anthropic found that the industry's understanding of the term "agent" is quite chaotic. Some believe an agent must be a fully autonomous "digital employee" capable of independent thought and action, while others consider any system that follows preset processes to complete tasks as an agent.

To resolve this confusion, Anthropic proposed a broader concept—Agentic Systems—and clearly delineated two key architectures within it:

The introduction of this concept is essentially a reclassification of current AI application architectures. Previously, the industry often lumped all LLM-involved automation systems under the umbrella term "Agent," conflating a simple RAG Q&A system with a complex system capable of autonomously operating a browser. Anthropic's classification framework draws from the classic distinction in software engineering between "Orchestration" and "Autonomy": workflows correspond to deterministic orchestration, similar to traditional directed acyclic graph (DAG) task scheduling; agents correspond to non-deterministic autonomy, more akin to the paradigm of agent-environment interaction in reinforcement learning. This classification not only aids technical decision-making but also provides a common language for team communication.

Workflows: Pipeline-Style Deterministic Execution

A workflow is like an assembly line or a recipe—the process and steps are fixed and pre-designed. The LLM acts more like a "super function" within it, called by human-written code to complete specific subtasks—such as "summarize this text" or "extract key information." Decision-making authority lies with the code, not the LLM.

Agents: Detective-Style Autonomous Decision-Making

An agent is more like a detective—you give it an overarching goal, but it has no fixed script. It dynamically decides step by step based on environmental feedback: what to do next, which tool to use, and whether the task is complete. Decision-making authority lies with the LLM, not the code.

Here's an intuitive example: If you ask an LLM to "first summarize a news article, then call an API to publish it to a blog," the process is fixed—that's a workflow. But if you simply say "help me promote this new product," and it needs to independently judge whether to write tweets, publish blog posts, or conduct market research first—this kind of scenario requiring autonomous decision-making is an agent.

Understanding the core difference between workflows and agents is crucial for the technical architecture selection that follows.

The Technical Selection Pyramid: Always Start with the Simplest Solution

Anthropic offers a highly practical recommendation: Always start with the simplest solution, and only consider adding complexity when the simple solution genuinely cannot meet your needs.

Why? Because building agentic systems comes at a cost, primarily in two areas:

• Latency: Typically requires multiple LLM calls and tool uses, significantly slowing response time
• Cost: Each LLM call and tool use consumes tokens, accumulating higher expenses

A token is the basic unit of text processing for LLMs, roughly equivalent to 3/4 of an English word or 1-2 Chinese characters. API call costs are priced separately by input tokens and output tokens—for example, Claude 3.5 Sonnet is priced at approximately $3/million input tokens and $15/million output tokens. In agentic systems, a seemingly simple task might trigger 5-10 or more LLM calls, each carrying substantial context (including system prompts, conversation history, tool call results, etc.), causing token consumption to grow exponentially. Take a typical agent task as an example: the initial planning call consumes 2,000 tokens, each tool call and result parsing consumes 1,000-3,000 tokens, and after 8 iterations the total consumption might reach 30,000-50,000 tokens—10-20x the cost of a single call. This is why Anthropic repeatedly emphasizes: "Never use a complex solution for a problem that can be solved simply."

Based on this principle, we can construct a Technical Selection Pyramid, from bottom to top:

Level 1: Optimize a Single LLM Call

This is the simplest, lowest-cost solution and should be tried first. By incorporating RAG (Retrieval-Augmented Generation) and few-shot in-context examples, you can solve most problems. Often, a well-crafted prompt is all you need.

RAG (Retrieval-Augmented Generation) is a technical paradigm proposed by Meta AI in 2020. Its core idea is to retrieve relevant document fragments from an external knowledge base before the LLM generates a response, injecting them as context into the prompt so the model can answer based on the most current and accurate information. This solves the fundamental problem of LLM training data having a cutoff date and being prone to "hallucination." A typical RAG pipeline includes: document chunking → vectorization (embedding) → storage in a vector database (e.g., Pinecone, Milvus) → semantic retrieval at query time → concatenating retrieval results into the prompt. Few-shot learning provides a small number of input-output examples in the prompt, allowing the model to understand task requirements through "pattern matching" without fine-tuning, significantly improving performance on specific tasks. When combined, these two techniques often enable a single LLM call to achieve surprisingly good results—this is the technical foundation behind Anthropic's emphasis on "optimizing single calls first."

Level 2: Build Workflows

When a single LLM call genuinely isn't sufficient, and the task process is fixed, clear, and predictable, you should choose a workflow. It delivers predictable and consistent results.

Level 3: Build Agents

Only when tasks are open-ended, steps cannot be predicted, and the model needs to make large-scale autonomous decisions should you choose a true agent. This is the most powerful but also the most complex and expensive solution.

Practical Example: Technical Selection for AI Translation

Let's use an AI translation scenario to concretely demonstrate how to apply this technical selection pyramid.

Scenario 1: Translating Internal Emails

The purpose is to help colleagues quickly grasp the gist, with low quality requirements and a focus on efficiency. Here, a single LLM call is the optimal choice—simply say in one prompt "translate this into Chinese and check the grammar." It's fast, cheap, and even minor translation imperfections won't affect usability.

Scenario 2: Translating Company Website Product Descriptions

Any error could cost you customers, so quality standards are high. This is where the power of workflows shines:

1. Step 1: Have the LLM play the role of a professional translator, focusing entirely on translating the content
2. Step 2: Have the LLM play the role of an experienced native-speaking editor, rigorously reviewing and polishing the translation

This role separation makes each step more focused, producing final output quality far exceeding a single call. This pattern is known in academia as "Self-Refine," and its principle leverages the difference in attention allocation under different role settings—when the model is asked to "translate," it focuses attention on semantic conversion; when asked to "review," it pays more attention to grammatical accuracy, natural expression, and terminology consistency. Research shows that this multi-role pipeline typically improves output quality by 15%-30% compared to a single call.

Scenario 3: Translating and Publishing to a Global Blog

This requires localization optimization based on local culture and SEO requirements—a task complex enough to require autonomous exploration and decision-making: researching online, making judgments, and choosing strategies. Only then do you need a true agent to autonomously complete the work.

Framework Usage Strategy: A Three-Step Guide to Avoiding Pitfalls

With frameworks like LangChain, Dify, and n8n flooding the market, should you use them? Anthropic's position is very clear: these frameworks' advantage is enabling rapid prototyping and idea validation, but the cost is black-boxing.

LangChain is currently the most popular LLM application development framework, offering high-level abstractions like Chains, Agents, and Memory, supporting Python and JavaScript, with its core value being the standardization of common LLM application patterns. However, its over-abstraction has drawn criticism—a simple API call might be wrapped in multiple layers of nested class inheritance, making stack traces during debugging absolutely nightmarish. Dify is an open-source LLMOps platform that provides a visual workflow orchestration interface where users can build Agents by dragging and dropping nodes, particularly suitable for non-technical teams to quickly build prototypes. n8n positions itself as a general-purpose workflow automation tool (an open-source alternative to Zapier) that recently added AI node support, making it suitable for embedding LLM capabilities into existing business automation workflows. The common problem across all three: when a framework's default behavior doesn't perfectly match your needs, the cost of "working around the framework" is often higher than "building from scratch."

Frameworks encapsulate too many underlying details, and once your Agent encounters problems, debugging becomes extremely painful—you simply can't tell whether it's your logic that's wrong or whether the prompt constructed by the framework is the issue. Moreover, all those flashy features in frameworks easily tempt you into over-complicating simple problems, falling into the trap of over-engineering.

Anthropic's recommendations can be summarized as a three-step guide to avoiding pitfalls:

Step 1: Start with native APIs. Don't shy away from the effort—call an LLM API yourself at least once, and you'll truly understand how agents work, building cognition from first principles. First Principles Thinking originates from Aristotle's philosophy and was later popularized in engineering by Elon Musk. Its core is decomposing problems down to fundamental facts and principles rather than relying on analogy or existing experience. In agent development, this means understanding that an LLM is fundamentally a function that "receives text and outputs text"—all agent behaviors (tool calling, memory management, multi-step reasoning) are achieved through carefully designed prompts and parsing logic. When you call the API directly, you'll clearly see: how the System Prompt defines the agent's role and behavioral boundaries, how Tool Descriptions inform the model of available capabilities in JSON Schema format, and how the model's output is parsed into specific function calls. Once you master these underlying mechanisms, you can navigate any framework with ease and confidently customize when frameworks can't meet your needs.

Step 2: Treat frameworks as prototyping tools, not final answers. Using LangChain or Dify for rapid idea validation is great, but always make a conscious effort to understand how things work underneath—don't settle for being a "framework wrapper."

Step 3: Be ready to "graduate" at any time. When a project gets serious and demands ultimate stability and reliability, be brave enough to discard the prototype and rebuild core code using the underlying principles you've learned.

The same applies to visual tools like Dify and n8n—they're excellent for prototyping and simple automation, but when you need professional-grade stability and control, you need to return to the more fundamental code level.

Conclusion

The core philosophy of building effective LLM agents can be distilled into four key points:

1. Simplicity first is the golden rule—complexity does not equal power
2. Use ownership of decision-making to distinguish workflows (code controls) from agents (LLM controls)
3. Follow the Technical Selection Pyramid—single call → workflow → agent, progressing incrementally
4. Frameworks are stepping stones for learning and prototyping, not final production solutions

Understanding these underlying principles and selection criteria helps us avoid pitfalls and truly build efficient, practical AI applications. Rather than chasing the latest and most complex frameworks, it's better to return to first principles, start with the simplest solution, and scale up as needed.