I freelance for five clients right now. Different stacks, different deployment preferences, different opinions about tabs vs spaces (yes, it still matters to some people). My OpenClaw agent helps with all of them, and for a while, that was a mess.

The problem wasn’t the agent’s capability. It was memory bleed. I’d be working on Client A’s project and my agent would suggest a deployment pattern from Client B. Or it’d use the wrong commit message convention. Small things, but the kind of small things that make you look like you aren’t paying attention.

I fixed this with MemoClaw namespaces. Here’s the actual setup.

The problem with one big memory pool

Before namespaces, everything my agent knew about every client sat in one pile. A recall for “what deployment tool do we use” might return answers from three different projects. The agent had to guess which one was relevant based on… vibes? Semantic similarity to the current conversation? It got it wrong often enough to be annoying.

MEMORY.md files were the previous approach, and they were worse. Every client’s preferences in one file, eating context window, and the agent still getting confused because the correction for Client B was buried between notes about Client A’s API schema.

One namespace per client

The fix was stupidly simple. Each client gets a MemoClaw namespace. Memories stay isolated.

# Client A — fintech startup, very particular about infrastructure
memoclaw store "All infra managed with Terraform. No exceptions." \
  --namespace client-volta --importance 0.9 --tags "infra,preference"

memoclaw store "Deploys go through GitHub Actions -> Railway" \
  --namespace client-volta --tags "deployment"

# Client B — e-commerce, fast and loose
memoclaw store "Uses Vercel for everything. Deploy on push to main." \
  --namespace client-shopwright --tags "deployment"

memoclaw store "Prefers Tailwind, hates styled-components" \
  --namespace client-shopwright --tags "preference,frontend"

When I recall from client-volta, I only get Volta’s stuff. No Shopwright bleeding in. No confusion about which client wants Terraform and which one ships straight to Vercel.

Importance scoring for the stuff that matters

Not all client preferences carry equal weight. “Prefers dark mode in the dashboard” is a nice-to-know. “Never deploy to production on Fridays” is a rule that’ll get you fired if you break it.

I score these differently:

# Hard rules — importance 0.9-1.0
memoclaw store "NEVER merge without QA sign-off. Non-negotiable." \
  --namespace client-volta --importance 1.0 --tags "process" --immutable

memoclaw store "All API responses must follow their internal schema v3 format" \
  --namespace client-volta --importance 0.9 --tags "api,requirement"

# Preferences — importance 0.5-0.7
memoclaw store "Prefers kebab-case for file names" \
  --namespace client-volta --importance 0.6 --tags "code-style"

# Context — importance 0.3-0.5
memoclaw store "Tech lead is Marcus, usually reviews PRs within 2 hours" \
  --namespace client-volta --importance 0.4 --tags "team"

When the agent recalls with limited result slots, the hard rules always surface first. The agent might forget that Marcus reviews PRs quickly, but it won’t forget that deploying without QA approval is forbidden.

Immutable memories for contractual stuff

Some things should never get overwritten or updated, even accidentally. Client contracts, compliance requirements, rate agreements. I mark these as immutable:

memoclaw store "Contracted rate: $150/hr. SOW signed Jan 2026." \
  --namespace client-volta --importance 0.8 --tags "contract" --immutable

memoclaw store "GDPR compliance required. No user data in logs." \
  --namespace client-volta --importance 1.0 --tags "compliance" --immutable

An immutable memory can’t be updated or deleted through normal operations. It’s a lock. I use it sparingly — maybe 5-10 memories per client — but for the stuff that absolutely can’t drift, it’s worth it.

The monthly cleanup

Memories accumulate. After a few months, each client namespace has session notes, old architectural decisions that got reversed, and context that stopped being relevant when the project pivoted.

Once a month, I run a consolidation pass:

memoclaw consolidate --namespace client-volta

This uses GPT-4o-mini to merge redundant memories, surface conflicts, and flag stale content. It costs $0.01 per run. For five clients, that’s $0.05/month to keep memory clean.

I also eyeball the list manually:

memoclaw list --namespace client-volta

If I see memories about a feature that shipped three months ago and is no longer changing, I delete them. Old context that isn’t relevant anymore is just noise in future recalls.

What my AGENTS.md looks like

My OpenClaw agent’s instructions include a section that maps projects to namespaces:

## Client memory

Active clients and namespaces:
- client-volta: Fintech startup. Terraform, Railway, strict QA process.
- client-shopwright: E-commerce. Vercel, Tailwind, move fast.
- client-greenline: Climate tech. Python/FastAPI, GCP.
- client-mosaic: EdTech. Next.js, Supabase.
- client-thread: Social app. React Native, Firebase.

When working on a client project:
1. Recall from the client's namespace first
2. Recall from default namespace for my general preferences
3. If a client rule conflicts with my preference, the client rule wins

Two recalls per task. $0.01 total. The agent gets client-specific context and my personal coding preferences in separate, clean batches.

What it costs

Real numbers from last month, five active clients:

• Stores: ~80 across all namespaces ($0.40)
• Recalls: ~200 total ($1.00)
• Consolidations: 5 runs ($0.05)
• Total: $1.45

I started on the free tier (100 calls). Burned through that in the first two weeks because I was experimenting. After funding my wallet with $10 USDC on Base, I haven’t thought about it since. Pay-per-use with no subscription means quiet months cost almost nothing.

What I’d do differently

If I started over, I’d set up namespaces on day one instead of retroactively splitting a mixed memory pool. The migration wasn’t hard — export, edit namespace fields, re-import — but it took an afternoon I could’ve avoided.

I’d also be more disciplined about importance scores early on. My first month, everything was default importance. It wasn’t until I noticed the agent surfacing random session notes alongside actual requirements that I went back and re-scored things.

The namespace-per-client pattern is the single most useful thing I’ve done with MemoClaw. Context-switching between clients used to mean re-explaining everything. Now I switch namespaces and the agent already knows the deal.

---

MemoClaw gives your OpenClaw agent persistent semantic memory. 100 free API calls, no registration. docs.memoclaw.com