How this course works

Two things are true of this course, and they balance against each other: everything you write runs locally, and nothing you write calls a remote model. This lesson covers what that combination provides, what it leaves out, and how the exercises operate.

Where this ends up

The last two modules are capstone projects that apply every mechanism covered earlier in the course.

The first is a support agent that handles automated escalation. It answers customer queries from a knowledge base, annotates factual claims with source document identifiers, refuses queries outside the knowledge base, and hands unresolved conversations to human operators with an actionable summary. A test harness grades the agent against simulated customer dialogues, failing it for premature handoffs or for continuing past the point where human intervention was required.

The second project is a research briefing pipeline. It fans questions out to worker tasks, synthesizes a unified brief from the returned findings, and runs a validation pass to ensure cited documents support every claim. Unsupported assertions are removed before generating the final report.

The preceding modules build the required components: model completions, token budgeting, prompt construction, tool execution loops, retrieval pipelines, agent runtimes, multi-agent handoffs, and schema validation.

The shape of a lesson

Each lesson pairs technical explanation with an implementation exercise. The text defines concepts and data structures; the exercise requires writing working code against automated unit tests.

The desktop workspace displays three panes: the lesson text, a code editor, and a terminal. When an exercise opens, the editor presents a stub definition:

def count_words(content: str | None) -> int:
    """
    Count the whitespace separated words in one message's content.

    Args:
        content: the text of a message, or None. None is not an error here. An
            assistant turn that only calls a tool carries no text at all.

    Returns:
        The number of words. Runs of spaces, tabs and newlines count as a single
        separator. Both None and "" count zero.
    """
    raise NotImplementedError

Running the test suite before writing implementation code confirms that the test runner executes properly:

$ python3 test.py
test_an_empty_string_is_zero (__main__.TestCountingWords.test_an_empty_string_is_zero) ... ERROR
test_collapses_runs_of_whitespace (__main__.TestCountingWords.test_collapses_runs_of_whitespace) ... ERROR
...
Ran 16 tests in 0.001s

FAILED (errors=16)

Implement the functions one at a time, running the test suite after each modification until all assertions pass.

The docstring serves as the functional specification. It defines edge cases, such as None handling, directly in the parameter description. When docstring prose leaves ambiguity, inspect test.py for exact expected behavior. Keep reference.py closed until you have completed your own attempt.

Conceptual lessons without exercises cover foundational architecture where code implementation is not required.

The scaffold and reference solutions

When opening an exercise for the first time, the application copies scaffold.py to solution.py. The scaffold contains type signatures, docstrings, and NotImplementedError bodies. Your implementation belongs in solution.py.

The reference solution is complete and accessible behind a confirmation prompt. Comparing your working implementation against the reference solution highlights differences in architecture and style. You evaluate alternative designs with the full context of the problem fresh in mind.

Viewing the reference before attempting the exercise bypasses the problem-solving process. Recognizing a correct implementation is easier than generating one from scratch; passive reading gives an illusion of mastery that fails during independent implementation.

When you lack necessary context or an explanation is unclear, continued effort without guidance is counterproductive. The exercise timebox helps identify when to consult reference material.

Twenty-minute timeboxes

Each exercise suggests a time limit, typically twenty minutes. The timer serves as an advisory boundary rather than an enforcement mechanism.

During active problem solving, attempting candidate implementations clarifies the problem constraints. Arriving at the reference solution with specific unresolved questions makes design decisions clear and memorable.

If you have spent several minutes rereading lines without forming new hypotheses, check the reference solution. If you are actively making progress, continue working past the timer.

Mock models in testing

All exercises execute against mockllm, a deterministic client included with the course. The mock client accepts pre-scripted responses and returns standard completion objects matching production SDK structures:

client = MockClient([text("Six on weekdays.")])   # in this course and in CI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])   # only in a live integration

# Everything below this line is identical either way.
response = client.chat.completions.create(model=MODEL, messages=messages)

Mirroring standard API response schemas lets the same application code be exercised offline and, separately, in an explicitly configured live integration. This course does not run that live path.

This setup offers three practical benefits:

1. Fast test execution (typically under one second).
2. Deterministic outputs, ensuring test failures originate entirely in your code rather than stochastic model variance or API outages.
3. Offline execution without external API keys or network dependencies.

Working without a live model means you will not observe live model quirks, such as non-deterministic instruction drift or hallucinated tool parameters. You will practice the surrounding engineering: conversation state management, tool dispatch loops, schema validation, and error recovery.

Environment requirements

The course requires Python 3.10 or newer.

No external packages, virtual environments, or Docker containers are required. mockllm uses only the Python standard library, and tests run via unittest. The next lesson verifies your local environment.