Building a knowledge-sharing agent team: shared wallet memory patterns


I run three OpenClaw agents for content work. One researches topics, one writes drafts, one reviews them. For weeks, the researcher would find useful information, store it in its own context, and then I’d have to manually relay that context to the writer. The reviewer had no idea what the researcher found or what decisions the writer made.

The fix was embarrassingly simple: give them the same wallet.

Why shared wallets work

MemoClaw uses your wallet as identity. No API keys, no registration. You sign requests with your wallet, and that wallet owns all the memories stored under it.

When two OpenClaw agents share a wallet, they share a memory pool. Agent A stores a memory, Agent B can recall it. No federation protocol, no message passing, no shared database to configure. Just the same wallet credentials.

This sounds like it could get messy fast. It does, if you don’t use namespaces. But with a few conventions, it turns into a clean knowledge-sharing layer.

Namespace isolation by role

Here’s the setup I landed on. Each agent gets its own namespace for private working memory, plus a shared namespace for cross-agent knowledge:

# Researcher stores findings in shared namespace
memoclaw store "Current MemoClaw free tier: 100 calls per wallet" --importance 0.8 --tags facts,pricing --namespace shared

# Researcher also keeps its own working notes
memoclaw store "Need to verify: does consolidate count against free tier?" --importance 0.5 --tags todo --namespace researcher
# Writer recalls research from shared namespace
memoclaw recall "MemoClaw pricing details" --tags facts,pricing --namespace shared

# Writer keeps draft-related context private
memoclaw store "Draft 3 uses more casual tone per editor feedback" --importance 0.7 --tags drafts --namespace writer
# Reviewer recalls both research and writing decisions
memoclaw recall "pricing details for fact-check" --namespace shared

Three agents, one memory pool, clean separation between shared knowledge and private working state.

A real workflow: content pipeline

Here’s how this plays out in my content pipeline.

Step 1: Research. The researcher agent gets a topic (say, “memory consolidation patterns”). It searches the web, reads docs, and stores what it finds:

memoclaw store "MemoClaw consolidate endpoint: $0.01/call, uses GPT-4o-mini for dedup and merging" --importance 0.8 --tags research,consolidation --namespace shared
memoclaw store "Consolidation respects immutable flag, won't merge immutable memories" --importance 0.7 --tags research,consolidation --namespace shared
memoclaw store "Common pattern: weekly cron consolidation on Sunday nights" --importance 0.6 --tags research,consolidation,patterns --namespace shared

Step 2: Writing. The writer agent picks up the topic. Before starting, it pulls in the research:

memoclaw recall "consolidation patterns and features" --tags research --namespace shared

All the researcher’s findings come back. The writer doesn’t need to re-research. It drafts the article using real facts that another agent already verified.

Step 3: Review. The reviewer agent reads the draft and fact-checks against stored research:

memoclaw recall "consolidation pricing" --tags research --namespace shared

If the draft says consolidation costs $0.02 but the stored research says $0.01, the reviewer catches the discrepancy. Without shared memory, the reviewer would need to re-verify every fact independently.

Patterns that emerged

After running this setup for a few weeks, some patterns became obvious.

Tag conventions matter more than you’d expect. When three agents share a namespace, sloppy tagging creates confusion. I standardize tags across agents: research for raw findings, decisions for editorial choices, feedback for review comments. Every agent uses the same tags. No synonyms, no variations.

Importance scoring needs calibration. The researcher tends to store everything at 0.7-0.8 because it all seems relevant during research. The writer needs to know which findings are central to the topic and which are tangential. I adjusted the researcher to use a wider range: 0.8-0.9 for core facts, 0.5-0.6 for supporting detail, 0.3-0.4 for “might be useful” context.

Consolidation becomes more important. Three agents storing memories in a shared namespace means the memory count grows three times as fast. I run consolidation on the shared namespace twice a week instead of once.

Shared wallet vs. passing context manually

Before shared wallets, my multi-agent setup looked like this:

  1. Researcher writes findings to a markdown file
  2. Writer reads the markdown file at session start
  3. Reviewer reads both the draft and the research file
  4. Any updates required manually editing the shared file

This works, technically. But it has problems. The markdown file grows without bounds. There’s no semantic search, so the writer has to read the entire file to find relevant sections. There’s no importance scoring, so everything is weighted equally. And the file burns context tokens on every session start.

With shared wallet memory:

  1. Researcher stores findings with tags and importance
  2. Writer recalls what’s relevant to the current topic
  3. Reviewer recalls specific facts to verify
  4. Consolidation handles cleanup automatically

The writer doesn’t load 5,000 tokens of research notes when it only needs the three facts relevant to today’s article. It runs a targeted recall and gets exactly what it needs.

Setting it up

The actual setup is straightforward:

  1. One wallet, multiple agents. Configure each OpenClaw agent with the same MemoClaw wallet credentials.

  2. Define namespaces. At minimum: one shared namespace and one per agent.

# In each agent's AGENTS.md or skill config:
# Shared namespace for cross-agent knowledge
MEMOCLAW_SHARED_NAMESPACE=shared

# Private namespace (varies per agent)
MEMOCLAW_PRIVATE_NAMESPACE=researcher  # or writer, reviewer, etc.
  1. Standardize tags. Write down your tag vocabulary and put it somewhere all agents can reference:
memoclaw store "Tag vocabulary: research (raw findings), decisions (editorial/technical choices), feedback (review comments), facts (verified information), todo (open questions)" --importance 0.9 --tags meta --namespace shared
  1. Set up consolidation. Weekly at minimum for the shared namespace, more frequently if you’re running high-volume workflows.

When this doesn’t work

Shared wallets aren’t the right call for every multi-agent setup.

If your agents work on completely unrelated tasks (one manages your calendar, another writes code), sharing memory creates noise without benefit. Keep them on separate wallets.

If you need access control between agents (agent A shouldn’t see agent B’s memories), shared wallets don’t support that. MemoClaw doesn’t have per-agent permissions within a wallet. Namespace isolation is a convention, not an enforcement mechanism. Any agent with the wallet can read any namespace.

If you’re running agents from different trust levels (your own agent + a third-party skill), don’t share wallet credentials. The third-party skill would have full access to all your stored memories.

What I’d do differently

If I were starting over, I’d define the tag vocabulary on day one instead of letting it evolve organically. Retroactively standardizing tags across 200 memories stored by three different agents is not fun.

I’d also set importance scoring guidelines per agent role upfront. The researcher was over-scoring everything as “high importance” for the first two weeks, which made the writer’s recalls noisy until I tuned it.

Shared wallet memory between OpenClaw agents is one of those things that feels obvious in retrospect. Your agents already share a wallet. The memories are already there. Namespaces keep things organized. The only cost is being deliberate about conventions.

Three agents, one memory pool, zero coordination overhead.