Persistent Memory

Persistent memory lets Anyy keep durable facts across sessions. It is for stable user preferences, recurring corrections, assistant notes, and environment or project conventions that should survive the current conversation.

It is not the transcript search system. Use session search for prior conversation recall, and use tasks or session state for temporary progress.

How Memory Works

Anyy stores profile-scoped long-term memory under the active Anyy home. The two ordinary profile files are:

File	Purpose
USER.md	Durable user identity, stable preferences, and recurring corrections.
MEMORY.md	Assistant notes, environment facts, and project conventions.

The memory store also maintains indexes, write events, and suggestion records in the state database. Those records support review, audit, dashboard views, and retention.

Memory In The System Prompt

When memory is available, Anyy builds a bounded memory snapshot and includes it in the model context. The snapshot carries profile memory path guidance so the assistant distinguishes USER.md from MEMORY.md.

Memory context is assembled at controlled context-building points. A memory write in the middle of a turn does not rewrite the already-running model request.

Memory Tool Operations

The ordinary model-visible memory surface is one structured tool named memory, provided by the memory toolset.

It accepts:

Argument	Required	Values	Meaning
action	yes	add, replace, remove	The memory operation.
target	yes	user, memory, daily	user writes USER.md; memory writes MEMORY.md; daily appends today's daily note.
content	for add and replace	string	New entry content.
old_text	for replace and remove	string	A short unique substring identifying the entry.

The schema is closed. Lower-level fields such as scope, kind, mode, gate, line ranges, or review reasons are rejected.

Add

action: add appends a durable entry when content is non-empty. Duplicate entries are skipped instead of being written again.

Use target: user for user facts and preferences:

{
  "action": "add",
  "target": "user",
  "content": "The user prefers concise status updates during long-running work."
}

Use target: memory for assistant/project notes:

{
  "action": "add",
  "target": "memory",
  "content": "This repository keeps user-facing docs under docs-site/."
}

Replace

action: replace requires old_text and non-empty content. old_text must match one existing memory entry, or duplicate entries with identical content.

If the substring matches different entries, Anyy rejects the operation as ambiguous. Pick a more specific old_text.

Remove

action: remove requires old_text. It removes the matched memory entry. It has the same ambiguity checks as replace.

What Not To Store

Do not store temporary task progress, one-off search results, raw collected resources, saved links, attachments, bookmarks, or full transcripts in memory.

For those cases:

• use session search for previous conversations,
• use task/reminder tools for work that needs follow-up,
• use skills for reusable workflow knowledge,
• use files or artifacts for material the user explicitly wants to keep.

Safety Scanning

Generated memory content is scanned before it is written. Unsafe generated memory is blocked, and secret-like values are redacted.

Anyy also blocks obvious collected-resource data from being written to USER.md, because user memory should describe the user, not become a bookmark or document dump.

Memory writes are audited as low-risk config/file-write operations and pass through the memory store's review-policy write gate.

Memory Suggestions

Suggestion management is not exposed as ordinary model tools. It is handled by trusted local and dashboard RPCs:

RPC	Purpose
memory.suggestions.list	List suggestion records, defaulting omitted status to pending.
memory.suggestions.accept	Accept a suggestion and write it through the approved-suggestion gate.
memory.suggestions.reject	Reject a suggestion and record the governance decision.

The read-only memory.view RPC returns the active profile's USER.md and MEMORY.md files for local/dashboard surfaces. Missing files are reported as missing entries, not RPC errors.

These RPCs are not anyy memory shell subcommands. The CLI currently exposes manual AutoDream runs only.

Background Review

After every 10 successful user turns in a session, the gateway may fork a silent background memory-review agent over the current conversation snapshot.

That review agent exposes only the structured memory tool. It can add durable facts or preferences to USER.md and records memory_review_started, memory_review_completed, or memory_review_failed events for observability.

If the review writes user memory successfully, Anyy may publish a channel notification that long-term memory was updated. Ordinary tool calls in the main turn do not reset the 10-turn cadence.

Memory Scopes

The current profile memory layout uses profile-level USER.md and MEMORY.md. Legacy workspace or agent-scoped paths are migrated into the profile layout by the memory migration code.

Session search and memory are intentionally separate. Session search searches prior messages. Memory tools edit long-term memory files.

AutoDream CLI

Use the CLI when you want to manually preview or apply AutoDream consolidation against the running gateway:

anyy memory dream --dry-run
anyy memory dream --execute --yes

--dry-run calls memory.dream with execute: false and writes nothing. --execute --yes first previews the result, then applies validated changes through the gateway RPC. Execution may write USER.md and MEMORY.md, so --yes is required.

Both modes require a running resident gateway. Use --socket for a non-default gateway socket, and --json when a script needs the raw RPC response.

Configuration

Memory maintenance is configured under memory:

memory:
  maintenance_enabled: true
  suggestion_ttl_days: 14
  daily_keep_days: 180
  daily_mode: delete
  auto_dream_enabled: true
  auto_dream_min_hours: 168
  auto_dream_min_user_turns: 50
  auto_dream_scan_interval: 8h

Field	Default	Meaning
maintenance_enabled	true	Starts the background retention loop in the resident runtime.
suggestion_ttl_days	14	Expires pending suggestions older than this TTL.
daily_keep_days	180	Retention window for daily memory files under daily/*.md.
daily_mode	delete	delete removes expired daily files; archive moves them under archive/.
auto_dream_enabled	true	Enables AutoDream consolidation when memory maintenance is enabled.
auto_dream_min_hours	168	Minimum hours since the previous successful AutoDream run.
auto_dream_min_user_turns	50	Minimum successful external user turns across channels since the previous successful run.
auto_dream_scan_interval	8h	Background check interval; checks are cheap and only run AutoDream when thresholds pass.

The retention loop runs every 24 hours while the runtime is active. It expires suggestions and applies daily-file retention. It does not prune USER.md or MEMORY.md.

daily_mode only accepts delete or archive. Blank values default to delete.

Troubleshooting

If memory does not appear in a new session, check that the memory toolset is in the active toolset list and that the resident runtime was started with the expected home and profile.

If a replace or remove fails, make old_text more specific. Anyy rejects ambiguous matches to avoid editing the wrong memory entry.

If a memory write is skipped as duplicate, the same durable entry already exists.