Coordination memory: what your multi-agent stack is missing

Multi-agent isn't new. Most engineering teams have agents in production today — Cursor for code, Claude Code for autonomous tasks, ChatGPT for research, custom agents for ops. The interesting problem isn't whether to use them. It's that even with orchestration, your agents still don't know what your other agents have learned. They re-read the same context. They re-derive the same decisions. They forget across sessions. The thing that breaks at fleet scale isn't agent count — it's coordination memory.

We hit this running Memory Stack itself across two projects with eight+ agents. Here's the substrate that closes the gap.

What we're running

Two projects. Eight+ agents. One substrate.

Memory Stack (this product): a supervisor agent, a worker agent, and a marketing agent. The supervisor reviews every output before it ships. The worker builds. The marketing agent owns outbound narrative. They don't share a prompt or a session — they share a memory layer.

Operator Stack (a VC operating system we run on top of Memory Stack): supervisor, admin worker, public site worker, LP portal worker, marketing worker, content manager, Clara engine. Five workers under one supervisor, plus Clara running as an independent engine on a different schedule and different model.

None of these agents were designed to work together. They run on different models, different tools, different schedules. What keeps them coherent is Memory Stack.

Three things that flow through the substrate

Coordination state — protocols that transfer without re-briefing

The supervisor-worker protocol we use inside Memory Stack was invented here. A review queue that workers write to, supervisors respond in, and neither side re-explains context to the other. It's file-based: [PENDING] when work starts, [DONE] when it lands, [BLOCKER] when something's stuck. The supervisor reads the queue; the worker reads the supervisor's responses. No catch-up calls. No re-briefing.

When we stood up Operator Stack, that protocol transferred without any rewrite. The Operator Stack supervisor picked it up from Memstack and started operating the same way — same queue format, same discipline, same escalation patterns. We didn't copy a document. We didn't schedule an onboarding session. The memory was there; the agent loaded it.

This is the core value of coordination memory: hard-won operational patterns move across agent boundaries, across project boundaries, across model boundaries. Without it, every new agent you spin up starts from zero and re-derives — or re-violates — the same patterns your other agents already worked out.

Engine rules as data — tunable behavior without a deploy cycle

Clara, the VC ops engine inside Operator Stack, runs behavior that changes frequently. Lead qualification criteria, email triage rules, LP update scheduling — all modified by the team operating Clara, not by engineers. In a conventional setup, that means a prompt rewrite, a PR, a review cycle, a deploy, and a thread to confirm nothing drifted.

In our stack, rules live as tagged Memstack memories. Clara loads them at session init. The team member who owns the rule logs it directly; Clara reads it on the next call. The gap between "we need to change Clara's behavior" and "Clara's behavior changed" collapses to seconds. No engineer in the loop, no deploy required.

The audit trail is built in: every rule load is logged with rule ID, memory ID, user, and timestamp. You can trace which rules governed any session — two weeks later, two quarters later.

Standing house rules — constraints that load automatically

Brand-safety rules, scope guardrails, response principles — loaded at session init by every agent in both projects. Not embedded in prompts. Not in a shared doc someone remembered to link. Memstack memories tagged for the relevant agents, loaded automatically.

When we update a rule, every agent that cites it gets the update on its next session. When we add a new agent, it inherits the rule set by default. The discipline this creates is hard to replicate with docs: the system enforces the context instead of trusting that someone will remember to attach it.

Why the alternatives fail

Single-agent memory tools (Mem0, Letta, Zep)

These are good products for a specific use case: one agent persisting state for itself across sessions. The user_id is the scope. For personal assistants and single-purpose agents that need to remember things between runs, they work well.

The limit shows up the moment you have two agents on the same task. Agent A learns something; agent B — on a different tool or a different session — doesn't have access to it unless you build the bridge yourself. Mem0's tenancy model is user_id-scoped: there's no native model for one agent writing a memory that a different agent in the same org reads as part of its coordination context. You'd be building the cross-agent layer from scratch.

Memory Stack's tenancy model is org → team → user → project. Cross-agent recall is built in. A protocol written by the Memory Stack supervisor loads for the Operator Stack supervisor. A rule logged by Clara's operator loads for Clara. No custom integration required.

Docs-for-humans (Confluence, Notion, shared documents)

Agents can read docs. The failure mode isn't access — it's load discipline.

Docs get included when someone remembers to include them. Memstack memories load automatically at session init based on tags and scope. The team member who sets up an agent on Monday includes the relevant documents. The agent spawned on Thursday for a related subtask probably doesn't get them. The rule that was added to the shared doc two weeks ago doesn't surface unless someone specifically thought to pull it.

In a fleet running eight agents across two projects, "remember to include the right docs" is not a reliable coordination strategy. Automatic memory loading is.

In-runtime memory (Claude Projects, ChatGPT memory)

The most convenient options, and the most constrained. Claude Projects memory stays in Claude. ChatGPT memory stays in ChatGPT. If your Cursor agent and your Claude agent are working on the same codebase, they don't share what they've learned. A decision captured in a Claude conversation doesn't surface in the next Cursor session.

Cross-runtime portability is the capability these products explicitly don't offer — by design. They're features of a single vendor's runtime, not substrate for an org's AI fleet.

Memory Stack connects to Claude, ChatGPT, Cursor, Copilot, Gemini, and any MCP-capable tool. A memory written in one runtime is readable in any other. When we spin up a new agent in a new tool, it joins the same substrate the other agents are already using.

What you get

• No coordination drift. Agents working on related tasks share context automatically. A protocol established by one agent loads for the next. A rule updated in one project propagates across all agents that cite it.
• Tunable without a deploy. Rules and principles stored as memories are updated by the people who own them — no engineering cycle, no PR review.
• Auditable at the memory layer. Every rule load is logged with rule ID, memory ID, user, and timestamp. You know which rules governed which sessions, traceable back to the memory that specified them.
• Portable across tools. The same substrate works in Claude, ChatGPT, Cursor, and Copilot. New tools join the fleet without migrating any memory or rebuilding any integration.

The honest version

This matters if you run more than one AI agent and want them to stay coherent over time. If your org has a single Cursor user on one project, this is overkill.

If you have a marketing team using ChatGPT, an engineering team using Claude Code, and an ops team using Cursor — they're running independently. Each team re-derives patterns the others figured out months ago. Each agent re-reads context the others already hold. Each new tool you add starts fresh.

Coordination memory is the gap. It's not a new category — it's the part of multi-agent infrastructure that the single-agent memory tools, the docs platforms, and the in-runtime memory features all leave open.

We built Memory Stack to close it. We run it on ourselves. It works.