Chapter 2: The Nature of Agents

You must have heard this saying: 2025 is the year of the Agent.

But if you ask ten people “what is an Agent,” you’ll get different answers. Some say it’s an upgraded version of automation, some say it’s a ChatBot that can use tools, some say it’s a digital employee. All these descriptions are correct, yet none are precise enough. It’s like asking “what is a smartphone” — some say it’s a phone, some say it’s a camera, some say it’s a computer. Each description captures one aspect, but none touch the essence.

In this chapter, I want to break open the technical nature of Agents in the simplest way possible. You don’t need to know programming, you don’t need to know math. You just need to bring one question: how exactly does this thing work?

After reading this chapter, you’ll figure out the Agent’s basic formula, how it “thinks,” how it evolved over the past three years, and most importantly — what it can do, and what it can’t.

2.0 From Model Shift to the Agent Inflection Point

Around late 2025, many observers noted a qualitative change: models were no longer “intern-style” assistants that only moved when you gave the next step. In programming, document work, and data analysis, they began handling longer, multi-step work reliably — an Agent inflection point, not just incremental speed or IQ gains.

To understand Agents, you need both what the Model can stably produce and how the Harness equips it to think, call tools, and observe results. Chapter 1 laid the model foundation; this chapter is about Agents themselves.

2.1 Agent = Model + Harness

Let’s start with the conclusion: an Agent is a model plus a runtime framework.

Written as a formula, it’s Agent = Model + Harness.

Sounds simple, but the meaning behind these two words deserves elaboration.

Model: Reasoning Capability, the Agent’s Brain

Model refers to the Large Language Model (LLM), such as GPT-4, Claude, Gemini, DeepSeek. It’s the Agent’s brain, responsible for “thinking.”

What does this “thinking” include?

First is understanding. You give it a sentence, a paragraph, an image, a PDF — it can understand the meaning within. Second is reasoning. It can make judgments, draw conclusions, and make choices based on known information. Finally is generation. It can write text, code, plans, and output the results you need.

You can analogy the Model to a CPU. A CPU is the core computing unit of a computer, but it’s meaningless on its own. A CPU sitting on a desk can’t access the internet, can’t type, can’t play video. It needs a motherboard, memory, hard drive, operating system — it needs someone to tell it “do this first, then do that.”

The Model is the same. A standalone large language model is just a program that can accept input and produce output. It doesn’t know how to use tools, doesn’t know how to remember previous conversations, doesn’t know how to break down complex tasks into steps for execution.

Here’s a concrete example. You open ChatGPT’s dialog box, type “help me check today’s weather in Beijing,” and it will tell you: “I can’t query real-time weather information because I don’t have internet access.” Its reasoning capability is sufficient to understand your request, but it lacks the means to execute this request. This is the Model’s limitation — it can think, So you need Harness.

Harness: Operating System, the Agent’s Body

The word “Harness” literally translates to “tack” — the collective term for the reins, saddle, and bridle on a horse. When you ride a horse, you don’t rely on your own legs to run; you control the horse’s direction, speed, and behavior through the Harness.

Applied to Agents, Harness is a runtime framework that “equips” the model’s reasoning capabilities, enabling it to actually do things.

Harness consists of six components:

Orchestration: Decides the Agent’s action flow. What to do first, what to do next, what to do when encountering errors, when to stop and ask humans. This is the Agent’s “work methodology.” Orchestration determines whether the Agent takes it one step at a time (ReAct mode), or makes a plan first then executes (Plan-and-Execute mode), or reflects on itself after completing a task (Reflexion mode). Without orchestration logic, an Agent is like a new employee without a workflow — has capability, Tools: External capabilities the Agent can use. Search engines, calculators, code executors, database queries, API calls — these are all tools. The model itself can’t access the internet, but Harness can give it a search engine tool; the model itself can’t execute code, but Harness can give it a code sandbox. Tools are the bridge for Agents to interact with the real world. An Agent without tools is like a person locked in a room — can think, Memory: Lets the Agent remember what happened before. Memory is divided into two layers. The first layer is short-term memory, which is the current conversation’s context — what you said before, what the Agent did before, what the intermediate results are. Short-term memory resides in the context window, limited by window size, typically thousands to hundreds of thousands of Tokens. The second layer is long-term memory, which is cross-conversation knowledge accumulation. For example, if you told the Agent last week that your company’s name and main business, it should still remember this week when you talk again. Long-term memory is usually stored in an external database and retrieved into context when needed. An Agent without memory starts every conversation like having amnesia. This is unacceptable in many scenarios — you wouldn’t want to re-introduce yourself to your “digital colleague” every day.

