Most agent courses teach you the buttons. This one teaches the control
system, and you leave holding a harness you wrote yourself: regulator.
Each module opens with a regulatory question an autonomous agent forces on you,
derives the mechanism that answers it, then shows the Pi feature and the typed
treatment underneath regulator, the control plane this course
is built against.
The Viable System Model (VSM) is Stafford Beer's answer to an old question: what does any system, whether an organism, a company or an autonomous agent, need structurally to stay viable while its environment keeps generating more variety than anyone predicted? Ashby's Law gives the constraint: only variety can absorb variety, so a regulator with fewer possible responses than the disturbances it faces will eventually fail somewhere it can't see. A model plus a good prompt is not a regulator. It is a hope, and hope doesn't survive contact with a real codebase, a real filesystem, or real money moving. This course treats the harness itself as the regulator: explicit functions, typed channels, and gates that hold when the prompt is ignored or the model changes, and even when the task has nothing to do with code. More on VSM and the six functions →
If you've used an agent for real work and hit its limits, this course gives you the vocabulary and the mechanism to fix that inside a harness you write yourself.
| Who | What this course gives you |
|---|---|
| Senior / staff engineers | running agents on real codebases: a principled reason for every guardrail, tuned to their repo. |
| Platform & DevEx teams | a design method for an internal agent platform, plus the evaluation machinery to prove it helps. |
| Agent-tool builders | deep Pi extension/SDK competence and a structural critique of "five agents in a trench coat." |
| Technical leaders | a vocabulary for where autonomy is safe, and what evidence would demonstrate it. |
Repo, written modules, recorded walkthroughs, graded labs. Ends at reference-build checkpoint 14.
Two 90-minute live sessions a week, labs between, design reviews, capstone crit.
Modules 01, 02, 03, 09 & 10 only. Labs run on the team's own repository.
Every module is a fixed unit: question → concept → Pi mechanism → build
step → break it → field study → checkpoint. The primer is the one exception: it
teaches the cybernetics the rest relies on, with figures, and builds nothing. Modules 00 to 15 are written end to end in
course/modules/. The capstone is specified in course/ASSESSMENT.md,
and docs/PATHOLOGIES.md catalogs the ways a viable system fails as a whole
(structural, functional, channel, and the agent-specific rows), each mapped to the regulator
that absorbs it, the fixture that reproduces it, and what nothing absorbs yet.
Present the finished harness as a control system, not a feature demo: a system map, a channel table, a mechanism ledger, an enforcement-boundary statement, evidence, the residual uncertainty that's still unresolved, and a boundary critique. The critique asks who may amend the system's purpose, who is affected but cannot challenge it, what its metrics conceal, and when the system itself should be retired. The harness you present has to have survived one run in which the regulatory machinery itself failed, not only its executor. The crit attacks from the course's catalog of pathologies, the ways a viable system fails as a whole.
This isn't a hypothetical. regulator is the product itself,
and it's already running end to end: the agentic loop, a versioned
recovery policy, a that never
trusts a unit's own report, and a read-only control room over all of it. You build it
the same way, one checkpoint per lesson.
The full architecture (the control model, the orchestrator, the mechanism hierarchy, and the control room) has its own page. How a unit runs draws the mechanism out end to end, and the worked example declares a second workload, a household ledger instead of a codebase, to show what's yours to design versus what the harness already gives you.