Reference
These are the questions the course set out to make easy. Answer each one out loud before you open the model answer.
Tick the ones you can answer without looking. You can answer 0 of 31 so far. Ticks are saved in this browser only.
A runtime loop in which the model chooses the next action. The runtime executes that action, feeds the result back as context, and repeats until a stop rule fires. A single model call has no loop and no actions. A workflow has steps, but code chooses every one of them. In an agent, the model chooses the steps, inside limits the runtime enforces.
Read more: Chapter 0, from a single call to an agent
Build a context from state. Call the model. If it requested tools, validate and execute them. Append the results to state. Repeat. The loop stops on a final answer, a budget, an error rule, or a person. Then something verifies success with evidence.
Read more: Chapter 1, observe, decide, act, repeat
In the runtime. It has the loop that keeps going, the tools wired to real systems, the permission to use them, the state that persists, and the authority to stop. The model contributes the choice of action. The same model behind a different runtime is a different agent.
Read more: Chapter 0, where intelligence lives and where agency lives
What it learned in training, frozen at a cutoff, plus the context of the current call. Nothing else. Stored history, memory, files, and provider-side conversations only matter once something puts them into a call's context.
Read more: Chapter 0, the model is a function and Chapter 4
The exact input to one model call. It holds instructions, tool definitions, conversation, tool results, retrieved memory, and files. The runtime rebuilds it for every call as a selected view of its state, under a token budget.
Read more: Chapter 4, the anatomy of a context
Everything the system tracks to do its work. That includes the conversation, runtime variables such as the step count, plan, approvals, and budgets, and the outside world it acts on. It also includes whatever is saved so work can resume. State lives in the runtime and its stores. Context is a chosen view of it.
Read more: Chapter 3, runtime state
Information kept beyond the current context to guide future behavior. It reduces to storage, a write policy, retrieval, and injection into context. The common kinds are working, conversation, structured, semantic, episodic, and procedural memory. It is not the model remembering.
By purpose, lifecycle, and reuse. State serves the current run: what is true now and what is pending. Memory is curated for future runs: facts, lessons, and procedures. They overlap. Saved state can be read back as memory, and memory is itself stored state.
Read more: Chapter 5, state vs memory
The runtime lists tools in the context: a name, a description, and an input schema for each. The model emits a structured request with arguments and a call id. The runtime validates the request against the schema and its policy. Then it runs the implementation and returns the result or the error as a message tied to that call id. The model never runs anything.
Read more: Chapter 2, the full flow of a tool call
Generating and maintaining an explicit list of intended future actions. It can be text in the conversation, a todo structure in runtime state that is shown to the model, or the output of a separate planner call that an executor follows. Replanning updates it when an assumption fails.
Read more: Chapter 6, what planning means
Another model call that looks at earlier state or output, such as a draft, a diff, or a trace, and proposes changes. It works best with an outside signal like test results. Without one, it can repeat the same mistake. It always costs extra calls.
Read more: Chapter 6, reflection
Another agent loop that a parent starts, usually through a delegate tool. It has its own context, and often its own prompt, tools, model, permissions, and budget. It returns a result, usually a short one, as a tool result to the parent.
Read more: Chapter 7, subagents from first principles
To keep noisy exploration out of the main context. To run independent subtasks in parallel. To give each role a focused prompt and a narrow set of tools. To use different permissions or different models per role.
Read more: Chapter 7, when multiple agents help
When the work is tightly coupled and needs shared decisions. When the parent needs details that a summary would drop. When the task is small. When cost and latency matter more than breadth. More agents mean more tokens and new ways to fail, such as conflicting results.
Read more: Chapter 7, when they are unnecessary
A reusable package the agent selects at runtime. Depending on the system, it is reusable instructions, a tool bundle, a workflow, a script, a knowledge package, or a learned procedure. A common format is a folder with a SKILL.md file. A short description is always in context, and the body loads only when relevant. Bundled files are read or run when needed.
Read more: Chapter 8, what a skill reduces to
Your code runs the basic loop, and a capable model chooses each step from a few primitives: search, read, edit, and run commands and tests. The environment gives fast, exact feedback from compilers and tests. State lives in files under git, so changes are visible and reversible. Success can be checked. Try, test, and revise behavior emerges from that loop.
Read more: Chapter 9, why coding fits
The model uses only what is in its context. The window is finite. Cost and latency grow with context size. Irrelevant or stale content makes decisions worse. Most capabilities, such as memory, skills, plans, and subagent results, work by changing what is in the context.
Calls get slower and cost more. Quality can drop as relevant details get buried. Eventually the request exceeds the window and fails. Agents respond in a few ways. They trim or offload big tool outputs, compact history into summaries, retrieve just in time, or move work into subagents. Compaction can lose constraints if the summary is careless.
Read more: Chapter 4, compaction
The runtime turns a need into a query plus filters. Keyword or vector search returns candidates. The runtime selects or reranks them under a token budget, checks where they came from and how fresh they are, and puts the survivors into the context. Similarity is not relevance, and relevance is not correctness.
Read more: Chapter 5, a retrieval trace
From saved state. The runtime writes a checkpoint after each step, holding the history, plan, step, and pending actions. On restart it reloads the last checkpoint. It reuses recorded results instead of calling the model again. It handles side effects that were in flight through idempotency keys, or by asking the receiver what actually happened.
Read more: Chapter 12, resumability
It must survive crashes, restarts, deploys, and long waits for events or people. That brings checkpoints, queues, workers, retries, schedules, idempotency, and monitoring. Those are distributed-systems problems. A durable agent is defined by what it can recover from, not by how long it runs.
Read more: Chapter 12, interactive vs durable
Keep these deterministic: security and permissions, money movement, invariants, validation, budgets, known process steps, idempotency, and routing by authoritative data. Let the model handle ambiguous input, choosing tools when the path is unknown, writing content and code, and summarizing. Put each decision where the knowledge is.
Read more: Chapter 19, what should be deterministic
Outside the model. Use enforced gates on the tool path. Use containment: filesystem mounts, sandboxes, and network egress rules. Use controls in the other services: scoped short-lived credentials, branch protection, and access policies. A prompt can state a rule, but it cannot enforce one.
Read more: Chapter 10, permissions vs boundaries
Tools turn model output into real effects, and that output can be wrong or steered by injected text. A sandbox limits what the process can touch at all: files, network destinations, and credentials. That caps the damage even when the model or the approval step fails.
The runtime catches a matching action before it runs. It saves a checkpoint with the exact pending call and asks a person to approve, edit, or reject it. It waits, possibly for days. Then it resumes. An approved call runs exactly as approved. An edited or replacement call goes through the policy again. A rejection goes back to the model as the tool result.
Read more: Chapter 11, the mechanism
Through shared state, messages, an event bus, task queues, parent and child return values, a blackboard, or a database. Each one trades coupling, consistency, visibility, and context cost. Whatever a model must act on has to enter its context, so pass references instead of full contents where you can.
Read more: Chapter 13, tradeoffs
Results that do not change the model's next decision. Missing or vague success criteria. Tools that keep failing with similar errors. Results that were truncated or compacted away, so the model asks again. And a runtime with no exits. The fixes are budgets, repeat detectors, clear success criteria, and escalation to a person.
Read more: Chapter 15, infinite loops
Run whole tasks in reproducible environments, several trials each. Grade the outcome, and sometimes the path, with deterministic checks first and model or human graders after. Track completion, correctness, policy compliance, cost, latency, model calls, interventions, recovery, and robustness. Use pass^k, where all k trials must succeed, when reliability matters.
Choosing the next action, reasoning about errors, writing code and arguments, following long instructions, planning, and judging what is relevant. Even these depend on the context and tools being good.
Read more: Chapter 18, better model
Security boundaries, permissions, durability and recovery, idempotency, budgets, context selection policy, verification, monitoring, and evaluation. A better model can help with some of them, for example by choosing context or grading results better, but code and outside controls must still enforce the guarantees.
Read more: Chapter 18, attributing a gain
Work through the brief. Does it need an agent, or is a workflow enough? Which tools does it need, and what is each one's effect class? Then decide the state, the context policy, memory, planning, and delegation. Name the security boundary and the approval points. Plan for crashes and retries, and decide how you will know it works. Practice on the ten exercises before you trust the habit.
Read more: Chapter 21, the brief template and Chapter 20, the rubric