OpenClaw subagents have a cold-start problem. You spawn a scout to research a topic, it does good work, finds useful stuff, and then it dies. Ten minutes later you spawn a writer to turn those findings into an article. The writer knows nothing. All that research is gone unless you manually pipe it through.

Most people solve this with markdown files. The scout writes to research-notes.md, the writer reads it. It works until it doesn’t — the file gets huge, there’s no way to search it, and every agent loads the entire thing into context whether it needs all of it or not.

There’s a cleaner approach: give your agents the same MemoClaw wallet. One stores, the other recalls. No files to manage, no context bloat, and semantic search means each agent pulls only what’s relevant.

The cold-start problem, concretely

Say you have this setup:

Main agent (orchestrator)
├── Scout subagent — researches topics
├── Writer subagent — writes content
└── Reviewer subagent — fact-checks drafts

You spawn the scout:

/subagent spawn --label scout --prompt "Research MemoClaw's batch operations. Find pricing, limits, common patterns."

The scout runs for a few minutes, finds useful information, and completes. Its context is gone. Now you spawn the writer:

/subagent spawn --label writer --prompt "Write a blog post about batch operations."

The writer starts from scratch. It doesn’t know what the scout found. It doesn’t know the scout even ran. Every subagent starts with a blank slate.

Without shared memory, the orchestrator becomes the bottleneck. It has to receive the scout’s output, hold it in its own context, and then relay it to the writer in the spawn prompt. That means the orchestrator’s context grows with every piece of research, and you’re paying tokens just to shuttle information between agents.

Shared wallets as a memory bus

MemoClaw identifies you by wallet address. No accounts, no API keys. You sign requests with your private key, and all memories belong to that wallet.

The trick: configure every subagent with the same wallet. Now they all read from and write to the same memory pool.

The scout stores its findings:

memoclaw store "Batch store endpoint: up to 100 memories per call, costs $0.04" \
  --tags research,batch-ops,pricing \
  --importance 0.8 \
  --namespace content-pipeline

The writer recalls them:

memoclaw recall "batch operation pricing and limits" \
  --tags research \
  --namespace content-pipeline

The scout doesn’t need to be alive anymore. Its findings persist in the shared wallet. The writer pulls exactly what it needs through semantic search, without loading a giant markdown file or relying on the orchestrator to pass context.

Keeping memories organized

Three agents dumping memories into one pool gets messy fast. Tags and namespaces are how you prevent it.

Namespaces isolate by project or workflow. A content pipeline gets its own namespace, separate from your daily standups or project notes:

# Scout stores research
memoclaw store "finding here" --namespace content-pipeline --tags research

# Writer stores draft decisions
memoclaw store "using casual tone for this piece" --namespace content-pipeline --tags draft-notes

# Reviewer stores feedback
memoclaw store "pricing figure in paragraph 3 is wrong" --namespace content-pipeline --tags review

Tags isolate by role and type within a namespace. I use a fixed vocabulary:

Tag	Who uses it	What it means
research	Scout	Raw findings and facts
draft-notes	Writer	Tone decisions, outline choices
review	Reviewer	Corrections, fact-check results
decision	Any	Choices that affect downstream work

The key word is fixed. If the scout tags something research and the writer searches for findings, the tag filter won’t match. Write the tag vocabulary down somewhere all agents can see. I put mine in the shared namespace itself:

memoclaw store "Tag vocabulary for content pipeline: research, draft-notes, review, decision. All agents use these exact tags." \
  --tags meta \
  --importance 0.9 \
  --namespace content-pipeline

A real handoff: scout to writer

Here’s a concrete example. I want an article about cost optimization with MemoClaw’s free tier.

Scout’s job:

# Store each finding separately — granular memories recall better than one big dump
memoclaw store "Free tier: 100 calls per wallet. No payment needed to start." \
  --tags research,pricing --importance 0.8 --namespace content-pipeline

memoclaw store "Free endpoints (no call cost): list, get, delete, search, stats, export, namespaces" \
  --tags research,pricing --importance 0.8 --namespace content-pipeline

memoclaw store "Paid endpoints: store ($0.005), recall ($0.005), batch store ($0.04), consolidate ($0.01)" \
  --tags research,pricing --importance 0.7 --namespace content-pipeline

