MemoryGraph provides memory tools, but your AI assistant won't use them automatically. You need to configure memory directives to encourage storage and retrieval.

Why Configuration Is Needed

MemoryGraph is an MCP tool provider, not an autonomous agent. This means:

• Your AI needs to be prompted to use memory tools
• You control what gets stored - nothing is saved without instruction
• Configuration is key for consistent behavior

Quick Setup

Add this to your ~/.claude/CLAUDE.md (or AGENTS.md for other tools):

## Memory Protocol

### REQUIRED: Before Starting Work
You MUST use `recall_memories` before any task. Query by project, tech, or task type.

### REQUIRED: Automatic Storage Triggers
Store memories on ANY of:
- **Git commit** → what was fixed/added
- **Bug fix** → problem + solution
- **Version release** → summarize changes
- **Architecture decision** → choice + rationale
- **Pattern discovered** → reusable approach

### Timing Mode (default: on-commit)
`memory_mode: immediate | on-commit | session-end`

### Memory Fields
- **Type**: solution | problem | error | fix | code_pattern | workflow | task | project | technology | command | file_context | general
- **Title**: Specific, searchable (not generic)
- **Content**: Accomplishment, decisions, patterns
- **Tags**: project, tech, category (REQUIRED)
- **Importance**: 0.8+ critical, 0.5-0.7 standard, 0.3-0.4 minor
- **Relationships**: Link related memories when they exist

Do NOT wait to be asked. Memory storage is automatic.

Trigger Phrases

Your AI responds well to explicit memory requests:

For Storing

• "Store this for later..."
• "Remember that..."
• "Save this pattern..."
• "Record this decision..."
• "Create a memory about..."

For Recalling

• "What do you remember about...?"
• "Have we solved this before?"
• "Recall any patterns for..."
• "What did we decide about...?"

For Session Management

• "Summarize and store what we accomplished today"
• "Store a summary of this session"
• "Catch me up on this project"

Memory Types

Choose the right type for better organization:

Tagging Best Practices

Tags are critical for reliable retrieval. Follow these guidelines:

Always Include Acronyms as Tags

Fuzzy search struggles with abbreviations. Including acronyms as tags ensures reliable retrieval via exact match.

Tag Categories

• Project: Project or repo name
• Technology: Languages, frameworks, services
• Domain: Business domain or category
• Acronyms: All abbreviations mentioned in content

Query Strategies

Choose the right tool for your query type:

Relationship Types

Link related memories with typed relationships. MemoryGraph supports 35 relationship types across 7 categories:

Causal Relationships

# Direct causation
problem --CAUSES--> error
change --TRIGGERS--> bug
misconfiguration --LEADS_TO--> failure
validation --PREVENTS--> invalid_data
bad_merge --BREAKS--> feature

Solution Relationships

# Fixes and improvements
solution --SOLVES--> problem
fix --ADDRESSES--> error
caching --ALTERNATIVE_TO--> database_query
refactor --IMPROVES--> legacy_code

Context Relationships

# Where things apply
bug --OCCURS_IN--> auth_module
pattern --APPLIES_TO--> api_layer
redis --WORKS_WITH--> session_management
feature --REQUIRES--> database_migration
helper --USED_IN--> multiple_services

Knowledge Relationships

# Learning and understanding
new_pattern --BUILDS_ON--> existing_pattern
finding --CONTRADICTS--> assumption
test_result --CONFIRMS--> hypothesis
architecture_pattern --GENERALIZES--> specific_impl
microservice_config --SPECIALIZES--> base_config

Similarity Relationships

# Related concepts
timeout_fix --SIMILAR_TO--> connection_retry
v2_approach --VARIANT_OF--> v1_approach
auth_pattern --RELATED_TO--> security_pattern
graph_algorithm --ANALOGY_TO--> tree_traversal

Lifecycle Relationships

# Sequences and dependencies
deploy --FOLLOWS--> test
service --DEPENDS_ON--> database
auth --ENABLES--> api_access
lock --BLOCKS--> concurrent_write
frontend --PARALLEL_TO--> backend
new_api --REPLACES--> deprecated_api
success --OPPOSITE_OF--> failure

Evaluation Relationships

# What works and what doesn't
caching --EFFECTIVE_FOR--> read_heavy_workload
polling --INEFFECTIVE_FOR--> real_time_updates
websockets --PREFERRED_OVER--> long_polling
old_sdk --DEPRECATED_BY--> new_sdk
approach --VALIDATED_BY--> load_test

Example Workflows

Debugging Workflow

1. Encounter error → Store as type: error
2. Find root cause → Store as type: problem, link: error TRIGGERS problem
3. Implement fix → Store as type: solution, link: solution SOLVES problem
4. Result: Complete chain for future reference

Feature Development Workflow

1. Start: "Recall any patterns for user authentication"
2. Implement: [Work on feature]
3. Store: "Store this authentication pattern" → type: code_pattern
4. Link: pattern APPLIES_TO project
5. End: "Store summary of authentication implementation"

Project-Specific Configuration

For team projects, add a .claude/CLAUDE.md to the repository:

## Project Memory Protocol

This project uses MemoryGraph for team knowledge sharing.

### When to Store
- Solutions to project-specific problems
- Architecture decisions and rationale
- Deployment procedures and gotchas
- Performance optimizations
- Bug fixes and root causes

### Tagging Convention
Always include these tags:
- Project name: "my-app"
- Component: "auth", "api", "database", etc.
- Type: "fix", "feature", "optimization", etc.

### Example
When fixing a bug:
1. Store the problem (type: problem)
2. Store the solution (type: solution)
3. Link them: solution SOLVES problem
4. Tag both with component and "bug-fix"

Next Steps

• Available Tools Reference
• Configuration Options
• Troubleshooting Guide