From Model to Agent: What Makes a System Act

This course was first taught live as a five-week cohort at Nebius Academy. This is its opening lesson, rewritten for engineers and researchers preparing for applied-AI and research roles at frontier labs.

Before you start

Prerequisite: none. The book's Chapter 1, Your first model call, derives tokens, softmax and sampling if you want the model itself from first principles. After this lesson, you can: say in one sentence whether a system is an agent, describe the model's role inside it precisely enough to reason about its failures, and name the two design defaults that the rest of the course keeps comparing.

Ask what turns a chatbot into an agent and you will often hear that it remembers more, talks longer, or uses a bigger model. None of those is the difference. A chatbot and an agent can run on the same model with the same context window. The difference is entirely in the code around the model.

The one-sentence test

A system is an agent when your code executes actions the model chooses, feeds the results back to the model, and repeats until a rule says stop.

Every clause does work. "Your code executes" means something outside the model changes: a file, a job, a database row. "Actions the model chooses" means the model, not a fixed script, picks which action comes next. "Feeds the results back" means the model sees what happened, so it can correct course. "Until a rule says stop" means the loop ends by design, by an answer or a budget, not by running out of patience.

Anthropic's Building effective agents draws a related line between workflows, where code fixes the path through model calls and tools, and agents, where the model directs its own tool use. Both are useful. A workflow is easier to test; an agent handles tasks whose steps you cannot list in advance. Knowing which one you are building is the first design decision, and "an agent" is not automatically the better answer.

Quick check — A team says its research assistant is now an agent because it keeps a 200,000-token conversation history and cites earlier turns. What would make it an agent by this lesson's test?

The model is a policy, the loop is yours

It helps to be precise about what the model contributes. At each step it reads everything so far, the instructions, the task, every tool result, and produces a distribution over what to do next, sampled exactly as the next token is sampled. The book's Chapter 3 calls this a policy: a function from history to a distribution over actions. The model does not run anything, remember anything between calls, or know whether its last action succeeded, except through what your code puts in its context.

This course's working definition names the parts your code supplies:

text

agent = policy (the model) + tools + memory + planning + interaction + a stopping rule

The model proposes; your code executes, records and decides when to stop. a tool request; no; yes; an answer; History: instructions, task,every earlier result; Model as policy:samples the next action; Your code checks and executes it; The result is recordedand appended to the history; Stopping rule:answer given or budget spent?; Report the status andthe recorded results — The model proposes; your code executes, records and decides when to stop

Tools are how actions reach the world. Memory is what persists between calls and sessions (Week 4). Planning is how a long task is broken down before acting (Week 3). Interaction is how a person or another system talks to it. The stopping rule is the budget that turns "it never finished" into a reported status instead of a large bill.

This framing is what lets you reason about failures. If the model's next action is a sample from a distribution, then a long task is a sequence of samples, and success is a product of probabilities, which Lesson 04 works through. If the model sees only what your code shows it, then a lost fact is a context problem (Lesson 02) and a leaked secret is a trust-boundary problem (Lesson 06). None of those is fixed by calling the model smarter.

Why a lab cares about the distinction

Agent evaluations grade effects, not text. A task counts as solved when the repository's tests pass, the file has the right contents, or the environment ends in the right state, and not when the transcript says so. That is why this course keeps separating what the model claimed from what the code recorded, starting with Lesson 00's report that described work nobody did.

In an interview loop the same distinction shows up as a design question: build an agent for some task, then say where it fails and how you would know. A strong answer names the actions, the observations the code records, the stopping rule, and the check that compares the final claim with the record. The book's Chapter 16, Evaluation, builds exactly that kind of harness.

Two defaults for the same design question

Once a system can act, you have to decide what it is allowed to attempt. This course keeps returning to two opposite defaults, because they fail in opposite ways.

Act, then check. The model plans and acts with a broad set of tools, and code-level limits catch problems after the fact: budgets on calls and cost, sandboxes, monitors that stop a run that drifts. It gets the most done with the least human effort, and its safety depends on the checks catching a bad action in time.

Refuse by design. The set of possible actions is fixed by configuration. The model interprets what was asked and chooses among the actions that exist; anything outside that set cannot be attempted, whatever the model is told. It is bounded and auditable, and it cannot do what nobody anticipated.

	Act, then check	Refuse by design
Who decides the next action	The model, from a broad tool set	The model, among actions the configuration defines
Safety comes from	Limits and monitors after the choice	The action space itself
Handles ambiguity by	Making a judgment and reporting it	Asking before acting
Fails by	A harmful action the checks miss	A legitimate task nobody anticipated

Lesson 05 studies one capstone for each default: PyNanoClaw, a headless automator from the live class in the style of the open-source Claw agents, and a refuse-by-default agent built the way this site's book builds one, from typed tools, approvals bound to an exact proposal and isolation. The same axis runs through lab work. An agent that submits jobs to a shared training cluster, edits a research codebase, or runs an evaluation sweep overnight sits somewhere on it, and where you put it is a decision about who bears the cost of a mistake. The course Two Architectures spends its whole length on this axis.

Quick check — You are designing an agent that can cancel and resubmit jobs on a shared training cluster used by twenty researchers. A wrongly canceled job loses days of someone else's compute. Which design is easier to defend in a review?

What comes next

Lesson 02 takes the first place an agent quietly fails, its context, and derives why a fact can be present and still not be found.

Continue to Lesson 02

Lost in the middle, derived and measured: why confusable neighbors matter more than context length, and a protocol to check it on your model.