Sandbox: A secure execution environment. When an Agent needs to run code, manipulate files, or access systems, the sandbox ensures these operations happen within a controlled scope, without breaking your computer or leaking your data. You can imagine the sandbox as a glass room — you can see everything the Agent does inside, but it can’t touch things outside. If it runs a problematic program inside the sandbox, only the sandbox environment crashes; your computer is unaffected. This is an important safeguard for Agent security. An Agent without a sandbox is like a race car without seat belts — performance might be good, State Management: Tracks task progress. What step are we at now? What were the previous results? Which subtasks are completed, which are still in progress? Which tools have been called already, and what results were returned? State management gives the Agent coherence in multi-step tasks. Without state management, an Agent doing a complex task is like a project manager without a notebook — forgets what they were doing halfway through, or repeats work already completed.

Safety Mechanisms: Prevent the Agent from doing things it shouldn’t. Access control, content moderation, behavior restrictions — ensuring the Agent won’t overreach, won’t generate harmful content, won’t access sensitive data without your authorization. Safety mechanisms include multiple layers: input-layer filtering (preventing malicious instructions), execution-layer controls (limiting the Agent’s operational permissions), output-layer review (checking whether the Agent’s output is compliant). An Agent without safety mechanisms is like a company without rules and regulations — might operate efficiently in the short term, Dependencies between Harness components:

These six components are not isolated; they interdepend and collaborate. Orchestration logic decides when to call tools; tool return results need state management to track; memory provides historical context for orchestration logic; the sandbox provides security boundaries for tool execution; safety mechanisms set defenses at the boundaries of all components.

These six components combined together are Harness. Its relationship with the Model is like the relationship between an operating system and a CPU. The Model provides computing capability; Harness provides the runtime environment, resource scheduling, and behavior norms.

Why This Formula Matters

Agent = Model + Harness — the value of this formula lies in it helping you establish a clear thinking framework.

When you encounter an Agent product, you can use this formula to deconstruct it: what Model does it use? Is the reasoning capability strong enough? Is its Harness well-designed? Are the tools sufficient? Is memory reliable? Are the safety mechanisms robust?

Many Agent products that look flashy are actually just stacking a bunch of flashy Harness components on top of a Model, but the Model’s own reasoning capability can’t support it. It’s like putting an airplane’s steering wheel and dashboard on a tricycle — looks professional, There’s a point that’s easily overlooked: the stronger the Model, the simpler the Harness can be.

The stronger the Model, the simpler the Harness needed. A Model with extremely strong reasoning capability might only need a few tools to complete tasks, because its “thinking” capability compensates for the “doing” deficiency. Conversely, if the Model’s capability is average, more complex Harness is needed to compensate — more tools, more refined orchestration logic, stricter result verification.

Practical case comparisons:

The Coinbase case is quite convincing. They used Claude to build a customer service Agent, giving the Agent only a few core tools (query account information, query transaction records, search knowledge base, create tickets), but Claude’s powerful reasoning capability allowed it to flexibly combine these tools to solve complex problems. Result: processing thousands of messages per hour, 99.99% availability, 35-50 internal AI applications derived from this.

The Tines case demonstrates the delicacy of Harness design. Their security operations Agent uses Claude to dynamically process workflow logic, compressing complex multi-step security operations into single Agent operations, improving time value by 100x. The key isn’t more tools, but the orchestration logic letting the Agent “smartly” use tools.

Anthropic, in their widely cited report “Building Effective Agents,” specifically emphasized one principle: start with the simplest solution.

What does this mean? Many people want to build an all-powerful Agent right from the start — giving it dozens of tools, complex memory systems, multi-layered safety mechanisms. But many scenarios simply don’t need that much complexity. A powerful Model plus a few carefully designed tools is often more effective than a mediocre Model plus fifty tools.

