10.1 Frozen Models and Changing Systems
[DEMO: Two identical LLM-backed agents answer a sequence of similar tasks. Both use the same underlying model and temperature. The left agent always uses a static prompt and fixed retrieval configuration. The right agent stores successful interactions and periodically updates its prompt and retrieval rules based on those examples. Users can step through tasks; over time the right agent’s answers measurably improve while the left agent’s do not, despite identical model weights.] You can ship an agent, do nothing to the model, and watch performance improve over weeks: fewer escalations, better formatting, fewer hallucinations on common queries. The model is fixed, the weights are identical, and every inference call is stateless, so any accumulated experience must live outside the model. Architecturally, the agent is the composite system, not the model alone. Improvement accumulates in the components you control.The model doesn’t learn; the system learns. Improvement lives in everything that can change around a fixed reasoning engine: prompts, examples, retrieval configuration, routing rules, and external knowledge.
LLMClient changes. You never touch weights. All of the improvement happens in the wrapper:
- The prompt library can be edited.
- The set of good examples can grow.
- The routing hints can accumulate new guidelines.
10.2 The Difference Between Learning and Memory
[DEMO: On the left, an agent with a “tape recorder” log: it stores entire past interactions and can retrieve and replay them into context. On the right, an otherwise identical agent that, after each task, extracts a short “lesson” (a generalized rule) and stores that instead. Users can run varied tasks; the left agent can quote prior interactions but keeps repeating old mistakes, while the right agent begins to avoid classes of mistakes even on new, unseen inputs.] By Chapter 2 you already had memory: databases, vector stores, logs. By Chapter 9 you had feedback: scores, critiques, test failures. You can now store almost anything and you can judge almost everything. Logging every interaction and replaying it into context does not necessarily mean the system has learned. Adding evaluation labels also does not guarantee learning. Pasting past successes verbatim into prompts remains memory until it is processed into general rules. The line is easy to blur, because both memory and learning involve putting bits somewhere and reading them later. But they play different roles.Memory stores information; learning stores patterns that improve performance. Few-shot examples, routing rules, and distilled guidelines are memory that has been processed into reusable behavior.
- Generalization. Memory lets you copy-and-paste previous behavior. Learning lets you adapt to new inputs that merely rhyme with the old ones.
- Compression. You can only fit so much into the context window. Storing a rule (“always ask for the account ID before answering a billing question”) is cheaper than replaying ten transcripts where that turned out to be necessary.
- Control. Patterns are audit-able. You can read through a list of lessons and see what the system has “internalized.” Raw logs are opaque.
10.3 Managing Example Accumulation
[DEMO: An interface shows a live prompt for a particular task type, with a panel of “candidate examples” collected from past usage. Users can click to accept or reject examples, or let the system auto-select based on similarity. As more tasks run, the prompt on the right either steadily improves (when selection is curated) or bloats and degrades (when every past example is appended). A metric chart shows performance over time under each strategy.] Learning lives in prompts, examples, routing, and knowledge. This raises another question: as those artifacts accumulate, how do you prevent them from turning into noise? If you keep adding examples to prompts, you need a stopping rule. If every good interaction becomes a demonstration, you risk filling the context window with old news. When the system edits its own instructions, you must decide which edits persist and which get rolled back. “Just store what worked” is not enough. Without selection, learning collapses back into memory: a pile of episodes with no structure. Without forgetting, new knowledge gets buried under old, and previously helpful examples become misleading as the domain shifts.Examples accumulate usefully when you treat them as a retrieval problem. You store many, select few. The system learns not by hoarding every success, but by choosing the most relevant, current, and representative patterns for each new task.
- The
examplesarray can grow large. - The prompt never sees more than
maxExamplesfor a given task. - Old examples gradually lose influence via the age penalty.
- Low-similarity or low-quality examples rarely surface.
- Learning is constrained by the context window. You cannot “remember everything” and “use everything.” Retrieval is the valve that determines what actually affects behavior.
- Staleness is domain-dependent. In a fast-moving domain (policies, prices, medical guidelines), your age penalty should be aggressive; in a stable domain (math proofs), examples can remain valid far longer.
- Human oversight scales further than you think. You do not need to hand-curate every example. For example, instead of reviewing thousands of support tickets, a reviewer can examine 10–20 archetypal examples per week before they are added to the prompt library. You only need to review the patterns the system proposes to keep.
10.4 System-Level vs Model-Level Learning
[DEMO: Three panels compare approaches on the same evaluation set. Panel A: a vanilla agent with static prompts and no adaptation. Panel B: an adaptive agent that logs outcomes, updates prompts and retrieval, and uses distilled lessons, but never fine-tunes the model. Panel C: an agent backed by a custom fine-tuned model but with static prompts. Users can toggle which axes to view (accuracy on old tasks, accuracy on new tasks, robustness to distribution shift). The demo highlights that system-level learning improves performance without erasing capabilities, while model fine-tuning can boost some areas while degrading others.] By now we have a clear recipe for system-level learning:- Use feedback (Chapter 9) to identify what went wrong or right on a task.
- Distill that into patterns, examples, or updates to prompts, routing, and knowledge.
- Store those patterns somewhere persistent.
- Retrieve the relevant subset for the next task.
Feedback improves a single task; learning connects that feedback to future tasks via storage and reuse. System-level learning changes the wrapper and is reversible and local. Model-level learning (fine-tuning) changes the core and can improve capabilities at the cost of forgetting or distorting others.
- If the model simply cannot perform a capability at all (e.g., a small model consistently fails at nontrivial code synthesis), no amount of prompt cleverness will conjure the missing competence.
- If you want to encode domain knowledge so deeply that it is always “there” even without retrieval, you eventually face the context window and latency costs of external memory.
- In system-level learning, you update prompts, examples, routing rules, and knowledge inside your own infrastructure.
- In model-level learning, you feed labeled examples into a separate training run that produces a new set of weights.
- Safety. System-level changes are easy to sandbox and roll back. If a new routing rule is bad, you delete one row. If a fine-tune is bad, you have a misaligned model and need to revert the whole artifact.
- Scope. Wrapper changes affect specific surfaces (a task type, a tool, a prompt). Fine-tuning changes behavior everywhere, including places you did not test.
- Forgetting. System-level learning rarely destroys previous capabilities; at worst it can overshadow them with new prompts. Fine-tuning can overwrite internal representations (“catastrophic forgetting”), making the model worse on tasks it previously handled well.
- Use system-level mechanisms to adapt quickly, cheaply, and safely.
- Use the data they generate to inform occasional fine-tunes when there is a clear, well-scoped need (for example, a narrow domain where context-based retrieval is too slow or unwieldy).
- The wrapper (prompts, examples, retrieval, routing, knowledge).
- The weights (a new model or fine-tune).
10.5 Putting It Together: An Improving Agent Architecture
The elements from previous chapters come together here. You already know how to store state (Chapter 2), schedule autonomous work (Chapter 7), evaluate (Chapter 8), and feed feedback into multi-step loops (Chapter 9). Learning is what happens when you point those capabilities across tasks instead of just within one. The following class sketches an architecture for an improving agent:promptLibraryholds evolving instructions.examplesandlessonshold distilled patterns from experience.knowledgeBaseholds growing domain knowledge.nightlyReflectionis the scheduled feedback-to-learning bridge.
- A personalized assistant is one whose prompts and lessons are keyed by user ID.
- A team-adapted agent is one whose examples and routing rules are filtered by team.
- A self-improving system is one with credible evaluation, disciplined logging, and scheduled routines that convert feedback into concrete updates.
Key Takeaways
- The model’s weights are frozen in production. What users experience as “learning” is the evolution of prompts, examples, routing rules, and external knowledge—components you control.
- Memory and learning are not the same. Memory stores episodes; learning extracts and stores patterns that change future behavior. Few-shot examples are learning in compressed, concrete form.
- Example accumulation is a retrieval problem, not a hoarding problem. You can store many, but you should select few: relevant, recent, high-quality, and representative.
- System-level learning is safe and local: you change the wrapper, not the core. Model-level learning (fine-tuning) is powerful but global and risky: you change the core behavior and can accidentally erase prior capabilities.
- Architecturally, learning appears as three hooks: before-task application of accumulated knowledge, after-task capture of feedback, and periodic reflection that turns feedback into updated scaffolding.