Why Google wants language models to sleep between tasks

A language model can use a fact in a conversation and fail to retain it after the conversation ends. A system can also store that conversation without changing what the model has learned. The sleep framework concerns the harder question of turning recent information into durable learned behaviour while preserving what already works.

Google Research’s 27 October explanation describes alternating active interaction with offline consolidation and synthetic rehearsal. The linked paper has an earlier history: arXiv submission in June, revision in July and an identified OpenReview version from September 2025. This is a recent explanation of research, not a paper first disclosed in October. Google’s post and the paper record distinguish those dates.

For builders, the useful insight is architectural rather than anthropomorphic. Learning does not have to happen on the same schedule as answering a user. But a pause creates an opportunity, not a guarantee. The system still has to decide what deserves consolidation, whether the update succeeded and what earlier capabilities it may have disturbed.

“Memory” names several different mechanisms

Consider a hypothetical technical-support assistant that receives a new troubleshooting procedure. A user pastes it into one conversation. The assistant follows it successfully. Later, another user asks the same question in a fresh session and receives the old procedure. Nothing about the first success establishes that the underlying model changed.

The procedure might have existed only in the first prompt. It might have been written to a database that the second session did not search. It might have been retrieved but truncated. Or a training job might have attempted to incorporate it and failed. These are different failures, and calling all of them “amnesia” makes diagnosis harder.

Start by identifying the storage boundary. Context supplies information during a particular computation. An external record can persist independently of the model. Retrieval selects records to supply again. Parameter learning changes the model’s numerical state. Each can contribute to an apparently remembering assistant, but the engineering obligations differ.

The original retrieval-augmented generation paper explicitly combines parametric and non-parametric memory for language generation. Its particular architecture uses a learned model alongside a retrieved document index. That historical design illustrates why storing knowledge outside weights is a meaningful choice, rather than a lesser form of memory waiting to become parameter learning.

The CoALA framework similarly separates modular memory, actions and decision processes in language agents. It provides a conceptual organisation of systems, not a universal claim that a particular memory component works. The practical benefit of such distinctions is to let an engineer say which part is responsible for persistence and which part decides when to use it.

For our support assistant, a memory inventory could list the conversation, the approved procedure repository, a search index and the deployed model revision. The inventory should record who can update each and how a new session obtains information from it. That is more actionable than a product description saying the assistant “remembers everything”.

An organisation may discover that retrieval already meets its need. A procedure that changes frequently and requires a visible citation can be easier to maintain as an authoritative document. Parameter learning might be considered for a recurring skill or representation that is cumbersome to provide repeatedly. The decision should follow the required behaviour rather than the prestige of a more ambitious learning mechanism.

A slower update schedule creates a review boundary

Separating answering from learning creates a place to examine proposed changes. In the hypothetical support workflow, the live assistant can collect candidate material while an offline process decides what is approved for an update. This is a proposed operational design, not a description of a released Google support product.

The boundary is useful because not every recent interaction deserves to become knowledge. A customer may describe an unusual workaround that only applies to a local setup. An agent may generate a plausible but incorrect diagnosis. A temporary incident procedure may expire. A consolidation process that treats frequency or confidence as authority can preserve the wrong thing more efficiently.

A robust design would attach provenance to candidate material. Where did it originate? Who reviewed it? What scope does it have? Which earlier statement does it replace? These questions are ordinary information-management work, but they become more consequential when an update changes behaviour beyond the original conversation.

The update schedule also affects service behaviour. If knowledge is consolidated periodically, users need to know when an approved change becomes effective. A system that answers with one procedure before a cycle and another afterwards should be able to identify the relevant revision. Otherwise, an incident investigator may see contradictory answers without knowing whether the model, retrieval index or source document changed.

Scheduled learning can support rollback only if the system retains the right state. A previous model checkpoint, associated configuration and evaluation record can make a reversal possible. A vague promise to “undo learning” is insufficient if no one knows which candidate material caused the change. Reversibility needs a concrete artefact and a tested procedure.

This connects with the distinction in our agent-harness explainer. A useful learning agent is a system of controllers, storage, tools and checks around a model. The controller decides when a pause starts, which work is allowed and how the next active period begins. The model’s ability to produce training material is only one component.

