Do AI agents learn? Memory is not model training

“The agent learned from its mistake” leaves an important question unanswered. Did the next request contain a correction? Did someone save a note, change an instruction or train a different model? Those changes need different tests and different ways to undo a bad update.

Ask what changed, and where#

Chapter 1 of Michael Albada’s book groups reinforcement learning, knowledge and model updates, and user feedback under continuous learning. Those are useful directions for improvement, but they do not describe one automatic feature that every agent has. This page separates their mechanisms rather than treating all adaptation as model training.

Conversation state carries information through the current task. Saved memory keeps selected information for later use. LangChain’s memory guide distinguishes thread-scoped memory from information shared across conversations. “Short-term” describes the scope here, not necessarily whether the data is stored on disk.

Instructions tell the model how to approach the task. Changing a prompt or a procedure changes what the application asks it to do. Model parameters, often called weights, are the learned numerical values inside the model. Changing those is a different intervention from supplying different input.

For the broader picture of how an agent selects actions, start with the agent decision loop. A loop can adapt to a new observation while using the same model throughout.

Follow one preference across two conversations#

In this illustrative assistant design, a user says, “Use 25-minute meetings unless I ask for another length.” The assistant proposes a 25-minute meeting in the same conversation. The instruction is already in the input; persistent memory is not needed to explain this result.

Now end that conversation and start another. To apply the preference there, the application needs an explicit route from the earlier statement to the new input. It might store an approved preference under the user’s account, retrieve it for scheduling tasks and include it in the next model call.

Keep its scope and origin: this user stated a default duration, not a company-wide rule. A practical record also needs a way to correct or remove it. These are design recommendations for the example, not requirements imposed by every memory framework.

If the user now requests a 50-minute workshop, the old default should not overwrite that explicit request. If the application retrieves a different user’s preference, the problem is access and retrieval, not a model that needs more training.

A preference sitting in a database cannot influence this call unless the system makes it available through some input or tool interaction. Context engineering asks what the model actually received, rather than what information existed somewhere in the application.

Try it: change what reaches the next conversation

A user previously chose 25-minute meetings. What is available now? Preference only in the old conversationSaved for this user and loadedA different user’s record is loaded

The new conversation has no preference input.

1. The old thread ends.
2. No approved preference is loaded.
3. Ask or use the ordinary default.

The model weights did not change; missing input calls for storage and loading checks.

The record and request are invented; no preference is stored.

A new document and a new model are different updates#

Suppose a public product manual changes its supported file formats. A retrieval system can find the revised section and include it in an answer. Updating that document or its search index does not, by itself, update the answering model’s weights. The answer may improve because it now has the relevant information.

Do not turn that into “retrieval is always right”. An old document may still rank first, the new text may omit an exception, or the answer may misread it. Keep source versions with important findings and test whether the right material is retrieved.

Training changes a different part of the system. For example, OpenAI’s supervised fine-tuning documentation describes using example inputs and desired outputs to update model weights, followed by evaluation. That describes the mechanism, not a recommendation to adopt a particular training service.

A model provider might separately use eligible interaction data in a later training process under its data policies. That possibility should not be confused with an agent retraining itself during the current task. The claim “this agent learns” needs to name the actual system and update process.

Feedback needs a change and a check#

A failed test can affect the next attempt without training. The application returns the failure; the model sees it and proposes a different action. A system can also save a short reflection for a later attempt. Reflexion, a 2023 research paper, explicitly studies linguistic feedback and reflective memory rather than weight updates. Its findings do not establish that any self-written note improves any task.

Consider a bad reflection: “The meeting failed because the user dislikes mornings.” The actual problem was an unavailable room. Saving the guess as a preference makes future behaviour worse. A useful memory should preserve what was observed and distinguish it from an explanation that has not been checked.

Likewise, a developer might revise a scheduling instruction after reviewing several failures. That is an application improvement, even if the model stays unchanged. Record the revised instruction and compare outcomes; do not describe the new prompt as proof that the agent taught itself.

For consequential actions, remembered preferences must not become new permissions. An assistant remembering a preferred meeting time does not thereby gain permission to invite people or edit every calendar. The harness must continue enforcing those boundaries.

Choose the update for the failure you observed#

Chapter 7 names the distinction more precisely. Its nonparametric learning approaches use examples, reflections or extracted experience without changing model parameters. Its parametric learning section discusses fine-tuning those parameters. Retain that terminology without turning either mechanism into a promise of improvement.

If the 25-minute preference is absent from a new conversation, inspect storage and loading first. If an outdated manual supplied the wrong rule, trace the document and retrieval path. Neither failure establishes that the model needs new weights.

If the right information is present but the assistant repeatedly formats scheduling proposals incorrectly, compare clearer instructions or a small set of reviewed examples. Fine-tuning becomes a candidate when a recurring behaviour problem and suitable training data justify testing it. It is not a substitute for a service rejecting an unauthorised calendar write.

The chapter’s experiential-learning approach also derives reusable insights from past tasks. Treat a proposed rule as a candidate change: keep its supporting cases, scope and version, and compare it before wider use. A rule extracted from one user’s correction must not silently become policy for everyone. Make the scope of saved corrections visible.

Keep examples used for tuning separate from the final comparison. That applies to retrieved demonstrations as well as weight training: a memory store containing a test’s reference answer can make the evaluation look better without showing generalisation. Check whether copied tasks, users or time periods create leakage relevant to the intended deployment.

A reviewed change can still regress other behaviour. Record which prompt, example set, memory policy or model changed, preserve a way to restore the previous configuration, and compare the affected task with representative neighbouring cases. These are proposed maintenance controls, not procedures the book establishes as sufficient for every system.

Test the mechanism you actually changed#

For the meeting preference, try a new conversation, an explicit exception and a second user with a different default. Check the stored record, the retrieved information and the resulting proposal separately. A correct final answer can conceal a retrieval bug that happened not to matter on that request.

For a revised instruction, compare the same representative tasks before and after the change, including cases the instruction was not written to fix. For a trained model, evaluate the new model on held-out tasks rather than only the examples used for training. A reusable agent evaluation set helps make those comparisons explicit.

The practical rule is to finish the sentence: “The system improved because we changed this part, and these checks showed the difference.” When the only thing added was a log entry, the improvement has not yet been demonstrated.

Questions people also ask

2 QUESTIONS

▸ Does a thumbs-down train the agent immediately?

Not necessarily. A rating may be stored, reviewed, used to change instructions or later included in a training process. Inspect the application's actual feedback pipeline. The existence of a feedback button does not establish which of these happens.

▸ Does deleting a saved memory make the model forget it?

Deleting an application record is not model untraining. It also does not necessarily remove copies in conversation history, caches, summaries or logs. Check the storage and deletion behaviour of the specific system rather than treating one delete operation as a universal guarantee.