What an agent is, and the question to ask before you build one
Agents are the most over-applied pattern in applied AI. This lesson gives you the spectrum from fixed workflow to autonomous loop, the honest cost of each step along it, and the decision rule the rest of this course is built on: use the least autonomy that solves the task.
TL;DR: An agent is a model that decides its own next step in a loop, and every increment of that freedom is bought with reliability, predictability, cost, and your ability to debug. The rule this course is built on: use the least autonomy that solves the task. Most production value sits well short of a fully autonomous loop.
Where you are. This is the first lesson of the course, and it argues against the thing the course is about. That is deliberate, and it is the last time the course will apologise for it. Engineers who ship agents that survive contact with users are the ones who know exactly when not to build one, and interviewers screen for that judgement specifically. Everything after this lesson is machinery. This lesson is the decision that tells you which machinery you need.
You need no agent experience to follow it. You should be comfortable calling an API and reading code.
The word means too many things
"Agent" is used for everything from a prompt chain with two steps to a system that plans its own work for an hour. That vagueness is why the industry argues past itself, and why an interview answer that starts "well, an agent is basically an LLM with tools" lands flat.
The useful move is to stop treating it as a category and start treating it as a dial: how much control are you handing to the model?
At the left end, you orchestrate. Your code decides the order of operations and the model fills in well-scoped gaps: extract this, summarise that, classify this into one of five buckets. Control flow lives in your repository, where you can read it, test it, and set a breakpoint in it.
At the right end, the model decides. It chooses which tool to call, in what order, how many times, and when the job is finished. You wrote the tools and the goal. You did not write the path.
The middle is where most working systems actually live, and it is the least discussed part of the spectrum.
The industry has its own vocabulary for the scaffolding that goes around the model, and you will hear it in interviews before anyone defines it. This is a short tour of where those words came from.
What each step to the right costs you
This is the part that beginner material skips, so here it is plainly. Moving right buys flexibility and pays for it in four currencies at once.
Reliability. In a fixed workflow, an error surfaces at a known step. In a loop, errors compound: a bad observation at step three poisons the reasoning at step four, which selects the wrong tool at step five. A per-step success rate that sounds excellent becomes an unimpressive end-to-end number once you multiply it across ten steps. Do that multiplication before you commit to a loop, because it is the single most clarifying number in agent design.
Predictability. The same input can take a different path on different runs. That breaks the assumption underneath most testing: that you can assert on the output of a known input. It also means a customer's bug report may not reproduce.
Cost and latency. Every loop iteration is another model call carrying the accumulated history. Cost per task stops being a constant and becomes a distribution with an unpleasant tail. Budget for the tail, not the average.
Debuggability. When a workflow breaks you read the code. When an agent breaks you read a trajectory, reconstruct what the model believed at each step, and try to work out which observation sent it wrong. This is a genuinely harder skill and it is why observability arrives early in this course rather than as an afterthought.
None of that says do not build agents. It says autonomy is a cost you should be able to justify.
The decision rule
Use the least autonomy that solves the task.
Reach right along the dial only when the path genuinely cannot be known in advance. Three conditions, and you want all three, not one:
- The steps depend on intermediate results. You cannot enumerate them when the request arrives, because what to do next depends on what the last step returned.
- Real tools are involved and their output changes the plan. If nothing the system learns mid-task could change what it does next, you have a pipeline, and you should write it as one.
- A capable human would also work iteratively, probing and adjusting rather than executing a known checklist.
Research tasks, debugging, and multi-step customer resolution meet all three. "Summarise this document" meets none, and wrapping it in a loop adds latency, cost, and new failure modes to a problem that was already solved.
A worked example of the reasoning, because the rule is easy to nod at and hard to apply. Take "answer questions about our internal documentation." The instinct is an agent with a search tool. But the steps are knowable: retrieve, then answer. There is no branch that depends on what retrieval returned, beyond handling the empty case. That is retrieval with a generation step, not an agent, and it will be cheaper, faster, and far easier to evaluate. Now change the task to "resolve this customer's billing complaint," where the system may need to look up an account, check a payment, read a policy, and decide whether it is even allowed to issue a refund. The path now depends on what it finds at each step. That earns a loop.
What this course does with that
Every remaining module assumes you have made this call honestly, and each one is about controlling a specific cost from the list above:
- The single-agent loop and its termination conditions, which is where the reliability cost is contained.
- Tools as an interface, which is where most wrong-behaviour bugs actually originate.
- Memory and context, which is where the cost curve is bent.
- More than one agent, and the point at which that stops paying for itself.
- Reliability and evaluation, which is how you know any of it works.
If you take one thing from this lesson into the rest: an agent is not a more advanced solution. It is a more expensive one, and sometimes the expense is worth it.
Do this before moving on
Do the compounding multiplication yourself, because reading about it does not land the way seeing the number does.
Open a calculator. Assume a per-step success rate of 0.95, which sounds like a system working well. Raise it to the power of 5, then 10, then 20. You get roughly 0.77, 0.60, and 0.36. Now try 0.99 per step: 0.95, 0.90, 0.82.
Two things to take from those six numbers. A loop that looks healthy step by step can fail most of its tasks end to end, and the fix is usually fewer steps rather than a better model. Then pick a task you have actually considered automating, write down how many tool calls it would really take, and decide from the number whether it earns a loop.
Go deeper
- Agents and tool use is the mechanism this lesson deliberately skipped: the reason-act loop and how a tool call is actually executed by your code rather than by the model. Read it before the next module.
- Agent design patterns names the shapes you will meet at the right-hand end of the dial.
- Practice question: Workflows versus agents: how much autonomy should you actually give an AI system? is this decision under interview conditions, and it is asked often.
- Practice question: When do you build an agent instead of a single LLM call? pushes on the three conditions above until they break.
Key takeaways
- Autonomy is a dial, not a category. Say where on it your system sits and why.
- Every step right costs reliability, predictability, money, and debuggability at the same time.
- Multiply your per-step success rate across the expected number of steps before committing to a loop.
- Reach for an agent only when intermediate results genuinely determine the next step.
Check yourself before an interviewer does. Answer from memory first.
A system retrieves internal documents and answers questions about them. Where does it sit on the autonomy dial?