What Is an AI Agent?
An AI agent decides its own steps, uses tools to act and reviews the results until it finishes. How it works and how it differs from a chatbot or a workflow.
What does it mean that it “decides” its steps?
A traditional chatbot answers a question with text and waits for the next one. An agent receives a task such as “fix the failing tests in the authentication module” and works out the order by itself: first it runs the tests, then it reads the files that fail, then it edits the code and finally runs the tests again to check.
The model makes that decision at each step, based on what it has already seen. That is the central difference. In a fixed flow, a person writes the steps in code. In an agent, the model chooses the steps within the limits you set.
In its guide Building effective agents, Anthropic separates two kinds of agentic systems. Workflows are “systems where LLMs and tools are orchestrated through predefined code paths”. Agents are “systems where LLMs dynamically direct their own processes and tool usage”. An agent has more freedom and, therefore, more risk.
| Chatbot | Workflow | Agent | |
|---|---|---|---|
| Who decides the steps | Nobody: it answers and waits | A person, written in code | The model, on every pass |
| Can use tools | Not necessarily | Yes, in the fixed order | Yes, when the model asks |
| How much it varies between runs | Little | Little | A lot |
| Example | Answering a customer’s question | Summarizing an email and saving it to a spreadsheet, always the same way | Fixing a bug by exploring the code |
How does it work inside?
Almost all current agents follow the same cycle. The Claude Agent SDK documentation describes it in five steps: Claude receives the prompt, evaluates the state and decides whether to answer with text or request one or more tools, the SDK runs the tools, the results go back to Claude and the cycle repeats until Claude answers without requesting more tools.
Each full pass through that cycle is a turn. A simple question may take one or two turns. A complex task, such as refactoring a module and updating its tests, can chain dozens of tool calls. That cycle has its own article, on the agent loop.
Tools are what make action possible. According to the Claude API documentation, the model determines when to call a tool based on the user’s request and the tool’s description. With “client” tools, your application runs the call and returns the result; with “server” tools (such as web search), Anthropic runs them. For more detail, see tool use.
Why does it matter to a designer?
Because it changes what kind of interface the product needs. An agent does not only show information: it does things on the person’s behalf. That forces you to design pieces that were not needed before:
- How progress looks while the agent works (long task progress).
- Which actions need approval before they run (action approval).
- How a change the agent already made gets undone (undoing agent actions).
- How the available tools and their permissions are shown (permissions UX).
The levels of autonomy of an agent define how many of those decisions go through a person. If you are unsure whether you need an agent, an assistant or a copilot, see agent vs. assistant vs. copilot.
When is an agent NOT the right choice?
Anthropic recommends finding the simplest solution possible and adding complexity only when needed. According to the same guide, agentic systems often trade latency and cost for better task performance, and their autonomy means higher costs and the potential for compounding errors. If the task has known steps, a fixed workflow is cheaper, more predictable and easier to test.
An agent makes sense when:
- The steps cannot be predicted in advance.
- The task requires exploring, reading results and adjusting the plan.
- The cost of an error is low or there is a human review step.
It does not make sense when the result must be exact and repeatable, or when an irreversible action depends on a decision the model cannot verify.
Example
Illustrative example: a person asks an agent to check whether every button in a payment flow has an error state. The agent lists the component files, opens four of them, finds that the “retry” button has no disabled state, proposes the change and asks for confirmation before editing. The person approves, the agent fixes it and runs the review again. The model decided every intermediate step; the approval came from the person.
What happens when the agent fails halfway through?
An agent can make a mistake at any step, and the cycle does not stop by itself when something goes wrong. If a tool fails or is rejected, the message returns to the model as a result, and the model usually tries another route or reports that it could not continue. It may also insist on the same route or treat an incomplete result as good. That is why it pays to set limits in the design: the Claude SDK lets you cap, for example, the number of turns or the maximum spend of a session.
Before you give an agent access to actions, define what it should do on an error: retry once, stop and report, or ask for help. Designing that moment is part of the product work. An interface that only shows the final result hides the intermediate errors, and the person discovers the problem after something they did not expect has already changed.
What can you do tomorrow?
Pick a task you do every day and write down on paper which steps you follow and which ones depend on your judgment. The ones that depend on your judgment are candidates for an agent with human control; the rest can be solved with a script or a fixed flow. Start with one read-only task, with no write permissions, and review what it returns for a week before you grant more access.
Common mistakes
- Calling any chatbot with buttons an agent. The difference is that it can act and repeat steps.
- Granting broad permissions from the start instead of starting with reading and expanding later.
- Trusting that the agent finished correctly because it says it did. You have to verify the result.
- Using an agent for a task with fixed steps that a script handles better.
- Setting no cap on turns or spend, and letting an open-ended task run without limit.