Personal Agent memory design

Personal Agent Memory: Preferences, Facts & Updates

Author: DeepSeekAgent.io Editorial Team
Published: Oct 22, 2026
Updated: Oct 22, 2026

Personal Agent memory is not every conversation permanently inserted into context. A reliable memory system must answer four questions: what is remembered, where it came from, whether it is still valid, and how the user can edit or delete it. Without these properties, more history creates higher cost and less visible errors.

This guide provides a memory layout that can live directly in a DSH workspace, plus rules for writing, retrieval, conflict, expiry, and deletion.

Do not mix four types of memory

Type	Content	Example	Default lifetime
Preference	How the user wants the system to work	Chinese output; confirm before publishing	Until changed
Fact	Relatively stable personal or project data	Timezone, project path, device name	Periodic review
Event	What happened and its result	An article published last week	Time-based archive
Working	Temporary state of the current task	Verifying the third source	Current Session

Working memory stays in the Session, events enter dated records, and preferences and facts live in editable files. This prevents a temporary instruction from accidentally becoming a permanent persona.

A minimal directory

memory/
├── profile.md
├── preferences.md
├── facts.md
├── sources.md
├── events/
│   ├── 2026-10.md
│   └── 2026-11.md
└── checkpoints/
    └── daily-intelligence.md

Organize filenames by meaning, not model or conversation ID. A model replacement should not change what the memory means.

Add metadata to every durable record

A durable record needs content, provenance, confirmation state, and update time:

## Publishing approval

- Value: Publishing always requires explicit confirmation.
- Source: User instruction in Session 2026-10-22.
- Status: confirmed
- Updated: 2026-10-22
- Scope: all website publishing tasks

A model inference and explicit user confirmation have different authority. Inferred information starts as a candidate and must not control consequential actions.

Write policy matters more than retrieval algorithms

Every run can produce large amounts of information, but little deserves durable storage. Write only when:

the user explicitly asks for a future default;
a fact will affect multiple later tasks;
a completed event is required for recovery or audit;
the user confirms a candidate memory proposed by the model.

Do not store passwords, complete credentials, one-time codes, or unrelated private material. A credential system manages secrets; memory records only which connection to use and its permission scope.

Resolve conflict and temporal change

When new information conflicts with an old record, retrieval similarity is not enough. Use this order:

explicit new instruction
  > newer confirmed record in the same scope
  > confirmed durable preference
  > model-inferred candidate

Do not silently erase the old value. Mark it superseded and link the replacement so the system can explain why today's behavior differs from last week's. Time-sensitive facts such as schedules, addresses, project status, and subscriptions also need review dates.

Retrieve the minimum relevant set

Injecting the entire memory/ directory on every run wastes tokens and lets irrelevant preferences interfere. Scope first, then load related fragments:

article work: language, editorial policy, target site, and recent topic events;
calendar work: timezone, work hours, and the selected calendar;
email drafting: salutation, tone, and current contact—not every project;
code work: project path, test, and release boundaries—not private travel.

Retrieved fragments retain provenance and update time so important decisions can name their basis.

Checkpoints after Session compaction

Long Sessions compact, and tool messages can also reach Provider limits. Never keep the only copy of task progress in chat history. Record a checkpoint:

# Daily intelligence checkpoint

- Last successful date: 2026-10-22
- Output: reports/daily/2026-10-22.md
- Sources processed: 18
- Pending: verify one Gemini release date
- Next safe action: verify pending item; do not publish

Recovery reads the checkpoint, then only the required events. It does not replay the entire conversation. Update the checkpoint after completion and retain old outputs for audit.

Apply write approval in DSH

Add rules to AGENTS.md:

- Reading memory files is allowed automatically.
- Before modifying a candidate fact, show the proposed change to the user.
- Change status to confirmed only after explicit user confirmation.
- When deleting memory, explain which schedules and workflows depend on it.
- Old authorization in memory cannot approve publishing, sending, payment, or account changes.

The model may propose memory, while deterministic rules control durable writes. External actions still require current authorization; “the user usually agrees” is never sufficient.

Maintain memory monthly

Review memory in this order:

find facts beyond their review date;
merge duplicate records while retaining sources;
ensure superseded preferences are no longer retrieved;
remove unnecessary event detail and preserve only useful summaries;
verify referenced Schedules, Plugins, and workspaces still exist;
sample model switches and compare permission decisions.

Users should be able to export and clear memory. Deletion must include indexes, summaries, and derived caches rather than only the original Markdown file.

Evaluate memory reliability

Test whether the next task adopts a changed preference, whether a temporary request is incorrectly made permanent, whether conflicting facts retain provenance, whether expired information triggers review, and whether deleted material still returns through a summary.

Personal Agent research increasingly uses temporal interventions and user-conditioned evaluation because a static persona can look accurate in one test while failing to adapt to a real person. Good memory does not remember everything. It uses the right information at the right time and within the right scope.