The report also has an important distinction: Workflow and Agent are two different things.

Workflow uses pre-defined code paths to orchestrate LLM calls. Developers design the process in advance — first call the model to do A, then call the model to do B based on results, then pass B’s results to C — the entire process is fixed and predictable. This is like an assembly line: what each step does and how it does it are all pre-designed.

An Agent lets the LLM dynamically guide its own process. The model itself decides what to do next, which tools to use, and when to stop. This is more like an employee with autonomy: you give them a goal, and they use their own judgment to complete it.

The key distinction lies in control. In Workflow, control is in the code’s hands; in Agent, control is in the model’s hands.

So when to use Workflow, and when to use Agent?

Anthropic’s suggestion is: use the simplest method first. If a pure Model (without any Harness components) can complete the task, then don’t add Harness. If adding one tool can handle it, don’t add ten. If a fixed Workflow can meet the requirements, don’t make it a higher-autonomy Agent. Only when simple solutions truly can’t meet the requirements should you gradually increase complexity.

This principle runs through the entire Agent design philosophy.

2.2 The ReAct Loop: Reasoning → Action → Observation

Now you know Agent = Model + Harness. But you might be curious: how exactly does Harness drive the Agent to “do things”?

The answer is: through a loop called ReAct.

ReAct is the most core execution mode of Agents, fully named Reasoning + Acting. Understanding this loop, you understand the Agent’s “thinking pattern.”

A Real Example

Suppose you ask an Agent to help you do this: “Help me check Tesla’s stock price trend over the past week, analyze the reasons, and then write a brief report.”

How would a human analyst do this?

Step 1, think: I need to first check stock price data. I can use a search engine or financial data website.

Step 2, act: Open a browser, search Tesla stock price.

Step 3, observe: Saw the data, past week from $245 dropped to $231, with a significant drop on Wednesday.

Step 4, think: Wednesday’s drop might be related to some event? I need to check the news of that day.

Step 5, act: Search “Tesla May 14 news.”

Step 6, observe: Discovered Tesla released earnings that day, revenue was below expectations.

Step 7, think: Now I have sufficient information, I can write the brief.

Step 8, act: Write the brief.

You see, the process of human work is: think → act → observe → think → act → observe… constantly looping. ReAct formalizes this process.

What the Agent does is almost exactly the same as what this human analyst does. The only difference is that each step of the Agent is faster — searching only takes seconds, organizing information only takes seconds, writing the brief only takes tens of seconds. But the thinking pattern is the same.

Internal Mechanism of the Three-Step Loop

The ReAct loop consists of three steps:

Step 1: Reasoning

The Agent first “thinks.” It analyzes the current situation, decides what to do next, selects which tool to use. This step is entirely completed by the Model (Large Language Model).

The Agent generates a segment of “inner monologue,” like: “I now have the stock price data, but I still need to understand the reason for the drop, so I should search for related news.” This inner monologue is not for human eyes — it’s the Agent’s reasoning process, and will serve as the basis for the next action.

The quality of this reasoning process directly determines the Agent’s performance. If the reasoning capability is strong, the Agent will make correct judgments — selecting the right tool, setting the right parameters, formulating the right strategy. If the reasoning capability is weak, the Agent might make wrong choices — using the wrong tool, searching for irrelevant keywords, omitting important information.

Step 2: Acting

The Agent “acts.” It calls a tool — such as a search engine, code executor, API — to acquire information or execute an operation. This step is completed by Harness, because Harness is responsible for managing tools and the execution environment.

There’s an important detail in the action step: parameter generation. The Agent doesn’t just decide “I want to search,” it also needs to decide “what keyword to search for.” This parameter is generated by the Model, then passed to the tool managed by Harness. After the tool finishes executing, it returns a result.

So you see, the action step is actually a collaboration between Model and Harness: the Model is responsible for decision-making and parameter generation; Harness is responsible for tool management and execution.

Step 3: Observation

The Agent “looks at the result.” What did the tool return? What was searched? What did the code output? The Agent takes the result and uses it as input for the next round of reasoning. Then it returns to step 1, continuing to think based on new information.

