Continual learning is training a model on a sequence of tasks or data distributions over time so that it acquires new capability without losing what it already learned. The problem it exists to solve is catastrophic forgetting: when you keep training a neural network on new data, the updates that fit the new data overwrite the parameters that encoded the old, and performance on earlier tasks collapses. Everything in the field is a response to that.
This is an established research term with a specific technical meaning. It is also, more recently, used loosely to describe LLM applications and agents that “learn” from production feedback. Those are usually not the same thing at all. An agent that retrieves better examples, carries memory between sessions, or runs on a prompt someone improved last week has not trained on anything, and none of its weights have changed. Both usages are in circulation, so this page covers the research meaning first and then says plainly where the loose usage differs.
If you are here because you want your LLM feature to get better over time, the second half is what you need, and the answer there almost never involves continual learning in the technical sense.
Key takeaways
- Continual learning means learning from a sequence of tasks while retaining earlier capability. Catastrophic forgetting is the central obstacle.
- The tension is stability versus plasticity: a model rigid enough to retain everything cannot absorb anything new.
- Method families group into replay, regularization, and parameter isolation, each trading storage, compute, or capacity for retention.
- Evaluation has to measure retention on earlier tasks. A model that looks excellent on the current task may have lost the previous three.
- An agent improving from feedback without a weight update is a different practice with different failure modes.
Catastrophic forgetting, and why it happens
Standard supervised training assumes the data is shuffled and drawn from one distribution. Continual learning breaks that assumption on purpose: data arrives in sequence, one task or distribution at a time, and earlier data is often gone by the time later data arrives.
The mechanism follows from how these models represent things. Parameters are shared across everything the network has learned, so gradient descent on a new task moves weights that earlier tasks depended on. Nothing in the objective asks the model to preserve earlier performance, because the loss it minimizes only refers to the data in front of it. Fit the new task well enough and the old task’s accuracy falls, sometimes sharply.
That produces the stability-plasticity tradeoff, the frame worth carrying around. Constrain the model to protect prior knowledge and you limit how much it can learn next. Leave it free to adapt and it forgets. Every method is a position on that dial rather than an escape from it.
The literature separates scenarios: task-incremental settings tell the model which task it is performing, domain-incremental settings keep the task and shift the input distribution, and class-incremental settings add categories without saying which group an input belongs to.
Families of methods
In general terms, since the specifics move quickly and the families are stable.
Replay. Keep a buffer of earlier examples and mix them into training on the new task.
Regularization-based. Penalize moving parameters that mattered for earlier tasks.
Parameter isolation. Freeze earlier parameters, add modules, or attach adapters while the base model stays fixed. Keep this separate from fine-tuning as a one-time adaptation to a new task, which never asks you to preserve performance on the original.
Measuring it
Single-task accuracy is the wrong instrument, and this is the most common mistake teams make when borrowing the idea informally. Train on task four, report task four accuracy, and you measured plasticity while saying nothing about stability. The measurements that mean something are sequential: average performance across all tasks seen so far, and the drop on each earlier task from its peak after later training. Forgetting is that drop, so tracking it means keeping old test sets long after their training data is gone.
The loose usage, and how it differs
The phrase now gets applied to systems that improve from production feedback without any training. Those practices are real and useful, and none of them are continual learning in the sense above.
- Retrieval and memory. Storing prior interactions, documents, or corrections and pulling them into context changes what the model is given, not what the model is.
- Prompt and instruction updates. Rewriting prompts, adding examples, tightening tool descriptions after observed failures. The improvement lives in text you can diff, which is the appeal of optimizing an LLM system from feedback rather than from gradients.
- Growing eval sets. Every production failure becomes a permanent test case, and the system improves because the code and people around the model improve.
- Harness changes. Better context assembly, retries, limits, and stopping conditions.
The difference is not pedantry. Catastrophic forgetting requires gradient updates to shared parameters. Systems that never train suffer different failures: stale memory, bad retrieval, and prompt edits that fix one case while breaking two others.
Most teams skip real continual learning on a deployed LLM because the alternatives are cheaper and safer. A prompt change ships in an afternoon and reverts in minutes. A weight update costs compute, needs a full re-evaluation, and rolls back only if you kept the old checkpoint. When you need that loop in production, start with continuous model monitoring and improvement practices rather than weight updates by default.
FAQ
What is catastrophic forgetting?
The sharp loss of performance on previously learned tasks after training on new data. Parameters are shared across everything the model has learned, and the loss for the new task has no term asking it to preserve the old, so updates that fit new data damage the representations the old task relied on.
Is an agent that improves from feedback doing continual learning?
Usually not. If the improvement comes from retrieved examples, updated memory, a revised prompt, a better tool schema, or a larger eval set, no model was trained and no forgetting in the technical sense can occur. That is a feedback loop around a fixed model: a legitimate practice and a different one. It becomes continual learning only when weights are updated on a sequence of data.
Do I need continual learning to keep my LLM application current?
Almost certainly not. Keeping knowledge current is usually a retrieval problem, and keeping behavior current is usually a prompt, tool, and eval problem. Reach for weight updates when you need capability the model lacks rather than information it has not seen.
