User vs. director CORE
Most people who use AI tools today are users. They type, they read what comes back, and they trust or mistrust the output based on how it feels. If the output is wrong, they either ask again with a different prompt or blame the tool. They do not look under the hood, because they do not know there is a hood.
A director starts from the same prompt box, but with a different mental model. A director sees model, loop, tools, state. A director knows the output is next-token prediction, runs in cycles, draws on tools, and lives inside a finite memory. When the output is wrong, a director looks at the trace and asks which part of the system failed, because she knows the parts. When a new task arrives, a director asks what the loop will need to succeed, because she knows a loop is what she is staffing.
The difference between the two is not intelligence. It is mental model. This lesson hands you the vocabulary that makes the director’s view yours, and asks you to use it on something real — the task you will carry through the rest of the course.
The vocabulary you will use from now on CORE
Five terms you have met — scattered — across Lessons 1.1 through 1.4. You will use these words for the rest of the course, so name them cleanly once here.
Scope. What the task includes and, more importantly, what it excludes. A well-scoped task has boundaries you could draw on a whiteboard. “Help me with my homework” has no scope. “Make a 10-question practice quiz for Chapter 7 of my chem book and save it to practice-q.md” has scope.
Grounding. The real-world sources the agent consults before answering — files, searches, APIs, databases. An ungrounded answer comes from the model’s parameters; a grounded answer comes from a tool. Anything that must be exact is an anything-that-must-be-grounded.
Tool surface. The full set of tools the agent can call on a task. A small tool surface (a search + a file writer) produces predictable loops; a large tool surface (search + file + email + calendar + code execution) produces powerful ones, with more ways to go sideways. Sizing the tool surface to the task is a directing decision.
Handoff. The point where one agent, one turn, or one task passes its output to another. Handoffs are where state moves between contexts, and where the most state gets lost. A research agent writing a brief that a drafting agent will read tomorrow: that is a handoff. You will build many of these in Module 8.
Trace. The visible record of the loop. Your diagnostic instrument. Reading traces is a defining skill of a good director.
Use the words. They are not jargon for its own sake; they let you say in a sentence what would otherwise take a paragraph.
The four questions a director asks before touching a tool CORE
When a task arrives, work it in this order. Every time.
- Do I have the right model for this? A local model on your machine for something private and small. A large cloud model for something that needs the model’s best reasoning. A specialized reasoning model for a hard problem. This is the Module 2 question; the answer is never “whatever is cheapest” and never “whatever is biggest.”
- Is my loop well-framed? Does the task have a scope that can be drawn on a whiteboard and a done condition that a reader could test? If not, you do not have a task yet — you have a wish. Rewrite until you do.
- What tools does the agent need, and does it have them? List them in plain English first — “a search,” “a file writer,” “a calendar reader.” Then check: are any of them missing from the tool surface? If so, either add them (Module 7), or redesign the loop so it can succeed without them.
- What state does the agent need, and where does that state live? What information has to be in the context window at the start? What will need to persist past this conversation? What will the agent write to external memory so a future run can pick up where this one left off?
These four questions are the whole course, compressed into one page. Every module from 2 onward elaborates one of them. Make the habit of asking them, and the rest of the course will feel like elaboration on something you already know.
The failure patterns you can now name CORE
Also compressed into one page: the failure patterns from Lessons 1.1 through 1.4, organized by which question they answer.
Model-side failures. Vague input producing generic output (“magic frame” from Lesson 1.1). Confident output on low-data topics (“search engine frame” from Lesson 1.1; hallucination mechanism from Lesson 1.2). Bad arithmetic, miscounted letters, brittle single-shot reasoning on hard problems (token-level prediction from Lesson 1.2).
Loop-side failures. A task that never terminates because it has no done condition (Lesson 1.3). A turn that misreads the task and poisons every subsequent turn (Lesson 1.3). A loop that runs out of turn budget before the work is done (Lesson 1.3).
Tool-side failures. A tool returns an error the model does not notice (Lesson 1.3). A tool was never given to the agent in the first place and the agent answers from parameters instead (Lesson 1.2). The tool surface is wrong-sized for the task — too small to succeed, too large to predict.
State-side failures. Context-window truncation dropping early constraints (Lesson 1.4). New-conversation reset losing everything (Lesson 1.4). Information stored externally but never consulted on this task (Lesson 1.4).
You now have names for most of the ways an agent can fail. Putting the name on it is the first move toward fixing it.
Design your first loop CORE
The rest of this lesson is an active exercise, and it sets your capstone in motion. Open the note you started in Lesson 1.1. By now it has five short pieces: candidate task, confidence-≠-correctness risk, tools, done condition, state. You will now move that note into a proper file and expand it into a one-page loop design — the first draft of your capstone, written all in one place.
It is a sketch, not a build plan. It is specific, not final. What it gives you is something a reader could poke at — is the task actually scoped? is the done condition testable? are the tools named? — before Module 2 starts asking you to stand anything up.
This page is your capstone candidate for the rest of the course. You can revise it, scope it up or down, or change the task entirely before Module 10 — but you need a specific candidate in hand now, so that every subsequent module has something real to attach to. The Try it activity below walks you through the seven sections. Do it on paper or in a text file; one page, plain language, no code.
Try it CORE
Design your first loop
Instructions. Write the following seven sections for your candidate task, in order. One page. Plain language. No code. Save it as my-first-loop.md in your working folder.
- Task, in one sentence. Write it so it has a scope (what the agent will and will not do) and a done condition (something a reader could check to know it finished). Example: “Each weekday morning, write a one-paragraph summary of the top three stories from my news feed and save it to today.md — done when today.md exists with three stories.”
- Why I chose it. What makes this task worth automating? What goes wrong today when you do it by hand?
- Model. What kind of model does this want — local, cloud, small, large, reasoning? Commit to a first guess; you will refine in Module 2.
- Tool surface. The tools, named in plain English.
- State. What goes into the context window up front. What persists to external memory between runs.
- Termination. The precise, testable form of your done condition. Specific file paths, exact counts, observable side effects — something a script could check, not just a person.
- Failure modes I am watching for. Two from Block 4 that are most likely on this task.
Before you call it done, run a self-check:
- Could a classmate or parent read your task sentence and tell when the agent is done? If not, rewrite the done condition.
- Did you name every tool the agent needs? Cross-check by walking through the loop mentally — can you complete the task using only the tools you listed?
- Did you say something specific about state? “The agent will remember things” is not specific. “The agent will read ./notes/log.md at the start of each run and append to it at the end” is specific.
- Did you name two plausible failure modes from Block 4?
If any answer is no, revise. The value of this exercise is not finishing it — it is catching the spots where you have been vague.
Optional stretch: trade designs with another student or a parent. Ask them to read only your one page and then describe, in their own words, what the agent will do and how they would tell whether it succeeded. If they cannot, your design has not fully left your head yet.
A note on "frozen" copies. Throughout this course you'll save certain files as "frozen" snapshots — meaning you copy the current version into your /capstone/ folder and don't edit it again. The working file in your day-to-day folder keeps evolving; the frozen copy is the version you'll point to as evidence at the end of the course. Think of it like saving a photograph of where you were at this moment.
Done with the hands-on?
When the recipe steps and any activity above are complete, mark this stage to unlock the assessment, reflection, and project checkpoint.
Key concepts CORE
- A director starts from the same prompt box as a user, but sees model, loop, tools, and state, and diagnoses by parts.
- Vocabulary of the course: scope, grounding, tool surface, handoff, trace.
- Before touching a tool, ask four questions: right model? well-framed loop? tools present? state in the right place?
- Every failure you have seen in Module 1 belongs to one of four zones: model, loop, tools, state.
- Your capstone candidate is a one-page loop design — specific enough to test, loose enough to revise.
Quick check CORE
Four questions. Pick the best answer, then reveal the explanation.
Show explanation
Answer: C. The difference is mental model, not budget, not coding ability, and not guaranteed output quality. A director is sometimes wrong — but when she is, she can name which part of the system failed and try a targeted fix. A user, facing the same failure, can only re-prompt and hope. D is too strong; good directors still hit walls, but they know where the walls are.
Show explanation
Answer: C. “Figure out what the business needs” has no scope and no done condition, so every downstream decision is fogged in. Before sizing a model or picking tools, rewrite the task as something like “Summarize the 5 most recent Square reports plus the 10 most recent customer emails and produce a 1-page action list in weekly-plan.md.” Now you can reason about model, tools, and state. Loop framing first, always.
Show explanation
Answer: D. This is almost always a context-window truncation — the early constraint has dropped out of the model’s visible state. Lesson 1.4, forgetting mode #1. The fix is usually to write the constraint to a scratchpad file the agent consults on each major turn. A model or loop explanation is possible but far less likely given the specific pattern (good start, late drift).
Show explanation
Answer: B. The one-page design is a candidate, not a commitment. You will revise it as you learn more about models, tools, state, and orchestration in later modules. But having a specific, scoped, plain-language task in hand makes the rest of the course dramatically more useful. A overstates; C misunderstands the sequence; D is not the point of this lesson.
Reflection prompt
Name the biggest assumption you’re making.
In 5–7 sentences, answer: Reread your one-page loop design. Which part felt easiest to write, and which part felt fuzziest or least specific? What would a skeptical parent or friend poke holes in first? Write one sentence naming the single biggest assumption you are making, and how you would test that assumption before Module 10.
The assumption you name here is worth remembering. Capstones fail most often because a buried assumption turns out to be wrong in Week 5 and the whole loop has to be redesigned. Surfacing it now is cheap; surfacing it in Week 5 is expensive.
Project checkpoint
Your first capstone artifact.
Save your one-page loop design as my-first-loop.md in your working folder. That file is the first artifact of your capstone portfolio. Do not delete it even if you change the task completely later — you will revise it at several more module-end checkpoints, and the history of those revisions is part of your credit-documentation evidence for parents.
Make a second copy in /capstone/my-first-loop-v1.md (or its equivalent in your course workspace). This gives you a snapshot of where you started, frozen, while the working file evolves.
Next in Module 1
End-of-module check.
Ten-question integrative assessment, closed-book. Passing bar: 8 of 10, with full credit on at least one applied question. The first formal piece of credit evidence for your portfolio.