If you use one OpenClaw agent across multiple codebases, you’ve hit this: your agent recalls deployment configs from your backend repo while you’re working on the frontend. Or it suggests a testing pattern from your side project in your day job’s repo. Memories bleed across projects because there’s one flat memory pool.

MemoClaw namespaces fix this. Each project gets its own namespace, recalls are scoped by default, and you can still do cross-namespace lookups when you want shared context.

The memory bleed problem

Say you have three projects: a React frontend, a Node API, and a personal automation repo. Your agent learns things in each context — “this project uses Vitest,” “deploy to Railway on merge,” “Ana prefers tabs.” Without namespaces, all of that goes into one bucket. When your agent recalls “how do we deploy this?” while you’re in the frontend repo, it might pull up the backend’s Railway config instead of the frontend’s Vercel setup.

This isn’t theoretical. It happens as soon as you accumulate 50+ memories across projects. The more your agent knows, the noisier the recalls get.

Setting up namespaces

A namespace is just a string you pass to store and recall. Nothing to configure upfront.

# Store with a namespace
memoclaw store "Deploy to Vercel on push to main" --namespace frontend --importance 0.8 --tags deploy

# Store in a different namespace
memoclaw store "Deploy to Railway on merge to main" --namespace backend --importance 0.8 --tags deploy

# Recall is scoped to the namespace
memoclaw recall "how do we deploy" --namespace frontend
# → Returns only the Vercel memory

In your OpenClaw agent’s AGENTS.md or skill config, you’d set the namespace per workspace:

## Memory

Use namespace `frontend` for all memoclaw calls in this project.

Your agent picks this up and passes --namespace frontend on every store/recall. Each project’s workspace file sets its own namespace.

Cross-namespace recall for shared context

Some memories should apply everywhere. “I prefer TypeScript” isn’t project-specific. Neither is “always use pnpm” or “my timezone is GMT-3.”

You have two options:

Option 1: Store global memories without a namespace. Memories stored without --namespace go into the default pool. Any namespaced recall that doesn’t find a match can fall back to the default pool.

# Store a global preference (no namespace)
memoclaw store "User prefers TypeScript over JavaScript" --importance 0.9 --tags preferences

# This gets found from any namespace
memoclaw recall "what language does the user prefer" --namespace frontend
# → Finds the global preference

Option 2: Recall across namespaces explicitly. Skip the namespace flag when you want the full picture.

# Search everything
memoclaw recall "deployment process" 
# → Returns memories from all namespaces

What this looks like in practice

Here’s a real setup. Three projects, one agent:

Frontend workspace (~/code/app-frontend/AGENTS.md):

Use memoclaw namespace `app-frontend` for all memory operations.

Backend workspace (~/code/app-backend/AGENTS.md):

Use memoclaw namespace `app-backend` for all memory operations.

Personal workspace (~/code/personal/AGENTS.md):

Use memoclaw namespace `personal` for all memory operations.

Global preferences stored without a namespace:

memoclaw store "Always use pnpm, not npm or yarn" --importance 0.9 --tags preferences
memoclaw store "Prefers Hetzner for VPS, Vercel for frontend" --importance 0.8 --tags preferences,infra
memoclaw store "Timezone is GMT-3, based in Brazil" --importance 0.7 --tags personal

Now when your agent works in app-frontend, it recalls frontend-specific memories first. But when it needs to know your package manager preference, the global memory is still accessible.

Namespace naming

Keep it simple. Use the repo name or project name. Don’t overthink a hierarchy — flat namespaces work fine.

frontend          ← good
backend           ← good
app/frontend/v2   ← too much

If you rename a project, you can recall all memories from the old namespace and re-store them under the new one. There’s no migration command yet, but it’s a few lines of scripting.

When namespaces aren’t the answer

If you only have one or two projects, namespaces add overhead for minimal benefit. Just use the default pool. Namespaces start paying off at three or more active projects, or when you’re getting noisy recalls from mixed contexts.

Also, namespaces don’t help if the problem is stale memories. If your agent keeps recalling outdated deployment configs, the fix is deleting old memories, not adding namespaces. Use memoclaw list --namespace backend to audit what’s stored and clean out anything that’s no longer accurate.

Getting started

Install the CLI if you haven’t:

npm install -g memoclaw

Pick a namespace for each project, add a line to each workspace’s AGENTS.md, and start storing. Your agent’s recalls will get noticeably less noisy within a day or two of scoped usage.

That’s it. No registration, no config files, no database to manage. Just --namespace on your store and recall calls.