Chapter 1 · AI Agent Basics

Tools: The Agent’s Action Interfaces#

Tools are the Agent’s bridge to the outside world. They turn the Agent from a passive observer into an active system that can search, write files, run code, call APIs, send messages, or operate interfaces. Without tools, an Agent is limited to text generation; with them, it can act on external systems.

To discuss tools systematically, we can sort them into five types by the direction of the Agent’s interaction with the world. At this stage, a brief overview of each type’s representative scenarios is enough to establish the overall picture; later chapters treat each in depth.

Perception Tools allow the Agent to access information: search engines provide real-time web data, file systems read local documents, and APIs and databases connect to external services and enterprise core data.

Execution Tools allow the Agent to act on external systems: code execution, file operations, system commands, and external API calls turn decisions into concrete actions.

Collaboration Tools allow the Agent to divide work with other Agents: delegating specialized tasks to sub-agents, requesting human confirmation at key decision points, or coordinating actions in multi-agent systems.

Event Trigger Tools are invoked in a fundamentally different way from the first three categories: the Agent does not call them; they arrive as external inputs that trigger the Agent to begin work. A new email comes in, a scheduled time arrives, or another system fires a Webhook callback; the event activates the Agent and initiates reasoning and action. The Agent never calls these itself, yet they are still a channel through which it interacts with the outside world, so we count them in the broad tool system.

User Communication Tools are the channels through which the Agent communicates with the user. Where execution tools change the external world, communication tools carry information—delivering the Agent’s progress, or a proactive check-in, by text message, voice call, email, and so on.

Chapter 4 covers the full taxonomy and design principles for these five types. The quality of tool design directly determines what an Agent can reliably accomplish: define interfaces vaguely and the model will misuse them; handle errors poorly and a single failed tool can leave the Agent stuck; scope permissions too broadly and one Agent error can become irreversible. As the MCP (Model Context Protocol) standard spreads, integrating a tool is becoming as easy as installing a plugin—the ecosystem is expanding rapidly, but the design principles will not go out of date.

Tool Calling (also known as Function Calling) is a core capability of modern LLM Agents: it lets the model invoke external tools in a structured way, transforming the LLM from a pure text generator into an intelligent system that can act through external interfaces. This book uses the term “tool calling” throughout.

Tool calling proceeds in four steps: first, the context tells the model which tools are available (names, purposes, parameters); then the model decides on its own whether to call a tool, which tool to call, and with what arguments; next, once the tool has run, its result is appended to the context; finally, the model decides its next move based on that result. This loop is the foundation of ReAct, introduced later in the chapter.

For a weather query, the simplified representation of the four-step process at the API level is as follows:

1
Step 1: Declare tools                  Step 2: Model decides to call
2
tools: [{                             assistant: {
3
  name: "get_weather",                  tool_calls: [{
4
  parameters: {                           function: "get_weather",
5
    city: "string"                        arguments: {city: "Beijing"}
6
  }                                      }]
7
}]                                    }
8

9
Step 3: Result appended to context    Step 4: Model responds based on result
10
tool: {                               assistant: {
11
  tool_call_id: "call_1",               content: "Today in Beijing: 28°C, sunny."
12
  content: '{"temp":28,"sky":"clear"}' }
13
}                                     }

The developer only defines the tools and executes the calls; the model itself decides whether to call, which tool to call, and what arguments to pass. Chapter 2 examines this API structure in detail.

When designing tools for an Agent, keep them general-purpose and give the LLM flexibility. Instead of a dedicated calculator tool, provide a Python code interpreter and a secure sandbox to run it in. Instead of a special tool for logging work notes, provide file read/write tools and a virtual file system. General-purpose tools let the Agent combine basic capabilities to solve problems creatively.

LLM: The Agent’s Reasoning Engine#

The Large Language Model (LLM) is the Agent’s decision-making core. Given a user request, it first has to infer the real intent (what users say is often not what they actually want), then break a vague or complex task into executable steps. Throughout execution it keeps making decisions: what to do next, whether to call a tool, which one, and with what arguments. This understand–plan–execute capability comes from knowledge accumulated during pre-training, and it is the foundation that workflows and autonomous Agents alike depend on.