The result of the observation step typically has two situations: one is positive, where the tool returned useful information, and the Agent can continue to push forward based on this information. The other is negative, where the tool returned an error, empty result, or unexpected information, and the Agent needs to adjust its strategy.

Reasoning → Action → Observation → Reasoning → Action → Observation… this loop repeats continuously until the Agent believes the task is completed, or encounters a problem it can’t solve on its own and needs to ask a human for help.

Why ReAct Works

The brilliance of ReAct lies in how it tightly interweaves “thinking” and “acting.”

Before ReAct emerged, there were two mainstream methods:

One was “pure thinking.” Give the model a large task, let it figure out all the steps at once, then output the result in one breath. The problem is: the model’s “context window” is limited; it’s impossible for it to reason out a complete answer without intermediate results. It’s like asking you to write a complete industry analysis report without drafts or reference materials — almost impossible. Moreover, the pure thinking method easily produces “hallucinations” — the model has no real data as basis, and can only “fabricate” to fill information gaps.

The other was “pure acting.” Write a fixed program that calls this API first, then calls that API, and pieces the results together. The problem is: the program is dead; it won’t adjust strategy based on intermediate results. If there’s an anomaly in the stock price data, the program won’t “realize” this anomaly and go look for the cause. If the search results mix in irrelevant information, the program won’t “realize” it needs to change keywords and re-search.

ReAct combines both. Each step thinks first, then acts, then thinks after finishing. This allows the Agent to both utilize the model’s reasoning capability for flexible decision-making, and acquire real-world feedback through actual actions. This is like a person walking in a maze — not planning every step in advance (because the maze might change at any time), nor walking blindly (because that way you’ll never get out), but walking one step, looking at the situation, then adjusting direction based on the new situation seen at each step.

Limitations of ReAct

But ReAct isn’t omnipotent. It has several obvious limitations.

First, cost and speed issues. Each step requires calling the large language model once, and model calls cost money. A 10-step ReAct loop might call the model 10 times, search engine 5 times, code executor 3 times. If one model call costs $0.05, one search costs $0.01, the total cost of one task might be between $0.5-1. This doesn’t sound like much, Second, error accumulation. If the success rate of each step is 95%, the overall success rate after 10 steps is only about 60%. This is because errors at each step affect the reasoning of subsequent steps — if the second step searches for wrong information, all subsequent analysis is built on the wrong foundation. The more steps, the more serious the cumulative error.

Third, context window limitations. As the loop progresses, the Agent needs to remember more and more intermediate results and tool return information. The context window is limited; when there’s too much information, either early information gets truncated (causing “forgetting”), or information gets compressed (causing loss of details).

The industry has concluded a rule: well-done Agents are all short flows. Empirical data shows that Agents should have human intervention or checkpoints within 10 steps. Beyond this number of steps, error probability and costs both increase sharply.

Cost analysis of the ReAct loop (using GPT-5.5 as example):

As you can see, after 10 steps the success rate drops below 60%, while costs double. This is why production-grade Agents typically adopt a “divide and conquer” strategy: break large tasks into multiple small tasks, each completed within 5 steps, with human checkpoints added in between.

Anthropic also clearly stated in “Building Effective Agents”: don’t use an Agent for the sake of using an Agent. In many scenarios, a pre-defined workflow — that is, a fixed program flow, plus model calls at a few key nodes — is more reliable, cheaper, and more controllable than a fully autonomous Agent.

ReAct is a powerful foundational pattern, but in practical applications, it often needs to be combined with other design patterns. For example, you can use the Plan-and-Execute pattern to first formulate an overall plan, then use ReAct loops within each subtask. Or, you can use the Reflexion pattern to perform self-checking and correction after the ReAct loop finishes.

This is what the next section will cover.

2.3 From ChatBot to Agent: Three-Year Evolution Path

To truly understand Agents, the best way is to look at how they came to be.

Over the past three years, the form of AI products has undergone a clear evolution path: Copilot → Agent → Digital Labor. Each step represents a qualitative change in capability, not just quantitative.

Stage 1: Copilot (2023-2024)

In early 2023, ChatGPT ignited the global AI boom. Back then, what everyone talked about most was “AI assistant” or “copilot.”

