The Compound Learning Loop: Corrections Become Rules
Every correction that evaporates at session end is a correction you will make again — the compounding loop converts one-time fixes into permanent behavior change, with receipts.
The Receipt That Changes Everything
A content pipeline's review caught an error class: a mismarked answer key. The answer index pointed to option B, but the explanation defended option C. One rule was added to the build spec: every future run would triple-check that each answer index marks the option its explanation actually defends.
The next run of 40 items produced zero errors of that class.
That is the compounding loop working — not as a concept, but as a receipt. One correction became a structural rule. Every subsequent run read that rule. The error class stopped recurring. The lesson cost one session's review time and paid off across every run that followed.
This lesson is about how to build that loop deliberately, at scale, and with the receipts to prove it.
Why Sessions Evaporate
Every correction you make in a session — a rule discovered, a mistake understood, a better approach found — lives only as long as the context window. When the session ends, that knowledge is gone. The next session starts from the model's baseline, with no memory of what was learned.
This is not a bug. It is the designed behavior of context windows. The context window is working memory: fast, capacious for the task, and deliberately non-persistent. If it were persistent, it would become bloated with irrelevant history. The design is correct.
The consequence is that without a deliberate compounding loop, agent quality does not improve over time. You make the same corrections, discover the same rules, encounter the same failure modes — session after session. The lessons exist; they just never leave the session that produced them.
The compounding loop converts the correction into something permanent.
The loop has six stages. A session ends. A retro pass extracts candidate lessons from the transcript. Each candidate passes through a dedupe gate before being written to the store. The next session hydrates the stored lessons. The agent's behavior changes because the relevant rule is now in its context at the start of the session. The error class stops recurring.
The key architectural insight is that none of these stages are manual. A manual retro, run when someone remembers, produces inconsistent results and misses most sessions. The compounding loop is worth building only if it is automated end-to-end.
The Write Path Is Still a Gate
The write-path lesson established that the write path is a dedupe gate, not a log. That rule applies here with extra urgency.
Consider what happens without the gate: a session ends, a retro extracts five candidate lessons, all five are inserted as new rows. Two of them are near-duplicates of lessons already in the store. Over fifty sessions, the store accumulates hundreds of near-identical procedural rules. Recall surfaces five versions of the same lesson, crowding out everything else. This is the duplicate spiral from the write-path lesson, recreated systematically by an automated pipeline that forgot to check before writing.
The fix is identical to the write-path lesson: embed the candidate, search the store for near-matches (cosine distance < 0.08), and supersede instead of append. The retro pipeline's write path must be a dedupe gate. Automation without a gate is worse than a manual process, because it runs at scale.
The Escalation Ladder
Not all lessons belong in the same place. Some observations are one-offs that belong in the store as episodic memories. Some rules are strong enough that they belong in a build spec every run reads. Understanding where a lesson belongs is as important as writing it.
The ladder has four rungs. An observation that stays at L1 (noticed but not stored) is lost when the session ends — that is the baseline behavior we are trying to escape. An L2 lesson entry is written to the memories store and hydrated by relevant future sessions. An L3 spec rule is promoted into a build spec or protocol document that every run reads as a hard requirement. An L4 context file is added to the always-loaded session context — the axioms of the system.
The promotion signal is repetition. A lesson that recurs at L2 means the rule-as-context approach is not strong enough. The agent is reading the lesson and still making the error. Promote it: move it into the build spec where it is a hard requirement, not a soft reminder.
Measuring Compounding
Compounding is not a feeling. It is measurable. The question is simple: did the error class that produced this lesson recur after the lesson was stored?
The most direct measurement is to tag stored lessons with the error class they address, then track whether that class appears in subsequent session transcripts. Zero recurrences of a tagged class is a receipt. One or more recurrences means the rule is not strong enough and should be escalated.
A system that cannot produce these receipts is not compounding — it is remembering. The distinction matters. A notes file that grows over time is not compounding; it is accumulating. Compounding requires that the accumulated knowledge measurably changes behavior. The receipt is the evidence.
For the academy itself, this pattern is live: the build spec that every lesson review pass reads was updated with exactly this rule — triple-check each answer index marks the option its explanation defends. The lesson is now a structural constraint on every future build. The error class that produced it has not recurred. That is the receipt this lesson was built on.
Claude Code and Mission Control
Claude Code uses this pattern in practice. When the operator identifies a correction mid-session, the lessons.md file in the project root captures the rule — what went wrong, why, and the rule to prevent recurrence. At the next session, that file is read before any work begins. The rule is active. The correction compounds.
Mission Control operates the same way at fleet scale. Lessons learned during incident resolution are stored as procedural memories and hydrated before the next session involving the affected system. An agent fleet where every agent hydrates the same incident lessons does not rediscover the same failure modes independently.
The pattern scales from a single developer's workflow to a multi-agent fleet. The loop is the same; the automation requirements scale with the fleet size.
Building the Retro Pipeline
The challenge for this lesson assembles the automated retro pipeline: extract candidate lessons from a session transcript using claude-haiku-4-5 structured output, then write each candidate through a dedupe gate.
The extraction prompt instructs the model to identify rules that prevent recurrence of errors — not session trivia, not one-time observations, but procedural knowledge that belongs in permanent storage. The structured output schema requires additionalProperties: false at every level, including nested objects, and no min/max constraint families. The write step calls the same search-before-write pattern from the write-path lesson.
A well-built retro pipeline turns every session end into a write opportunity. Over time, the store accumulates a growing body of procedural knowledge that every future session draws from. The corrections compound.