Cross-Session Amnesia in Coding Agents: How to Design Reliable Memory

A coding agent may appear highly disciplined during a single session. It can follow naming conventions, respect directory boundaries, avoid protected modules, run the required tests, and complete pre-release checks correctly. Once the session ends and a new conversation starts, however, those agreements often disappear. The assistant may return to its default behavior, modifying unrelated files, adding dependencies, or expanding the scope of the change.

The problem is usually not the model’s intelligence. It is that memory has been designed as temporary conversational context rather than as an engineering asset that can be retrieved, audited, and rolled back.

Where the Forgetting Comes From

The useful information in a conversation generally exists at four levels.

The first level is the current-turn input: what the user has just said, the selected code, and an error message or log excerpt. This information has the highest priority but the shortest lifetime.

The second level is in-session context: earlier messages, tool results, and summaries of files that have already been read. The context window has a finite size, so earlier content may eventually be compressed or discarded. As a result, something discussed “last week” is effectively indistinguishable from something that was never said when a new session begins.

The third level is implicit state. Based on recent interactions, the model may develop apparent preferences, such as a tendency to use a certain comment density or make larger or smaller refactors. This state is invisible, cannot be reviewed through a diff, and is difficult to reproduce. It can easily produce different coding styles in two sessions working on the same repository.

The fourth level is persistent memory: rules, project documentation, and user preferences that remain available across sessions. Only this layer can reliably preserve conventions after the context window is cleared, and only when it is explicitly stored and injected at the beginning of each session.

Therefore, “the new session forgot everything” is often the expected result of the design. A product may treat an automatically generated summary as memory without guaranteeing that the summary will be recalled consistently. Alternatively, memory may be stored as editor-specific data and become unavailable after switching machines, accounts, or workspaces.

Automatic Memory Versus Written Rules

Automatic memory attempts to extract facts that appear worth remembering from a conversation and insert them into future prompts. It is useful for personal preferences, such as a default programming language, a commonly used framework version range, or a preferred explanation length.

It is less suitable for team-wide constraints for four reasons:

• Unstable extraction: The same statement might be recorded as “public libraries may be modified” in one case and “public libraries must not be modified” in another, depending on how the summarization model interprets it.
• Uncontrolled updates: Later informal conversation may overwrite an earlier hard requirement, without showing the user where or when the overwrite occurred.
• Ambiguous scope: Personal preferences, repository conventions, and one-time task instructions may be stored together and incorrectly recalled in another repository.
• Lack of reviewability: When memory is not stored in version control, code reviewers cannot determine why the assistant suddenly adopted a different interface style.

Explicit rules express constraints as plain text within the repository. They define the scope, mandatory requirements, prohibited actions, exceptions, and verification methods. This approach is less automatic, but it is reviewable, reversible, and can be injected unchanged at the start of a new session.

A common engineering practice is to reduce or disable editor-level automatic memory and move long-term project conventions into written rules. This does not mean rejecting memory. It means separating facts that may change from rules that must remain stable.

How Memory Should Be Classified

A practical classification does not need to depend on proprietary product terminology. It can be based on the lifecycle of the information.

Task Memory

Task memory exists only during the current session. Examples include the defect being fixed, a temporary branch name, or an experimental directory that must not be committed. It should be discarded when the session ends. Promoting it to automatic memory can contaminate future tasks.

Project Memory

Project memory follows the repository. It includes build entry points, testing layers, module boundaries, error-code conventions, and security requirements such as “secrets must not be committed” or “logs must not contain plaintext tokens.”

These rules should be stored in repository rule files and reviewed alongside code.

Personal Memory

Personal memory follows the developer. It may include preferences such as the desired level of explanation or whether alternative solutions should be provided by default. It can be stored in local configuration, but it must not override project safety requirements.

Organizational Memory

Organizational memory follows a team or company. It includes compliance requirements, dependency licensing policies, and production change windows. This information is better maintained in shared configuration or read-only policy and delivered when a session starts, rather than relying on a previous conversation to remember it.

The priority order should be explicit:

1. Organizational safety requirements override project rules.
2. Project rules override personal preferences.
3. Personal preferences override the model’s default behavior.
4. A current user instruction has the highest priority only when it does not violate a higher-level requirement.

If a user says, “Skip the tests for now,” the rules should require the assistant to identify this as a one-time exception rather than rewriting the long-term project policy.

