/brain:memorize

Analyze the current session and extract significant decisions, learnings, insights, experiences, or goals into persistent memory files.

Usage

/brain:memorize [topic] [--sync] [--confirm]

Arguments:

• [topic] — (Optional) Focus area for memorization. If provided, the agent focuses on memories related to that topic. If omitted, the agent analyzes the entire session.

Flags:

• --sync — Automatically push to Brain Cloud or Git after storing. Eliminates the need for a separate /brain:sync push step.
• --confirm — Ask for confirmation before writing. By default, memories are stored immediately — the user said "memorize", so no confirmation is needed.

What It Does

When you run /brain:memorize, the agent:

1. Analyzes the session — Reviews the conversation for significant content worth preserving
2. Classifies each memory — Determines memory type, cognitive type, strength, salience, confidence, tags, and hierarchy path
3. Calls brain memorize CLI — Pipes the classified memories as JSON to a single CLI command that handles all file operations: ID generation, directory creation, file writing, index updates, association edges, and search index
4. Reports results — Shows what was stored with IDs, paths, and metadata

The entire flow is a single tool call — no multi-step file juggling.

Hierarchy Placement

The agent decides placement depth based on how specific the memory is:

• A generic career thought lands in professional/
• A skill-related learning goes to professional/skills/
• A specific project decision goes to professional/companies/acme/projects/alpha/

Subdirectories are created on demand — the agent creates deeper nesting when the content warrants it, up to the configured max_depth (default: 6).

Sensitivity

Every memory carries a consent tier, sensitivity. The agent classifies it — it read the conversation — and the CLI keeps a narrow pattern backstop that can raise a label but never lower it.

The label describes the topic, not whether you asked to remember it — "user is diabetic" is sensitive even after "remember that". Approval is per-item consent. Opting in is never retroactive: it does not recover a refused write, and memories already held keep their pending flag until you approve them. Receipts for sensitive memories carry ⚠ sensitive, before and after approval.

Only non-standard values are written to frontmatter and the index. The vocabulary deliberately matches Anthropic's published memory consent model (August 2026), so a brain interoperates with it instead of inventing a schema. See Provenance & Trust for how consent sits beside origin.

Memory File Format

Each memory is created as a Markdown file with YAML frontmatter:

---
id: mem_20260213_a3f2c1
type: decision
cognitive_type: semantic
created: 2026-02-13T14:30:00Z
last_accessed: 2026-02-13T14:30:00Z
access_count: 0
recall_history: []
strength: 0.85
decay_rate: 0.995
salience: 0.8
confidence: 0.9
tags: [architecture, microservices, scaling]
related: [mem_20260210_b4e5d6]
source: project-alpha-session
encoding_context:
  project: project-alpha
  topics: [architecture, scaling, kafka]
  task_type: designing
---
 
# Chose Event-Driven Architecture for Project Alpha
 
We decided to use event-driven architecture with Kafka instead of
synchronous REST calls between services, because the traffic analysis
showed 10x burst patterns that would overwhelm synchronous endpoints.
 
## Context
 
Sprint planning for Q2, evaluating scaling strategy for the notification system.
 
## Key Details
 
- Kafka chosen over RabbitMQ for its replay capability
- Event schema registry added to prevent breaking changes
- Estimated 3-week implementation vs 1-week for REST

See Memory Format for a complete field reference.

Example Interactions

Memorizing the entire session

User: /brain:memorize

Agent: Analyzed the session and found 3 memories to store:

1. 📝 Decision: Chose event-driven architecture for Project Alpha
   → professional/companies/acme/projects/alpha/architecture-decision.md
   Strength: 0.85 | Salience: 0.8 | Type: semantic

2. 💡 Insight: Burst traffic patterns require async processing
   → professional/skills/architecture/async-patterns.md
   Strength: 0.90 | Salience: 0.6 | Type: semantic

3. 📖 Learning: Kafka schema registry prevents breaking changes
   → professional/skills/kafka/schema-registry.md
   Strength: 0.70 | Salience: 0.4 | Type: semantic

Created 2 association links:
  • Decision ↔ Insight (tag overlap: architecture)
  • Decision ↔ Learning (explicit relation)

Memorizing a specific topic

User: /brain:memorize deployment lessons

Agent: Focused on deployment-related content from this session:

1. 📝 Experience: Production deploy failed due to missing env variable
   → professional/companies/acme/projects/alpha/deploy-incident-mar5.md
   Strength: 0.85 | Salience: 0.7 | Type: episodic

2. 📖 Learning: Always verify env variables before deploy
   → professional/skills/devops/pre-deploy-checklist.md
   Strength: 0.70 | Salience: 0.5 | Type: procedural

CLI

Brain Memory also provides a brain memorize CLI for programmatic use:

brain memorize <<'EOF'
{
  "memories": [{
    "title": "Chose event-driven architecture",
    "type": "decision",
    "cognitive_type": "semantic",
    "path": "professional/projects/alpha/architecture-decision.md",
    "tags": ["architecture", "kafka"],
    "salience": 0.8,
    "confidence": 0.9,
    "content": "# Chose Event-Driven Architecture\n\nWe decided to use Kafka..."
  }]
}
EOF

Add "sensitivity": "sensitive" (or "blocked") to a memory to classify it; omit the field for standard. Each stored memory in the result reports sensitivity when it is not standard, plus sensitive_opt_out: true — alongside quarantine_pending: true and quarantine_reasons — when the write was held for consent. A blocked memory is not stored; the CLI returns an error naming the category.

Add --sync to auto-push after storing:

brain memorize --sync <<'EOF'
...
EOF