A deployment team should therefore define the lifecycle in terms it can observe. Record the last approved input set, the resulting checkpoint, the checks that passed and the moment the new version became available. If a process cannot produce those records, it may still be a research experiment, but it is not yet an accountable production update pipeline.

The table is an operational interpretation. It is not a performance claim or a specification supplied by the sleep paper.

Forgetting is a competing objective, not a missing feature toggle

Continual learning has to accommodate change without destroying useful prior behaviour. That tension is more demanding than adding a persistent text file. A parameter update can affect many responses, including ones unrelated to the new material. Preserving a record and preserving a capability therefore require different evidence.

Elastic weight consolidation research addresses forgetting by slowing changes to weights important for earlier tasks, with experiments including classification and sequential games. The historical result is specific to its methods and evaluations. Its broader relevance is that retaining old capabilities is an explicit optimisation concern, rather than something guaranteed by learning new tasks successfully.

Gradient Episodic Memory studies learning over a sequence of tasks and proposes metrics covering accuracy and transfer. It also develops a method to alleviate forgetting. Those older experiments do not validate the sleep framework, but they establish why a continual-learning report needs more than a final new-task score.

A hypothetical assistant can improve its new troubleshooting procedure while becoming worse at escalation rules. If the evaluation includes only the new procedure, the update looks successful. If the deployment requires both, it has regressed. The definition of success must include the retained obligations the organisation cannot afford to lose.

This is also why “all previous knowledge” is a poor practical test specification. No finite evaluation can exercise every possible response. The team needs a representative retained-task set, selected because those behaviours matter, and a record of its gaps. A claim of no observed regression on that set is narrower and more useful than an unqualified claim that forgetting is solved.

The order of learning can matter too. A model exposed to one sequence of tasks may behave differently after a reordered sequence. An experiment intended to demonstrate robustness should examine that possibility rather than treating one curriculum as universal. An applied team can start with the sequences its own release process is likely to produce.

The right comparison is not merely an older model against a newer one. Include an alternative that receives the same approved information through retrieval or context, where appropriate. That establishes whether the parameter update adds value beyond supplying the fact through an existing mechanism. Different tools can be evaluated against the same application requirement without pretending they implement the same kind of learning.

A retention curve needs a time axis

Testing immediately after an update measures an early state. It does not show whether the capability survives subsequent updates. A continual-learning evaluation should revisit earlier tasks after later material arrives. The relevant time axis may be update cycles or exposure to new tasks, rather than wall-clock days.

In the support example, the procedure should be tested after several other product procedures have been added. Keep the test conditions stable enough to interpret movement. If prompts, retrieval data and model weights all change between checks, a drop in performance becomes harder to attribute. The evaluation record should name those changes rather than present an unexplained trend.

A useful visual or table would track each task family across release cycles, alongside the newly added family. The result can reveal uneven retention that a single average hides. It can also show positive transfer, where later learning improves an earlier task. Both directions matter when judging whether a learning schedule is useful.

Consolidation and rehearsal need trustworthy material

The sleep paper proposes consolidation and “dreaming”, including distillation and synthetic rehearsal, and evaluates components on defined learning tasks. The metaphor names computation within a designed system. It is not evidence of consciousness, biological sleep or unlimited self-improvement.

Generalized Knowledge Distillation supplies relevant background for learning from student-generated sequences with teacher feedback. The distinction is between training only on fixed teacher outputs and supplying guidance on contexts the student itself visits. The method’s documented tasks and objectives should remain visible when it is used to explain a later research proposal.

The Nested Learning paper provides another part of the background, framing learning as processes with different context flows and update frequencies and introducing Hope. It is a separate source with its own claims. A reference to it does not remove the need to identify which component of a combined system was evaluated.

A synthetic example can be useful without adding an independently verified fact. Suppose the support assistant generates several phrasings of an approved troubleshooting question. Those examples may help train flexible recognition of the same procedure. If it instead invents a new cause of failure, repeating the claim in synthetic material does not make the cause real.

This distinction should shape data selection. Label whether an example reformulates established material, proposes a hypothesis or asserts a new fact. A training pipeline can permit the first while requiring external verification for the latter. Otherwise, consolidation risks converting an uncertain inference into a confidently repeated behaviour.

The selection procedure can also overfit to the evaluator. If the same narrow task set repeatedly decides which synthetic material is good, improvements may reflect adaptation to that set. Reserve independent tasks for later assessment and record which examples influenced selection. Evaluation data is part of the experiment’s causal structure, not a decorative final report.