The core pattern of Copilot is: human leads, AI assists.

You’re writing code and get stuck halfway, Copilot helps you complete the second half. You’re writing an email and don’t know how to phrase it, Copilot helps you polish it. You’re making a PPT and don’t know how to organize the content, Copilot helps you outline it.

In Copilot mode, AI doesn’t take initiative. It won’t go search for information on its own, won’t call APIs on its own, won’t make decisions on its own. It just provides a suggestion, a draft, a reference when you need it.

This is like an intern sitting next to you. You ask them questions, they answer. You say “help me write this,” they write it and show it to you. But they won’t proactively do things on their own, won’t arrange work priorities on their own, won’t coordinate with others on their own.

The product form of Copilot is also very intuitive: a dialog box, you type text, AI outputs text. The interaction is linear, single-turn, passive.

The iconic products of this stage are GitHub Copilot (code completion), ChatGPT (conversation assistant), Notion AI (writing assistance). They all share one characteristic: waiting for the user to initiate a request, then giving a response. Without user input, they do nothing.

The main technical challenge of this stage is whether the model itself is smart — can it give high-quality answers. All innovation was concentrated at the Model level: larger parameter counts, better training data, stronger reasoning capabilities. Harness barely existed at this stage — the most complex “Harness” might just be a conversation history management feature.

Stage 2: Agent (2025-2026)

From late 2024 to early 2025, the industry began shifting from Copilot to Agent.

The Agent’s pattern became: AI leads, human supervises.

What’s the difference?

Copilot is “you tell it what to do, it does it.” Agent is “you tell it the goal, it plans how to do it itself.”

Here’s an example. You say to Copilot: “help me analyze competing products,” it will give you an analysis framework or a template, but the specific things are still for you to do yourself — search for competitor information, collect data, organize comparison tables, write analysis text. You say the same thing to an Agent, and it will go search for competitor information, collect data, organize comparison tables, analyze strengths and weaknesses, and finally hand the report to you. You might only need to wait a few minutes, and a complete competitor analysis report appears in front of you.

From “advisor” to “executor,” this is a fundamental change.

To enable AI to “execute” rather than just “suggest,” Agents need capabilities that Copilots don’t have:

• Using tools: Can call search engines, databases, APIs, code executors
• Planning capability: Can break down a large goal into multiple sub-steps
• Memory capability: Can remember previous conversations and intermediate results
• Autonomous decision-making: Can adjust strategies based on intermediate results
• Error recovery: Can try a different approach when encountering failure

These capabilities combined together are what we earlier called Harness.

This stage has five major design patterns. Understanding them helps you understand the technical panorama of Agents:

ReAct (Reasoning + Acting): Discussed in detail in the previous section. The loop of reasoning → action → observation. Suitable for tasks requiring real-time information and flexible adaptation. Its advantage is flexibility — the Agent can dynamically adjust strategies based on each step’s results. The disadvantage is efficiency — each step requires calling the model, slow speed, high cost.

Plan-and-Execute (Planning + Execution): The Agent first formulates a complete plan, then executes it step by step. Suitable for complex tasks, because the planning stage can consider the global picture all at once, avoiding the short-sightedness brought by ReAct’s “one step at a time” approach. Imagine renovating a house — you don’t design as you go; you draw the design first, then construct according to the drawing. Plan-and-Execute is this logic. Its advantage is global vision and execution efficiency. The disadvantage is lack of flexibility — if unexpected situations arise during execution, re-planning might be needed.

Reflexion (Reflection): After completing a task, the Agent will self-reflect — what did I do right? What did I do wrong? How to improve next time? This mimics human learning, improving capability through “review.” An Agent using Reflexion will check its own code after writing it; if it finds logic errors, it will correct them itself, rather than directly handing you code with bugs. This is particularly useful in scenarios requiring quality control like programming and writing.

Multi-Agent: Multiple Agents collaborate to complete tasks. One Agent is responsible for searching, one for analysis, one for writing, one for review. Like a team, each member has their own expertise. The advantage of Multi-Agent systems is professionalism and efficiency brought by division of labor. Each Agent can focus on what it’s good at, without needing one Agent to do everything. The disadvantage is coordination cost — Agents need to communicate, synchronize, resolve conflicts, all of which require additional mechanisms to manage.