memoclaw store "Pattern: use list (free) instead of recall (paid) when you just need recent memories in order" \
  --tags research,patterns --importance 0.9 --namespace content-pipeline

Notice: each fact is a separate memory with its own importance score. Don’t dump everything into one big memory. Granular storage means better recall, because semantic search can surface the specific fact that matches the query rather than returning a wall of text.

Writer’s job:

The writer doesn’t need to know what the scout did. It just recalls:

memoclaw recall "MemoClaw pricing and free tier details" \
  --tags research --namespace content-pipeline

Back come the four memories above, ranked by relevance. The writer now has the facts it needs without loading everything the scout ever stored.

For a more targeted pull:

memoclaw recall "cost saving patterns" \
  --tags research,patterns --namespace content-pipeline

This surfaces the “use list instead of recall” pattern at the top, since it matches both the query meaning and the tag filter.

Reviewer’s job:

The reviewer reads the draft and fact-checks pricing claims:

memoclaw recall "free tier call limit" --tags research,pricing --namespace content-pipeline

If the writer said “200 free calls” but the scout stored “100 calls,” the reviewer catches it against the source. Three agents, no coordination meetings.

Importance scoring across agents

One thing that bit me early: the scout was scoring everything at 0.8. When the writer recalled research, everything came back at roughly the same relevance. Core facts mixed with tangential details.

I now use this convention:

• 0.9 — Central fact, load-bearing for the article
• 0.7-0.8 — Supporting detail, useful but not essential
• 0.5-0.6 — Background context, might be useful
• 0.3-0.4 — “I found this but I’m not sure it’s relevant”

The writer’s recall naturally surfaces the 0.9 facts first. The 0.4 stuff stays in memory but doesn’t dominate the results.

Cleanup: don’t let the pool grow forever

Three agents storing memories in a shared namespace means the count grows fast. After a few content cycles, you’ll have hundreds of memories in the pipeline namespace.

Two strategies that work:

Consolidation after each cycle. Once an article is published, run consolidation on the namespace to merge redundant memories:

memoclaw consolidate --namespace content-pipeline

This costs $0.01 per call but keeps your memory pool lean. Duplicate facts get merged, outdated draft notes get cleaned up.

Namespace rotation. For bigger projects, use a namespace per project instead of one shared pipeline namespace:

# Project-specific namespace
memoclaw store "finding" --namespace article-batch-ops --tags research

# Next project gets its own space
memoclaw store "finding" --namespace article-cost-optimization --tags research

After the article ships, you can leave the namespace alone or clean it up. Either way, it won’t pollute future recall results in a different namespace.

Cost reality check

Shared wallets don’t cost more than separate ones. The pricing is per-call, not per-wallet. Whether three agents share one wallet or each has their own, the total cost depends on how many store and recall calls they make.

A typical content cycle in my setup:

• Scout: 5-8 store calls = $0.025-0.04
• Writer: 2-3 recall calls = $0.01-0.015
• Reviewer: 1-2 recall calls = $0.005-0.01
• Consolidation: 1 call = $0.01

Total per article: roughly $0.05-0.075. That’s about $1-1.50/month if you’re publishing several articles a week.

The free tier (100 calls) covers your first 10-15 content cycles without paying anything. Use memoclaw stats (free) to keep an eye on your usage.

When not to share wallets

A few situations where separate wallets make more sense:

Different trust levels. If you’re running a third-party skill alongside your own agents, don’t give it your wallet. It would have full access to all your stored memories. Keep untrusted agents on their own wallet.

Unrelated workloads. A calendar agent and a content writer have nothing to share. Separate wallets keep their memory pools clean without needing namespace discipline.

Access control requirements. MemoClaw doesn’t have per-agent permissions within a wallet. Namespace isolation is a convention, not enforcement. If agent A absolutely must not read agent B’s memories, they need different wallets.

Getting started

1. Install the MemoClaw CLI: npm install -g memoclaw
2. Configure all your agents with the same wallet credentials
3. Pick a namespace for the workflow
4. Define your tag vocabulary (write it down, don’t improvise)
5. Have the first agent store something, the second agent recall it
6. Iterate on importance scoring after a few cycles

The whole point is that your agents stop waking up with amnesia. The scout finds things, the writer uses them, the reviewer verifies them. Each agent does its job without needing the others to be alive at the same time. The wallet is the shared brain.