The loop: one definition that actually works
Lesson 1 of 5 in What Is an Agent? The Loop That Changes Everything.
The word agent has been slapped on everything from autocomplete to autonomous drones, so start with the definition this entire academy is built on:
An agent is an LLM given tools, run in a loop, with a stopping condition.
Every word earns its place. The LLM supplies judgment — reading, reasoning, deciding. The tools give that judgment hands: search a codebase, query a database, send an email, run a shell command. The loop feeds each tool result back into the model so it can decide what to do next. And the stopping condition is what keeps the loop from running forever: the model declares the task done, hits a turn limit, or gets stopped by a human.
If you work somewhere that already bought automation, you have a fairer question than “what is an agent”: we have had software that does things by itself for years — what is actually new? The answer is a single property, and it is easiest to see by walking the staircase that led here.
Hand-written rules engines came first: a person writes the decision down — if the claim is under this amount and the customer is in that tier, approve it — and the engine matches those conditions against records. Robotic process automation (RPA, the category UiPath sells into) drives the user interface of software you cannot change: click this, read the value out of that field, type it over there. Workflow and integration automation (Zapier, Make) wires APIs together along a path you draw in advance: when a form is submitted, create the record, then post the message. Each wave reached further into the business. None of them changed who was doing the thinking.
That is what moves at the last step. In every earlier wave, all of the judgement lives in the person who drew the flowchart, and the system executes that person’s decisions without understanding any of them — which is why an input nobody anticipated produces the wrong action at full speed instead of a pause. With an agent, some of that judgement moves inside the running system: the model works out the next step while the task is actually in front of it. That is the same claim as model-directed control flow, named from the buyer’s side rather than the engineer’s — one idea in two vocabularies, not two definitions. The staircase is history; the definition at the top of this lesson is the test. The next lesson re-cuts the same world along the axis that test actually asks about — who decides the next step — so the waves land where you would expect: hand-written rules and recorded click paths both sit in script / automation, drawn API wiring sits in workflow, and one box this staircase has no room for appears alongside them — the chatbot, which reads and reasons but has no hands.
| Wave | What it automates | Who supplies the judgement | How it fails |
|---|---|---|---|
Rules engines — if this, then that | A decision table someone wrote out by hand: thresholds, tiers, exception codes. | The rule author, entirely. The engine matches conditions; it interprets nothing. | On the case nobody wrote a rule for — either no branch matches and the item stalls, or a nearly-right branch fires and the wrong thing happens quietly. |
Robotic process automation — RPA (UiPath and similar tools) | The user interface of systems you cannot modify: clicks, keystrokes, values read back off a screen. | Whoever recorded the click path. The bot has no model of what a screen means. | Brittleness. A renamed button, a new consent dialog, a slower page — the recorded path no longer exists and the run dies part-way through a transaction. |
Workflow / integration automation — Zapier, Make, CI pipelines | The wiring between APIs along a fixed path: trigger, then step, then step. | Whoever drew the path — and they drew it before this particular case existed. Steps can be clever; their order cannot adapt. | Anything off the drawn path is simply unhandled: the run errors out, or completes a branch that does not fit the case. |
Agents — an LLM with tools, in a loop | The choice of what to do next, given the goal and whatever just came back from the last action. | Split. You still supply the goal, the tools, the limits and the gates; choosing the next step moves into the model, at runtime. | Plausibly. It takes a defensible-looking wrong path and keeps going — which is why the later domains spend their time on evaluation and containment rather than on branch coverage. |
One email, keyword-and-template automation
The email: “Order 88214 arrived yesterday but the second lamp is cracked. I don’t want a refund, I want the same lamp again — and I move house on Friday, so please send it to 12 Ash Lane. Also, can you take me off the newsletter.”
The rules that fire: contains("refund") → send the refund-policy template. contains("cracked") → open a damage ticket.
What the customer gets: the refund policy they explicitly declined. The house move is never read, so the replacement — whenever a human finally opens that ticket — goes to the old address. The newsletter request matched no rule, so as far as this system is concerned it was never made.
Why it broke: the rules matched strings, not meaning. “I don’t want a refund” contains the word refund, and nothing in the pipeline can notice the negation, because nothing in the pipeline reads.
The same email, an agent
What it works out: one message, three requests — a like-for-like replacement rather than a refund, a delivery address that changes on Friday, and a marketing opt-out.
What it does: get_order(88214) to confirm the item and that it is inside the damage window → create_replacement(order=88214, item="lamp-2") → set_shipping_address on the new order, dated after the move → unsubscribe(list="newsletter") → one reply naming all three outcomes.
Why it holds: nobody wrote that four-step sequence, and a different email produces a different one. The reading is the work; the actions follow from what the message turned out to say. And had the customer asked for something outside this agent’s tools or limits — a goodwill credit, say — the right design is to stop and hand the ticket to a human rather than improvise. The autonomy lesson later in this module is where you set that.
The agent loop
- Goal + system prompt
The task, the agent’s job description, and the tool definitions all enter the context window together.
- Model reasons over context
The LLM reads everything so far — goal, instructions, prior tool results — and produces its next move.
- Tool call or final answer?
This is the model-directed branch: nothing in the code dictates which way it goes.
- Runtime executes the tool
The harness — not the model — actually runs the code, with whatever permissions it was given.
- Result appended to context
The tool output becomes new input. The model sees it on the next pass and adjusts.
- Stopping condition met?
Task declared complete, turn budget exhausted, error threshold hit, or a human intervened.
- Report result
Notice what is not in the diagram: a plan written by a programmer. When a coding agent fixes a bug, nobody scripted “first grep, then read the file, then edit, then run the tests.” The model chose that sequence — and on a different bug it will choose a different one. That flexibility is the entire value proposition, and (hold this thought) the entire risk profile.
Notice also the division of labour. The model only ever emits text — a structured request saying “call this tool with these arguments.” The runtime decides whether to honour it and executes the call. Everything you will later learn about permissions, approval gates, and sandboxing lives in that gap between requested and executed.
Key terms: agent, agent loop, tool, stopping condition, model-directed control flow, context window
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.