What an AI agent is
An AI agent is a language model that, instead of returning one answer, uses tools in a loop, sees the result of each step and picks the next step from that result. The difference from a chatbot is not intelligence; it is that a chatbot answers and an agent acts, and what it does may be wrong.
- Lesson 9 of 15
- Intermediate
- Free, no signup
What an agent is made of
The two sides above are the model and the tools, and what sits between them is the loop. The node below is the working memory: both sides read from it and write to it.
The model, which decides
It reads the goal and picks what the next step should be.
- nothing guarantees the decision was right
- each step re-reads the whole conversation
The tools, which act
Search, reading a file, calling an API, writing to a database.
- a real result comes back, not the model guess
- every tool you hand over is a permission you granted
both read from and write to the working memory
Working memory
The goal, the steps already taken and every tool result, all in one text.
- a wrong step stays here and the next step is built on it
Nothing in this drawing shows a human approval step, and that is correct: a human gate is not part of an agent structure and has to be added deliberately.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
The difference between an agent and a chatbot in one sentence
A chatbot has a turn: you ask, the model answers, done. An agent has no turn; it has a loop. You give it a goal, it decides which tool to call, it sees that tool result, and it picks the next move from that result, until the job is finished or it hits a stopping condition you set.
Anthropic states this in its own engineering write-up with an explicit architectural distinction that is more useful than any other definition: in a workflow, the model and the tools are orchestrated through code paths you wrote in advance. In an agent, the model directs its own process and tool usage. The same page carries a sentence that deflates the whole industry: agents are typically just models using tools in a loop based on feedback from the environment.
Once you have that, the question is this product really an agent or is agent just its label has an answer. If the path is fixed in advance and the same three steps always run, it is a workflow, however the marketing reads. And that is not an insult: for work whose shape is stable, a workflow is the better choice, because it is predictable.
The loop is the whole thing
The loop has four steps and it is always the same four, whether it is a commercial product or a hundred lines of your own code. The model reads the goal and decides what is needed. It calls a tool. The real result of that tool comes back, and this is what separates an agent from a text generator: the model no longer guesses whether the file exists, it sees the actual filesystem error. Then it decides again with that result in hand.
Two things fall out of this shape that the advertising leaves out. First, the loop needs a stopping condition, or one small mistake becomes twenty consecutive attempts; Anthropic recommends a maximum number of iterations precisely to keep control. Second, an agent cost grows with the number of steps, not the number of questions. A task that needs twelve tool calls re-reads the whole conversation twelve times.
And the point that matters most: errors compound. Anthropic uses that exact phrase, compounding errors. If each step is ninety percent right, a ten step task is not ninety percent right any more. So a good agent is not one that takes more steps; it is one that takes fewer steps and checks reality after each of them.
The four steps of the loop, and where it must stop
Step three is what separates an agent from a text generator: the real tool result comes back and the model stops guessing. Step four is where the cost climbs, because every turn re-reads all the text before it.
- 1 Reads the goal
- 2 Picks a tool
- 3 Sees the real result
- 4 Decides again
This cycle has no end of its own. The stopping condition is something you add, and without it one small mistake turns into repeated attempts.
What reliably works today and what is a demo
There is a pattern in the things that actually worked: agents do well where the environment can tell them they were wrong. Writing code is the cleanest example, because code either compiles or it does not and a test is either green or red. In that same write-up Anthropic names the two domains where its customers found the most value: customer support and coding. Both share one property, and that property is a clear success signal.
What stays a demo is work the environment gives no signal about. An agent that writes a content strategy never gets an error, because nothing in the world tells it that strategy was wrong. Its output always reads fluently and always looks acceptable, and you find out months later that it did not work. For that kind of work you do not need an agent; you need a person to decide and a model to make them faster.
Our position, which agrees with Anthropic own advice: before building an agent, ask yourself seriously whether one is needed at all. That page says plainly to find the simplest possible solution and add complexity only when needed, and adds that this might mean not building agentic systems at all. For a great many tasks, one good prompt with a few examples is enough.
Workflow or agent: neither is the permanent right answer
Workflow
- you wrote the path in code in advance
- predictable and testable
- when it breaks, it makes a noise
- for work whose shape is fixed
Agent
- the model directs its own path and tools
- for when the number of steps cannot be known in advance
- higher cost and latency, and compounding errors
- when it breaks, it is usually silent
This split comes from the Anthropic engineering write-up. The choice depends on the shape of the work, not on which one sounds more modern.
For a small business, two places this is real
The first place is research. You tell the agent to look into a specific question, open the sources, and hand back a summary with a link for every claim. Here, if it is wrong, the mistake is cheap and visible: you open the link and it is not there. That makes it the simplest place for a small team to start, and in practice it returns the most time, because the tedious half of research is gathering, not deciding.
The second place is triaging incoming messages. An email or ticket or contact form arrives, the model works out what it is about and how urgent it is, hands it to the right person and leaves a draft reply beside it. So far so good. The next sentence is where everything is decided: the agent does not send the draft. A person sends it.
That is not general caution, it is a rule, and its boundary is specific: wherever an agent output leaves the organisation, or moves money, or deletes something, a person stands between the agent and the result. Anthropic says the same thing in engineering language: extensive testing in sandboxed environments along with appropriate guardrails. And the reason is the compounding error from the previous section: a step that was wrong stays in the conversation and the next step is built on it.
Before you build an agent, write its stop card
Five things: if they are not on paper, what you have is an experiment rather than a tool. The goal, in one sentence, with a criterion that lets you say done or not done. The list of tools it may call, and just as importantly the list of things it must never do. The stopping condition, meaning a cap on steps and a cap on spend. The point where a person approves. And the last one, always forgotten: if the agent fails, who finds out.
That last item matters more than the rest, because an agent failure is usually silent. A script that errors writes a log; an agent that misunderstood at step three carries on confidently to the end and hands you a tidy output. So part of building an agent is forcing it to say what it decided on. Anthropic writes three principles and the second is exactly this: transparency, meaning show the agent planning steps explicitly. The first is simplicity and the third is carefully designing the interface between the agent and its tools.
And a real boundary that gets said too rarely: if you write those five items down and find the goal is met by three fixed steps, you have not arrived at an agent, you have arrived at a workflow. Build that and be glad. It is cheaper, it is faster, and when it breaks it makes a noise.
The fast path, with AI
Most agent projects do not fail because the code was bad; they fail because nobody ever wrote down what this agent counts as finished. The fast path is to make the model write the stop card from the section above before any code exists, and more importantly, to make it also propose the simplest possible version. Use a strong model here rather than a cheap one, because this is judgment work.
- Write the job you want automated the way it is done by hand today, in a few lines. No use of the word agent and no tool names.
- Run the recipe below. Insist on the version without an agent as well; that one clause is what separates this recipe from an idea generator.
- Put the two versions side by side and if the gap is small, build the simple one. Make that call on day one, not after two weeks of coding.
- Before running anything, fill in the who finds out column yourself. If the answer is nobody, you are not ready.
Copy-ready recipe
The job described below is done by hand today and I want to automate it. You are not here to be excited; you are here to be strict.
The job: {the few lines you wrote}
What must never happen: {for example, no email goes out without my approval}
First give me a table with these columns, one row per step:
step | is this step a fixed rule or a judgment | if it breaks, what does the breakage look like | who finds out
Then write two plans:
Plan A, the simplest thing that does this job, even if it contains no agent at all.
Plan B, the agent version, with: the goal in one sentence, the list of allowed tools, the list of forbidden actions, a cap on the number of steps, and the point where a person approves.
Finally, in three lines, say what Plan B gives that Plan A does not. If the honest answer is that it gives nothing more, write that and do not argue for it.Before you trust the output: The output of this recipe is a plan, not a decision. Check two things yourself: the if it breaks column, because models tend to write the obvious failures and skip the silent ones; and the list of allowed tools, because every tool left on that list is a real permission granted to a non-deterministic program. And if the model made a weak case for Plan A, that is probably not because Plan A is weak.
AI in this kind of work
To understand agents, the best move is to run one yourself somewhere its mistakes are cheap and then look at its steps rather than its output. Three questions that give instructive answers during that run: how many tool calls did you make, which step did you take on a guess, and if I stop you right now what is left half done. Our position is that an agentic tool which does not show its steps is unfit for serious work, not because it is worse, but because when it goes wrong you cannot see where.
Tools that actually help
- Claude Code A specimen from the one domain where agents genuinely work, because a programming environment keeps telling it what failed. It shows its steps, which for learning this lesson matters more than its output. Iran is not on the Anthropic supported-countries lists.
- ChatGPT Fine for running a simple research agent and seeing which sources it genuinely opened. The rule is the same: open every link it gives you, and if it gave none, no search happened. We make no claim about access from Iran, because the OpenAI supported-countries page returns an access error to this server.
- Gemini It handles Persian well and is a reasonable choice for testing classification and routing of Persian messages. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.
Where it backfires
The specific risk of agents is that they scale up capability and error together. A chatbot that is wrong hands you one wrong paragraph and you read it; an agent that is wrong applies that same mistake across its next five steps, which Anthropic calls compounding errors in its own write-up, recommending sandboxed testing and guardrails. The second risk is the tools: every tool you hand an agent is a real permission granted to a non-deterministic program, and once that tool can send email or delete a record, the model mistake no longer stays on paper. The third risk is data: an agent that reads your files or your inbox sends their contents to the model service, and whether that content is used for training depends on plan and settings, which Anthropic sets out on its privacy page. Our rule is simple: wherever output leaves the organisation or changes money or data, a person approves. For how access and payment for these tools stands from Iran, see the buying guide.
Sources: Anthropic: building effective AI agents Anthropic: is my data used for model training Anthropic: supported countries Google: where the Gemini web app is available
Where this advice stops
This lesson explains the shape of an agent and is not a build guide. The tooling layer and the libraries change every few months, and naming one of them means a page that is wrong next year, so only the principles that survive a tool change are written here. Second, we print no figures about agent success rates, because we hold no source we would trust; what is quoted from Anthropic is engineering advice, not measurement. Third, we run no unattended agent with write access on this site, so we claim no experience of running autonomous agents in production.
From our own work
This learning section took its own lesson from a real failure. The data files here are written by automated sessions on a live site, and a hundred kilobyte file is not written atomically; for those few seconds an include hits the half written version and throws a ParseError. Because the function that reads these files is called from the wp-admin screen through to every /learn/ route, those few seconds turned into a site wide critical error. The answer sits in rgbl_read_data_file() in includes/registry.php: the read is inside a try, a broken file is skipped and reported in the validate output, and the same place defines DONOTCACHEPAGE so a page that was missing a lesson can never sit in cache. Note that php -l is disabled on this server, so catching that ParseError was the only route. This is exactly the guardrail this lesson is about, written in code: we did not stop the automated writer, we drew a boundary its errors cannot cross.
Real follow-up questions
How is an agent different from a chatbot
A chatbot gives one answer and stops; an agent uses tools in a loop and sees the result of each step. The difference is not being smarter, it is that one talks and the other acts.
Is an agent worth it for a small business
In two places yes: research and gathering, and triaging incoming messages with a draft reply. In both, the final approval stays with a person. For work with no clear success signal, an agent does not buy you time.
Can an agent be left running unattended
Where its mistakes are reversible and nobody outside sees them, yes. Where money moves, client data changes, or something leaves the organisation, no. Not out of timidity, but because an agent error is usually silent and rides forward into the next steps.