Our explanation of reasoning-model training is useful context here. Training objectives, generated trajectories and verification mechanisms have distinct roles. A fluent rationale for an answer should not be mistaken for evidence that the underlying update acquired a correct general skill.

Rehearsal has a budget and a stopping rule

A system can generate more practice indefinitely in principle, but an organisation has finite compute and evaluation capacity. The rehearsal loop needs a stopping rule connected to a useful outcome. Reaching a chosen number of synthetic samples is an operational checkpoint, not necessarily a quality threshold.

For a pilot, track how much candidate material was generated, how much was selected and what evaluation improvement resulted. Include failed runs. This helps distinguish an efficient learning process from one that searches many alternatives and reports only a fortunate result. It also gives a team a basis for estimating the cost of its next update.

The update interval has a similar trade. Frequent cycles may reduce the delay before new knowledge becomes available but create more release and evaluation work. Infrequent cycles may amortise preparation while leaving the assistant stale for longer. There is no universal best schedule independent of the application and its tolerance for delay.

More capacity does not make information management disappear

Adding trainable capacity can provide room for new behaviour, but it does not decide which behaviour should occupy that room. A learning system still needs a policy for contradiction, correction and expiry. Those are especially important when material changes because an earlier instruction has become wrong.

LoRA demonstrates a parameter-efficient adaptation approach using frozen base weights and trainable low-rank matrices. It is background for understanding one way of adapting models with fewer trainable parameters. It does not imply that any low-rank update will preserve all old tasks or correctly resolve conflicting information.

Return to the hypothetical support procedure. An older document says to restart a service immediately; a revised procedure requires collecting diagnostics first. The system should not blend these into an ambiguous answer. It needs an authoritative source relationship that marks one instruction as superseded under the relevant conditions.

The same fact can also have a scope. A procedure may apply to one software version, jurisdiction or customer configuration. Learning the sentence without the condition creates an error even if the sentence was copied accurately. The evaluation should include nearby cases where the new procedure does not apply, not only cases where it should be used.

Deletion raises a different issue. Removing a record from a database and removing its influence from model parameters are different operations. A team should not promise equivalent deletion behaviour without evidence and a defined process. Applications involving sensitive information may therefore prefer external storage for material that must be individually managed or removed.

An update can be technically successful and organisationally inappropriate. A private conversation might contain information the assistant could learn but has no authority to reuse across users. Candidate selection must respect that boundary before the material enters a durable process. A clever consolidation mechanism cannot supply missing permission or decide a company’s retention policy.

The practical design is to keep an authoritative knowledge layer even when learning is introduced. Documents, approvals and revision history let humans investigate why a behaviour was expected. Learned parameters can support useful generalisation, but they should not become the only record of a procedure the organisation is accountable for.

Contradiction tests should be designed before release

A pilot should include an old instruction, its authorised replacement and a similar instruction that remains valid. The system needs to update the right case without treating every related procedure as obsolete. This small set can reveal whether the training objective is acquiring a useful distinction or simply preferring the latest wording.

Include a question that asks about the historical procedure explicitly. A support organisation may need to explain what applied at an earlier date without recommending it now. Temporal knowledge is more structured than overwriting one answer with another. The evaluation should reflect whether the application needs historical explanation, current action or both.

If a candidate update cannot express those distinctions reliably, retrieval with dated source records may remain the more appropriate solution. That outcome is a useful result of a pilot. The purpose is to choose a dependable information path, not to demonstrate parameter learning at any cost.

Put the learning process through an ordinary work week

An update cycle is easier to reason about when it encounters conflicting demands. In a proposed pilot, begin with an assistant answering from an approved procedure set. Introduce one genuinely new procedure, one correction to an existing procedure and one customer-specific exception. These should be separately identified inputs, because the organisation wants different persistence and access rules for each.

During the first active period, the assistant might use all three in context. That establishes whether it can follow them when the information is directly available. It does not establish retention. The next test should begin without the original conversation and identify which external information, if any, is supplied. Otherwise, the evaluator cannot distinguish parameter learning from accidentally preserving the answer in the prompt.

The offline process then receives only the material it is authorised to learn. The new general procedure and approved correction might be eligible. The customer-specific exception might remain in an access-controlled external store. This is an illustrative policy choice, not a requirement of the research method. Its purpose is to examine whether the learning controller can respect different boundaries rather than treating every observed sentence as equally reusable.

