Agents fit ambiguous, valuable tasks where the cost of exploration is justified and errors can be checked.
2
A simple agent has an environment, tools, and a system prompt, with the model operating in a loop.
3
Builders should inspect the limited context available to an agent and use that perspective to improve prompts, tools, and guardrails.
Summary
Barry Zhang presents three practical rules for building agents. Do not use agents for every problem. When a task has an explicit decision tree, a workflow is cheaper and easier to control. Agents fit ambiguous tasks with enough value to justify their token use, especially when errors are easy to discover, as with coding tasks tested through unit tests and CI. Once the use case is chosen, keep the system small: an environment, a set of tools, and a system prompt around a model loop. More advanced optimizations can follow. Zhang also asks builders to think from the agent's limited context window. A computer-use agent may see only a screenshot and a poor description, then lose visibility while a tool runs. Replaying the task from that perspective exposes missing information and weak tool interfaces. He closes with open questions about budgets, tools that improve themselves, and communication between multi-agent systems.
Agents should be reserved for ambiguous, valuable tasks
Zhang says agents are a way to scale complex and valuable tasks, so they should not replace workflows everywhere. Agents work well when the problem is ambiguous and the decision tree cannot be mapped out easily. If the whole tree is clear, explicit control flow gives better cost and control. The task also needs enough value to justify exploration. He gives a customer support example where a budget of around 10 cents per task allows only 30 to 50,000 tokens, making a workflow for common scenarios the sensible choice. Teams should also test critical capabilities and consider how costly and difficult errors will be to discover.
Coding is a strong agent use case because its work is complex and testable
Zhang uses coding to show how the checklist works. Moving from a design document to a pull request involves an ambiguous, complex process, and good code has substantial value to developers. Existing coding tools already handle many parts of that workflow. Coding also gives the agent an output that people can check with unit tests and continuous integration. That makes errors easier to discover than in tasks where the result is difficult to verify. If an agent has a bottleneck, such as weak debugging or poor recovery from its own errors, Zhang recommends reducing the scope and simplifying the task before adding more autonomy.
A basic agent consists of an environment, tools, and a system prompt
Zhang describes agents as models using tools in a loop. The environment is the system where the agent operates. Tools give it an interface for taking actions and receiving feedback. The system prompt defines the goal, constraints, and desired behavior. He says these three components should be built first because extra complexity slows iteration. Three agents built for different products and scopes can still share almost the same backbone and code. The main design choices are the tools exposed to the model and the instructions that tell it how to work in the environment.
Optimization should follow working behavior instead of preceding it
After the basic agent works, teams can optimize for the needs of each use case. Coding and computer-use agents may benefit from caching the trajectory to lower cost. Search agents can run many tool calls in parallel to lower latency. Agents also need to show their progress in a way that helps users trust the process. Zhang's order matters: first build the environment, tools, and prompt, then establish the behavior, and only afterward add optimizations. He says complexity added too early harms iteration speed, while improvements to the three basic components usually provide the highest return.
Builders need to reason from the agent's limited context
Zhang asks developers to put themselves inside the agent's context window when investigating mistakes. Although agent behavior can look sophisticated, each decision is based on a limited amount of context, which he describes as roughly 10 to 20k tokens. A computer-use agent may receive a static screenshot and a poorly written description, then issue a click without seeing what happens during tool execution. That is like closing your eyes for three to five seconds while using a computer. Repeating a full task from this perspective can reveal missing information, such as screen resolution, recommended actions, and limits on exploration.
Models can help inspect prompts, tools, and agent trajectories
Because these systems communicate through language, Zhang says builders can ask Claude to inspect the agent itself. A system prompt can be checked for ambiguous instructions. A tool description can be tested to see whether the agent understands how to use it, or whether it needs more or fewer parameters. Zhang also feeds an entire agent trajectory into Claude and asks why the agent made a particular decision and what could help it decide better. He does not present this as a replacement for understanding the context. It provides a closer view of how the agent interprets the task.
Production agents need explicit budgets and better tool adaptation
Zhang's open questions begin with budget awareness. Compared with workflows, agents give teams less control over cost and latency, so teams need ways to define and enforce limits for time, money, and tokens. He also expects tools to become more adaptable. Models already help improve tool descriptions, and Zhang imagines a meta-tool through which agents can design and improve the ergonomics of their own tools. That could let agents adopt tools for a particular use case rather than relying on a fixed interface. He treats both ideas as unfinished engineering problems rather than solved capabilities.
Multi-agent systems need communication beyond synchronous turns
Zhang expects more multi-agent collaboration in production and gives subagents one practical benefit: they protect the main agent's context window. Delegated agents can also run in parallel and divide responsibilities. The unresolved part is communication. Current systems are built around mostly synchronous user and assistant turns, which does not fit agents that need to coordinate independently. Zhang asks how systems can support asynchronous communication and richer roles that let agents recognize and communicate with one another. His prediction is paired with an implementation question about the protocols and system structure required to make that collaboration work.
"Everything that the model knows about the current state of the world is going to be explained in that 10 to 20k tokens."08:41
Who should watch
You are deciding whether a workflow or an autonomous agent fits a product task, and need a practical way to compare complexity, cost, and error risk.
You are building a coding, search, or computer-use agent and want a small starting architecture before adding optimizations.
Your agent makes decisions that seem irrational, and you need techniques for inspecting its context, tools, prompts, and trajectory.
