You installed MemoClaw, stored some memories, and everything’s working. Then you start a second project. Then a third. Suddenly your agent’s recalls are pulling payment integration notes when you’re asking about your blog redesign. Everything’s in one bucket, and the bucket is getting noisy.

Namespaces fix this. They’re MemoClaw’s way of isolating memories into separate containers, like databases within a database. Each namespace has its own memory space, so recalls only search within the namespace you specify.

The problem is that most people never move beyond the default namespace. This guide covers practical patterns for organizing namespaces that actually scale.

Namespace basics

Every MemoClaw operation accepts an optional --namespace flag. If you omit it, memories go into the default namespace.

# Stores in "default" namespace
memoclaw store --text "User prefers dark mode"

# Stores in "work" namespace
memoclaw store --text "Sprint planning is every Monday at 10am" --namespace "work"

# Recalls ONLY from "work" namespace
memoclaw recall --query "meeting schedule" --namespace "work"

Namespaces are created implicitly. Just use a name and it exists. No setup required.

Managing namespaces

# List all namespaces with memory counts
memoclaw namespaces

# Get stats for a specific namespace
memoclaw stats --namespace "work"

Pattern 1: Per-project isolation

The most common and most useful pattern. Give each project its own namespace.

# E-commerce project
memoclaw store --namespace "project-ecommerce" \
  --text "Payment provider: Stripe Connect. Webhook endpoint: /api/webhooks/stripe. Using TypeScript strict mode." \
  --tags "architecture" --importance 0.85

# Blog redesign
memoclaw store --namespace "project-blog" \
  --text "Using Astro with MDX. Design system: Tailwind + custom components. Deploy target: Vercel." \
  --tags "architecture" --importance 0.85

# Open source library
memoclaw store --namespace "project-memoclaw-sdk" \
  --text "SDK supports TypeScript and Python. Publishing to npm and PyPI. Semantic versioning with changesets." \
  --tags "architecture" --importance 0.85

When you switch projects, your agent switches namespaces and gets clean, relevant context:

# Working on e-commerce? Only e-commerce memories surface
memoclaw recall --namespace "project-ecommerce" --query "payment setup" --limit 5

Wiring it into your agent

Add project awareness to your agent’s AGENTS.md:

## Project context

When working on a specific project, set the active namespace:
- E-commerce app → namespace: "project-ecommerce"
- Blog redesign → namespace: "project-blog"
- MemoClaw SDK → namespace: "project-memoclaw-sdk"

Use this namespace for all store and recall operations during the session.
At session start, recall: `memoclaw recall --namespace "<active>" --query "project context and recent decisions" --limit 5`

Pattern 2: Memory type separation

Instead of (or alongside) project namespaces, separate memories by type:

# User preferences — rarely change, high importance
memoclaw store --namespace "preferences" \
  --text "Prefers concise responses. Uses vim keybindings. Timezone: UTC+1. Name pronunciation: ah-nah, not anna." \
  --importance 0.95 --tags "user-pref"

# Session summaries — rolling context, medium importance
memoclaw store --namespace "sessions" \
  --text "Session 2026-03-08: Debugged webhook handler, decided on retry strategy..." \
  --importance 0.7 --tags "session-summary"

# Learned knowledge — from cron jobs, external monitoring
memoclaw store --namespace "learnings" \
  --text "PostgreSQL 17 released with incremental backup support..." \
  --importance 0.6 --tags "tech-news"

This lets you set different consolidation strategies per type:

# Consolidate sessions weekly (they accumulate fast)
memoclaw consolidate --namespace "sessions"

# Consolidate learnings weekly (news gets stale)
memoclaw consolidate --namespace "learnings"

# Never consolidate preferences (they're curated)

Pattern 3: Hybrid (project + type)

For power users managing multiple projects, combine both patterns:

project-ecommerce/     → project-specific knowledge
project-blog/          → project-specific knowledge
preferences/           → cross-project user preferences
sessions/              → session summaries (all projects)
learnings/             → external knowledge

Your agent loads preferences and sessions every startup, then loads the project namespace based on what you’re working on.

# Always load on startup
memoclaw recall --namespace "preferences" --query "user preferences" --limit 10
memoclaw recall --namespace "sessions" --query "recent session summaries" --limit 3

# Load project context when switching
memoclaw recall --namespace "project-ecommerce" --query "current state and decisions" --limit 5

Pattern 4: Environment separation

If your agent works across dev/staging/prod (maybe managing deployments or infrastructure), namespace by environment:

# Store prod deployment details
memoclaw store --namespace "env-prod" \
  --text "Last deploy: v2.3.1 on 2026-03-07. Railway auto-deploy from main branch. 3 instances, 512MB each." \
  --tags "deployment" --importance 0.8

# Store staging issues
memoclaw store --namespace "env-staging" \
  --text "Staging DB is on Neon free tier — connection limit of 5. Use connection pooling." \
  --tags "infrastructure" --importance 0.7

When debugging a production issue, recall from env-prod only. No staging noise.

Pattern 5: Multi-agent with shared wallet

If you run multiple OpenClaw agents sharing the same wallet, namespaces prevent memory collisions:

# Agent: Quill (content writer)
memoclaw store --namespace "agent-quill" \
  --text "Editorial calendar: publish Tuesday/Thursday. Current series: MemoClaw tutorials." \
  --tags "workflow" --importance 0.8

# Agent: Scout (research assistant)
memoclaw store --namespace "agent-scout" \
  --text "Monitoring: HN, ArXiv cs.AI, OpenClaw Discord. Report frequency: daily digest." \
  --tags "workflow" --importance 0.8

# Shared knowledge (both agents read)
memoclaw store --namespace "shared" \
  --text "Company voice: developer-friendly, direct, no corporate speak. See PRODUCT_CONTEXT.md for full guidelines." \
  --tags "brand" --importance 0.9

Each agent reads its own namespace plus shared. No one steps on anyone else’s memories.

Naming conventions

Keep names consistent. Here’s a convention that scales:

Pattern	Format	Example
Project	project-<name>	project-ecommerce
Environment	env-<name>	env-prod
Memory type	<type>	preferences, sessions
Agent	agent-<name>	agent-quill
Shared	shared	shared

Lowercase, kebab-case. No spaces or special characters.

When to split vs. share

Split into separate namespaces when:

• Memories from different contexts would pollute each other’s recalls
• You want different consolidation strategies
• Multiple agents need isolated memory spaces
• You want to delete an entire context cleanly

Keep in the same namespace when:

• Memories are closely related and benefit from cross-referencing
• You want a single recall to surface connections across topics
• The total memory count is small (under 100)

Good rule of thumb: if you’d put them in separate folders on a filesystem, put them in separate namespaces.

Migration: from default to organized

Already have a bunch of memories in default? Here’s how to reorganize:

# 1. List what's in default
memoclaw list --namespace "default"

# 2. Recall by topic and re-store in the right namespace
memoclaw recall --namespace "default" --query "user preferences" --limit 20
# Copy the relevant ones to their new homes

# 3. Delete from default after migrating
memoclaw delete --id <memory-id> --namespace "default"

It’s manual, but you only do it once. Going forward, store to the right namespace from the start.

Start here

Namespaces are the difference between a memory system that works at scale and one that collapses into noise. Start simple: one namespace per project, one for preferences. Expand as your needs grow.

The thing to remember: namespaces are free (no extra cost) and recall is scoped (you only search where you point it). Use that.

# Install the skill
clawhub install anajuliabit/memoclaw

# Check your current namespaces
memoclaw namespaces