OpenClaw lets you spawn subagents for specific tasks. A main agent kicks off a research subagent, a coding subagent, a review subagent, whatever the job needs. The problem: these subagents are isolated. They get a task description and that’s it. They don’t know what the other agents found, what the main agent learned last week, or what the user cares about.

MemoClaw fixes this because all agents sharing a wallet share a memory pool.

The basic pattern

Your main agent and its subagents all use the same wallet. That means any memory one agent stores, another can recall. The trick is using namespaces and tags to keep things organized instead of turning shared memory into a free-for-all.

Main Agent (wallet 0xABC...)
├── stores findings in namespace "project-alpha"
├── spawns Research Subagent
│   └── recalls from "project-alpha", stores with tag "research"
├── spawns Writing Subagent
│   └── recalls from "project-alpha", stores with tag "draft"
└── recalls everything tagged "research" + "draft" to synthesize

Passing context down

Before spawning a subagent, your main agent stores the task context:

memoclaw store \
  --text "Researching competitor pricing for the Q2 report. Focus on Mem0, Zep, and Pinecone. User wants actual dollar amounts, not vague comparisons." \
  --namespace "q2-report" \
  --tags "task-context,research" \
  --importance 0.9

The subagent’s instructions include a recall step at startup:

memoclaw recall \
  --query "current task context and requirements" \
  --namespace "q2-report" \
  --tags "task-context" \
  --limit 3

Now the subagent knows what it’s doing and why, without the main agent needing to pack everything into the task description.

Subagents storing results

Each subagent stores its findings as it goes:

# Research subagent stores what it found
memoclaw store \
  --text "Mem0 pricing: free tier 1000 memories, Pro at $49/mo for 100k memories. No per-call pricing. Requires API key signup." \
  --namespace "q2-report" \
  --tags "research,competitor,mem0" \
  --importance 0.7

memoclaw store \
  --text "Zep pricing: open source self-hosted (free but you run infra), cloud version pricing not public, requires sales contact." \
  --namespace "q2-report" \
  --tags "research,competitor,zep" \
  --importance 0.7

Main agent synthesizing

After the subagents finish, the main agent pulls everything together:

memoclaw recall \
  --query "competitor pricing research findings" \
  --namespace "q2-report" \
  --tags "research" \
  --limit 10

All the subagent findings come back, ranked by relevance. The main agent didn’t need to parse subagent output from stdout or manage temp files. The memories are just there.

Tags as coordination

Tags become a lightweight coordination protocol between agents:

• task-context — what the parent agent wants done
• research — raw findings from research subagents
• draft — written content from writing subagents
• review — feedback from review subagents
• approved — content the main agent signed off on

A writing subagent can recall all research tagged memories to write from, then store its output with a draft tag. A review subagent recalls draft tagged memories and stores feedback with review. The main agent watches the whole pipeline through tag-filtered recalls.

Avoiding collisions

When multiple subagents run in parallel, they might store overlapping or contradictory memories. Two research agents investigating the same competitor could store different numbers from different sources.

Handle this by being specific in what you store. Include the source:

memoclaw store \
  --text "Mem0 Pro plan: $49/mo (from mem0.ai/pricing, checked March 2026)" \
  --namespace "q2-report" \
  --tags "research,competitor,mem0" \
  --importance 0.7

When the main agent recalls and sees two conflicting data points, the source attribution helps it decide which to trust.

What this costs

A typical subagent run involves 1 recall at startup and 2-3 stores for results — call it 3-4 calls per subagent. For the full orchestration pattern described above with five subagents, the math looks like this:

• Main agent stores task context: 1 call
• 5 subagents × ~4 calls each (1 recall + 3 stores): 20 calls
• Main agent synthesis recall: 1 call
• Total: ~22 calls ($0.11)

With 100 free calls per wallet, that’s roughly 4-5 full orchestrations before hitting paid territory. A single subagent run (3-4 calls) gives you 25+ runs on the free tier, but the multi-agent pattern burns through it faster than you’d expect.

When this pattern breaks down

Shared memory works well for loosely coupled agents doing complementary work. It gets messy when agents need real-time coordination, like one agent waiting for another’s output before proceeding. MemoClaw doesn’t have websockets or push notifications. An agent has to recall and check, which means polling.

For tight coordination, you’re better off using OpenClaw’s built-in subagent result passing. Use MemoClaw for the persistent context layer (what does this project need, what have we learned so far) and let OpenClaw handle the real-time orchestration.

The bigger picture

The wallet-as-identity model means any agent or tool with your wallet can read and write to the same memory pool. That’s powerful for building agent teams, but it also means you should think about namespace hygiene. Don’t dump everything in the default namespace. Give each project or workflow its own space, use consistent tag conventions, and your agents will find what they need without wading through noise.

---

Install the MemoClaw skill from ClawHub or get the CLI with npm install -g memoclaw. 100 free calls per wallet, no signup required.