A distinctive capability of LLM Agents is internal reasoning—before acting, the Agent can plan and reason through the task. This does not change the external environment, yet it markedly improves the actions that follow. This ability comes from pre-training (the initial training on massive amounts of internet text, through which the model learns language patterns and world knowledge): the model draws on reasoning patterns encoded in human knowledge, including mathematical laws, causal relationships, and strategies for decomposing problems. An Agent’s reasoning is therefore not blind trial and error; it builds on a structured body of knowledge.

This structured reasoning lets an LLM Agent handle entirely new tasks without prior examples—two concepts, zero-shot and few-shot, illustrate this point. The direct manifestation is Zero-shot Generalization: facing a task it has never seen, the Agent handles it by recombining what it already knows, no examples needed. The model may never have been explicitly taught to write a poem about quantum physics, yet it can produce a reasonable one from its existing knowledge of language and physics.

With a few examples, an LLM Agent can also perform Few-shot Adaptation: two or three demonstrations in the prompt are enough for it to learn a new task pattern. If shown a few “user comment -> sentiment label” examples, it can classify the sentiment of new comments. In short: zero-shot means solving a task with no examples; few-shot means learning the pattern from a small number of examples.

Agent Learning Mechanisms: Post-training, In-Context Learning, and Externalized Learning#

The previous section showed how reinforcement learning lets a model internalize the decision of when and how to call tools. But an Agent’s learning is not confined to the training phase—many readers, when considering how an Agent learns from experience, assume the model must be retrained. In fact, post-training is only one way for an Agent to learn from experience. Its learning mechanisms fall into three complementary paradigms (Figure 1-1):

• Post-training: Encodes experience into the model’s parameters through reinforcement learning—the strongest cross-task generality, at the highest update cost (see Chapter 7).
• In-Context Learning: Adapts on the fly through pattern retrieval within the context, powered by the attention mechanism (how the model decides which parts of its input to focus on). If the prompt contains a few worked examples of customer service handling, such as “customer complaint → apology/reassurance + compensation plan,” the model can handle new customer service conversations in the same pattern. This is in-context learning. Adaptation is fast but transient: it disappears when the session ends. Despite the name, its inner mechanism is closer to pattern matching than true learning. As an analogy, if you are shown three solved math problems of the same type and then a fourth, you can probably solve it by following the pattern. But if the fourth problem requires a genuinely new approach, reviewing the first three answers will not get you there. In other words, in-context learning lets the model apply patterns it has already seen, but it cannot discover entirely new rules—a fundamental difference from post-training (Chapter 2 develops this claim through the lens of the attention mechanism).
• Externalized Learning: Externalizes knowledge and procedures into knowledge bases and executable tool code—persistent and interpretable at once.

The three paradigms complement each other on different time scales: post-training provides foundational capability, in-context learning provides rapid adaptation, and externalized learning provides reliability and efficiency. Chapter 8 systematically compares how the three work in concert.

An analogy: post-training is like studying a textbook—it can permanently improve capability, but at high cost; in-context learning is like consulting a reference on the spot—it helps while the reference is open, then disappears; externalized learning is like keeping a personal notebook—it is persistent and always at hand, but requires deliberate upkeep.

Context: The Agent’s Working Set#

Context is the working set of information available to an Agent at each decision point. Just as a person making a decision needs the right materials on the table—task instructions, reference manuals, earlier correspondence, the latest data—an Agent’s context window is the information it can use. From the API’s perspective (detailed in Chapter 2), the context of each LLM call consists of five parts:

• System Prompt: Unlike the prompts users enter during a conversation, the system prompt is written by the developer and stays fixed for the whole conversation. It is the Agent’s “job description”—defining its identity, permissions, and rules of conduct. Careful prompt engineering of the system prompt is how we shape the Agent’s operating behavior. The system prompt also carries user memory that persists across sessions (personalized information such as preferences, past behavior, and background settings; see Chapter 3), plus dynamically injected environmental state.
• Tool Definitions: Declares the names, functional descriptions, and parameter formats of the tools available to the Agent. Without tool definitions, the Agent cannot recognize or call any tools—an ablation study (Experiment 1-1) will verify this. Tool definitions, together with the system prompt, form the static prefix that remains unchanged throughout the conversation. (This is the foundational pattern; since 2026, production frameworks can also load full tool schemas on demand at the end of the context without breaking the prefix—see the tool definitions section of Chapter 2 and Chapter 4.)
• User Messages: Input from the user. User messages may also contain external knowledge dynamically retrieved via RAG (Retrieval-Augmented Generation, see Chapter 3 for details)—covering information beyond the training data cutoff or private domain knowledge.
• Assistant Messages: Responses previously generated by the model, which can contain up to three parts—reasoning (the internal chain of thought, maintaining coherence and decision interpretability), content (the response to the user), and tool_calls (the way the Agent takes action). In a specific response, these three parts may not all appear simultaneously: for example, when the Agent decides to call a tool, it usually only has reasoning + tool_calls; when giving a final answer, it usually only has reasoning + content.
• Tool Results: The output returned after the Agent framework executes a tool. These results are the direct basis for the Agent’s next reasoning step—and what lets it learn from outcomes rather than repeat its mistakes.

