What an AI agent actually is.

Why your definition of “agent” matters CORE

You are about to spend a lot of hours directing AI systems to do real work. How well that goes depends almost entirely on one thing that nobody teaches: how you think about what you are directing.

If you think an AI agent is magic — a box that “just knows things” — you will hand it vague tasks and be disappointed when it invents facts. If you think it is a fancy search engine — a tool that looks things up — you will ask it to find sources it does not have access to and blame it for being wrong. Both of these ways of thinking produce the same result: a frustrated human and a mediocre output.

Good directors have a sharper picture. They see an agent as a specific kind of machine with specific parts, each of which can be broken or missing. When the output is bad, they can point at the part that failed. When the task is new, they can figure out what the agent needs to succeed. That sharper picture is what this lesson gives you.

The definition: model + loop + tools + state CORE

An AI agent is four things working together.

A model. A large language model — the AI you've used as a chatbot is one. The model is the “brain.” On its own, it can read, write, and reason, but it cannot do anything outside the conversation. (You don't need to know how a model is built to direct one. You only need to know what it does and where it stops.)

A loop. Code that runs the model more than once. After the model responds, the loop decides whether the task is done. If not, the loop feeds the model's output back in — along with new information — and runs it again. A chatbot runs the model once per user message. An agent runs the model many times, often without the user in between.

Tools. Specific actions the model is allowed to take. Reading a file. Searching the web. Sending an email. Running a shell command. Querying a database. (You'll sometimes hear these called “functions” — same idea: a named, defined thing the AI can do.) Without tools, the model can only produce text from what it already knows. With tools, it can reach out into the real world — your computer, the internet, your calendar — and act.

State. Information that persists between loop iterations. The conversation so far. A scratchpad of notes the agent writes to itself. Files it has read. Results from tools. State is the agent's memory for this task; without it, every step of the loop would start from nothing.

Chatbot vs. agent, in one concrete example CORE

Imagine you are writing a paper on the Dust Bowl.

You open a plain chatbot and type: “What were the top three causes of the Dust Bowl?” The chatbot responds in one turn. It produces three causes, drawn from what the model remembers from training. It cannot check a source. It cannot open a book. It cannot tell you how confident it is. The loop runs once. There are no tools. State is just your question and its answer.

Now imagine you open an agent and type: “Find the three most commonly cited causes of the Dust Bowl across at least five academic sources. For each cause, give me a one-paragraph explanation with a direct quote and a citation. Save it as dust-bowl-brief.md on my desktop.”

The agent does something very different. It plans. It calls a search tool. It reads the results. It notices that one source disagrees with three others and decides how to handle that. It writes the brief. It opens your filesystem and saves the file. Along the way, it has run the model maybe twenty times. It has called five or six tools. It has kept state — a running list of sources it has already checked, so it does not re-read the same page.

Same underlying model. Wildly different output. The difference is the loop, the tools, and the state — the parts that turn a model into an agent.

Two misconceptions that will make you a worse director CORE

Misconception 1: the “magic” frame. “It just knows things.” Students who hold this frame give vague commands like “make this better” or “fix my essay” and are disappointed when the output is generic. The model does not know what you have not told it. It does not know your assignment, your teacher's preferences, what you have already tried, or what you are actually optimizing for. Vague input, vague output — every time.

Misconception 2: the “search engine” frame. “It just looks stuff up.” Students who hold this frame assume every answer is grounded in a real source. It is not. A model without a search tool answers from its trained parameters — essentially, from compressed patterns of text it saw during training. Those patterns are often right and sometimes confidently wrong. This is where hallucinations come from: the model is not lying, it is pattern-completing. If you want grounded answers, you have to give the agent a tool that reaches real sources, and you have to direct it to use that tool.

Both misconceptions fail for the same reason: they ignore the parts. If you cannot name model, loop, tools, and state separately, you cannot tell which part is letting you down.

Why this changes everything you do next CORE

Everything you will learn in this course maps onto those four parts.

Module 2 sets up the models you will use — local models on your own machine, cloud models through an API. Module 3 teaches you to direct coding loops. Modules 4 through 6 teach you the tools that matter most — research, email, calendar, scheduled tasks. Module 7 teaches you to build your own tools when the defaults fall short. Module 8 teaches you to chain loops together, so one agent's output becomes another agent's input. Module 9 teaches you to protect state from leaking where it should not go.

Before you direct anything, ask four questions:

Do I have the right model for this task? Is my loop well-framed — does the agent know when to stop? What tools does it need, and does it have them? What state am I giving it up front, and what will it carry forward?

Those four questions are the whole course. This lesson gave you the words to ask them.