When you first set up MemoClaw, everything goes into the default namespace. It works. Then you add a second project, a third agent, a client engagement, and suddenly your recall results are a mess. Your coding agent pulls back memories about grocery preferences. Your personal assistant recalls deployment notes.

Namespaces fix this. But “just use namespaces” isn’t advice — it’s a suggestion. Here’s how to actually think about organizing them.

What namespaces do

A namespace is an isolation boundary. Memories stored in one namespace don’t show up in recalls against another. That’s the whole thing. No inheritance, no nesting, no fancy hierarchy. Just separate buckets.

# Store in a specific namespace
memoclaw store --text "User prefers dark mode" --namespace personal-prefs

# This recall won't find the above memory
memoclaw recall "user preferences" --namespace work-project

# This one will
memoclaw recall "user preferences" --namespace personal-prefs

Simple. The question is: how do you decide what goes where?

Three strategies that work

After running multiple agents with MemoClaw, three patterns cover most situations. Pick the one that matches how you work.

Strategy 1: project-based namespaces

One namespace per project. If you’re working on three things, you have three namespaces.

myapp-backend
myapp-frontend
client-acme-redesign

When this works: You have distinct projects with different contexts. An agent working on the backend doesn’t need to know about the client redesign.

How to name them: Keep it short and greppable. project-name or client-name-project works. Avoid dates in namespace names — that’s what tags are for.

# Agent working on the backend
memoclaw store \
  --text "Migrated auth to JWT. Old session-based auth removed." \
  --namespace myapp-backend \
  --tags "auth,migration"

# Agent working on the frontend
memoclaw store \
  --text "Login form now sends credentials to /api/auth/token endpoint" \
  --namespace myapp-frontend \
  --tags "auth,login"

Both are about auth, but they’re in separate namespaces because they’re different contexts. The backend agent doesn’t need to wade through frontend memories.

Strategy 2: role-based namespaces

One namespace per agent role. Your coding agent, personal assistant, and content writer each get their own space.

agent-coder
agent-assistant
agent-writer

When this works: You have specialized agents with different responsibilities. The coder shouldn’t recall your dinner preferences, and the assistant doesn’t need to know about database schemas.

When it breaks down: When two agents need the same context. If your coder and assistant both need to know about project deadlines, you’re storing things twice or picking which namespace to put shared info in.

The workaround: create a shared namespace for cross-agent knowledge.

# Coder stores technical context
memoclaw store \
  --text "PostgreSQL 16, using pgvector for embeddings" \
  --namespace agent-coder

# Assistant stores scheduling context
memoclaw store \
  --text "Sprint ends Friday. Demo scheduled for Monday 10am" \
  --namespace agent-assistant

# Both can recall from shared when needed
memoclaw store \
  --text "Project deadline moved to March 15" \
  --namespace shared \
  --importance 0.9

Strategy 3: hybrid (project + role)

Combine both. Use a project-role pattern.

myapp-coder
myapp-assistant
client-acme-coder
client-acme-pm

When this works: You’re running multiple agents across multiple projects. This is the most granular approach and scales well, but it means more namespaces to manage.

Only reach for this if you’re actively juggling 3+ projects with 2+ agents each. For most setups, project-based or role-based alone is enough.

Naming conventions that save headaches

A few rules learned the hard way:

Use lowercase and hyphens. my-project not MyProject or my_project. Consistency saves you from “wait, did I capitalize that?” moments.

Be specific enough to be unique. backend is too vague if you have multiple backends. myapp-backend is fine.

Don’t encode temporal info in the namespace. standup-2026-03 tempts you to create a new namespace every month. Use tags for dates, keep the namespace stable: standup.

Keep a list. Seriously. A simple text file in your workspace that lists your active namespaces and what they’re for. Future you will appreciate it.

# Active namespaces

- `myapp-backend` — Backend service for MyApp. Auth, API, database decisions.
- `myapp-frontend` — Frontend for MyApp. UI decisions, component patterns.
- `standup` — Daily standup agent summaries.
- `personal` — Personal preferences, habits, corrections.

You can even store this as a memory:

memoclaw store \
  --text "Active namespaces: myapp-backend (backend decisions), myapp-frontend (UI patterns), standup (daily summaries), personal (preferences and corrections)" \
  --namespace meta \
  --importance 0.8 \
  --tags "namespaces,organization"

Cross-namespace recall

MemoClaw doesn’t support querying across multiple namespaces in a single recall. Each recall hits one namespace. If you need to aggregate, make multiple calls.

# Pull context from two namespaces
memoclaw recall "authentication changes" --namespace myapp-backend --top-k 3
memoclaw recall "authentication changes" --namespace myapp-frontend --top-k 3

Two calls, $0.01 total. Not a big deal for the clarity you get from keeping namespaces separate.

If you find yourself constantly recalling from multiple namespaces for the same task, that’s a signal your namespace boundaries might be wrong. Merge them or rethink the split.

When to share a namespace (same wallet)

All agents using the same wallet can access the same namespaces. This is by design — your wallet is your identity, and all your agents are “you.”

This is powerful for agent teams. A research agent stores findings, and a writing agent recalls them later. Same wallet, same namespace, different agents.

# Research agent stores a finding
memoclaw store \
  --text "According to the 2025 State of AI report, 73% of production agents have no persistent memory" \
  --namespace content-research \
  --tags "statistics,memory,research"

# Writing agent recalls it later
memoclaw recall "statistics about agent memory adoption" \
  --namespace content-research \
  --top-k 5

No API keys to share, no permissions to configure. If both agents use the same wallet, they see the same memories. Coordinate through namespace conventions, not access control.

When to split vs. when to merge

Split when:

• Two agents or projects have genuinely different contexts
• Recall results are noisy because unrelated memories keep showing up
• You want to delete all memories for one project without affecting others

Merge when:

• You’re making multiple recall calls to different namespaces in almost every run
• Two “separate” contexts always need each other’s information
• The namespace split is creating more work than it prevents

There’s no perfect answer. Start with fewer namespaces and split when recall gets noisy. That’s easier than starting with ten namespaces and trying to figure out which one has the memory you need.

Practical starting point

If you’re just getting started with MemoClaw and aren’t sure how to structure things:

1. Use default for personal preferences and corrections (things every agent should know)
2. Create one namespace per active project
3. If you run cron jobs, give each cron agent its own namespace
4. Keep a list of your namespaces somewhere findable

Refine from there. You’ll know when a namespace needs splitting because your recalls start returning irrelevant results. That’s the signal, not some upfront architecture diagram.

Namespaces are cheap. Creating one costs nothing. The only cost is the mental overhead of keeping track of them, and a simple list handles that.