If you’re running more than one OpenClaw agent, you’ve probably hit this: Agent A learns something useful, but Agent B has no idea. They’re both yours, running on the same machine, maybe even in the same workspace. But their knowledge is siloed.

MemoClaw fixes this in a simple way. Since your wallet address is your identity, any agent configured with the same wallet reads and writes to the same memory pool. No sync protocol, no shared database config, no message passing. Just the same wallet.

Here’s how to set it up so it actually works without turning into a mess.

The basic idea

Every MemoClaw call is authenticated by a wallet. Two agents using the same wallet address and private key see the same memories. Agent A stores something, Agent B can recall it immediately.

That’s the whole mechanism. The interesting part is making it practical — “shared memory” without any organization is just a shared junk drawer.

Setting up two agents with shared memory

Say you have a research agent (Scout) that reads papers and articles, and a writing agent (Quill) that drafts content. You want Quill to build on what Scout finds.

Both agents need the same MemoClaw environment variables:

export MEMOCLAW_URL=https://api.memoclaw.com
export MEMOCLAW_WALLET=0xYourWalletAddress
export MEMOCLAW_PRIVATE_KEY=0xYourPrivateKey

If both agents have the MemoClaw skill installed, they’re already sharing memory. Scout stores a finding:

memoclaw store "React Server Components reduce bundle size by 30-40% according to Vercel's 2025 benchmark" --importance 0.8 --tags research,react,performance

Quill can immediately recall it:

memoclaw recall "React performance improvements"

Scout’s memory shows up in Quill’s results. Done.

Use namespaces to avoid noise

Shared memory without structure gets noisy fast. If both agents dump everything into the default namespace, recall results become a mix of research notes, draft outlines, user preferences, and whatever else got stored.

Namespaces partition the memory space. Same wallet, different compartments.

A multi-agent setup that works:

# Scout stores research in a dedicated namespace
memoclaw store "Finding about X" --namespace research --tags topic1

# Quill stores drafts and editorial notes separately
memoclaw store "Draft outline for article Y" --namespace content --tags drafts

# Shared namespace for things both agents need
memoclaw store "Company voice: direct, no jargon, developer-focused" --namespace shared --tags style-guide

When Quill needs Scout’s research:

memoclaw recall "React performance" --namespace research

When Scout needs to check what’s already been written about:

memoclaw recall "React" --namespace content

Each agent queries the namespace that has what it needs. No cross-contamination.

Tagging conventions that actually help

Tags are the other organizational tool. With multiple agents writing to the same wallet, consistent tags make the difference between useful recall and noise.

Pick a convention and stick to it. Here’s one that works:

• Source tags — who stored it: from:scout, from:quill
• Type tags — what it is: research, draft, preference, correction
• Topic tags — what it’s about: react, performance, pricing

Scout stores research:

memoclaw store "Vue 3.5 introduced a new reactivity system that reduced memory usage by 20%" \
  --importance 0.7 \
  --tags from:scout,research,vue,performance \
  --namespace research

Quill can then pull all of Scout’s performance research:

memoclaw recall "frontend performance improvements" --namespace research --tags research,performance

Or find everything Scout stored recently:

memoclaw recall "latest findings" --namespace research --tags from:scout

The from: prefix is useful when you have three or four agents sharing a wallet. You can always trace which agent contributed what.

A real workflow: Scout and Quill

Let’s walk through an actual workflow. You want an article about WebAssembly adoption trends.

Step 1: Scout does research

Scout reads a few sources and stores what it finds:

memoclaw store "StackOverflow 2025 survey: 12% of developers now use WebAssembly, up from 7% in 2023" \
  --importance 0.8 --tags from:scout,research,wasm,stats --namespace research

memoclaw store "Figma rebuilt their renderer in WebAssembly, cut load times by 3x — mentioned in their engineering blog March 2025" \
  --importance 0.7 --tags from:scout,research,wasm,case-study --namespace research

memoclaw store "Main WASM pain points per developer surveys: debugging is hard, tooling is immature, binary size management" \
  --importance 0.7 --tags from:scout,research,wasm,challenges --namespace research

Step 2: Quill pulls research and writes

Quill starts drafting. First, it grabs everything Scout found:

memoclaw recall "WebAssembly adoption and trends" --namespace research --tags wasm

All three of Scout’s memories come back. Quill has real data points, a case study, and known challenges — without reading a single article itself.

Quill writes the draft and stores its own notes:

memoclaw store "Draft written for WASM adoption article, needs stats verification and one more case study" \
  --importance 0.6 --tags from:quill,content,wasm,status --namespace content

Now if Scout checks in later, it can see what Quill still needs:

memoclaw recall "what does quill need" --namespace content --tags wasm

The agents collaborate through shared memory, each in their own context, without talking to each other directly.

Things to watch out for

Call budget. Both agents share the same wallet, which means they share the same free tier (100 calls). If Scout burns through 80 calls on research, Quill only has 20 left before you’re paying. Keep an eye on usage early on.

No locking. MemoClaw doesn’t have write locks. If two agents store memories at the exact same time, both writes succeed independently. This is fine in practice — agent workflows are usually sequential enough that collisions don’t happen. But don’t design a system where two agents update the same memory simultaneously.

Consolidation affects everyone. If you run memoclaw consolidate, it merges memories from all agents within the namespace you specify. That’s usually what you want, but Scout’s raw research notes might get merged with each other. Run consolidation per namespace to keep control.

One wallet = one identity. From MemoClaw’s perspective, there’s no distinction between Agent A and Agent B. It’s all the same wallet. The from:agent-name tag convention is your only way to tell who stored what. It’s not enforced by the system, so make sure your agents actually use it.

When to share, when not to

Shared memory works well when your agents have complementary roles: one researches, another writes; one monitors, another acts; one handles customer questions, another handles internal tasks.

It doesn’t make sense when agents are doing unrelated work. If you have an agent managing your calendar and another doing code review, sharing a memory pool just adds noise. Give them separate wallets or at minimum use completely separate namespaces.

The test is simple: would Agent B ever benefit from something Agent A learned? If yes, same wallet. If no, separate wallets.

Getting started

1. Configure both agents with the same MEMOCLAW_WALLET and MEMOCLAW_PRIVATE_KEY
2. Pick a namespace convention (per agent role, per project, or a shared namespace)
3. Agree on tagging — at minimum use from:agent-name tags
4. Have each agent recall before storing to avoid obvious duplicates
5. Run memoclaw consolidate --namespace <name> periodically to keep things clean

That’s it. No infrastructure, no message queues, no shared databases. Same wallet, some discipline around namespaces and tags, and your agents can build on each other’s work.