In the next active period, ask questions covering each input type. The general procedure should be available in its intended scope. The correction should replace the old recommendation for current cases. The exception should appear only when the requester and case qualify. A system that recalls everything to everyone would fail this operational test even if its memory score looked excellent.

Now introduce unrelated material and repeat the earlier questions. This tests whether the intended behaviour survives intervening learning. Add a deliberately ambiguous question that should trigger clarification. A consolidated model that becomes more confident without becoming more discriminating can create a new failure while preserving the headline fact.

The final step is a disputed answer review. Give a reviewer the actual answer, the model revision and the update record, without relying on the operator’s memory. Can they determine which procedure should have applied? Can they find the source? Can they identify whether the error came from missing information, incorrect scope or an observed regression? If the record cannot support that review, the production process needs work independently of the model score.

Capacity planning should follow the entire cycle

The active service and the offline learner may compete for resources. An organisation needs to know whether consolidation pauses answering, uses separate capacity or queues work until a quieter period. Those are deployment choices that require measurements. The sleep metaphor should not create the impression that spare computation appears without an infrastructure decision.

For a proposed pilot, report a complete cycle rather than just the fastest phase. Include data preparation, candidate review, update time, checks and release. If the system becomes temporarily unavailable, record the effect on users. If old and new revisions coexist, explain how requests are assigned and whether a conversation can cross the revision boundary.

The storage trajectory matters too. A method that adds capacity should be evaluated over the number of cycles relevant to the application. An early successful update does not establish a sustainable long-term footprint. The team can estimate growth from measured cycles while marking the projection as a projection, rather than presenting it as an observed operating history.

Human attention is another limited resource. Candidate selection and error review may become the bottleneck even when the automated update is inexpensive. Track review effort and unresolved cases. The goal is not to remove people from the account, but to determine where their judgement is necessary and whether the system makes that judgement easier.

Avoid moving the test into the training material

An assistant that keeps learning creates a special evaluation risk: its own past tests can become candidates for later consolidation. If test questions, grading comments or expected answers enter the learning stream, a later improvement may partly reflect exposure to the evaluation. The pipeline should separate operational feedback from held-out assessment deliberately.

There is no contradiction in using errors to improve a model. The requirement is to retire exposed items from the role of untouched evidence, or identify their exposure when reporting results. Keep an independent set for assessing the next cycle. A model that performs well on known exercises may be useful, but that result answers a different question from generalisation to new requests.

This separation becomes more important when synthetic rehearsal imitates patterns from selected examples. Near-duplicates can reach the learning process without identical text. Review the provenance and role of the material, rather than relying only on exact-string filtering. The evaluation design should reflect the fact that the system is intended to change over time.

Evaluate a learning lifecycle, not a single impressive recall

A practical study can start with a modest set of approved procedures and a clearly defined baseline. Measure how the unmodified assistant answers ordinary and ambiguous questions. Then introduce new material through the proposed learning process and through a retrieval-based alternative. Keep the tasks and scoring rules consistent.

The study should separately measure new information, retained capabilities and inappropriate transfer. The third category matters: an assistant might remember a new procedure while applying it too broadly. A recall-only evaluation would reward persistence without noticing that the model now gives the wrong advice in neighbouring cases.

Use delayed checks after further updates. Preserve item-level records, model revisions and the provenance of each update set. A reviewer should be able to trace a changed answer to a particular cycle or identify that the available record does not establish the cause. That honesty is more useful than a polished dashboard that hides missing evidence.

Cost belongs in the result. Count consolidation compute, synthetic-data generation, evaluation, storage and release work. A lower per-answer prompt cost may coexist with a higher maintenance burden. Our analysis of the full cost of AI products explains why a single token-price comparison cannot settle the economics of a system that keeps learning.

Finally, run the rollback procedure before relying on it. Restore the prior revision, confirm that the intended behaviour returns and inspect which external stores also need restoration. A checkpoint is only one part of a stateful assistant. The real recovery boundary includes retrieval, policies and the controller that supplies context.

The sleep framework makes a productive question explicit: what should happen between active interactions so that useful knowledge persists? A dependable implementation must answer a second question just as clearly: how will we know what changed, what survived and what deserves to become permanent?