How Do AI Agents Learn From Past Interactions?

When using an agent, if you explain your stack to it, close the session, the next session starts blank with no memory of what you told it last. AI agents lose memory between sessions because the model doesn't carry a durable record from one inference call to the next. When an agent does seem to learn, the surrounding system saved part of the earlier interaction, retrieved it, and placed it back in the model's context on the next call. The model's weights, or the underlying numerical parameters, usually stay the same.

What does it mean for an AI agent to learn?

An AI agent learns when a past interaction changes its later behavior, but several different mechanisms can cause that change.

The simplest is in-context adaptation. An instruction, example, tool result, or earlier message changes the next response. Nothing is written back to the model. This is called in-context learning: the model adapts to instructions and examples in the current prompt without being retrained.

The next is session state. The application saves the conversation, plan, tool outputs, or workflow variables and sends selected state back on the next turn. It often ends when the current thread is closed or it hits a retention limit.

External memory lasts longer. The application stores messages, summaries, preferences, and other useful information outside the model. When needed, it retrieves selected information and adds it to the model’s current context. These external memory systems are more common in deployed agents than memory stored by changing the model itself.

Agents can store different kinds of memory:

• Episodic memory records an event, action, and outcome.
• Semantic memory stores facts or preferences.
• Procedural memory stores rules, prompts, skills, or tool instructions.
• Reflection turns outcomes into a saved lesson.

Training-time learning changes the model itself. OpenAI’s fine-tuning tools use training data to adjust a model’s internal settings and general behavior. For user-specific personalization, ChatGPT uses stored memory instead of fine-tuning the model for each user.

How does an interaction become useful later?

An interaction becomes useful later through a write, update, retrieve, and use cycle.

Suppose a developer tells a coding agent, "This repo uses pnpm, not npm. Always run pnpm test before opening a pull request."

The system records the observation with the user, the repository, a timestamp, and the source message. It extracts two facts, that the package manager is pnpm and the pre-PR check is pnpm test, and saves them to a profile scoped to that repository.

On a later task in the same repo, retrieval surfaces the saved preference, and context engineering assembles the current instructions and that preference into one temporary input. When the agent is about to run npm install, it uses pnpm instead and runs pnpm test before opening the pull request.

This lifecycle can fail at every step. Extraction can turn an inference into a fact. Storage can use the wrong account key. Consolidation can overwrite a valid exception. Retrieval can miss the right episode. The model can ignore correctly retrieved evidence. In LongMemEval, 15% to 19% of total errors came from cases where the system retrieved the right evidence but generated the wrong answer.

Memory includes the policy for what persists, how records change, and what enters the next model call.

How do AI assistants personalize over time?

Over time, an AI assistant might personalize itself by applying user, project, or workspace information to later content, tone, recommendations, tools, and actions.

This kind of personalization is not automatic across sessions. A base model starts each session fresh. Cross-session personalization happens only when the surrounding system saves preferences somewhere durable, such as a profile, a memory store, or a config file like AGENTS.md or CLAUDE.md, and loads them into a later session.

An explicit preference comes directly from the user: "Use concise bullets," "default to a window seat," or "run pnpm test before opening a pull request." An inferred preference comes from repeated behavior, such as noticing that a developer consistently replaces npm commands with pnpm. Inferred preferences might not be consistently applied, as the agent might treat it as uncertain because the pattern may apply to one repository rather than every project.

When it does persist, personalization can draw on saved preferences, profile fields, selected conversations, summaries, corrections, workspace rules, and past outcomes. This is different from replaying chat history. A transcript preserves what was said. A profile extracts a smaller claim. An episodic store preserves what happened and how it turned out.

Current assistants ship several versions of this as opt-in features. OpenAI separates saved memories from dynamically selected chat history. Anthropic documents RAG-based chat search plus project-scoped memory entries. Google's Personal Intelligence report describes retrieval and context packing across connected applications, with user permission.

Storage scope matters. A writing preference may follow a user. A repository rule belongs to a project. An organization policy belongs to the organization. Combining those scopes can make personal experiments affect professional work.

Cold-start personalization uses defaults, onboarding, imported context, or tentative in-session inference. As preferences change, the system needs timestamps, sources, and correction controls instead of one permanent label.

Personalization also has a failure mode: it can make a model too agreeable. In a two-week study with 38 participants, a generated user profile increased agreement sycophancy for 3 of 4 tested models.

Why don't agents remember everything?

Agents don’t remember everything because total recall creates accuracy, cost, privacy, and security problems.

A large context window holds more tokens, but it doesn’t create durable state, nor will the model use every token equally. Lost in the Middle found that models often performed best when relevant information appeared near the beginning or end.

Keeping every interaction produces duplicate, stale, and contradictory records. Google's internal testing documented personal intelligence where agents encountered tunnel vision and overlooked corrections when it stored too many interactions.

Stored content can become an attack surface. In AgentPoison's experiments, poisoning under 0.1% of memory records triggered the attack at least 80% of the time, while degrading normal task performance by no more than 1%. In other words, a tiny, hard-to-notice amount of poisoned memory was enough to reliably hijack the agent.

Selective memory is a safety property. The system should keep what has future value, within the right scope and retention policy, and let the user remove what no longer belongs.

What makes agent memory trustworthy?

Agent memory is trustworthy when it keeps the evidence, time, scope, and control needed to check a recalled record before using it.

Each memory should carry a source, subject, scope, observation time, applicable time, and evidence type. The system should distinguish what the user stated from what a model inferred. Confidence can’t replace the source. Before a consequential action, the agent should verify remembered information against its source.

Changing facts need versions. If a user changes tasks or a project upgrades a dependency, the new record should supersede the old current fact while preserving valid history where policy allows. Deletion should ensure that data is removed from places like derived summaries, embeddings, indexes, and caches instead of stopping at the visible chat.

For memory to be truly trustworthy, access control must happen before retrieval. Another user's memory should never be something that can be altered or deleted by unauthorized personnel.

You can inspect, correct, delete, export, pause, or disable memory for an agent. OpenAI notes that deleting a chat doesn’t automatically delete a separately saved memory, while Anthropic documents separate chat-search and memory controls, including import and export.

What kind of memory can survive models and apps?

Memory survives across models and apps when it lives in a portable layer outside any single assistant, model, or runtime, so connected tools can read the same records. Import and export are a start, but they remain manual and may work for an occasional migration. It becomes cumbersome when you regularly switch between coding assistants or use several at once. Each tool must be taught the same repository conventions, preferred commands, and working style.

Claude Code shows the limitation. It can remember project-specific lessons across its own sessions, but auto memory is stored locally and separately for each repository. Anthropic says those files are not shared across machines or cloud environments. You can move selected lessons into a committed instruction file, but that file is then visible to everyone with repository access and only works with tools configured to read it. Claude Code’s accumulated auto memory does not automatically follow the project into Codex, another machine, or a custom agent.

That is the gap a portable memory layer is designed to address: it keeps memory outside the assistant that created it. Walrus Memory is a portable memory layer for AI agents. It keeps memory outside any single coding assistant, model, or runtime, allowing connected tools to access the same records across sessions and workflows. This reduces the need to copy preferences and project knowledge manually between compatible assistants.

About Walrus Memory

Walrus Memory is a portable memory layer for AI agents. It enables agents to operate reliably across apps and sessions without losing context – portable, verifiable, and fully under builders' control. Walrus Memory lets agents handle complex, long-running workflows and coordinate using data they can trust.