The first two items (system prompt + tool definitions) form the static prefix; the last three (user messages + assistant messages + tool results) form the dynamic message history that grows with every interaction. Together, these five parts make up the context of each LLM inference.

Is every component truly indispensable? The most direct way to find out is an ablation study—the diagnostic method of ruling out causes one at a time: remove component A and see whether the system still works, then component B, and so on, until each component’s contribution is clear. Experiment 1-1 applies exactly this method to the five components above. The results are direct: without tool definitions, the Agent is completely incapable of action; without tool results, it does not receive feedback from the previous step, so it calls the same tool repeatedly, becoming stuck in an infinite loop; without the reasoning in assistant messages, consecutive decisions start contradicting each other; without message history, the Agent loses task continuity and restarts the whole task from the beginning, repeating steps already done. Each component’s role rests on experimental evidence, not just theoretical inference.

Experiment 1-1 ★★: The Critical Role of Context#

We probed how each context component shapes Agent behavior with a systematic ablation study. Of the five components above, four were tested—the system prompt, as the Agent’s basic identity definition, was exempt: without it the Agent has no role awareness at all, and the test would be meaningless. As Figure 1-2 shows, the experiment ran five controlled groups: a complete baseline retaining every component, plus four groups each missing one, to observe each component’s effect on Agent performance.

The experimental results revealed the irreplaceable role of each context component. Tool Definitions (part of the static prefix) are the foundation of the Agent’s action capability; without them, the Agent cannot recognize or call any tools. Tool Results are key to closed-loop control; their absence deprives the Agent of execution feedback and causes it to fall into an infinite loop. The reasoning process (the reasoning part of assistant messages) preserves the reasons for the Agent’s previous decisions, making the overall reasoning more coherent and preventing contradictory decisions. Message history (user messages, assistant messages, and tool results from previous rounds) prevents redundant operations, maintains task execution coherence, and avoids repeating the same mistakes.

The experiment’s core insight: context determines what information the Agent has at decision time, and the Agent can only decide based on that information. Just as a person missing crucial documents cannot make sound judgments, an Agent missing any context component suffers a severe loss of decision-making ability—without tool definitions it does not know what tools exist; without previous execution results it does not know what has already been done.

The ReAct Loop#

With the three components in hand, a natural question follows: how do they work together? The ReAct loop is the core mechanism that connects LLM, context, and tools into one system. We can examine it step by step.

The core pattern by which an Agent executes a task is called ReAct (Reasoning + Acting). The name mentions only reasoning and acting, but the actual loop has three stages: the model first reasons about what to do next, then calls a tool to act, then observes the tool’s result and reasons about the subsequent step. This “reason → act → observe → reason → act → observe” loop repeats until the task is done.

Consider a concrete example—aggregating revenue across multiple currencies—to understand an Agent’s trajectory: the message history that accumulates as the Agent works, comprising user messages, assistant messages (with their reasoning and tool calls), and tool results. On every LLM call, the complete context the model receives is the static prefix (system prompt + tool definitions) plus the trajectory (dynamic message history) (Figure 1-3). This shows a key fact: Agent context = static prefix + trajectory. Concretely, the static prefix is the first two of the five components above (system prompt + tool definitions); the trajectory is the last three (user messages + assistant messages + tool results, growing with each interaction). From this complete context the LLM generates its next response, which is then appended to the trajectory for the subsequent call.

Here is the structure of a trajectory, in pseudocode:

1
trajectory = [
2
  {role: "user", content: "Based on the company's quarterly revenue: Q1 2.5M USD, Q2 2.1M EUR, Q3 1.8M GBP, Q4 380M JPY, calculate the company's total annual revenue and average quarterly revenue"},
3

4
  # First iteration - LLM receives the above trajectory and generates a response
5
  {role: "assistant",
6
   reasoning: "Need to convert all currencies to USD...",
7
   content: "",  # No direct reply to the user
8
   tool_calls: [
9
     {name: "convert_currency", args: {amount: 2100000, from: "EUR", to: "USD"}},
10
     {name: "convert_currency", args: {amount: 1800000, from: "GBP", to: "USD"}},
11
     {name: "convert_currency", args: {amount: 380000000, from: "JPY", to: "USD"}}
12
   ]},
13

14
  # Agent framework executes tools, adds results to trajectory
15
  {role: "tool", content: "EUR->USD: 2282608.7"},
16
  {role: "tool", content: "GBP->USD: 2278481.01"},
17
  {role: "tool", content: "JPY->USD: 2541806.02"},
18

19
  # Second iteration - LLM receives the complete trajectory, including tool results
20
  {role: "assistant",
21
   reasoning: "Conversion results obtained, now need to aggregate and calculate...",
22
   content: "",
23
   tool_calls: [
24
     {name: "code_interpreter", args: {code: "total = 2500000 + 2282608.7 + ..."}}
25
   ]},
26

27
  {role: "tool", content: "Total: $9,602,895.73, Average: $2,400,723.93..."},
28

29
  # Third iteration - LLM receives the complete trajectory and generates the final answer
30
  {role: "assistant",
31
   reasoning: "All calculations complete, summarizing results...",
32
   content: "FINAL ANSWER: Total revenue $9,602,895.73..."}
33
]

Note that the system prompt and tool definitions are not shown in the trajectory—they serve as the static prefix and are automatically prepended to the trajectory before each LLM call.

In our experiment, this loop was clearly visible. In the first round, the Agent analyzed the task and called three currency conversion tools in parallel; in the second, it fed the conversion results to a code interpreter for the more computationally intensive calculation; in the third, having confirmed all calculations were complete, it produced the final answer. A complex multi-step task was completed in 3 iterations and 4 tool calls.

The elegance of this design lies in the cumulative nature of the context. Every LLM call receives the complete trajectory, so the model knows which stage of the task it is in, what was tried before, and what the outcome was. Just as people keep reviewing and summarizing while solving a problem, the Agent maintains a global view of the task through its trajectory. And because the trajectory is structured—user messages, assistant messages (reasoning + tool calls), and tool results all separated cleanly—the system is highly interpretable and debuggable.

The trajectory is more than an execution record; it is evidence of the Agent’s capability. Analyzing trajectories at scale reveals behavior patterns, better decision paths, and better tool designs. Trajectory data can even be distilled into a knowledge base, or used to train stronger Agent models via reinforcement learning—closing the loop of learning from experience.

Now that we understand the Agent’s operating loop, we examine two experiments to see how different models drive it.

Experiment 1-3 ★: GPT-5.6 Native Deep Research Capability#

The second experiment uses OpenAI GPT-5.6 to show how an advanced model, backed by API-level built-in tools, closes the “search—read—analyze” orchestration loop on the server side for Deep Research. GPT-5.6 comes in three variants—Sol (flagship frontier model), Terra (balanced model for everyday work), and Luna (fast, economical lightweight model)—all leaving the tool-calling decisions to the model natively, so the client needs no orchestration framework of its own. One convenient feature is Freeform Tool Calling. Traditionally, a model calling a tool must serialize every parameter into strict JSON (a structured data format), much like filling out a form with rigid formatting rules. Freeform tool calling (declared in the API through a tool of type: "custom") lets the model send raw text straight to the tool (a snippet of Python code, a SQL query), avoiding JSON escaping entirely. It is worth stressing that this is an evolution of the API’s parameter format, not an innovation in model architecture—the client’s tool-calling loop (detect tool_calls → execute → return the result) stays the same; only the arguments change from a JSON string to raw text. GPT-5.6 also introduces a Verbosity parameter (controlling output detail) and a Reasoning Effort parameter (adjusting reasoning depth; Sol adds a max level for the most thorough reasoning time), letting developers tune model behavior to the complexity of the task.

