Module 1 · Foundations

What Is an Agent?

Before context windows, skills, or hooks, one plain idea underpins the whole course: an agent is a language model put in a loop and handed tools. Everything else is a consequence of that.

7 min read

Lesson 1.1

A model in a loop, with tools

A plain language model does one thing: you give it text, it predicts text back. Useful, but it's a closed room: it can't read your files, run a command, or check anything in the real world. It only talks.

An agent is that same model with two things added around it:

  • Tools, concrete actions it's allowed to take: read a file, run a script, search the web, query a database, edit code, create a file.
  • A loop: after every action, the result comes back to the model, which decides what to do next. It keeps going (act, observe, decide, act again) until the goal is met.

Zoomed all the way out, the loop looks like this. Send the message below to watch it turn.

User
  1. User

    Sends a request in plain language.

  2. LLM

    Processes the request and everything it's learned so far, and decides what to do next.

  3. LLM

    Does something: calls read_file

  4. LLM

    Checks the result against the goal: is it actually done yet?

    Not yet — back to “processes” Goal met — moves on
  5. LLM

    Takes the final action and then responds to the user. Loop complete.

That loop is the whole trick. A model that can only answer is a chatbot. A model that can act, see what happened, and adjust is an agent. It's the difference between someone describing how to fix a bug and someone actually opening the file and fixing it.

Fundamentals of an Agent

Agent = model + instructions + tools + a loop. You are not programming it step by step. You give it a goal and a set of tools, and it decides the steps itself, one at a time, reacting to what it finds.

Lesson 1.2

Watch one work

Here's a single, ordinary request handled by an agent. Notice that no one told it to read the file first, or to edit second; it chose that order by reacting to what each step returned. Press the button below to see it in action.

User “The signup form lets you submit an empty email. Fix it.”
  1. 1 · The goal

    A goal in plain language. No file named, no line number, no instructions on how, just what "done" looks like.

  2. 2 · It reasons

    "I can't fix what I can't see. First I need to find the form and read how it validates input."

  3. 3 · It acts: reads the file

    It calls a read tool. This is the loop reaching out of the closed room and into the actual project.

    read_file src/SignupForm.jsx;
  4. 4 · It observes

    The result comes back into the loop. Now it can see the cause: the submit handler checks the password but never checks the email.New to code? Here's what it does. The block below is the function that runs when someone clicks Submit. In plain English: if the password box is empty, it stops and shows “Password required.” The greyed-out line is just a note that there's no matching check for the email. Then it submits the form. Because the email is never checked, an empty one slips straight through, and that's the bug the agent is about to fix.

    function onSubmit() {
  if (!password) return error("Password required");
  // no check for email …
  submit();
}
  5. 5 · It acts again: edits

    Same loop, new decision. Having seen the code, it now makes a targeted change, adding the missing guard by calling the edit tool.

    edit_file + if (!email) return error("Email required");
  6. 6 · The function is updated

    The edit lands in the file. The function now has the code necessary to require an email; the new line is highlighted.

    function onSubmit() {
  if (!password) return error("Password required");
  if (!email) return error("Email required");
  submit();
}
  7. 7 · It reports back
    Agent

    Fixed. SignupForm.jsx now rejects an empty email before submitting, matching the existing password check. Want me to add a test for it?

Seven steps, two tool calls, one loop. The model supplied the thinking; the tools supplied the agent with the ability to take action; the loop tied them together so each action was informed by the last.

Lesson 1.3

Powerful but dangerous

Because it can perform actions on your computer like you can, an agent's usefulness scales with the tools you give it. Hand it terminal access, a code editor, and network access and it can refactor a function, run a test suite, file a ticket.

But that same access is exactly what makes it dangerous. An agent can do anything its tools allow inside the sandbox your put around it, and it acts on its own reading of your intent, which is not always your actual intent. The blast radius of a mistake is precisely the set of tools and access you handed over.

Access is the risk

"Clean up the old files" against a broad shell tool can become rm -rfNew to the shell? Here's what it does. rm deletes. -r is "recursive": go into a folder and delete everything inside it, subfolders included. -f is "force": don't ask "are you sure?" before each delete. Together, rm -rf permanently removes whatever files you point it at, with no confirmation and no undo. in the wrong directory. A database tool with write access can drop a table it only needed to read. The model isn't malicious; it's literal, and it moves fast. Give it the narrowest access that still lets it do the job, and keep a human in the loop for anything destructive or hard to undo.

