memory_store
Proactively store detailed, self-contained memory entries about facts, preferences, events, and summaries, enabling future AI to understand context without re-deriving information.
Instructions
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".
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | DETAILED, self-contained paragraph (3-5+ sentences). Must include full context so a future AI can understand without re-deriving. Include specifics: names, paths, colors, versions, decisions, reasoning. NEVER write single sentences — that defeats the purpose of memory. | |
| memory_type | Yes | Category: 'core' for critical permanent info, 'fact' for knowledge, 'preference' for user likes/dislikes, 'event' for what just happened, 'summary' for compressed notes. | |
| confidence | No | Confidence 0.0-1.0. Lower confidence = evicted first. Default 1.0. Use lower values for uncertain or temporary information. | |
| entities | No | Key entities this memory relates to. REQUIRED for 'fact' type — first entity is the subject. Example: ['User', 'JavaScript'] for 'User knows JavaScript'. |