Curriculum agents (University)

The capstone assembles every piece of the track into one autonomous system. In the playground’s University, a Dean agent (a reasoning graph — last chapter’s machinery) decomposes a domain into an ordered curriculum; each subject is taught by generating coursework and fine-tuning the student (the SFT/LoRA machinery from two chapters ago); a teacher-judged exam decides mastery (the RLAIF judge, now wearing academic robes); failures trigger re-teaching (a feedback loop — this chapter’s own contribution); and mastered subjects are saved as composable skills. This chapter supplies the theory under each joint — and, in its widget, the uncomfortable statistics of letting an imperfect judge decide who graduates.

Curriculum learning: does order matter?

The premise that teaching order matters for machines is older than LLMs: Elman’s “starting small” (1993) and Bengio et al.’s formalization (2009) showed easy-to-hard ordering can speed learning and improve final quality — the intuition being that early easy examples shape a loss landscape (Foundations module) whose basins guide later hard learning, rather than dropping the learner straight into a non-convex wilderness. The honest modern record adds the caveats: gains are strongest when the difficulty signal is real and the domain is genuinely hierarchical (you cannot learn policy-gradient math before expectations), and curricula can hurt when the easy stage induces shortcuts the hard stage must unlearn. In modern LLM practice the idea is everywhere under other names — data mixture schedules across pretraining, staged post-training (SFT before preference optimization — the order your own playground pipeline enforces, for exactly this reason), and RL curricula from short horizons to long ones.

What is new in the University is who designs it: the curriculum is authored at runtime by a model, from a domain description. That works for the same generator–verifier-gap reason reasoning loops work — decomposing a field into an ordered syllabus is a task LLM planners are demonstrably decent at, and its output is checkable (the exam results feed back into re-planning: a Dean that ordered badly sees the failures).

The mastery loop: teaching as closed-loop control

Each subject runs the cycle: teach → examine → branch (mastered → next subject; failed → re-teach with more/different coursework). Control-theoretically, this is a feedback controller regulating a plant (the student’s competence) toward a setpoint (the mastery bar τ), using a noisy sensor (the exam). Two classic control pathologies map directly onto training-run behaviour you will see in the lab:

• Actuator saturation. If the student’s capacity ceiling for a subject is below τ, no amount of re-teaching converges — the loop needs a stopping rule (the playground’s attempt cap and budget/time limits) or it burns the budget on an unreachable setpoint.
• Sensor noise. The branch decision is only as good as the exam. This deserves mathematics, not vibes — because every certification the system emits flows through it.

The examiner problem: certifying mastery with a noisy judge

Model an exam as $n$ questions; the student answers each correctly with probability $p$ (their true mastery); the judge grades each answer correctly with probability $a$ (its accuracy — position-swaps and temperature-0 grading, from the distillation chapter, exist to push $a$ up). A question is recorded correct with probability

and the student is certified when the recorded score clears the bar: $\Pr(\text{cert}) = \Pr\!\big(\mathrm{Bin}(n, q) \ge \lceil \tau n \rceil\big)$. Note the pincer: at $a = 1$, $q = p$ and the exam is an honest (if finite-sample) measurement; at $a = 0.5$, $q = 0.5$ regardless of $p$ — the exam is a coin flip and the curriculum’s entire control loop is steering on noise.

This little model earns three design rules the playground implements and any agent-evaluation pipeline should copy: spend on the judge before spending on the student (a better $a$ moves every curve at once); n is cheap statistical power (more exam questions sharpen certification for free, up to the judge’s ceiling); and let a human override — the campus’s grade-override buttons are the human-in-the-loop correction for exactly the failure mode the widget displays.

Skills as artifacts: the registry, merging, and interference

Each mastered subject is saved as a LoRA adapter (the $BA$ factors from the distillation chapter) plus its coursework and transcript — a skill you can toggle, retrain, or combine. The University rebuilds a deployable model by merging enabled skills’ low-rank updates. The linear algebra of why this works at all, and when it does not: each adapter is a low-rank nudge in weight space; summing nudges trained independently is safe exactly to the extent they occupy weakly-interacting subspaces. Related subjects write to overlapping directions and interfere — merged performance dips below individually-measured mastery, the multi-task forgetting problem in miniature (and the reason the transcripts store per-skill retention checks). The mitigation toolbox mirrors the research line — TIES/DARE-style pruning-then-merging of adapter deltas, or routing between adapters instead of summing them — but the load-bearing practice in the playground is simpler: measure after merging, because a skill registry whose entries were only ever tested alone is an inventory of untested combinations.

The capstone’s actual thesis, stated once directly: training pipelines are becoming agent systems. A Dean planning a curriculum, generating data, judging exams and deciding what to re-teach is the same architecture as any agentic workflow — reasoning loops for planning, distillation for skill transfer, RLAIF judging for feedback, and closed-loop control gluing them — applied to the making of models rather than the answering of queries. Every failure mode you learned in this track (reward hacking, judge bias, non-stationarity, interference) reappears here as an institutional failure mode: hackable exams, inflated grades, curricula optimized to the test. The track ends where AI engineering currently stands: the hard problems are the evaluation problems.

Exercises