You’re working on three projects. Your agent knows things about all of them. When it recalls memories for the dashboard project, it also pulls up decisions about the CLI tool and that side project you abandoned two weeks ago.

This is the default experience with flat memory. Everything’s in one bucket. Semantic search does its best, but “API authentication approach” matches memories from every project you’ve ever worked on. Your agent gets confused, mixes up contexts, and occasionally applies the wrong project’s conventions to the current one.

Namespaces fix this. They’re simple, just a string you pass when storing and recalling, but they change how your agent thinks about projects.

What namespaces actually do

A namespace is an isolation boundary for memories. When you store a memory in the “dashboard” namespace, it only shows up when you recall from “dashboard.” Search the “cli-tool” namespace and dashboard memories don’t exist.

store("Using Tailwind for all styling, no CSS modules", namespace: "dashboard", importance: 0.7, tags: ["tech-stack"])

recall("what styling approach are we using?", namespace: "dashboard")
// Returns: "Using Tailwind for all styling, no CSS modules"

recall("what styling approach are we using?", namespace: "cli-tool")
// Returns nothing — different namespace

That’s it. No complex configuration, no setup step. You pick a namespace string and use it consistently.

Designing your namespace scheme

This is where people make it harder than it needs to be. I’ve seen setups with nested namespaces, namespaces per feature, namespaces per sprint. They all collapse under their own weight.

What works: one namespace per project. Maybe a “global” namespace for cross-project stuff. Done.

dashboard          — the dashboard web app
cli-tool           — the CLI you're building
memoclaw-content   — content writing project
global             — preferences and patterns that apply everywhere

Use short, lowercase, hyphenated names. Your agent will type these a lot. Don’t make it spell out “enterprise-dashboard-application-v2-refactor” every time.

The “global” namespace

Some memories don’t belong to any project. Your human’s coding style preferences. How they like commit messages formatted. Their timezone. General patterns.

Store these in a “global” namespace (or “shared” or “common,” pick a word and stick with it). When your agent starts a session, it can recall from both the project namespace and global to get full context.

store("Always use conventional commits format: feat/fix/chore prefix", namespace: "global", importance: 0.8, tags: ["conventions"])

This memory is now available regardless of which project your agent is working on. But it won’t pollute project-specific recalls with unrelated context.

Making your agent project-aware

The real trick isn’t namespaces themselves. It’s teaching your agent to pick the right namespace automatically. You don’t want to manually specify “use the dashboard namespace” every time.

Option 1: Directory detection

If each project lives in its own directory (which it probably does), your agent can infer the namespace from the working directory.

Add this to your AGENTS.md:

## Memory namespaces

When working in a project directory, use the directory name as the MemoClaw namespace:
- ~/code/dashboard → namespace: "dashboard"  
- ~/code/cli-tool → namespace: "cli-tool"

For general preferences and cross-project patterns, use namespace: "global"

Always recall from both the project namespace AND "global" when starting work.

Your agent reads this, checks its working directory, and knows which namespace to use. No manual intervention.

Option 2: Explicit project context

If your projects don’t map cleanly to directories (monorepo, maybe), keep a small mapping in your AGENTS.md or TOOLS.md:

## Active projects

| Project | Namespace | Description |
|---------|-----------|-------------|
| Dashboard redesign | dashboard | Web app, React + Tailwind |
| Release CLI | cli-tool | Node.js CLI for release management |
| Content pipeline | content | Blog posts and social media |

Your agent reads the table, matches against whatever task it’s doing, and picks the right namespace.

Option 3: Let the agent figure it out

If you trust your agent’s judgment (and it’s gotten pretty good at this), just tell it the principle:

Use MemoClaw namespaces to separate project memories. Pick a consistent namespace name per project. Use "global" for cross-project knowledge. When in doubt, check what namespaces you've already used.

The list command in MemoClaw shows existing namespaces, so your agent can see what’s already there and stay consistent.

The session flow

Here’s what a project-aware session looks like:

Session start:

1. Agent reads MEMORY.md (always-on context, small)
2. Agent reads today’s daily log
3. Human says “let’s work on the dashboard”
4. Agent recalls from namespace “dashboard”: recent decisions, open questions, tech stack
5. Agent recalls from namespace “global”: coding preferences, conventions
6. Agent now has project-specific context without reading a giant catch-all file

During work:

Agent stores new memories in the “dashboard” namespace as decisions get made. Importance scores and tags work the same way, namespaces just add the isolation layer.

store("Moved from REST to GraphQL for the data layer. Using urql as the client.", namespace: "dashboard", importance: 0.7, tags: ["decisions", "architecture"])

Session end:

Agent reviews what happened, stores permanent memories in the right namespace, writes short-term notes to the daily log. Same three-bucket approach (if you’ve read the session summaries post), the namespace just tells memories where to live.

Multi-agent setups

Here’s where namespaces get interesting. If you run multiple agents under the same wallet, they share memory access. A coding agent and a review agent working on the same project can both read and write to the “dashboard” namespace.

The coding agent stores: “Refactored the auth middleware to use JWT validation instead of session cookies.”

The review agent recalls this when reviewing a PR that touches auth. It has context the coding agent created, without any explicit handoff.

This works because MemoClaw ties memory access to wallets, not individual agents. Same wallet, same memory pool. Namespaces let you organize within that shared pool so agents aren’t drowning in each other’s unrelated notes.

You can also use namespaces to create agent-specific memory spaces within a shared wallet. A “coder-meta” namespace for the coding agent’s self-reflections. A “reviewer-patterns” namespace for the review agent’s learned heuristics. Each agent has its own space for internal notes while sharing project namespaces for work output.

When not to use namespaces

If you only work on one project, namespaces add complexity for no benefit. Just use the default namespace (or “global”) and skip the overhead.

If your projects are very short-lived (a weekend hack, a one-off script), creating a namespace for each one is overkill. Store memories in “global” with descriptive tags instead.

Namespaces make sense when you have 2+ ongoing projects and your agent regularly context-switches between them. That’s where the isolation pays off.

Getting started

Pick your two most active projects. Give each a namespace. Add a note to your AGENTS.md telling your agent how to pick namespaces. That’s the whole setup.

On your next session for each project, have your agent store 3-5 memories about the current state: tech stack, recent decisions, open questions. This seeds the namespace with enough context that future recalls return something useful.

After a week, you’ll have project-specific memory pools that your agent can search independently. No cross-contamination, no irrelevant results, no confusion about which project uses Tailwind and which uses CSS modules.

The cost is the same, $0.005 per store and recall regardless of namespace. You’re just organizing, not paying more.

Start there. Expand if you need to.