GPT-5.6, paired with the Responses API’s web search and code interpreter built-in tools, delivers the core mechanism of Deep Research: the model can autonomously search the web for real-time information and write code for in-depth analysis, enabling an iterative research process of “search -> read -> analyze -> search again.” For example, when faced with a question like “What is the shortest distance between the capitals of the 10 ASEAN countries?”, GPT-5.6 automatically searches for the geographic coordinates of each capital, then writes Python code to calculate the great-circle distance between all pairs of capitals, ultimately identifying the closest pair. Similarly, in a task like “Search for Bitcoin’s trend over the past month and perform technical analysis,” it can fetch real-time price data from multiple financial data sources, use professional technical analysis libraries to calculate moving averages, RSI, MACD, and other technical indicators, generate visual charts, and provide trading recommendations.

More importantly, GPT-5.6 internalizes the design philosophy of the OpenAI Deep Research product at the model level, introducing an intent clarification process. Given a research request, GPT-5.6 does not start executing immediately; it first clarifies the user’s true intent through a series of questions. For “Search for Bitcoin’s trend over the past month and perform technical analysis,” it would first ask: “Which data source do you prefer? Which technical indicators would you like analyzed?” This interactive clarification lets GPT-5.6 produce research reports that are more precise and better aligned with what the user actually needs.

GPT-5.6 is a mature example of “Model as Agent”—web search, the code interpreter, and other built-in tools of the Responses API execute in a closed loop on the server; the orchestration loop moves from the client to the API server, which simplifies the client implementation. The model still emits standard tool calls; the client simply no longer has to build the “search—read—analyze” orchestration framework itself. Its most noteworthy aspect is the intent clarification mechanism: rather than executing a task immediately, the model first confirms what the user really needs, then formulates a research strategy. The gap between “what the user said” and “what the user actually wants” is addressed before execution begins.

Figure 1-4 illustrates the complete architecture of native tool calling under the “Model as Agent” paradigm, along with the ReAct execution process of Kimi K3 and GPT-5.6 in real-world tasks.

From Prompt Engineering to Loop Engineering: The Evolution of Engineering Paradigms#

Looking back at the development of AI application engineering, a clear evolutionary arc emerges:

Software Engineering is the foundation—traditional system design, architecture, testing, and deployment. Prompt Engineering was the first wave of innovation—improving output quality by refining the natural-language instructions fed to the model. Context Engineering was the second wave—the realization that optimizing the prompt alone is not enough: the model’s working context (system instructions, tool definitions, conversation history, external knowledge) has to be managed systematically. Harness Engineering was the third wave—it widens the view from “what information the model receives” to “what kind of system the model runs in,” taking in all infrastructure outside the model: constraint mechanisms, verification methods, feedback loops, error recovery. The newest wave is Loop Engineering—it widens the view once more, from a single run to sustained autonomous operation across runs: who discovers the next piece of work, when to verify, and when the task counts as truly done (Chapter 10 develops this alongside multi-agent collaboration systems).

These five stages are not replacements but nested layers: Prompt Engineering is a subset of Context Engineering, which is a subset of Harness Engineering, which is a subset of Loop Engineering. Each layer widens the engineer’s scope of concern and influence beyond the last. As models converge in capability and stop being the decisive differentiator, competitive advantage shifts to the engineering outside the model. Recent engineering practice supports this view. LangChain’s work on Terminal Bench 2.0 (a benchmark evaluating an Agent’s ability to complete complex tasks in a terminal environment) is a striking example: their Coding Agent improved from 52.8% to 66.5% (jumping from outside the top 30 to the top 5 on the leaderboard). What changed was not the model but the Harness—having the Agent check its own execution results, detect when it was stuck in a repetitive loop, and refine its reasoning strategy. OpenAI’s engineering team has shared a similar experience: 3 engineers completed approximately one million lines of code and nearly 1500 PRs in 5 months, about 10 times traditional development speed. The main driver was not a stronger model; it was getting the Harness right.

Core Principles of the Five Harness Functions#

The earlier table listed the Harness’s five functions. The table below adds each function’s core design principle and where this book treats it, mapping concept to practice:

The five functions form a closed loop: Context and Tools support decision-making, Constrain prevents errors, Verify detects deviations, and Correct closes the cycle. If any link is missing, the system develops a reliability gap. Before examining specific orchestration patterns and guardrail designs, we first lay out the core principles for building effective Agents and for choosing a model—the foundation for every design decision that follows.

Core Principles for Building Effective Agents#

