Three agents walk into a codebase. The architect makes decisions. The coder implements them. The reviewer checks the work. None of them can read each other’s minds.

This is the coordination problem with multi-agent systems. Every agent has its own context window, its own session, its own memory. The architect decides to use PostgreSQL with pgvector. Twenty minutes later, the coder picks SQLite because it never got the memo. The reviewer catches it, but now you’ve wasted a full implementation cycle.

The fix is shared memory. Same wallet, same MemoClaw instance, different namespaces. Here’s how to set it up with OpenClaw.

The architecture

Three agents, each with a role:

• Architect — makes design decisions, stores them with high importance
• Coder — implements features, recalls design decisions before writing code
• Reviewer — checks implementations against stored patterns and decisions

They all authenticate with the same wallet, so they see the same memory pool. Namespaces keep things organized.

Wallet: 0xYourWallet
├── namespace: architecture   (design decisions, tech choices)
├── namespace: patterns       (code patterns, conventions)
├── namespace: reviews        (review findings, recurring issues)
└── namespace: project        (general project context)

Setting up the architect

The architect’s job is to make decisions and make them findable. When it decides something, it stores it.

# Store a design decision
memoclaw store "Authentication: use JWT with 15-minute expiry, refresh tokens in httpOnly cookies. No session storage." \
  --namespace architecture \
  --importance 0.95 \
  --tags auth,security,decision \
  --memory-type decision \
  --pinned true

A few things matter here:

High importance (0.95). Design decisions should outrank observations and casual notes in recall. When the coder asks “how should auth work?”, the architect’s decision should be the top result.

Pinned. Architecture decisions shouldn’t decay. A decision made in week one is still relevant in week twelve.

Memory type: decision. This gives it a 90-day decay half-life (though pinning overrides decay). It also makes it easy to filter: memoclaw list --memory-type decision --namespace architecture.

Specific tags. The coder searching for “auth” context will match on both the semantic content and the tags.

Setting up the coder

The coder’s workflow has one additional step compared to coding solo: recall before implementing.

# Before starting work on the auth module
memoclaw recall "authentication implementation approach" \
  --namespace architecture \
  --limit 5

# Also check for relevant patterns
memoclaw recall "authentication patterns" \
  --namespace patterns \
  --limit 3

The coder gets back the architect’s decision about JWT + refresh tokens, plus any code patterns stored from previous implementations. It writes code that aligns with what was decided, not what it would have guessed on its own.

When the coder discovers something during implementation — a gotcha, a useful pattern, a library choice — it stores that too:

# Store a pattern discovered during implementation
memoclaw store "jose library for JWT: use SignJWT not the legacy jwt.sign. The legacy API doesn't support EdDSA keys." \
  --namespace patterns \
  --importance 0.8 \
  --tags auth,jwt,library \
  --memory-type correction

Memory type correction here means this knowledge sticks around (180-day half-life). The next time any agent works with JWTs, this surfaces.

Setting up the reviewer

The reviewer recalls before reviewing. It checks what was decided, what patterns exist, and what’s been flagged in past reviews.

# Before reviewing the auth PR
memoclaw recall "authentication requirements and decisions" \
  --namespace architecture --limit 5

memoclaw recall "jwt implementation patterns" \
  --namespace patterns --limit 5

memoclaw recall "common auth review findings" \
  --namespace reviews --limit 5

Now the reviewer knows what the architect intended, what patterns the coder should have followed, and what mistakes have come up before. It can check the implementation against all of that.

When it finds issues, it stores them:

# Store a review finding
memoclaw store "Auth PR: refresh token rotation not implemented. Without rotation, a stolen refresh token is valid until expiry. Flag this in future auth reviews." \
  --namespace reviews \
  --importance 0.85 \
  --tags auth,security,review-finding \
  --memory-type correction

Next review cycle, this finding surfaces automatically. The team learns from its mistakes without anyone manually maintaining a checklist.

The coordination loop

Here’s what this looks like in practice across multiple sessions:

Session 1: Architect plans the API

memoclaw store "REST API with versioned routes (/v1/). No GraphQL — team doesn't have the expertise and the client is simple enough." \
  --namespace architecture --importance 0.9 --memory-type decision --pinned true

Session 2: Coder starts the API

# Recalls architecture decisions before writing code
memoclaw recall "API design approach" --namespace architecture --limit 5
# Gets back: REST, versioned routes, no GraphQL
# Implements accordingly

Session 3: Someone asks “why not GraphQL?”

memoclaw recall "GraphQL decision" --namespace architecture --limit 3
# Gets back: "No GraphQL — team doesn't have the expertise and the client is simple enough"
# The reasoning is preserved, not just the decision

This is the part that’s hard to replicate with file-based memory. The reasoning behind decisions persists and surfaces when relevant. Three months later, when someone questions a choice, the context is there.

Namespace strategy tips

A few things I’ve seen work well:

Keep namespaces coarse. Four or five namespaces for a project is plenty. Too many and you spend more time figuring out which namespace to query than actually recalling.

Cross-namespace recall for ambiguous queries. If the coder isn’t sure whether something is an architecture decision or a pattern, recall from both:

memoclaw recall "database indexing strategy" --namespace architecture --limit 3
memoclaw recall "database indexing strategy" --namespace patterns --limit 3

Two calls, $0.01 total. Cheap insurance against missing relevant context.

Use the project namespace as a catch-all. Not everything fits neatly into architecture/patterns/reviews. General project context — team preferences, deployment targets, client requirements — goes in project.

memoclaw store "Client deploys to AWS GovCloud — all services must be FedRAMP compliant" \
  --namespace project --importance 0.95 --memory-type decision --pinned true

What this replaces

Without shared memory, multi-agent coordination usually looks like one of these:

• Passing context through prompts. The orchestrator stuffs relevant context into each agent’s system prompt. Works for small projects but hits context limits fast.
• Shared files. Agents read and write to shared markdown files. Race conditions, no semantic search, manual organization.
• Message passing. Agents send each other messages with context. Works if they’re in the same session, breaks across sessions.

MemoClaw replaces all of these with a single memory layer that every agent can write to and recall from. The memories persist across sessions, the search is semantic, and it costs nothing to list, export, or audit what’s in there.

Getting started

The setup is straightforward:

1. Install the MemoClaw skill (clawhub install anajuliabit/memoclaw)
2. Use the same wallet across all your agents
3. Define your namespace structure upfront
4. Have each agent recall before acting and store after learning

The first 100 API calls are free. A typical three-agent workflow might do 20-30 store/recall operations per session. That’s a few days of building before you hit the free tier limit.

After that, you’re looking at $0.005 per store or recall. For a team of agents making 100 memory operations a day, that’s $0.50/day. Compare that to stuffing shared context into three separate system prompts at full token cost.