Long-term memory
Carry stable preferences and background into later tasks without repeating them. Desktop memory is not a complete chat backup, a Gene or Capsule, or a node credential. See Reusable experience for evolution assets.
When to use it
Retain durable names, reply-language preferences, communication habits, and working background. Keep one-off instructions, temporary progress, credentials, and task-specific assumptions out. Store project sources in the project and identify them in the task.
Decide what belongs where
| Information | Better location | Example |
|---|---|---|
| Stable identity, background, or preference | Conversation profile or memory item | “I maintain product documentation for readers without a technical background.” |
| Standing requirements for one project | Project working rules | “Explain prerequisites for each product capability.” |
| An exception or deliverable for this task | Current request | “This review is for engineers, so technical terms are appropriate.” |
| A repeatable method | Skill or reusable experience | A validated documentation review procedure |
| Live progress and source material | Project files and current task | This week's change list and latest interviews |
Memory provides context, not permission to access files, publish, or perform other actions.
How background reaches later tasks
The conversation profile participates directly in conversation; profile highlights and past experiences are recalled by relevance. Both are visible in Memory, but an item appearing in the list does not mean every answer uses it.
Memory is reference context, not a guarantee that every item is recalled in every reply. Explicit current requirements take priority; an enabled reply-style preset also overrides the reply style in memory. Memory does not imply that EvoX has read every old conversation or current project file.
Verify the effect in a real task
Suppose your saved background says that your product documentation is for readers without a technical background. For the next guide, supply the current sources and deliverable requirements:
Turn this feature description into a user guide and save it as user-guide.md in the project. Keep prerequisites and limitations. Flag unsupported steps for confirmation.
Review three outcomes in the deliverable:
- Background is applied: unfamiliar terms are explained and steps suit the audience, rather than merely repeating “for nontechnical readers” in the introduction.
- Sources are respected: the guide reflects the current input without treating remembered product details as live facts or inventing controls.
- Current requirements are followed: output location, format, and limitations match the request; lasting habits do not override this task.
Memory reduces repeated background, not the need to supply current materials and acceptance criteria. Still identify the capability, source, and output location. Standing writing requirements can go in project rules rather than placing a whole specification into one memory item.
For example, a durable preference can be “Use Chinese by default; give the conclusion before evidence.” For a one-off English deliverable, specify the audience and language. If Always use this language is enabled, check whether it conflicts with this task.
An entry in the list or a recall-test match cannot replace reviewing the deliverable. To check saving or retrieval, follow Memory management and inspect save status, scope, and recall results separately.
Maintain changing background
If the audience permanently changes to developers, update the memory and reuse the same source material to check the effect: less unnecessary introductory explanation, while retaining prerequisites and limitations engineers need. Put standing technical requirements in project rules.
For a one-off exception, explain it in the request without changing otherwise valid background. When information is wrong, inspect its source before retaining an earlier AI assumption as fact.
If results still use outdated background, point out the specific error in the task and check sources and duplicate records in Memory management. Rephrasing the answer while retaining an incorrect fact does not resolve the problem.
Chat and Cowork support recall across projects; Code filters project memory by the current project. Do not use project labels to isolate confidential material.
Scope and data flow
Do not save credentials or unrelated personal data as preferences. Progress, paths, and service states can change; verify them again rather than treating memory as live status.
Local retrieval does not mean content always stays on the device: memory selected for a task is still sent to that task's model provider. See Memory management for cloud data flow, costs, and the scope of hiding and deletion.
Next steps
See Personalize EvoX for the relationship between profiles, styles, and adaptive responses, and Memory management for management steps.