Based on Anthropic’s experience, successful Agent systems follow three core principles.

Keep it simple. Start with the simplest solution and add complexity only when truly necessary. Direct API calls are preferable to complex frameworks; clear code is preferable to clever abstraction—every extra layer of abstraction is a new blind spot during debugging.

Keep it transparent. Show the Agent’s planning steps, execution logs, and decision trajectory clearly. This is not just a debugging convenience; it is a precondition for user trust—an error inside a black box is hard to locate or fix from outside.

Design a well-structured tool interface (ACI, Agent-Computer Interface). ACI means designing the interface from the Agent’s perspective—easy for the Agent to understand and use—rather than from the programmer’s perspective, as in traditional APIs. Tool names and parameters should be intuitive, and the design should prevent likely mistakes wherever possible; a USB connector that fits only one way is a simple example. Manufacturing calls this error-prevention philosophy Poka-yoke, a term from the Toyota Production System. A poorly designed tool can cause even the strongest model to fail repeatedly: the interface is the only channel between model and tool, and a vague interface gets amplified into systemic error.

The next three sections address three freestanding but important topics in Harness engineering: model selection, orchestration patterns, and guardrails and safety. None belongs to the five Harness elements proper, but all are unavoidable in engineering practice.

How to Choose a Model#

Before discussing orchestration patterns, we first need to answer a practical question: what kind of model should drive your Agent?

The model is the foundation of the Agent’s intelligence, and choosing the right one often matters more than any amount of prompt tuning. Model releases move too quickly for specific version recommendations to stay useful, so this section offers directions instead.

Know the “Big Three.” The three most commonly used closed-source model providers in current Agent development are OpenAI (GPT/o series), Anthropic (Claude series), and Google (Gemini series). Each has its strengths: Claude excels in complex reasoning, coding, and tool calling, making it a popular choice for Agent development; Gemini offers an ultra-long context window and powerful multimodal capabilities, making it suitable for long texts and multimedia scenarios such as images and videos; the GPT/o series offers broadly balanced capabilities and has the largest user base. When selecting a model, do not rely only on leaderboards; evaluate it on your own tasks (see Chapter 6).

Chinese Models. If your application is deployed in China or you are on a tight budget, models from Chinese vendors are a pragmatic choice. ByteDance’s Doubao series offers extremely low latency within China, suitable for real-time interaction; Moonshot AI’s Kimi is among the stronger Chinese models for Agent capabilities; open-source models like Qwen and DeepSeek have advantages in cost and customizability. Note that models differ widely in tool-calling ability, so be sure to test in your specific scenario before committing. Chinese models are typically accessed via APIs from platforms like Volcano Engine (Doubao) and SiliconFlow (open-source models), while non-Chinese models can be accessed through aggregator services such as OpenRouter.

Open Source vs. Closed Source. Closed-source models generally lead in capability but are more expensive and constrained by the vendor’s API policies. Open-source models are low-cost, support private deployment, and allow fine-tuning customization, making them suitable for cost-sensitive scenarios or those with data compliance requirements.

Most Agents Need a Model that Supports Reasoning. Agents make complex decisions—multi-step reasoning, tool selection—and models without reasoning tend to perform poorly on them. The exceptions are few: a single simple step, or Computer Use GUI operations that amount to clicking a fixed position, where a non-reasoning model may suffice. The moment multi-step reasoning or dynamic decision-making enters, a reasoning model is essential.

Consider Output Speed and Multimodal Capabilities. Beyond cost, two dimensions are easy to overlook. One is output token speed: Agents typically run many rounds of inference, and each round must finish before the next can start, so output speed directly determines end-to-end latency—a 20-round Agent task that runs 2 seconds slower per round means an extra 40 seconds of waiting. The other is multimodal support: if your Agent needs to understand images, audio, or video, multimodal capability is a hard requirement, and models differ widely here.

Orchestration Patterns: Workflow vs. Autonomous#

Orchestration patterns are how the Harness organizes its “context and tools” layer—they determine how context flows between LLM calls, how tools are scheduled, and whether the Agent’s execution path is fixed in advance or generated dynamically. Agent orchestration has evolved from simple to complex, and each pattern has suitable use cases and trade-offs. In Anthropic’s experience working with dozens of teams building LLM Agents, the most successful implementations rarely use complex frameworks; they use simple, composable patterns.

