Start a new memory session. Call this ONCE at the very beginning of each new conversation.

MANDATORY WORKFLOW — follow these steps IN ORDER every single time:

1. Call session_start (this tool) FIRST.

2. IMMEDIATELY after, call memory_retrieve to check for any context from this session.

3. Throughout the conversation, call memory_store to save DETAILED notes about everything important.

SESSION ISOLATION:

• Each session starts with ZERO entries — completely fresh memory.

• No data from past sessions, knowledge graph, or vector store leaks in.

• Only data stored via memory_store during THIS session will be retrievable.

• Session IDs are timestamp-prefixed UUIDs for guaranteed uniqueness.

WHAT IT DOES:

• Creates a completely fresh, empty memory for the new conversation.

• Returns the new session ID.

WARNING: Always call this first to ensure session isolation.

Store information in long-term memory. Call this PROACTIVELY whenever you learn something new — do NOT wait to be asked.

CRITICAL — CONTENT QUALITY RULES: Your memory entries MUST be DETAILED, SELF-CONTAINED paragraphs that a future AI can read and FULLY understand WITHOUT needing to re-derive anything. Each entry should be 3-5 sentences minimum. Include WHO, WHAT, WHY, HOW, and WHERE relevant.

BAD (useless — too short, forces re-thinking): "Fixed audio issue" "User likes dark mode" "Website uses Vanta.js"

GOOD (detailed — saves tokens by preventing re-derivation): "Fixed a CORS audio playback issue on the user's website fate.rf.gd. The problem was that the audio element was trying to load files from a different origin. Solution: added crossorigin='anonymous' attribute to the element and configured the server to send Access-Control-Allow-Origin headers. The audio visualizer now works correctly with the Vanta.js background." "User strongly prefers dark mode designs with deep blue (#0a0e27) and purple (#6c63ff) accent colors. They want glassmorphism effects, smooth animations, and premium-feeling interfaces. They dislike plain/basic designs and have explicitly requested 'wow factor' aesthetics in multiple conversations." "The user's personal website at fate.rf.gd uses a multi-section single-page layout with: Vanta.js globe wireframe background animation, a music player with bass-reactive glow visualizer, glassmorphic card components, Google Fonts (Inter/Outfit), and is hosted on InfinityFree. The tech stack is vanilla HTML/CSS/JS with no framework."

REMEMBER: A memory that takes 20 tokens to store but saves a future LLM from spending 500 tokens re-analyzing is EXTREMELY valuable. Write entries as if briefing a colleague who has never seen this project before.

WHEN TO USE:

• After the user tells you their name, preferences, project details, or any personal information.

• After completing a task — store WHAT was done, WHY, HOW it was solved, and the OUTCOME.

• When you discover important facts about the user's codebase, tech stack, architecture, or workflow.

• When you make design decisions — store the decision AND the reasoning.

• Whenever information might be useful in future conversations.

MEMORY TYPES (choose carefully):

• 'core': CRITICAL permanent facts (user identity, key project info, important preferences). Never evicted. Use sparingly — only for the 5-10 most important things.

• 'fact': Concrete knowledge with entities. Include full context, not just the fact. Automatically indexed in the knowledge graph.

• 'preference': User likes/dislikes/habits. Describe the preference with specifics (colors, styles, patterns), not just the category.

• 'event': What just happened in this session. Describe the task, approach, solution, and result in detail.

• 'summary': Compressed notes about a session or topic. Should be a dense briefing paragraph, not bullet points.

ENTITIES: Always provide relevant entity names in the 'entities' array for 'fact' type. The first entity is treated as the subject. Example: entities: ["User", "dark mode"] for "User prefers dark mode".

Retrieve memories stored in the CURRENT session. Returns only data from this conversation — no cross-session contamination.

MANDATORY — ALWAYS call this immediately after session_start. Also call before ANY task that could benefit from context stored earlier in this conversation.

WHEN TO USE:

• IMMEDIATELY after session_start — to check if there is any context from earlier in this session.

• When you need to recall what was discussed/decided/stored earlier in THIS conversation.

• Before starting a new task step — retrieve context about what was done so far.

HOW TO USE THE RESULTS:

• READ every section of the returned context carefully.

• APPLY the information to your current task — this is why it was stored.

• If you see stored decisions or notes, BUILD ON THEM.

• Do NOT ignore retrieved context — it was stored specifically to help you.

SESSION ISOLATION:

• Each session starts with ZERO entries — completely fresh.

• Only returns data stored via memory_store during THIS session.

• No data from past sessions, global knowledge graph, or vector store is included.

SECTIONS IN OUTPUT:

• [Current Session]: What has been stored so far in this conversation.

• [Current Session Notes]: Compressed notes from this session (if working memory was compressed).

TIP: Use a higher token_budget (5000-8000) for comprehensive context. Use lower (1000-2000) for focused lookups.

Compress memory at a given scope to reduce token usage and consolidate information.

WHEN TO USE:

• 'working': When working memory is getting large during a long conversation. Compresses current session buffer into a summary.

• 'session': When there are many session summaries. Merges multiple session-level summaries into fewer entries.

• 'epoch': After many sessions have accumulated. Promotes session summaries into high-level long-term knowledge. Requires at least 10 session summaries.

EFFECTS:

• All compression is lossy — details are condensed but key information is preserved.

• Compressed data is re-embedded for semantic search.

• Original entries are removed after compression.

Mark a memory as outdated, incorrect, or to be deleted.

WHEN TO USE:

• When the user corrects previously stored information.

• When stored facts become outdated (e.g., user changed jobs, moved cities).

• When duplicate or incorrect memories need cleanup.

ACTIONS:

• 'deprecate': Lowers confidence score so the memory is deprioritized but not removed. Use when unsure.

• 'correct': Replaces the memory content with new, correct information. Requires the 'correction' parameter.

• 'delete': Permanently removes the memory. Use for clearly wrong or duplicate entries.

You need the memory_id which is returned when you store a memory, or visible in memory_status output.

Get storage statistics for all memory subsystems.

WHEN TO USE:

• When debugging memory-related issues.

• When the user asks "what do you remember?" or "how much is stored?".

• To check if session_start was called (shows current session ID).

• To monitor token budgets and plan compression.

SHOWS: Tier counts, token estimates, knowledge graph size, vector store count, and current session ID.