A chatbot answers. An agent pursues a goal — deciding, acting, seeing what happened, and deciding again. That one structural change is the whole subject, and it explains both why agents are useful and every way they go wrong.
Everything in the first course described a model that answers. You send text, it sends text back, and the exchange ends there. That is a remarkable thing, and it is also strictly conversational — the model cannot look anything up, cannot check whether it is right, and cannot do anything on your behalf.
This course is about what changes when it can.
The consultant and the contractor
Imagine hiring a consultant who is brilliant but confined to a room with no phone and no internet. You describe a problem, they think, they answer. If the answer depends on something they do not know — today’s price, your actual inventory, whether the file compiles — they will guess, and they will guess fluently.
Now give the same person a phone, a filing cabinet, and permission to act. They look things up. They call to confirm. They try something, see it fail, and try again. The intelligence did not change. What changed is that the loop is closed: they can act, observe the result, and adjust.
That closed loop is the whole of agentic AI. An agent is a language model placed in a loop where it can take actions and see what happened.
The definition worth memorizing
A chatbot produces text. An agent pursues a goal — deciding, acting, observing, and deciding again until the goal is met or it gives up. Every architectural idea in this course exists to make that loop reliable.
Watch the loop turn
Figure 1 — one turn of the agentic loop
1 · GoalA request arrives. “Find out whether invoice 4471 was paid.”
2 · DecideThe model reasons about what it needs, and asks to use a tool.
3 · ActYour code runs the tool. The model does not run anything itself.
4 · ObserveThe result is appended to the conversation and the model reads it.
5 · Repeat or stopEnough to answer? Answer. Not enough? Around again.
stage 0 of 5
Stages 2 through 4 can repeat many times before stage 5 ends the loop.
Notice stage three carefully, because it is the most commonly misunderstood part of the whole subject. The model never executes anything. It emits a structured request — “call lookup_invoice with id 4471” — and your code decides whether to honor it.
That is not a limitation to work around. It is the security boundary the entire field is built on. Every guardrail you will meet in module 08 lives in that gap between the model asking and your code agreeing.
Four things agents can do that chatbots cannot
Reach real data. A chatbot knows what it read during training. An agent can query your database, read a file, or call an API — so it can tell you today’s answer instead of last year’s.
Verify its own work. Write code, run it, read the error, fix it. This single capability is why coding agents became useful so quickly — the compiler is an oracle that never flatters.
Take multi-step action. Not “here is how you would file that expense” but actually filing it, then confirming it was accepted.
Adapt mid-task. When step three fails, a fixed script stops. An agent can try a different route, because it decides the next step after seeing the last one.
And four ways they fail
Every one of these follows directly from the loop, which is why understanding the loop is worth the effort.
The characteristic failures
Looping forever. The model keeps deciding it needs one more lookup. Without a hard cap on iterations, the loop is genuinely unbounded — and so is the bill.
Compounding errors. A wrong result at step two becomes an input at step three. By step seven the agent is reasoning confidently from something false.
Acting when it should have asked. An agent that can send email can send the wrong email. Capability and risk arrive together, always.
Losing the thread. Every turn adds to the context. Long tasks push the original goal into the middle of a very long conversation, where module 05 of the first course told you attention is thinnest.
Where the industry actually is
Two honest observations, because the gap between demonstration and production is where most of the disappointment in this field comes from.
Agents work well when the environment gives clear feedback. Code either compiles or it does not. A test either passes or fails. Where the loop can observe an unambiguous result, agents improve rapidly, and that is why software engineering was the first domain where they became genuinely useful.
They work far less well when success is subjective, when the consequence of a wrong action is expensive, or when the task requires judgment nobody has written down. “Refactor this module” is a good agent task. “Decide which customer to prioritize” is not, and dressing it up as one is how organizations get into trouble.
Try it — 15 minutes
You can watch the loop from the outside without writing any code.
1. Open an assistant that has web search or code execution — Claude, ChatGPT, or Gemini all offer at least one. Ask something it cannot possibly know from training: “What is the current version number of Python, and when was it released?”
2. Watch the interface. Most show the tool call before the answer — “searching…” or “running code…”. That is stage two and three of Figure 1, made visible.
3. Now ask something requiring two dependent lookups: “Find the population of the largest city in Portugal, then calculate what 3% of that is.” Notice it searches, reads, then computes. Two passes through the loop.
4. Ask it to do something it has no tool for — “send an email to my manager”. It should decline and explain. That refusal is the boundary from stage three: no tool, no action.
What to take away
An agent is a model in a loop with the ability to act and observe. The model requests; your code executes. Everything that makes agents powerful, and everything that makes them dangerous, comes from that one structural change.
Check yourself
1. A colleague says “we gave the model database access, so now it runs queries itself.” What is the accurate correction?
Your code executes; the model only asks. The third option is the dangerous one, and it is dangerous precisely because some teams build it that way — auto-executing generated SQL removes the validation layer that makes the whole arrangement safe. The model requesting and your code deciding is not an implementation detail; it is the control point.
2. An agent that summarizes support tickets has started producing summaries citing details that do not appear in the tickets. It runs an average of nine loop iterations per ticket. What is the most likely cause?
Compounding error. Nine iterations is a lot of opportunity for a small misreading at step two to become an accepted premise by step eight. A model update is the tempting explanation because something clearly changed — but the iteration count is the clue, and it points at the loop rather than the model. Shortening the loop or validating intermediate results is the fix.
3. Which task is best suited to an agentic approach?
The test suite, because the environment answers honestly and immediately — the loop can observe an unambiguous result and iterate. The other two are the trap: both are complex and valuable, which makes them feel like worthy agent tasks. But neither offers feedback the agent can act on, and both carry consequences that make an unsupervised loop inappropriate. Suitability is about feedback quality, not task difficulty.