When building an LLM application, progress from simple to complex. Start with a single LLM call—if better prompts and in-context examples solve the problem, do not build an Agent system. When multiple steps are needed and the task decomposes cleanly into fixed sub-tasks, use a workflow. Use an autonomous Agent only when you need dynamic decisions and a flexible execution path. And remember: Agent systems typically trade latency and cost for better task performance—evaluate carefully whether that trade is worth it.

Autonomous Agent: Runtime Decision-Making#

When the fixed path of a workflow is insufficient, we need an autonomous Agent. The core difference between an autonomous Agent and a workflow is that the execution path is not predefined but is determined at runtime by the Agent based on environmental feedback.

Returning to the flight example, an autonomous Agent needs no four predefined nodes. The user says, “Book me a flight to Shanghai next Wednesday,” and the Agent determines the sequence dynamically: it searches for flights, discovers that login is required, verifies identity, and resumes the search. If the cheapest flight has a layover, it can ask whether that is acceptable; if the user says no, it adjusts the search criteria.

An autonomous Agent therefore has to plan for itself—choose its own execution steps—and recognize failure and change strategy rather than simply halting on error. But autonomy is not unbounded: explicit stopping conditions must be designed in (task complete, maximum iterations reached, unrecoverable error hit), or the Agent can enter infinite loops or continue executing after the task is already done.

From an implementation perspective, an autonomous Agent is essentially an LLM using tools in a loop, continuously obtaining environmental feedback to make progress on the task—this is the ReAct loop introduced earlier. Common exit conditions include: calling a final output tool, the model returning a response without any tool calls, or encountering an error or reaching the maximum number of rounds.

Autonomous Agents are well suited to open-ended problems—those where it is difficult or impossible to predict the number of steps required. Typical use cases include: Coding Agents solving SWE-bench (Software Engineering Benchmark, a benchmark for evaluating an Agent’s ability to automatically fix real GitHub issues) tasks, “Computer Use” Agents operating computer interfaces like a human, and research tasks requiring iterative search and analysis.

Autonomy also costs more and lets errors compound. Deploying an autonomous Agent therefore demands thorough testing in a sandbox, appropriate guardrails and monitoring, and human-in-the-loop checkpoints at critical decision points.

Choosing and Mixing the Two Patterns#

In practice, workflows and autonomous Agents are not mutually exclusive—many systems mix the two: critical processes with strict compliance requirements run as workflows for reliability, while the parts that need flexible decisions switch to autonomous mode. n8n, for example, is a mature open-source workflow automation framework in which developers build Agents by arranging functional components on a visual canvas—and workflow nodes and autonomous Agent nodes can coexist in the same system.

Guardrails and Safety#

This section gives a high-level overview of guardrails to establish the big picture. Implementation details and practice follow in Chapter 2 (prompt injection protection), Chapter 4 (tool permission control), and Chapter 5 (code execution security); first-time readers do not need to follow every detail.

Guardrails are how the “constrain, verify, and correct” layer of the Harness is primarily implemented—a layered defense that keeps Agent behavior safe and controllable. Well-designed guardrails help manage data privacy risks (for example, preventing system prompt leakage) and reputational risks (for example, keeping model behavior consistent with the brand). Start with guardrails for the risks you have already identified, then add new ones as new vulnerabilities surface.

Think of guardrails as defense in depth. No single guardrail is likely to be sufficient on its own, but several specialized ones combined make a far more resilient Agent system.

This Book as a Practical Guide to Harness Engineering#

Seen through the lens of Harness engineering, each chapter of this book systematically builds out one component of the Harness. Security, meanwhile, belongs to no single chapter; it is a cross-cutting concern of the whole book (a cross-cutting concern touches many parts of a system at once—the way logging, in software engineering, has to thread through every module). The table below presents the Harness functions, security aspects, and corresponding chapters in a single view:

Anthropic’s practice in building long-running Agents shows how Harness design can solve problems the model itself cannot. They split complex tasks between an “Initialization Agent” (setting up the environment, decomposing the task list) and an “Execution Agent” (making incremental progress each session and leaving clear handover artifacts), using a structured Harness to tackle the two failure modes of long tasks: running out of context and declaring the task done prematurely. The chapters ahead work through the Harness component by component—Chapter 2 begins with the most central one, context engineering, and Chapter 5 lays out the complete practice of Harness engineering in Coding Agents.