Station 6 · Agents
Up to now, AI has been a very smart talker. An agent is different: it can actually do things — search the web, run code, use a calculator — and keep working on its own until the task is finished.
What you'll walk away with
Concept 1
Everything you've built so far has been a talker. You send text, it predicts text back. Useful — but it can't lift a finger in the real world. An agent can.
Remember the core idea from Station 1: an LLM predicts the next chunk of text. A plain chatbot stops there. If you ask it "what's 4,318 × 27,904?" it will guess a number that looks right — and often be wrong, because it's predicting digits, not calculating. If you ask "what's the weather in Austin right now?" it has no way to know; its training data is frozen in the past.
An agent wraps that same LLM in a system that lets it take actions to actually get a job done. Instead of guessing the multiplication, it can reach for a calculator. Instead of pretending to know the weather, it can search the web. And crucially, it doesn't stop after one step — it keeps going, action after action, until the whole task is complete.
Takes your text, predicts a reply, done. Can't look anything up, can't run code, can't check its own math. One turn of talk.
Same brain, but it can use tools — search, calculate, run code, call other apps — and loop until the goal is reached. It gets things done.
A chatbot answers. An agent acts. The model is still just predicting text — but now some of that text is a command to use a tool, and the tool's result comes back into the conversation so the model can keep going.
Concept 2
An LLM is brilliant at language but genuinely bad at some things — exact arithmetic, knowing today's date, seeing live data. Tools patch those gaps.
A tool is just a function the AI is allowed to call — a calculator, a web search, a "read this file," a "send this email." As the builder, you describe the tools it can use: their names, what they do, and what inputs they need. You don't decide when to use them — the model does. This is often called function-calling or tool use.
The magic is in the handoff. The model reads your question, decides a tool would help, and instead of answering it emits a little request like "call calculator with 4318 × 27904." Your program runs the real calculator, gets the exact answer, and feeds that answer back into the conversation. Now the model continues, this time with a real number in hand.
Picture a sharp intern. Ask a plain chatbot a question and it's an intern who must answer instantly from memory — no phone, no calculator, no internet. An agent is that same intern, but now allowed to grab a calculator, look things up online, and check the files before reporting back. Same person, wildly more useful — because they can go do the work instead of just talking about it.
Concept 3
Let's make it concrete. Here's the back-and-forth when a user asks a math question and the agent has a calculator tool available.
# You describe a tool the model is allowed to call: tool calculator(expression) # does exact math # 1. User asks: user: "What is 2 + 2, then doubled?" # 2. The model doesn't guess. It requests the tool: model: CALL calculator("2 + 2") # 3. Your program runs the real tool and returns the result: tool_result: 4 # 4. That result is fed back in. The model continues: model: CALL calculator("4 * 2") tool_result: 8 # 5. Task done — now it writes a normal answer: model: "2 + 2 is 4, and doubled that's 8."
Notice there were two tool calls before the final answer. The agent chained them — using the result of step one to set up step two. That chaining, done automatically, is what separates an agent from a one-shot chatbot.
Concept 4
Every agent, no matter how fancy, runs the same simple loop under the hood. Once you see it, agents stop being mysterious.
That's the whole engine. A research agent might loop a dozen times — search, read, search again, cross-check — before writing its summary. A coding agent might read a file, edit it, run the tests, see a failure, fix it, and run the tests again. Same four beats, over and over.
You don't tell a good intern every keystroke. You say "figure out our cheapest shipping option and book it." They go look things up, do the math, check a few sites, and return with a done task — not a wall of talk. The agent loop is exactly that: you give the goal, it thinks-acts-observes on its own until it can hand back a real result.
Concept 5
This isn't theory anymore — agents are some of the most useful AI tools people touch every day. Two big families stand out.
You give a question, and the agent browses the web for you — opening pages, reading them, following links, cross-checking sources — then hands back a written summary with what it found. It's the loop in action: search, read, decide what's still missing, search again. What would take you an afternoon of tabs, it compresses into a few minutes of autonomous work.
Tools like Cursor, Claude Code, and GitHub Copilot-style agents can read across a whole codebase, edit files, run the tests, and react to what breaks. You describe the feature or the bug; the agent plans the change, makes edits, runs the code, sees the errors, and iterates — often finishing a multi-step task with you just reviewing the result. Again: think, act, observe, repeat.
The pattern generalizes. Anywhere a job is "several steps, some of which need real tools or live information," an agent is a natural fit — booking, data cleanup, customer support that actually looks things up, and more.
Concept 6
The exact thing that makes agents useful is what makes them dangerous: they take real actions in the real world.
A chatbot that's wrong just says a wrong sentence — annoying, but harmless. An agent that's wrong might delete the wrong files, send an email to the wrong person, or run code that breaks something. The model is still, at heart, predicting text (Station 1) — which means it can be confidently mistaken. Now that mistake can pull a trigger.
Be deliberate about what you let an agent do. Reading and searching are low-risk. But actions that are hard to undo — deleting files, sending messages, spending money, changing settings — deserve a human in the loop who reviews and approves before they run. "It seemed confident" is not a safety check. When in doubt, let the agent propose the action and make a person click the button.
Good agent design is mostly about this balance: give it enough power to be useful, but put guardrails and human review around the actions that could cause real harm. You'll go deeper on this thinking in Station 8: Safety & Ethics.
Checkpoint
What's the single clearest difference between a plain chatbot and an agent?
It's not about a smarter brain — an agent can run the exact same model as a chatbot. The difference is that the agent can call tools (search, calculate, run code) and keep looping think→act→observe until the goal is reached. And no, it's not mistake-proof — it's still predicting text, which is exactly why risky actions need human review.
Try it yourself — 15 minutes, no code
Use any free agent-style tool that can actually browse the web or run code — for example a "deep research" mode, a browsing assistant, or a code-running assistant. Then hand it a task that takes more than one step:
Keep: jot one sentence — "An agent thinks, acts with a tool, observes, and repeats — so I decide which actions it's safe to let it take."
Recap. A chatbot only talks; an agent acts. You give the model tools it can call, and it runs a simple loop — think → act → observe → repeat — until the job is done. That's how research agents browse and summarize, and how coding agents edit and test real code. The same power that makes agents useful (taking real actions) is why the risky actions need guardrails and a human in the loop. Next up: AI that goes beyond text entirely.