Week 0: Two Questions Before Any Agent Design

Before you start

Prerequisite: none. This is a short framing lesson before Week 1. After this lesson, you can: name the two questions this course's 2x2 comes from, and say which one a design you have in mind has answered only by accident.

Here is a question in the shape you should practice for an applied-AI role: design an agent system that evaluates every new model checkpoint overnight and explains any regression by morning. It reads like one system. It is four. A researcher asks for an eval run and waits a few seconds for a confirmation. A scoring pipeline runs at night while nobody watches. An investigator reads failing transcripts and drafts an explanation for a human to check. And you, in a coding agent, edit the harness that holds it all together. Each of the four needs its own answer to two questions, and most first designs answer them once, for the whole system, without noticing.

This course teaches you to ask them on purpose, per layer, and then to back each answer with arithmetic and an evaluation.

The two questions

Who is waiting for the result?

A person at a prompt, reading every turn? A researcher who will open a report tomorrow morning? Nobody, only a results table that a later job reads? The answer sets the latency budget, and it sets what a failure looks like when it happens.

Who decides what happens next: the model, or your code?

Does the model choose its next action each turn, which tool and with what arguments? Or does your code hold the route, and the model only fills in a step, such as turning a sentence into a typed command? Anthropic's engineering guide draws the same line: workflows run models and tools "through predefined code paths," while agents "dynamically direct their own processes and tool usage" (Building effective agents, December 2024).

Neither question has a correct answer in the abstract, and neither is a maturity ladder. They are two independent design choices. Cross them and you get four quadrants, each with its own reliability curve, latency budget, token bill and evaluation method.

Two independent axes, crossed into the grid this course teaches. Who is waiting?a person now vs. nobody until later; The 2x2four quadrants, four cost profiles; Who decides the next step?the model vs. your code; Each layer gets its ownarithmetic and its own eval loop — Two independent axes, crossed into the grid this course teaches

Why an applied-AI team cares

A design review, and a system-design interview, both probe the same thing: can you say why a piece of the system is built the way it is, and what it will cost? "I used an agent framework" is not an answer. "This layer is a workflow because its paths are known and a person is waiting; that single model step succeeds on 97% of a labeled set, with this error bar; this other layer is an agent because its paths are not known, and its budget is 15 calls, which costs this much" is an answer. The course builds that second kind of answer, one layer at a time.

Before this course	After this course
One architecture, chosen by the framework you know	A 2x2 you place each layer on before writing code
"Agents are unreliable" as a feeling	`p^n` reliability, per-call latency and quadratic token growth, derived and checked
One eval suite for the whole system, or none	A named eval loop per layer, with error bars
A design you can build	A design you can defend in a review or an interview

Quick check — A team builds an agent that plans its own tool calls. It works well as an overnight job. They then put it behind a chat box where a researcher waits on every turn, and it feels slow and erratic. What changed?

Start Lesson 01: The Question Nobody Asks Before Building

The running design question in full, why "use a smarter model" rarely fixes an architecture mismatch, and the four layers hiding in one sentence.