The build sequence#
This page is the course map: from a clean clone to a configuration-driven agent you assembled yourself, with every decision inspectable in a saved artifact. Each lesson opens from a named checkpoint and ends with a working component, a run command, an expected artifact, a failure exercise and a completion check.
There are two routes, and the second is optional:
Build a working agent: the core route and shortest path to your own assembled application: the first run → policy and records → stages and observations → model proposals → one marked detour into the controller laboratory for the selection contract, the baselines and the factory (from the top down to the bold return line at the end of step seven, then come straight back) → candidates and dispatch → retrieval and memory → context assembly → evidence and verification → stop, recover, finish → the assembly capstone. The assembled application runs the frozen priority baseline; nothing adaptive is a prerequisite for finishing it or for connecting your own model through examples/app_agent.py.
Investigate adaptive selection: the advanced route, taken after the core or interleaved with it: the rest of the controller laboratory, then LinUCB → the sparse controller → plasticity → optionally graph experiments → the comparison protocol, which is required before making any improvement claim and does not require the graph lesson. The named controllers on this route reconnect to the same application through the configuration's controller key; the graph lesson's experimental arm deliberately stays a research construction outside the factory. The route's additional prerequisites (a little linear algebra, comfort with SQL) are declared where they bite.
Start with the offline lab if you have not run it: it needs no API key or network and it is lesson 1's starting point. Connect a real model only when the model connection guide tells you what to replace and what to keep.
The lessons#
| Lesson | You leave with |
|---|---|
| Run the whole thing first | A reproduced fixture report you can explain line by line |
| Policy, records, write boundary | One recording door; refusals as recorded events |
| Stages and observations | An enforced stage machine and measured-or-unknown observations |
| Model proposals | Validated hypotheses, bounded repair, hostile text refused by policy |
| Candidates and dispatch | An eligible work set with reasons, and six outcome statuses that never blur |
| Retrieval and memory | Hybrid search with component scores, structured lanes, refutation that sticks |
| Context assembly | Tier budgets, whole-block drops, and the omissions record |
| Evidence and verification | Capture-bound findings, an isolated verifier, verdicts validated in host code |
| Stop, recover, finish | Budgets with owners, resume without invented success, a gated finish |
| The controller laboratory | One selection contract, shared feedback, two baselines |
| LinUCB step by step | The bandit arithmetic, worked by hand and recomputed by test |
| The mushroom-body controller | Sparse coding, soft competition and habituation you can replay |
| Plasticity and credit | Eligibility traces, clipped local updates, cross-run priors and their recorded defect |
| Graph controller experiments | The experimental edge-plastic arm and its controls |
| Comparisons and interpretation | The frozen-manifest protocol and scoped readings |
| Package your agent | The assembled, configuration-driven application |
The table lists every lesson; the two routes above tell you which to read first. Each lesson's "Start from here" and "Continue" sections follow those routes. The controller lessons compare adaptive selection with fixed baselines on synthetic worlds. The ordinary application keeps learning off; research constructors turn it on explicitly. The priority baseline is the default. Choose an adaptive controller only when the comparison protocol gives you evidence for your use case, and check the evidence register for what the earlier studies did and did not show.
The shape of every practical lesson#
Build this; start from here; inputs and outputs; implement it; run it; inspect it; break it; check completion; continue. The explanation lives beside the implementation it explains, every run command is copyable from the repository root, every expected artifact is committed and held byte-identical by a sync test, and every completion sentence is pinned to a named test. "Run the tests" is never the whole instruction.
Where the theory went#
The design essays that used to be the main reading path are now the design notes: the determinism argument, the historical case study and its recorded defects, and the controls each failure demanded. Read them when a lesson makes you ask why a control exists; the failure museum and the study appendices carry the evidence.
After the course#
A live adapter is a separate milestone with its own review: every destination, redirects, credentials and secondary requests, plus process restrictions and approved authorization. The offline dispatcher alone cannot contain arbitrary adapter behavior, and no lesson claims otherwise. Evaluate before extending the environment: the evaluation protocol and the completed verifier and factorial studies show what a defensible measurement looks like, and the evidence register keeps every claim's status honest.