If you’re running multiple OpenClaw agents, you’ve probably hit the same wall I have: Agent A learns something useful, but Agent B has no idea. They live in separate workspaces with separate MEMORY.md files, and there’s no clean way to share context between them.

MemoClaw fixes this with a simple trick: all agents using the same wallet already share the same memory pool. Add namespaces on top, and you get fine-grained control over what’s shared and what stays private.

The problem with isolated agents

Say you have a coding agent, a research agent, and a personal assistant. Your coding agent learns that you prefer TypeScript over JavaScript and always want ESLint configured a specific way. Your research agent discovers a useful API endpoint during a search. Your personal assistant knows your schedule.

Without shared memory, each agent starts fresh every session, reading only its own files. If your coding agent could access what the research agent found, you’d save time. If the assistant knew what projects the coding agent was working on, it could schedule around deployments.

Flat files don’t solve this. You’d need to manually copy information between workspaces, or build some hacky sync system. Neither scales.

How wallet-based identity enables sharing

MemoClaw uses your crypto wallet as your identity. No API keys, no registration. Just sign a message with your wallet, and you’re authenticated.

The key detail for multi-agent setups: all your agents use the same wallet. That means they already have access to the same memory store. When your coding agent stores a memory, your research agent can recall it.

# Agent A stores a memory
memoclaw store "User prefers Hetzner for VPS hosting" --importance 0.8 --tags preferences,infra

# Agent B recalls it later
memoclaw recall "what hosting does the user prefer"
# Returns: "User prefers Hetzner for VPS hosting" (score: 0.94)

No configuration needed. Same wallet, shared memories.

Namespaces for when you need boundaries

Sharing everything isn’t always what you want. Your personal assistant’s memories about your schedule shouldn’t clutter your coding agent’s recall results when it’s looking for technical context.

Namespaces let you partition memories while keeping them under the same wallet:

# Personal assistant stores in its namespace
memoclaw store "Dentist appointment Thursday 2pm" --namespace personal --importance 0.7

# Coding agent stores in its namespace
memoclaw store "Project X uses PostgreSQL 16 with pgvector" --namespace coding --importance 0.9

# Each agent queries its own namespace by default
memoclaw recall "database setup" --namespace coding

The memories still live under your wallet. An agent can query across namespaces when it needs to, or stick to its own lane.

Setting this up in OpenClaw

Install the MemoClaw skill on each agent:

openclaw skill install anajuliabit/memoclaw

Then configure each agent’s namespace in its workspace. Add a note to the agent’s TOOLS.md:

### MemoClaw
- Namespace: coding
- Shared namespace for cross-agent queries: shared

The agent uses its namespace by default and can query the shared namespace when it needs broader context.

A practical pattern: the shared namespace

I like setting up three tiers:

1. Agent-specific namespace for memories only relevant to that agent’s job
2. Shared namespace for memories any agent might need (user preferences, project info, common corrections)
3. No namespace (default pool) for general knowledge

When an agent learns something that other agents would benefit from, it stores it in the shared namespace:

# Coding agent learns a user preference that applies broadly
memoclaw store "User wants all commit messages in conventional format" \
  --namespace shared --importance 0.9 --tags preferences

# Research agent finds something useful for the coding agent
memoclaw store "The v2 API requires auth header X-Api-Version: 2" \
  --namespace shared --importance 0.8 --tags api,project-x

Any agent can then recall from shared to get cross-cutting context.

What about conflicts?

Two agents might store contradictory information. Your research agent finds one answer, your coding agent discovers the reality is different. MemoClaw handles this through importance scores and recency.

When you recall memories, results come back ranked by semantic similarity and importance. More recent memories with higher importance scores surface first. If you stored “API uses OAuth” at importance 0.5 and later stored “API switched to wallet auth in v3” at importance 0.9, the second memory ranks higher.

You can also use tags to filter. If your coding agent only cares about memories tagged infra, it won’t see noise from your research agent’s market-analysis tags.

Immutable memories for shared facts

Some shared knowledge shouldn’t change. Your company name, your preferred tech stack, your deployment process. For these, use immutable memories:

memoclaw store "Production deploys happen through Railway auto-deploy from main branch" \
  --namespace shared --importance 1.0 --tags infra,deploy --immutable

Immutable memories can’t be updated or deleted (without special flags). They’re facts that every agent should treat as ground truth.

When to use this vs. when to keep things separate

Shared memory works well when:

• Agents work on related projects
• User preferences should apply across agents
• One agent’s discoveries save another agent time
• You want a single source of truth for facts

Keep memories separate when:

• Agents serve different users (use different wallets)
• Memory domains are completely unrelated
• You want strict isolation for security reasons

Getting started

If you’re already running MemoClaw with one agent, adding cross-agent sharing takes about five minutes:

1. Install the MemoClaw skill on your other agents
2. They’ll automatically share the same memory pool (same wallet)
3. Add namespace configuration to each agent’s workspace
4. Optionally create a shared namespace for cross-cutting memories

The free tier gives you 100 API calls to test this out. Enough to set up namespaces and verify that recall works across agents before committing to pay-per-use.