An agent needs to summarize last quarter's orders from your production database. Which access do you grant?

Pick one. You'll get instant feedback.

Lesson 1.4

Non deterministic

There's one more property that shapes everything you'll do with agents: they are non-deterministic. A normal program, given the same input, produces the same output every time. A large language model doesn't. Under the hood it predicts each next word from a distribution of possibilities, so the same request can take a different path between conversations.

Run the fix from Lesson 1.2 twice and it might read a different file first, phrase the guard differently, or offer to write the test without being asked. Usually every one of those paths is fine. But it means you can't script an agent like a macro. You steer it; you don't control it keystroke by keystroke.

Non-determinism isn't a bug to stamp out; it's the same flexibility that lets one agent handle a thousand differently-worded requests. The job isn't to eliminate it. The job is to constrain it so the range of paths it takes are all good ones.

So what actually steers it?

If you can't dictate the steps, what can you do? You control the one thing the model reads before it decides anything: the information in front of it. A path goes wrong far more often because the agent was missing a key fact (a convention, a constraint, which file matters) than because it "reasoned badly." Give it the right context and most of the bad paths simply disappear.

Where this leads

Getting the right information to the agent at the right moment, and keeping everything else out of its way, is the single highest-leverage skill in this whole course. That's precisely what the next module is about: the agent's active memory, and how to spend it well.

Lesson 1.5

Be specific with your request

The last lesson landed on a rule: you steer an agent through the information you put in front of it. The most immediate piece of that information is the thing you type: the prompt. Skills, context, and tools all matter, but before any of them, a clear request is the cheapest, fastest steering you have.

A vague ask forces the agent to guess what you meant, and a non-deterministic model guesses differently every time. A precise ask collapses that range of guesses down to the paths you'd actually approve of. Four ingredients do most of the work:

A prompt that steers

1. Goal — what "done" looks like, in outcome terms, not steps.
2. Context — the facts it can't infer: which file, which convention, what's already tried.
3. Constraints — the guardrails: "don't touch the API", "match the existing pattern", "read-only".
4. Done-criteria — how you'll both know it worked: a passing test, a specific behavior.

You don't need all four every time; a one-liner is fine for a small, unambiguous task. The rule of thumb: the larger the task and the more room there is to guess wrong, the more specific you should be. Watch the same task run twice, once as an offhand line, once with those ingredients in place.

Your goal Get the agent to fix the empty-email bug in the signup form.
A vague one-liner
  1. The prompt. “The signup is broken, can you sort it out?”
  2. Which signup? Which break? No file, no symptom. The agent scans around and picks a problem, not necessarily yours.
  3. Guesses wide. It rewrites the whole handler, adds validation you didn't ask for, and changes an API call along the way.
  4. Overshoots. The empty-email bug may or may not be fixed, buried in a diff you now have to review line by line.
It might land the fix, but the blast radius is everything it decided to touch on your behalf.
Goal · context · constraint · done
  1. The prompt. “In SignupForm.jsx, the submit handler lets an empty email through. Add a guard matching the existing password check. Don't change anything else. Done when submitting an empty email shows an error.”
  2. Straight to the source. The file is named and the symptom is exact, so it opens the right code on the first move.
  3. Matches the pattern. The constraint pins the shape of the fix: one guard, mirroring the password check, nothing else disturbed.
  4. Verifiable. The done-criterion gives it a clear target and gives you a one-line way to confirm it.
Same model, same tools: the added information ruled out every path but the one you wanted.

And when the first prompt isn't perfect, you're not stuck: the loop is a conversation. Correct it mid-flight — “actually, keep the API call as-is” — and it adjusts. A good prompt gets you a good first path; steering as it works keeps you on it.

Recap

What to carry forward

Takeaways

1. An agent is a model + tools + a loop; it chooses its own steps toward a goal.
2. Its power and its danger are the same thing: it can do whatever its tools allow, so grant the narrowest access that does the job.
3. It's non-deterministic (you steer it, not script it), and the steering wheel is the information you put in front of it.
4. The most immediate steering is a clear prompt: goal, context, constraints, and done-criteria narrow the paths to the ones you'd approve.

Finished What Is an Agent?

Mark it done to track your progress across the course.