Back to course overview
Module 1Agent fundamentals 12 min

What makes an agent?

The line between a pipeline and an agent: the model chooses the next step. The loop, the spectrum of autonomy, and why guardrails become the product.

Everything you've built so far runs on rails you laid: the triage assistant classifies, the RAG pipeline retrieves-then-answers — you decided the steps; the model filled them in. An agent crosses one line: the model decides the next step. It reads the situation, picks a tool, observes the result, and picks again — looping until the task is done or a limit says stop.

the whole ideatext
PIPELINE (you decide the steps):
  input → [step you chose] → [step you chose] → output

AGENT (the model decides, inside limits you set):
  goal → ┌────────────────────────────────┐
         │ model: think → pick tool → act │──▶ done?  → result
         │        ▲ observe result ◀──────│
         └────────────────────────────────┘
         within: allowed tools, budgets, approval gates

What changes when the model steers

  • Capability jumps. Tasks with branching ('look up the order — if it shipped, check the carrier; if not, check inventory') stop needing you to enumerate every branch. The model navigates.
  • Variance jumps with it. A pipeline fails the same way twice; an agent can find novel paths to success and novel paths to failure. Run the same task twice, get two different trajectories — both maybe fine, maybe not.
  • The unit of review changes. You stop reviewing answers and start reviewing trajectories — sequences of decisions and actions. Module 6 is built on this.
  • Actions have consequences. A wrong answer misinforms; a wrong action refunds the wrong customer. The engineering weight shifts from output quality to action safety — which is why Module 5 is the heart of this course, not an appendix.

The autonomy dial (agents aren't binary)

Between 'pipeline' and 'fully autonomous' lies a dial you control per action: some tools the agent uses freely (read-only lookups), some it must ask before using (refunds), some it can only propose (account deletion). Setting this dial deliberately — per tool, per stakes — is most of what 'agent design' means in production. The reckless version isn't 'building agents'; it's leaving the dial at max everywhere. (You'll implement this dial in code in Module 5.)

The course project: the resolution agent

Across three courses you've built Harbor Lane's read side: triage (classify) and HarborDocs (answer). This course builds the resolution agent — it takes a triaged case and resolves it: looks up the order, checks policy via your RAG pipeline (yes, HarborDocs becomes a tool), computes any refund, updates the ticket, and escalates when it should. By Module 7 it's guarded, evaluated, and demo-ready; your capstone builds an agent for your own domain.

Prerequisites check

You'll need everything from Building RAG (Python, the eval mindset, your HarborDocs project if you built it) plus an Anthropic API key. Agents are the payoff for the discipline you've accumulated — schemas, validators, routing tables, golden sets all reappear with higher stakes.