Maintenance (Lesson 34.4) keeps memory true. This lesson improves the agent itself — its instructions, knowledge, tools, and checks — without letting it rewrite its own job description at 3 AM.

A learning loop is not retraining

Clear the biggest misconception first. Most product agents do not retrain their underlying model after every conversation. No nightly brain surgery. The model weights stay fixed; what improves is everything around them:

• Feedback reviewed — ratings, corrections, escalations collected deliberately.
• Instructions improved — clearer rules, tighter prompts, better examples.
• Knowledge updated — fixed articles, new sources, expired passages removed.
• Tools improved — more reliable calls, better validation, narrower permissions.
• Evaluation sets grown — past failures converted into permanent regression tests.
• Releases controlled — changes shipped in versions, monitored, rollback-ready.

A learning loop is this cycle: real interactions produce signals, humans (or human-governed processes) turn signals into proposed improvements, improvements are tested against fixed cases, approved, released, and watched. The agent gets better because the *system* learns — not because the model silently absorbed last Tuesday's argument.

The safe loop, end to end

Follow one support agent for a routine-questions product:

Customer interaction
  → outcome / rating / escalation signal
  → review queue
  → identify knowledge, policy, or workflow gap
  → proposed improvement
  → test against evaluation cases
  → human-approved release
  → monitor the new version

Concretely: the agent answers password-reset and refund-status questions. Unresolved conversations, one-star ratings, agent corrections, and human escalations land in a review queue — triaged weekly, not acted on individually. The team notices a cluster: six users asked about prorated refunds and got hedged non-answers. The gap is a missing knowledge-base article, possibly plus an unsafe instruction ("never quote amounts" — too broad). The proposal: add a prorated-refunds article with worked figures and narrow the instruction to "never quote amounts not in the knowledge base." The team tests the new version against a fixed set of previous cases — including the six failures and twenty old successes — and only then releases it. Monitoring watches the refund-question success rate and escalation count for two weeks.

Every arrow in that diagram has an owner and a record. That is what makes it a loop instead of a rumor.

What must not happen

The loop above is deliberately slow at the dangerous steps. Name the prohibitions outright — the agent must never do these on its own authority:

• Silently rewrite its own rules or instructions.
• Expand its own permissions or tool access.
• Change prices, discounts, or financial logic.
• Alter accounting, compliance, or safety behavior.
• Adopt a new behavior from one noisy customer interaction ("one user demanded it" is not evidence).

Each prohibition has the same root cause: a single interaction is anecdote, not policy. A furious user, a clever prompt injection, a misheard figure — any of these, learned instantly, becomes a vulnerability or a financial incident. Improvement proposals wait for patterns, and patterns wait for the review queue.

The ladder: consequential means slower plus evidence

Not every improvement needs the same ceremony. Match governance to consequence:

A support FAQ can update weekly after review — low blast radius, easy rollback. Trading or accounting logic needs far stronger validation and explicit human governance: larger eval sets, staged exposure, independent approval, and audit records that survive the change. The more consequential the agent's decisions, the slower and more evidence-based its improvement cycle. Speed is a property of the loop's *position on the ladder*, never a default.

Exercise: create LEARNING-LOOP.md

For one agent, write a LEARNING-LOOP.md with these fields filled for a single realistic improvement: signal, reviewer, proposed change, evaluation set, approval owner, rollout scope, rollback trigger, audit record.

Example skeleton:

Signal: 6 prorated-refund escalations in review queue (week of Sep 7)
Reviewer: support lead triages; knowledge owner drafts
Proposed change: add KB article REFUND-PRORATE-04 + narrow amount-quoting instruction
Evaluation set: 6 failed cases + 20 past successes (frozen set v12)
Approval owner: product owner signs release v2.4
Rollout scope: 10% of traffic, 3 days, then full
Rollback trigger: escalation rate on refund questions rises vs baseline
Audit record: queue IDs, article diff, eval results, approval note — retained 1 year

Then add the ladder line: where on the FAQ-to-trading spectrum this change sits, and why its governance fits.

Finish line: a committed LEARNING-LOOP.md with all eight fields plus the ladder justification, for one real improvement.

Verification: replay a hostile case — one angry user demanding a refund exception. Trace it through your doc: does it reach the eval set as one signal among many, or does it jump straight to a rule change? If any path lets a single interaction rewrite behavior, close it.

Common failure mode: a loop with no frozen eval set — "we tested a few examples and it looked fine." Past failures that are not preserved as tests recur on schedule.

Check your understanding

• Why is per-chat retraining neither what happens nor what you should want?
• Name three things an agent must never change on its own, and why one noisy interaction is not evidence.
• How does the action ladder from earlier classes reappear in learning-loop governance?

Next

Class 34 closes with the full picture: context is the desk, files / databases / retrieval are the stores, user memory runs on permission, maintenance keeps it fresh, and learning loops improve the system under human control. Part IX takes this agent — memory, tools, and all — into AI development methods: directing coding agents, planning work, preserving context, and keeping control over larger projects.