Continual learning

What is continual learning?

Continual learning is the idea that a model keeps updating itself from new data after it has been deployed, instead of staying frozen at the moment training stopped. It is what people mean in a first meeting when they ask whether the assistant learns from their corrections.

As a research goal it is well defined. Google Research described it in November 2025 as the ability for a model to actively acquire new knowledge and skills over time without forgetting old ones, and noted that a model's knowledge today is confined to either the immediate context of its input window or the static information it learns during pre-training. That second half is the honest answer for anything you can buy right now.

The models an SME uses in September 2026 do not change their weights because somebody corrected them. Fix the same invoice field ten times and the eleventh run starts from the same model as the first. Something may still get better between Monday and Friday. It does not get better inside the model, and that difference decides who can change it, read it and undo it.

What actually changes when a system looks like it learned

Three mechanisms produce the appearance of learning. In any given product one or two of them are doing the work, and it is worth naming which.

• It is sitting in the context. Correct the assistant inside one conversation and it holds the correction until the session ends. OpenAI's API guidance is blunt about the rest: each text generation request is independent and stateless, and the continuity you see exists because the application sends the earlier messages back with every call.

• It was written to a memory store. A file or a database row outside the model, written during the conversation and read back later. Anthropic's memory tool runs client-side: the model requests file operations and your application executes them against storage you control. Copilot Studio does the same in Microsoft-managed storage, one folder per user, in a loop it calls capture, store, apply.

• A person changed something. Somebody edited the system prompt, added a line to an instruction file, or dropped a corrected document into the retrieval corpus that RAG searches. This is the most common source of an assistant that visibly got better, and the one nobody credits, because the change happened in a file rather than in the conversation.

None of the three touches the model. All three change what the model reads before it answers. So when a vendor says the product learns from your feedback, four questions settle it: which of the three is running, where is it stored, can you read it, and can you delete it for one person.

One rule, traced back

A technical wholesaler near Hasselt runs an assistant that drafts order confirmations. In April the sales team started asking for the delivery terms as a separate paragraph for one customer group, and after a few corrections the assistant began doing it on its own. The reading inside the company was obvious: it had learned the rule.

In August it stopped.

Working out why took twenty minutes and three checks. The model ID was pinned and had not moved, so nothing had arrived from the provider. No fine-tuned model existed. What did exist was one line in the per-user memory of the account manager who had done the correcting, and he had been off for six weeks. The vendor deletes a user's memories after a stretch without interaction, and the line went with them.

Two things follow, and neither is about the model. The rule had only ever applied when that colleague was driving the assistant, because memory in that product is per user. And the fix was not to correct it more often. It was to move the rule into the instruction file every session reads, a shared file somebody owns and reviews.

That is also the answer when a colleague says the assistant has learned how they like things. It read something that somebody wrote down, and you can go and look at what that is.

Why continual learning is hard

This is not a feature nobody has got round to building yet. It is two open problems.

The first is catastrophic forgetting. Train a network on new data and it degrades on what it already did well. A team at DeepMind published a method in 2017 that gets round part of it by remembering old tasks and slowing down learning on the weights that matter for them, which tells you how delicate the trade is: you buy retention by refusing to move. Researchers who ran continual instruction tuning on language models between roughly one and seven billion parameters found forgetting across that range, and found it got worse rather than better as the models grew. Google Research presented its own November 2025 answer as a proof-of-concept architecture, not as a product.

The second problem is evaluation. A model that changes continuously cannot be tested once and certified, because the thing you tested is not the thing running tomorrow. The EU AI Act handles that in two places. Article 15(4) requires high-risk systems which continue to learn after being placed on the market to be built so the risk of biased outputs feeding back into future operations is removed or reduced as far as possible, with mitigation for any feedback loops that remain. Article 3(23) defines a substantial modification as a post-market change that was not foreseen in the initial conformity assessment and that affects compliance or the intended purpose, while Article 43 exempts changes the provider pre-determined and wrote into the technical documentation at that first assessment. A learning system is not banned. It has to have been described in advance, with the limits it stays inside.

What does update, and on whose schedule

Behaviour does change over time, on somebody else's calendar. The provider retrains and releases a new version, which is why an assistant answers differently in October than it did in June without anyone on your side touching a prompt. It is a different set of weights behind a model ID, on the provider's schedule, and our entry on model versioning and deprecation covers how to pin an ID so it stops being a surprise.

The two updates you control are one-off jobs. A fine-tuning run turns a dataset you assembled at one moment into a separate model version, and it has to be redone when the base model underneath it retires. Retraining a scoring or forecasting model monthly against fresh data is the usual answer to model drift. Both are planned releases: somebody starts them, somebody compares old against new, somebody can roll back. That is the property a self-updating model would take away from you.

Continual learning versus a memory store

The two get discussed as one feature at different stages of maturity. What separates them is what actually changes when the system appears to learn.

With continual learning the weights change. Everyone using that model shares the change, there is no artefact anyone can open and read, you cannot delete one fact without disturbing the rest, and you cannot show an auditor which version produced last quarter's output. With a memory store a file or a row changes. It is scoped to one user or one agent, you can open it, edit a line, delete it, expire it, and you can answer a customer who asks what the system knows about them. That is why regulated work prefers versioned releases: a system that changes itself is one you cannot show a fixed record of, and a conformity file wants a fixed record.

Where to put a correction so it sticks

Three places, ranked by how well they hold up in a small company, each with the way it fails.

1. The retrieval corpus. If the assistant answered wrongly about a return policy, fix the return policy document retrieval reads. The correction applies to everyone, survives model changes, and gets reviewed by whoever owns that document anyway. It fails when the old version stays in the index next to the new one and the model quotes whichever it reaches first.

2. An instruction file. A shared file the agent reads at the start of every session: house style, naming, which customer group needs which paperwork. It is readable, diffable and belongs in version control, the discipline described under prompt versioning. It fails by growing: a file nobody prunes turns into a page of contradictory rules that costs you context on every call.

3. A memory store. The closest thing to learning that ships today, and the least controlled, because nobody approves a line before it is written. It fails in two directions: an entry goes stale and gets quoted with full confidence months later, or something a bad input wrote once gets read back on every future run. Our entries on agent memory and memory poisoning deal with both.

The human version of the same wish is compound engineering: after each task a person decides what was worth keeping and writes it into the file the next task will read. The team that skips this step corrects the same output every week under the impression it is teaching the system, and will still be doing it next year.