When you first start using MemoClaw, you throw everything into the default namespace. Preferences, project notes, random facts your human mentioned once. It works.
Then you add a second project. Then a third. Then you realize your agent is recalling deployment notes for Project A while you're asking about Project B, and the context is wrong in ways that are hard to debug.
Namespaces fix this. They're isolated memory spaces within your MemoClaw account. Memories in one namespace can't leak into another. Same wallet, completely separate recall.
The question isn't whether to use them. It's how to structure them so they actually help instead of creating a different kind of mess.
What namespaces actually do
A namespace is just a label that isolates a group of memories. When your agent calls memoclaw recall, it searches within a single namespace. No cross-namespace results unless you explicitly query multiple.
# Store to a specific namespace
memoclaw store "Uses Railway for deploys" --namespace content-engine
# Recall from that namespace only
memoclaw recall "deployment setup" --namespace content-engine
If you don't specify a namespace, everything goes to default. Fine for simple setups, noisy fast.
There's no extra cost for namespaces. You can have as many as you want. Namespaces are just metadata on each memory, so the only cost is the store/recall calls themselves.
One namespace per project
The most common pattern. Each codebase or project gets its own namespace.
default → personal preferences, general knowledge
content-engine → blog workflow, content pipeline details
trading-bot → exchange APIs, risk parameters
home-automation → device names, room layouts, routines
This works well when you have 2-5 distinct projects and your agent switches between them in different conversations.
Where it breaks: overlapping projects. Maybe your content-engine deploys the same way as your trading-bot. Storing "Uses Railway" in both namespaces means maintaining the same fact in two places. It'll drift.
Fix: keep shared infrastructure knowledge in default and project-specific details in their namespaces. Your agent queries default first, then the project namespace.
Shared + project namespaces
A refinement of the above. You explicitly separate shared context from project-specific context.
shared → deployment patterns, coding standards, tool preferences
project-alpha → project-specific architecture, team contacts
project-beta → different stack, different team
personal → human preferences, communication style, schedule
Your agent's recall flow becomes:
- Always recall from
personal(preferences affect every interaction) - Always recall from
shared(common tools and patterns) - Recall from the active project namespace
This costs more calls per interaction, up to 3 recalls instead of 1. Each recall is $0.005, so three per interaction is $0.015. Still cheap. Context quality goes up noticeably.
You can bake this directly into your agent config:
## Memory recall pattern
For every task:
1. Recall from "personal" namespace for communication preferences
2. Recall from "shared" namespace for general technical context
3. Identify the active project and recall from its namespace
Client-based namespaces
If you're freelancing or consulting, organize by client instead of project.
client-acme → Acme Corp preferences, contacts, project history
client-initech → Initech codebase details, meeting notes
internal → your own projects and preferences
Client contexts rarely overlap, so this gives you clean separation without much discipline required.
One thing to watch: when you stop working with a client, their namespace still exists. Export it with memoclaw export --namespace client-acme (free endpoint) and then bulk delete if you want to clean up.
Environment-based namespaces
For agents that behave differently depending on context.
work → professional communication style, work projects
personal → casual tone, personal projects, home stuff
discord-server → community context, member names, channel purposes
Less about data separation, more about behavioral context. Your agent recalls from work and gets "Keep responses professional, use formal language." Recalls from personal and gets "Be casual, use humor."
Some people combine this with project namespaces using a convention like work/project-alpha as the namespace name. MemoClaw doesn't enforce hierarchy in names, but the slash convention keeps things readable in the CLI output.
When to skip namespaces
If your agent does one thing, for one person, on one project, a single namespace with good tags might be enough.
memoclaw store "Deploy command: railway up" --tags infra,deploy
memoclaw store "Human prefers dark mode" --tags preferences,ui
memoclaw recall "how do we deploy" --tags infra
Tags filter within a namespace. They're lighter-weight than namespaces and don't require deciding which namespace to query.
Rule of thumb: under 200 memories and one main project, tags are enough. Over 200 or multiple distinct contexts, add namespaces.
Naming conventions
Your agent constructs these strings programmatically, so predictability matters.
Good:
content-engine
trading-bot
client-acme
Avoid:
Content Engine
my_trading_bot_v2
ACME Corp Client (2026)
Lowercase, kebab-case. No spaces, no special characters.
Migrating between namespace strategies
Already have memories in the wrong namespaces? Here's the approach:
- Export the old namespace:
memoclaw export --namespace old-name > backup.json
Export is free.
Re-store in the new namespace. There's no "move" command. You'll need to store the memories again. Use batch store for up to 100 at once ($0.04) to keep costs down.
Delete from the old namespace:
memoclaw bulk-delete --namespace old-name
Bulk delete is also free.
It's manual, but namespace restructuring is a one-time thing. Better to do it once than live with a confusing structure.
Multi-agent namespaces
If multiple agents share the same wallet, they share access to all namespaces. You can use this intentionally.
Three agents: coding agent, review agent, documentation agent. Same wallet, different namespaces:
code-context → coding agent stores architectural decisions
review-notes → review agent stores patterns and issues found
docs-context → docs agent stores style guides and terminology
shared → all agents read from here for project-wide context
Each agent writes to its own namespace and reads from shared plus its own. The coding agent doesn't get confused by documentation style notes. The docs agent doesn't see low-level implementation details.
To share something across all agents, any of them can store to shared:
memoclaw store "Project switched from REST to GraphQL as of March 2026" \
--namespace shared --importance 0.8 --tags architecture
All three agents pick this up on their next recall from shared.
What to actually do
For most OpenClaw users:
- Start with
defaultnamespace and tags - When you add a second project that's clearly separate, create a namespace for it
- Move personal preferences to a
personalnamespace so they're always available regardless of project - Don't create namespaces preemptively. Create them when you feel the pain of mixed context
The goal is less noise in recall, not a perfect taxonomy. Keep it practical.
Checking what you've got
A few free endpoints for namespace management:
# List all your namespaces
memoclaw namespaces
# See memory count and stats
memoclaw stats
# List memories in a specific namespace
memoclaw list --namespace content-engine
# Export everything for backup
memoclaw export --namespace content-engine > backup.json
All free. No embeddings, no cost against your 100 free-tier calls.
Start simple, add structure when you need it, use the free endpoints to keep track of what's where.
Top comments (0)