Anthropic engineer Barry Zhang shared "How to build effective agents" at the AI ​​Engineer workshop. The most impressive point is: Don't build agents for everything . In other words, don't build agents that can do everything. That's what our big models should do.

Three key points to building an effective Agent:

1. 1. Choose your application scenario wisely. Not all tasks require an Agent.
2. 2. Once you find the right use case, keep the system simple for as long as possible
3. 3. During the iteration process, try to think from the perspective of the agent, understand its limitations and provide help

Barry is mainly responsible for Agentic Systems. The content of his speech is based on a blog post he co-authored with Eric. The following is a detailed summary of their core ideas and their thoughts on the evolution and future of Agent Systems.

Evolution of Agent Systems

1. 1.  Simple Features:  Initially simple tasks like summarization, classification, extraction, which seemed magical a few years ago, have now become fundamental.
2. 2.  Workflows:  As models and products mature, multiple model calls are orchestrated to form predefined control flows, sacrificing cost and latency for better performance. This is considered the predecessor of the Agent system.
3. 3.  Agent:  At the current stage, the model capabilities are stronger and domain-specific agents are beginning to appear. Unlike workflows, agents can autonomously determine the path of action based on environmental feedback and operate almost independently.
4. 4.  Future (guess):  It may be a more general single agent, or multi-agent collaboration. The trend is to give the system more autonomy, making it more powerful and useful, but also accompanied by higher costs, delays and consequences of errors.

01

Don't build agents for everything

Agents are mainly used to scale complex and valuable tasks. They are costly and have high latency and should not be used as a direct upgrade for all use cases. For tasks that can be clearly mapped to a decision tree, explicitly building a workflow is more cost-effective and controllable.

When building an Agent checklist:

1. 1.  Task Complexity: Agents are good at dealing with ambiguous problem spaces. If the decision path is clear, workflows should be preferred. 
2. 2.  Task value:  Agents’ exploratory behavior consumes a lot of tokens, and the value of the task must justify its cost. For scenarios with limited budgets (such as 10 cents per task) or high volume (such as customer service), workflows may be more appropriate.
3. 3.  Derisk Critical Capabilities:  It is necessary to ensure that there are no serious bottlenecks in the critical links of the Agent (such as coding Agent writing, debugging, and error recovery capabilities), otherwise it will significantly increase costs and delays. If there are bottlenecks, the scope of the task should be simplified.
4. 4.  Cost of Error & Error Discovery:  If errors are costly and difficult to find, it is difficult to trust the agent to act autonomously. This can be mitigated by limiting the scope (such as read-only permissions, increasing human intervention), but this will also limit its scalability.

Coding is a good use case for Agents because it is a complex task (from design documents to PR), has high value, existing models (such as Claude) perform well in many stages, and the results are easy to verify (unit testing, CI).

02

Keep it simple

The core structure of Agent: Model + Tools + Loop operates in an environment .

Three key components: 1.  Environment:  The system in which the Agent operates. 2.  Tools:  The interface through which the Agent takes actions and gets feedback. 3.  System Prompt:  Defines the Agent's goals, constraints, and ideal behavior.

Iterative approach: Prioritize building and iterating on these three basic components to get the highest ROI. Avoid over-complexity at the outset, which kills iteration velocity. Optimizations (e.g., caching traces, parallelizing tool calls, improving the user interface to enhance trust) should be done after the basic behavior is nailed down.

Consistency: Although different Agent applications (coding, searching, computer use) appear different in terms of product level, scope, and capabilities, they share almost the same simple backend architecture.

03

Think like your agents

Problem: Developers often have difficulty understanding why agents make seemingly unusual mistakes from their own perspective.

Solution: Put yourself in the "context window" of the agent. The agent's decision at each step is based on limited context information (such as 10k-20k tokens).

Empathy exercise: Try to complete the task from the agent's perspective and experience its limitations (e.g., only being able to see static screenshots and operating "with eyes closed" during reasoning and tool execution). This helps to discover what information the agent really needs (e.g., screen resolution, recommended actions, constraints) to avoid unnecessary exploration.

Leverage the model itself: You can directly ask the model (like Claude): Is the instruction ambiguous? Do you understand the tool description? Why did it make a certain decision? How can you help it make a better decision? This helps bridge the understanding gap between the developer and the agent.

04

Personal thoughts and future prospects

1. Budget-aware Agents: There is a need to better control the cost and latency of agents, define and enforce time, money, and token budgets, so that they can be more widely deployed in production environments.

2. Self-evolving Tools: Agents may be able to design and improve their own tools (meta-tools) to make them more general and adaptable to the needs of different use cases.

3.  Multi-agent Collaboration : We expect to see more multi-agent systems in production by the end of this year. Its advantages include parallelization, separation of concerns, and protection of the main agent context window. The key challenge is how agents communicate with each other, how to achieve asynchronous communication, and go beyond the current user-assistant turn-taking model.