How One MemClaw User Bridged His Marketing and Dev Agents.

Aaron, an independent builder running a small AI workflow out of his home setup, hit a wall this spring that anyone running a serious multi-agent stack will recognize.

He had two specialized agents in daily use. OpenClaw, an MCP-aware client running on DeepSeek-V4-flash, handled his marketing work — long-cycle automation, copy iteration, brand reasoning. Hermes, a local agent running Nous Hermes via Ollama, handled his development work — architectural design, code generation, refactor passes. Both agents were good at what they did. They were also completely cut off from each other.

Every product decision Aaron made in a Hermes coding session — naming conventions, tone preferences, positioning calls — died at the boundary of that session. The next time he opened OpenClaw, he had to retype the context. The next time he opened Hermes, the marketing decisions he’d made were nowhere to be found. He was paying the agent island tax, every day, multiple times a day.

In May 2026 he wired both agents into a single MemClaw instance over MCP. Within a day, the two agents were enforcing each other’s rules. The setup, and what it changed, is worth examining in detail.

01The Reveal

A Tuesday evening. Aaron was refactoring a security module in a Hermes coding session and decided to name it ClawShield — strict casing (capital C, capital S), zero-trust architecture, async non-blocking I/O, in-memory encrypted sandbox. He stated the rules to Hermes. Hermes wrote the code and crystallized the technical specs into MemClaw.

That same night, in a separate session, on a different model, Aaron switched to OpenClaw and asked for a tweet about the week’s release.

OpenClaw already knew what ClawShield was. It had the casing right. It framed the copy around “zero-trust, asynchronous high-concurrency” — the exact positioning Hermes had committed to hours earlier. Aaron had never mentioned ClawShield to OpenClaw. The two agents had never spoken.

The bridge was MemClaw.

02The Agent Island Problem

The problem Aaron solved isn’t unique to his stack. It’s the default state of most multi-agent systems in production today.

Memory belongs to the binary. Each tool keeps its own context. Each session forgets the others exist. Switching agents is the moment shared work dies. The dev agent learns the new product name; the marketing agent doesn’t know. A tone preference set with one assistant is invisible to the next. A naming convention declared in a coding session shows up nowhere else in the AI ecosystem.

The problem isn’t model quality. It’s a memory architecture problem — and it’s the most under-discussed bottleneck in serious agent deployments. Better models don’t fix it. Smarter orchestrators don’t fix it. The fix lives one layer down, in the substrate every agent reads from and writes to.

03The Wire-Up: MCP as the Connector

Aaron’s integration turned out to be a single JSON block in each agent’s MCP configuration, both pointing at the same MemClaw instance.

That’s the entire integration. MemClaw runs as a standard MCP server. OpenClaw and Hermes are MCP-aware clients. The moment they point at the same MemClaw URL, they share a single read/write memory space. Tool calls handle writes. Context views handle reads.

The part most builders underestimate: the MCP layer doesn’t require either agent to know the other exists. Hermes writes a fact. OpenClaw reads it. Neither agent ever calls the other. They communicate through a memory layer that doesn’t care what generated the writes.

04What Gets Shared, and How

The interesting question isn’t whether two agents can share memory. It’s what kind of memory survives the handoff, and how the receiving agent uses it.

Aaron’s ClawShield session produced five records in MemClaw, written by different sources during different sessions:

1. Architecture spec (fact, source: hermes, weight 0.9) — Technical description of the ClawShield module: zero-trust authentication, dynamic token decryption, async non-blocking I/O, in-memory encrypted sandbox.
2. Marketing guideline (fact, source: hermes, weight 0.9) — A translation layer mapping engineering vocabulary to user-facing vocabulary: asyncio → “bank-grade high-concurrency security,” zero-trust → “bank-level dual auditing.” Written by the dev agent, intended for the marketing agent’s use.
3. User preference (preference, source: founder, weight 0.95) — Strict naming convention: “ClawShield” (Caps C + Caps S). Minimalist tone. No hype. Clean Markdown spacing.
4. Business value (fact, source: hermes, weight 0.85) — Quantified impact: +300% throughput via async isolation, in-memory encrypted sandbox preventing data leaks.
5. Global language preference (preference, source: user, weight 0.95) — Reply in English only.

Two details matter here.