Tool Use: Agents call external tools as needed. This is the most basic and most frequently used capability; all other patterns depend on it. An Agent without Tool Use capability is like a person locked in a room — can think, These five patterns are not mutually exclusive. An actual Agent product often combines multiple patterns. For example, an Agent doing deep research might use Plan-and-Execute for overall planning, use ReAct loops for each subtask’s execution, and finally use Reflexion to check report quality.

Stage 3: Digital Labor (2026+)

The third stage, which is happening but hasn’t fully unfolded, is the evolution of Agents into “digital labor.”

The characteristic of this stage is: AI doesn’t just execute tasks, but assumes roles.

What does this mean?

In the Agent stage, you give it a specific task, and it goes to complete it. Tasks are discrete, one-time. After completing one, it waits for the next instruction. In the digital labor stage, AI occupies a continuous role — such as “customer service specialist,” “data analyst,” “market researcher” — it continuously works in this role, with clear responsibility scope, work processes, and evaluation criteria.

It’s not a tool you occasionally use, but a “colleague.” You don’t need to give it specific instructions each time; it knows what it should do, when to do it, how to do it. It has its own “work schedule” — check emails in the morning, process customer service tickets in the morning, analyze data in the afternoon, generate reports in the evening. It can switch between multiple tasks, can proactively ask for instructions when encountering uncertain situations, can proactively report after completing work.

Imagine your company has a “digital market researcher.” It automatically browses industry news every morning, organizing developments that might affect your company; automatically generates competitor analysis reports every week; automatically generates market trend insights every month. You don’t need to give it instructions every day — it knows its responsibilities and continuously executes.

The technical difficulty of this stage is much greater than the previous two. Agents need capabilities like long-term memory, continuous learning, cross-task coordination, interpersonal communication. Requirements for security, controllability, and reliability also surge — you can’t let a “digital colleague” make unauthorized decisions, can’t let it say inappropriate things when communicating with customers, can’t let it make irrecoverable errors when processing financial data.

The industry has a sobering statistic: 88% of enterprise Agent projects are stuck in production environments and can’t truly go live.

Why? Because there’s a huge gap between Demo and production environment.

Agents in Demo environments face carefully prepared inputs, simple tasks, and error-tolerant audiences. You give it a clear instruction, it executes a few steps, gives a good result. The audience is happy, feels that AI can really do things.

Agents in production environments face ever-changing user inputs (“half of what users say are typos, half are omitted sentences”), complex edge cases (“this user’s data format is different from the standard format”), zero-tolerance errors (“you sent a grammatically incorrect email to a customer? Unacceptable.”).

Moreover, production environments also have a series of engineering issues like cost, latency, concurrency, monitoring, auditing. A Demo-level Agent might spend 30 seconds and $1 per task execution. But if your business needs to execute 10,000 such tasks per day, the cost is $10,000 per day, equivalent to 300,000 seconds (nearly 3.5 days of serial execution time). You need to consider parallel execution, caching, degradation strategies, cost optimization — these are all not Agent “intelligence” issues, but engineering issues.

From Copilot to Agent to digital labor, this is not a smooth upward curve, but a step-by-step ladder. Each step up, technical difficulty and engineering complexity multiply.

2.4 Cognitive Architecture: Function Calling and the Four Layers

Chapter 1 covered model limits; this section shows how the Harness turns the model into an executable Agent system (complements the ReAct loop in 2.2, with emphasis on interfaces and layering).

From String Parsing to Native Function Calling

Early stacks often used string parsing on model output — fragile and error-prone. Native Function Calling (2024-2026) returns structured JSON via APIs, with higher parse success, type checks, parallel calls, and converging standards (OpenAI Functions, MCP, Anthropic Tools).

Function Calling is a type-safe bridge between the model and the outside world: the model picks tools; the interface layer validates and runs them — upper Agent logic can stay stable when you swap models.

Four-Layer Agent Architecture

Simple tasks (weather) often bottleneck on interface/execution; complex tasks (industry reports) on cognition. 2026 surveys also map ~17 reasoning paradigms (ReAct, CoT, ToT, Reflexion, etc.) — see 2.2 and later chapters.

