Agent Courses

Agent Courses describes courses an agent can teach in a learner’s own project. A course is a readable folder of Markdown, YAML and check programs. The tutor can type the edits; the learner owns the decisions. This site explains the 1.0 candidate and its repository examples so authors and runner builders can inspect the same contract.

Candidate, with runtime work still ahead

The candidate label is 1.0.0-rc.1. Repository checks exercise schemas, examples and replay rules; they qualify no production runner or host. The public validator, reference library and runner conformance suite are future work. No package installation or live tutoring session is offered here. See candidate and stable status.

A course you can read

A course starts with COURSE.md: its identity, the outcome and an ordered lesson list. Lessons, checks and private tutor rubrics live beside it. The learner’s editable project is separate from the installed course. The course layout explains each folder and who may see its contents.

This course page comes directly from the repository’s tested quickstart example. The include displays source; it does not start a runner.

---
name: quickstart
description: Build a one-file agent and explain it. For beginners.
version: "1.0.0"
license: Apache-2.0
project: [own]
---

# Build a small agent

You'll build a small agent.

## Outcome

`agent.py`: an agent that passes `final-check`.

## Lessons

1. [Meet the agent](lessons/intro.md)
2. [Make the agent](lessons/make.md)
3. [Finish and explain](lessons/finish.md)

Follow the author quickstart to copy every file and run the checkout-only checks. The checks guide, writing guidance and explain-back guide explain the teaching material behind that page.

Load only what is needed

A runner reads course frontmatter for its catalogue, then the full course page when the learner starts. It loads a lesson when that lesson starts. Check files are loaded for checks; tutor rubrics are loaded for judgement, never shown verbatim. References are loaded when a question needs them. These are the format’s loading boundaries, rather than an instruction to ingest every file at once.

Lessons progress through understand, build and a final demonstrate stage. The stage rules define their allowed evidence. Each lesson follows the teaching loop: Goal, build together, learner calls, checks and review. The final lesson adds an explain-back after its checks. Explicit learner gates control progress.

Decisions belong to the learner

A call is a decision reserved for the learner, such as choosing which behaviour a check protects. The tutor can explain options and recommend one, then waits. It never makes that decision for the learner. Read call ownership and building together for the full duties.

This exchange illustrates the contract; it is not output from a shipped runner:

Tutor: Which behaviour should the final check protect? I recommend checking that the tool is registered, because that catches a missing tool.

Learner: Check that the tool is registered.

Tutor: I will make that change and show you why. Before the first check run, I will show its command and wait for your agreement.

A page view or a tutor assertion cannot establish achievement. An objective needs its passing evidence and verified learner ownership of every call in that lesson. A receipt records a protected confirmation binding, without keeping the answer. The receipt boundary requires confirmation, verification and replay protection outside tutor authority. No current host is qualified here. Unsupported hosts leave calls unverified and objectives that depend on those calls unsettled, even when a check passes (settlement).

Local work, explicit trust

Reading or learning requires no account, telemetry or feedback service. Optional feedback needs the learner’s explicit consent for the named destination; declining never changes progress. Records stay local and contain no code, conversations, call answers or answer hashes. A host may retain its own prompt history. See consent and record privacy.

Courses and referenced projects are untrusted input. Course text cannot change host permissions or consent rules. A runner shows commands before execution and follows the host’s permission model (safety and trust).

Choose your next step

• Write a course with the quickstart.
• Inspect the planned runners and their evidence limits.
• Build a runner with the support guide and conformance guide.
• Read the candidate specification, whose canonical sources define the rules. The composed specification route arrives with site integration; its source fragments are already checked here.

A course’s own version, the format’s 1.0 version and an implementation’s release version are separate. The candidate label identifies the proposed specification snapshot, not an implementation release (course versions, candidate status).