First: Hermes — a dev agent — wrote a marketing guideline. It didn’t only crystallize code-side facts. It also produced a translation layer mapping engineering concepts to user-facing language, specifically for the marketing agent’s benefit. This isn’t accidental; it’s emergent. When agents know they share memory, they naturally produce records useful to agents other than themselves. The dev agent starts thinking about how its outputs will land downstream.

Second: records are typed, sourced, weighted, and governed. This is what makes MemClaw different from a vector store. The marketing agent doesn’t just retrieve “stuff that mentions ClawShield.” It retrieves facts and preferences, from specific sources, with specific recall weights, visible to the right scope. That structure is what lets one agent enforce another agent’s decisions.

05The Handoff in Action

The next day, Aaron asked OpenClaw: “Do you remember ClawShield? What do you have on it?”

OpenClaw didn’t search the web. It didn’t ping Hermes. It queried MemClaw via MCP and returned this:

Look at the closing line. OpenClaw caught Aaron’s own typo — “Clawshield” instead of “ClawShield” — recognized it conflicted with a stored preference set during a different agent’s session, and silently corrected its own output. The marketing agent enforced a brand rule the dev agent had written. The human got sloppy. The system held the line.

The flip side surfaces too. The next evening Aaron asked Hermes — the dev agent — to draft a tweet:

Hermes pulled the technical specs it had written itself. It applied the marketing guideline it had crystallized for OpenClaw’s benefit. It respected the founder’s tone preference. Three records, three sources, one coherent output — authored by a dev agent for a marketing task.

The conventional mental model is: agents have roles, and you route work to the right one. Aaron’s setup suggests the opposite. The role lives in the memory, not in the agent. Any MCP-aware client pointed at the same memory can produce the same quality of output for the same domain. The “right” agent is whichever one is open when the work needs to happen.

06What Changed for Aaron

After several weeks running the setup, Aaron’s workflow shifted in ways he didn’t predict.

Teach once, apply everywhere. Every preference he sets — a naming convention, a tone choice, a brand rule — gets written once. Both agents respect it immediately. He hasn’t re-stated a product decision across surfaces in over a month.

Domain compounding. Dev work doesn’t die in the codebase. Marketing decisions don’t die in a Notion page. Architectural commits in Hermes become positioning material in OpenClaw. Brand work done in OpenClaw constrains the naming Hermes uses in commits. Neither agent is purely a “marketing” or “dev” agent anymore. They’re two surfaces on one institutional brain.

No vendor lock-in at the memory layer. Aaron could swap Hermes tomorrow for a different local model. He could swap OpenClaw for Claude Desktop or Cursor. As long as the new agent speaks MCP and points at the same MemClaw instance, his memory survives. The agents are the workforce. The brain is the institution. Workforces change. Institutions persist.

Multi-agent collaboration stops feeling like orchestration. It used to feel like a routing problem — graphs of API calls, brittle DAGs of who-triggers-whom. Now it feels like two coworkers reading the same shared document. The collaboration emerged from the memory layer, not the orchestration layer.

07The Pattern, Generalized

What Aaron built isn’t a one-off hack for a one-builder workflow. It’s a pattern that scales.

N specialized agents, M business domains, one shared governed memory layer over MCP. That’s the architecture. It works anywhere multiple agents handle different roles and the cost of forgetting between them is non-trivial.

The cost adds up faster in larger organizations than in solo workflows. A sales agent forgets what a support agent learned about a customer. A research agent re-runs investigations an analyst finished last week. A compliance agent is unaware of what legal flagged six minutes ago. Every one of these is the same agent island problem wearing different clothes. The fix is the same: a shared, governed, persistent memory layer — with typed sources, typed permissions, typed weights, and a clean MCP interface so any client can join without custom integration.

MemClaw is that layer. MCP is the wire. The rest is wiring.

If You Want to Wire Your Own

Aaron’s full setup took an hour. The hardest part was deciding which preferences to seed first.

• Pull MemClaw: memclaw.net — Apache 2.0, self-hosted or hosted.
• MCP config: drop the MemClaw server block into any MCP-compatible client. Docs cover OpenClaw, Hermes, Claude Desktop, Cursor, and any client that speaks MCP.
• Seed three preferences first: a naming convention, a tone choice, one strong global rule. Aaron’s first was “reply in English only.” Everything compounds from there.

Two agents. One brain. Stop teaching your AI the same things twice.