2.5 What Agents Can Do, What They Can’t

Having discussed the technical nature and evolution path of Agents, let’s finally discuss the most practical question: what exactly can Agents do? What can’t they do?

This question is practical, because currently market expectations for Agents are a bit inflated. Many people feel Agents can do anything, or will soon be able to do anything. Building products with such expectations will likely lead to wrong decisions.

Conversely, some people, after seeing a few failures of Agents, assert that “Agents are just hype.” This view is also inaccurate.

Let me evaluate directly.

What Agents Are Good At

What Agents are best at are tasks that satisfy these three conditions:

First, having a clear goal. Agents need to clearly know what “success” looks like. “Help me write a competitor analysis report” — the goal is clear, the Agent knows what to output. “Help me understand the market” — the goal is vague, the Agent doesn’t know to what extent “understanding” counts as “understood.” The clearer the goal, the better the Agent performs.

This is not a problem unique to Agents. You ask a human employee “help me understand the market,” he also doesn’t know to what extent he should go. But humans can ask: “What aspect of understanding do you want? Depth or breadth? For what decision?” Agents’ current questioning capability is still far inferior to humans, so they rely more on the clarity of goals.

Second, can be decomposed into steps. Agents aren’t geniuses who figure out answers in one shot, but “workers” who “break large tasks into small steps, execute step by step.” If a task can be broken into a process like search → organize → analyze → output, Agents can usually do quite well.

Third, results of each step can be verified. After calling a search tool, the Agent can judge whether the search results are useful. After writing a piece of code, it can run it to see if there are errors. Results of each step can be checked, which is the foundation of Agent self-correction. If a certain step’s result is wrong, the Agent can go back to the reasoning stage, adjust strategy and retry.

Typical tasks that meet these three conditions include:

• Information collection and organization: Collect information from multiple sources, compile into a structured report. For example, “help me collect major news from the AI industry in the past week.” This task has a clear goal (collect news), can be decomposed (search → filter → organize → output), and results are verifiable (whether each news item is relevant is clear at a glance).

• Code generation and debugging: Write code, run code, look at errors, fix — this process is naturally suitable for the ReAct loop. The Agent writes a piece of code, runs it, if there’s an error, analyzes the error message, modifies the code, then runs it again. This “write → run → fix” loop is one of the areas where Agents perform most impressively.

• Document processing: Read PDFs, extract table data, do format conversion. Tasks of this type have clear rules, clear steps, and Agents rarely make mistakes when executing them.

• Data analysis: Query databases, calculate metrics, generate charts. Give an Agent a database access permission and a set of analysis requirements, and it can usually automatically generate SQL queries, execute calculations, output visualization results.

• Content creation: Write articles based on materials, do translation, modify formatting. Note that this refers to “material-based” creation — given raw materials, the Agent is responsible for organization and expression. Creating in-depth original content from scratch is not yet the Agent’s strong suit.

• Process automation: Process emails according to rules, fill out forms, update systems. The process for tasks of this type is fixed, and Agents can execute them efficiently in batches.

The common characteristic of these tasks is: clear goals, decomposable processes, verifiable results.

What Agents Can’t Do

Conversely, Agents perform poorly in the following scenarios:

First, open-ended exploration. “Help me find a business opportunity” — tasks of this type have no clear success criteria, and the Agent doesn’t know when it counts as “found it.” It might give you a list of directions, but each one only scratches the surface, lacking true insight. Real business insight requires deep industry understanding, intuitive judgment of markets, trade-off analysis of opportunity costs — these are all currently the model’s weak points.

Second, requiring deep domain knowledge. The Agent’s reasoning capability comes from the model. If the model itself doesn’t have sufficiently deep understanding of a certain professional domain (such as law, medicine, finance), then no matter how good the Harness is, it can’t compensate for this deficiency. You can’t expect an Agent that doesn’t understand medicine to do disease diagnosis, can’t expect an Agent that doesn’t understand Chinese tax law to do tax planning. The model’s domain knowledge has clear boundaries; beyond these boundaries, the Agent’s output becomes unreliable.

