Continual Learning: The Capability Models Still Lack

A model you use today knows nothing about your conversation with it yesterday unless you paste it back in. That is true of every deployed system, and the reasons are only partly about research difficulty.

What is actually missing

Continual learning is the ability to keep acquiring new knowledge and skills from a stream of experience without losing what was learned before, without retraining from scratch, and without needing the old data to still be available. Humans do it constantly and unremarkably. Deployed language models do not do it at all.

It is worth being exact about the boundary, because the systems around a model give a strong impression of learning. Persistent memory features store facts and retrieve them into context. Retrieval systems index documents added yesterday. Fine-tuning updates weights on a curated dataset in a controlled run. All three change behaviour, and none of them is continual learning: the first two leave the weights untouched and work by putting text back into the prompt, and the third is a discrete, supervised, offline event with a rollback path.

The distinction has consequences you can observe. Everything the model knows from context is bounded by the context window and is paid for on every request — see agent memory for how the bookkeeping works in practice. Nothing it learns in a session consolidates into cheaper, faster competence. And there is a hard ceiling: a system cannot accumulate ten years of experience with your organisation if the only mechanism is a prompt.

The technical obstacle

The classical problem is catastrophic forgetting, described by McCloskey and Cohen in 1989 and studied continuously since: training a neural network on new data degrades performance on tasks learned earlier, because the same weights encode both and gradient descent on the new objective has no reason to preserve the old one. It is not a bug in a particular architecture; it is what happens when a shared parameter set is optimised for a new distribution. The mechanics are in catastrophic forgetting.

The underlying tension has a name from the earlier connectionist literature: the stability-plasticity dilemma. A system plastic enough to absorb new information quickly is unstable enough to overwrite old information, and the two properties are in direct competition in a shared representation. Every proposed solution is a way of buying one with the other.

The operational reasons, which are bigger

Suppose forgetting were solved tomorrow. Production systems would still freeze weights, for reasons that have nothing to do with the research problem and that are rarely mentioned in discussions of this topic.

• Evaluation. You cannot ship a model you have not evaluated, and a model that changes hourly cannot be evaluated in the way current practice requires. The whole apparatus in LLM evaluation assumes a fixed artefact under test.
• Reproducibility. Debugging a bad output requires being able to reproduce it. A continuously updating model makes every incident unreproducible in principle, not just in practice.
• Rollback. The standard response to a bad deployment is to revert. If learning is continuous and incremental, there is no clean version to revert to, and the damage is spread through the parameters rather than isolated in a release.
• Poisoning. A model that learns from its inputs is a model an adversary can teach. This is the training-time version of the injection problem in data poisoning, with the attack surface widened to every user interaction.
• Privacy and deletion. If a system learns from user data into weights, a deletion request becomes an unsolved technical problem rather than a database operation — the reason the right to erasure is genuinely hard for trained models and easy for retrieval indexes.
• Multi-tenancy. One model serves many customers. On- line learning would mix one tenant’s data into another’s responses, which is a confidentiality breach and not a subtle one.

Taken together these say something that is often missed: even a perfect solution to continual learning would probably be deployed as per-tenant, sandboxed, auditable and revertible adaptation, not as a model that quietly updates itself in production. The research problem and the product problem have different shapes.

What is used instead

The gap these leave is skill acquisition. Retrieval can tell a model that your deployment procedure changed. It cannot make the model better at your deployment procedure through repetition, the way a colleague gets better at it.

The research directions

• Regularisation. Penalise changes to parameters identified as important for previously learned tasks. Elastic weight consolidation, from Kirkpatrick and colleagues in 2017, is the canonical example: estimate each parameter’s importance and constrain updates accordingly.
• Replay. Interleave old data, or model-generated approximations of it, with the new. Effective, and it reintroduces the requirement to keep the old data — which is exactly what several of the operational constraints above forbid.
• Parameter isolation. Give new tasks new parameters and leave the old ones alone. Avoids forgetting by construction and grows with the number of tasks, so it moves the problem to allocation and routing.
• Model editing. Locate and modify a specific fact without retraining. Genuinely surgical when it works, and the published work also documents the failure mode: edits that do not propagate to logically entailed statements, so the model asserts the edited fact and contradicts it a question later.

What solved would look like

A useful test, because it distinguishes real progress from a demonstration: a system that learns a new skill from a small number of examples during use, retains it across sessions without those examples being re-supplied, does not degrade on anything it could do before, and allows the update to be inspected and reverted. Every current approach fails at least one of those four, and which one it fails tells you what it actually is.

Whether this capability is required for the broader capability arguments in this cluster is itself contested. Proponents of scaling treat it as an engineering matter to be solved when it becomes the binding constraint; critics treat it as one of the missing ingredients, on the grounds that an agent that cannot accumulate experience is not doing the thing that makes human competence compound. The two positions are laid out in scaling versus missing ingredients.