“Agent” is currently doing more marketing work than technical work. It gets attached to chatbots, to scripted workflows, to anything with an LLM in it. That vagueness is a practical problem: if you cannot say precisely what an agent is, you cannot tell whether your problem needs one — and agents are meaningfully more expensive, slower, and harder to debug than the alternatives.
This lesson gives you a definition that holds up, distinguishes agents from the two patterns they are most often confused with, and gives you a decision procedure for whether to build one at all.
A working definition
An AI agent is a system where a language model decides, at runtime, which actions to take and in what order, using tools that affect the world outside the model, and continues doing so in a loop until it judges the task complete.
The load-bearing phrase is decides at runtime. If the sequence of steps is fixed in your code and the model only fills in the blanks, you do not have an agent — you have a workflow with an LLM in it. That is not an insult; workflows are usually the better engineering choice. But it is a different thing.
Three properties follow from that definition:
The model chooses the control flow. Nobody wrote if user_needs_weather: call_weather_api(). The model was given a weather tool and worked out on its own that this request needs it.
The loop is open-ended. The number of steps is not known in advance. It might take one tool call or fourteen. Termination is the model’s judgment, not a counter in your code — though you should always have a counter in your code as a backstop.
Actions have effects. An agent reads files, calls APIs, writes to databases, sends messages. That is where the value comes from, and it is also why agents demand more care than a text-in-text-out system.
The three patterns, compared
Chatbot
Text in, text out. The model has no tools and cannot affect anything. Its knowledge is frozen at training time, so it cannot tell you today’s date or your account balance.
A chatbot is the right pattern for explanation, drafting, summarization, translation, and classification — anything where the input contains everything needed to produce the output. Most “AI features” shipped in products are correctly built this way, and calling them agents does not improve them.
Workflow
Your code defines a fixed sequence; the model performs one or more steps inside it. A support ticket pipeline that classifies incoming tickets, extracts entities, looks up the customer in your CRM, then drafts a reply is a workflow. The model is called four times. Every one of those calls happens in an order you wrote, whether or not the model thinks it is necessary.
Workflows are the sweet spot for most production systems and they are badly underrated. They are debuggable, because the control flow is in your source and you can put a breakpoint in it. They are cheap, because there is no exploratory tool use. They are predictable, because the same input takes the same path. They fail comprehensibly, because you know which step broke.
If you can specify the steps up front, write the workflow. Do not reach for an agent because agents are more interesting.
Agent
You give the model a goal and a set of tools, and it decides the path. Ask a coding agent to “find why the checkout test is flaky and fix it” and it might grep the test file, read the implementation, run the test five times, notice a race condition, read a related module, make an edit, and re-run. You did not script any of that. You could not have — the right sequence depends on what it finds along the way.
That is the case for agents: tasks where the correct sequence of steps genuinely cannot be known before you start, because each step depends on what the previous step revealed.
Should you build one? Four criteria
Before choosing the agent pattern, check all four. If any is a clear “no”, drop to a workflow or a single call.
1. Complexity. Is the task genuinely multi-step and hard to fully specify in advance? “Turn this design doc into a pull request” qualifies. “Extract the invoice total from this PDF” does not — that is one call.
2. Value. Does the outcome justify the cost and latency? Agents make many model calls, and each one carries the entire conversation so far. An agentic run costs multiples of a single call and can take minutes. That is fine for a task that saves an engineer an hour. It is absurd for something that runs on every page load.
3. Viability. Is the model actually good at this task type? Coding, research, data analysis, and structured document work are strong. Tasks needing real-time precision, guaranteed determinism, or domain knowledge the model does not have are not — and no amount of agentic scaffolding fixes a capability gap.
4. Cost of error. Can mistakes be caught and undone? Agents take actions you did not explicitly authorize, and they will occasionally take a wrong one. This is survivable when there are tests, code review, or a rollback path. It is not survivable when the agent can irreversibly send money, delete production data, or email customers. Where errors are expensive, put a human approval gate on the dangerous tools — you will meet the mechanism for this in Lesson 12.
The failure mode nobody warns you about
The most common way an agent project fails is not a dramatic wrong action. It is silent under-delivery: the agent does a plausible-looking subset of the work, reports success, and nobody notices for a week.
This happens because the model is generating its own definition of “done”. If the task was underspecified, it will pick a reading of the goal that it can satisfy — usually a narrower one than you meant.
Two mitigations, both cheap. Specify completely up front. A single well-specified initial instruction outperforms the same information dribbled across five turns, and it dramatically reduces the odds of the model inventing its own scope. Make verification a separate step. Do not just ask the agent whether it finished; check the artifact. Run the tests. Diff the output. Assert on the result. An agent that grades its own homework will pass.
What actually makes it work
Strip away the framing and an agent is a loop:
- Send the conversation plus a list of available tools to the model.
- The model replies either with a final answer, or with a request to call one or more tools.
- If it asked for tools, run them and append the results to the conversation.
- Go to step 1.
That is it. Every agent framework you have heard of is this loop plus conveniences. The mechanism that makes step 2 possible — the model asking you to run a function, in a structured form your code can dispatch on — is tool calling, and it is the subject of the next lesson.
Understand tool calling properly and the rest of this track is assembly. Skip it and everything after will feel like memorizing incantations.
Next: Lesson 2: How LLM Tool Calling Works
New lessons in this track publish weekly. Subscribe to get each one when it lands.