Building Agents · Anthropic · 2026

How We Build Effective Agents

An interactive walkthrough of Barry Zhang's AI Engineer Summit talk. Three ideas anchor it: don't build agents for everything, keep it simple, and think like your agent — plus the spectrum that runs from simple features to workflows to fully autonomous agents, and the open questions coming next.

0 / 6 sections
1
The Agentic Spectrum: Features → Workflows → Agents
More agency makes systems more useful — and more expensive, slower, and riskier

Most of us started with simple features — summarization, classification, extraction — single model calls that felt like magic a few years ago and are now table stakes. As products matured, one call wasn't enough, so we started orchestrating multiple model calls in predefined control flows. Barry calls these workflows, and considers them the beginning of agentic systems.

Now models are capable enough that agents can decide their own trajectory and operate almost independently from environment feedback. What the next phase looks like — more general single agents, or multi-agent collaboration — is still too early to name.

The through-line: the more agency you hand a system, the more useful and capable it becomes — but cost, latency, and the consequences of errors all rise with it.
Demo — click a stage to see its trade-off
Agency & capability
Cost · latency · consequence of error
Pick a stage above. Notice both bars climb together as you move right.
As you give a system more agency along this spectrum, what happens?
2
Workflows vs Agents: Who Decides the Path?
A workflow follows a path you defined; an agent chooses its own from feedback

The distinction is precise. A workflow runs model calls through a predefined control flow — you drew the path, it always follows it. An agent runs the model in a loop, deciding its own next step based on what the environment gives back. Same building blocks; who's steering is different.

Demo — a predefined path; it runs the same way every time
You define every node up front. Predictable cost & latency, maximum control.
Demo — the model loops, choosing its next tool from feedback
The agent picks each step itself and stops when the goal is met. Flexible in ambiguous spaces — at higher, less predictable cost.
Workflowcontrol + predictable cost Agentautonomy + ambiguity handling
What actually distinguishes an agent from a workflow?
3
Don't Build Agents for Everything
Run the four-part checklist before you reach for autonomy

Agents scale complex and valuable tasks — they're not a drop-in upgrade for every use case. Barry's checklist has four questions. Toggle each one below and watch the recommendation change. If you can't check the first box, an explicit workflow is almost always the better, cheaper, more controllable choice.

Demo — toggle each criterion; the verdict updates live
Toggle the criteria above
The recommendation appears here.
Why coding is a great agent use case: going from design doc to PR is genuinely ambiguous and complex, good code is high-value, the critical capabilities (write, debug, recover) are already strong, and the output is easily verifiable through unit tests and CI — so errors are cheap to discover.
Your task's whole decision tree is easy to map, and each error is high-stakes and hard to detect. What does the checklist suggest?
4
Keep It Simple: Models Using Tools in a Loop
Environment + tools + system prompt, called in a loop. Optimize later.

To Anthropic, an agent is just a model using tools in a loop. Three components define it: the environment it operates in, the tools that let it act and get feedback, and the system prompt that sets goals, constraints, and ideal behavior. Then the model is called in a loop. That's it.

Wildly different agents — coding, search, computer use — look nothing alike on the surface but share almost the exact same backbone and code. The only real design decisions are which tools and what prompt. Any complexity up front kills iteration speed; optimizations (caching trajectories, parallelizing tool calls, surfacing progress for user trust) come after the behavior is right.

The three components

🌍
Environment
where it operates
The system the agent works in — a codebase, a browser, a search index. Largely fixed by your use case, not a design lever.
🔧
Tools
act & get feedback
The interface for taking action and receiving results. One of your two real design decisions: which tools to offer the agent.
📜
System Prompt
goals & constraints
Defines the goals, constraints, and ideal behavior. Your other real design decision: what you instruct the agent to do.
Demo — run the loop and watch the same backbone cycle
Model reasons → calls a tool → environment returns feedback → model reasons again. Repeat until done.
Same backbone, different surface: a coding agent, a search agent, and a computer-use agent share nearly identical code. Build the three components first; optimize once the behavior is down.
In this framing, what is an agent?
5
Think Like Your Agent
Put yourself in its context window — you'll see why it "made that mistake"

Builders design agents from their own perspective, then get confused when the agent errs. At each step the model is just running inference on a very limited context — everything it knows about the world lives in roughly 10–20k tokens. Limiting yourself to that context reveals whether it's actually sufficient and coherent.

Barry's exercise: be a computer-use agent. You get a static screenshot and a poorly written task. You reason, then attempt a click — but while inference and tool execution run, it's like closing your eyes for 3–5 seconds and using the computer in the dark. You open them to a new screenshot. Did it work? You just don't know. Try the blind cycle below, then give the agent the context it actually needed.

Demo — attempt a click "in the dark", then add the missing context
app.example.com/checkout
Submit
🖱️
👁️‍🗨️
Eyes closed — running inference + tool execution…
  • Screen resolution — so it knows where to click
  • Recommended actions — so it doesn't wander
  • Limitations / guardrails — so it avoids unnecessary exploration
Attempt a click blind first. Then add context and try again — the difference is the point.
Bonus move: we build systems that speak our language, so ask Claude to understand Claude. Paste in your system prompt ("is any of this ambiguous?"), a tool description ("do you know how to use this?"), or a whole trajectory ("why did you decide this — what would help you decide better?").
Why does Barry recommend putting yourself inside the agent's context window?
6
What's Next: Three Open Questions
Budget-awareness · self-evolving tools · multi-agent collaboration

Barry closes with the open problems on his mind — the things AI engineers still need to figure out together. Click each to see the idea and the question it leaves open.

Demo — click an open question
Click a card to explore the open question.
Three takeaways to keep: don't build agents for everything · if you do, keep it as simple as possible for as long as possible · as you iterate, think like your agent and help it do its job.
Which is one of the open questions Barry highlights for the future?

🧠 You've got the model

Agency rises along a spectrum (features → workflows → agents) and so do cost, latency, and risk → so don't build agents for everything; run the four-part checklist → when you do, keep it simple: a model using tools in a loop → and as you iterate, think like your agent by living in its context window. Now go build.

Learning Reference · How We Build Effective Agents — Barry Zhang, Anthropic (AI Engineer Summit)

Get new posts in your inbox

No spam — just new posts and learning pages when they ship.

Share X LinkedIn Reddit Hacker News