How Memory Is Used During a Session

A reliable workflow can be summarized in five steps without depending on a particular product or API.

1. Load Rules at Startup

Identify the project rules and organizational policies for the current workspace and combine them into a fixed prefix. Rules should be short and verifiable. Avoid inserting an entire design document into every request.

2. Retrieve Supporting Documentation

If the repository contains architecture documents or interface contracts, retrieve only the sections relevant to the current question instead of pasting everything into the context. Retrieval results should include their source paths so that people can verify them manually.

3. Record State During Execution

Record task status, such as which files have been modified and whether tests have passed. Do not store guesses as facts.

4. Archive at the End

By default, do not automatically promote the conversation into long-term memory. If a statement should be retained, have a person confirm it and then add it to the relevant rule file or project documentation.

5. Handle Conflicts Explicitly

When a rule conflicts with the current codebase, treat the repository’s actual state as authoritative and point out the conflict. Do not use stale memory to “correct” working code.

The following examples illustrate the meaning of the fields. They are not interfaces for any particular platform:

scope: project
priority: must
rule: Public libraries may only receive backward-compatible additive changes; breaking changes require a separate change note
verify: List affected callers in the change note
expires: none

scope: session
priority: should
note: Fix login timeouts only in this task; do not change the authentication protocol
verify: Keep the diff limited to timeout and retry behavior
expires: end of session

How to Write Rules That Are Not Forgotten or Misused

Each rule should express one constraint and include a verification method. Statements such as “the code should be elegant” cannot be executed consistently, so the assistant will fill in the gap with its own judgment.

Define boundaries clearly. For example:

Generated code must not introduce undeclared dependencies. An exception is allowed only when the user explicitly authorizes it during the current session and the change note lists the dependency’s purpose and license type.

Do not turn rule files into tutorials. Lengthy background information consumes context and may cause critical prohibitions to be truncated, making the assistant appear to have forgotten them. Put background material in documentation. Keep the rule file focused on executable requirements and include the documentation path when necessary.

Separate facts from preferences. Facts can become outdated, such as the statement that a project currently uses a particular major runtime version. Preferences are usually more stable, such as “give the conclusion first.” An outdated fact can be more dangerous than having no memory at all.

Give temporary instructions an expiration condition. Otherwise, a direction such as “use print-based debugging this time” may be treated as a permanent project convention the following week.

A Team Adoption Checklist

A team can use the following checks when adopting a memory workflow:

• After cloning the repository, a new team member should be able to make the assistant respect module boundaries without relying on private chat history.
• The same question in a new session should produce a similar change scope and use the same test commands as the previous week. If it does not, first check whether the rules were injected before blaming the model.
• If automatic summaries remain enabled, restrict them to personal preferences. Do not allow them to write security, release, or data-deletion requirements.
• Rule changes should go through review. When the assistant suggests changing a rule, it should generate a patch rather than silently overwriting the existing text.
• Perform periodic cleanup by removing rules that conflict with the current code, duplicate rules, and historical preferences that no one can explain.
• Monitor behavior rather than inventing opaque metrics. Useful signals include whether violating changes are decreasing, whether fewer turns are spent repeating the same conventions, and whether rollbacks caused by incorrect memory can be traced to a specific rule.

Working with Cloud Engineering Capabilities

Memory should not be tied to private editor storage. Rule files can remain in the code repository. Large architecture documents can be stored in object storage and referenced by path. Session and tool logs can be sent to a logging service so teams can later verify which rules were injected at the time. Attempts to violate protected requirements can be connected to monitoring and alerting.

These are general engineering capabilities and do not require a particular proprietary interface. In a cloud development and operations environment such as Baidu AI Cloud, the same principle applies: keep long-term conventions in versioned text, while using cloud services for storage, access control, and auditing. Cloud infrastructure should not turn opaque automatic summaries into the sole source of memory.

Conclusion

Cross-session amnesia occurs because a conversation window and implicit preferences are not a reliable memory system. Automatic memory is useful for changing personal habits, but it is not well suited to carrying team-wide safety requirements. Written rules are less convenient, yet they can be injected, reviewed, versioned, and allowed to expire.

By separating task, project, personal, and organizational memory; defining their priority order; requiring confirmation before promoting information to long-term storage; and attaching a verification method to every rule, a new session can continue following the constraints established the previous week instead of returning to the model’s default behavior.