Third, involving physical operations in the real world. Agents can help you write an email, but they can’t help you bring a cup of coffee. They can operate at high speed in the virtual world — searching for information, generating code, analyzing data — but the physical world is a completely different challenge. This is the so-called “embodied intelligence” problem, which is far from solved. The Agent’s “hands” are API calls, not mechanical arms.

Fourth, requiring long-term consistent roles. It’s easy to have an Agent execute a task, but having it continuously play a role, maintain consistent behavior patterns and decision criteria, is very difficult. The limitation of the context window means Agents will “forget” previous decisions after conversations get too long. It might say “this feature shouldn’t be added” today, and might say “this feature should be added” in a new context tomorrow. Humans can maintain long-term consistent values and decision criteria; Agents currently can’t do this. Long-term memory technology is still rapidly developing, but there’s still distance from truly reliable “continuous roles.”

Fifth, high-risk decisions. Decisions involving money, safety, legal liability shouldn’t be fully entrusted to Agents. Agents can provide suggestions, organize information, simulate scenarios, calculate probabilities, but the final decision-making power must remain in human hands. The reason is simple: Agents make mistakes, and the way they make mistakes might be different from humans — not because of carelessness, but because of fundamental misjudgment of situations. When an experienced human decision-maker makes a mistake, you know where they went wrong, and can review and improve. When an Agent makes a mistake, its “reasoning process” might be opaque, and you can hardly diagnose the root cause of the error.

Real Data on Success Rates

Let’s look directly at the data.

In the coding domain, SWE-bench (a standardized code problem-solving benchmark) shows that the best Agent systems can solve about 50-60% of real GitHub problems. This means that in relatively standardized programming tasks, Agents have reached the capability of mid-level engineers — but for the other 40-50% of problems, they remain at a loss.

In the information retrieval and analysis domain, Agents typically perform better than pure models, because they can actually search the internet for real-time information, rather than relying on static knowledge from model training. But the quality of search results varies, and Agents might be misled by low-quality information.

In complex multi-step tasks, success rate drops sharply as the number of steps increases. If the success rate of each step is 95%, then the overall success rate after 10 steps is only about 60% (0.95^10 ≈ 0.60). After 20 steps, this number drops to 36%. If you require an Agent to complete a 50-step task, with 95% success rate per step, the overall success rate is less than 8%.

So “good Agents are all short flows” isn’t a preference, it’s determined by math.

A Practical Judgment Framework

Facing a specific scenario, you can use the following five questions to judge whether an Agent is suitable:

1. Can this task be described in a process within 10 steps?

If not, Agent might not be the best choice. For tasks exceeding 10 steps, success rate and cost both deteriorate sharply.

2. Can the results of each step be checked or verified?

If not, the Agent can’t self-correct, and errors accumulate. The best Agent scenarios are those where each step has clear “right/wrong” feedback.

3. Is the task’s fault tolerance high?

If making one mistake is unacceptable (such as sending an email that shouldn’t be sent), Agents currently aren’t reliable enough. If errors can be corrected (such as writing a wrong piece of code, which can be fixed), Agents are more suitable.

4. Does the mainstream model possess the domain knowledge required by the task?

If very professional knowledge is needed (such as legal clauses of specific countries), fine-tuning or RAG (Retrieval-Augmented Generation) might be needed to supplement the model’s knowledge.

5. Is the cost of human intervention high?

If every step requires human approval, the Agent’s automation advantage disappears. The ideal situation is that humans only intervene at key nodes, and the Agent handles most steps on its own.

If the answers to all five questions are affirmative, then Agent is a very good choice. If more than three answers are negative, you need to seriously consider whether it’s worth investing.

Final Words

Agents aren’t omnipotent, but they also aren’t an empty concept. They are a real, rapidly evolving technological paradigm.

Understanding the nature of Agents — Model + Harness, understanding how they operate — the ReAct loop, understanding their evolution path — from Copilot to digital labor, understanding their capability boundaries — what they’re good at, what they can’t do — these four things combined together constitute the cognitive foundation for judging all Agent products.

The next chapter will dive into the specific design of Harness, looking at how those six components work together. But no matter how complex the technical details later become, remembering this formula is enough: Agent = Model + Harness.

The success or failure of all Agent products can be traced to the two variables of this formula.