The_Question_Before_the_Tools

The persistence conversation usually starts with tooling: which vector store, how to retrieve skills, whether to cache embeddings. Those are implementation details. The prior question is architectural.

When you have multiple agents working across multiple projects, you face a choice: do all agents read from one shared memory store? Or does each agent keep its own memory, scoped to the work they're doing?

The question sounds abstract until you run into the failure modes.

Shared_Memory_-_One_Brain_for_the_Fleet

A shared memory store makes intuitive sense. All agents draw from one source of truth. When one agent learns something, all agents benefit. You have a single place to audit what the fleet knows. One retrieval mechanism, one update protocol, one governance boundary.

The failure modes are operational.

First failure mode: retrieval overhead on every turn. If memory is retrievable by embedding-similarity rather than loaded at startup, every agent consults the store on every single turn where that memory might be relevant. For always-on rules - the voice vocabulary that cannot be skipped, the security check that runs every time - you've now introduced a retrieval latency and a retrieval failure surface. What happens when the vector store is slow? When the similarity match fails and the rule doesn't load? The rule is supposed to be guaranteed. The retrieval layer broke that guarantee.

This shows up most clearly when working across voice systems. A voice system that should catch every off-register phrase loading inconsistently because the embedding search has variance in relevance scores. The phrase gets through because retrieval succeeded but confidence was borderline, and the ranking surfaces the wrong version.

Second failure mode: the wrong memory activates. A shared store means every agent touching it must trust the same retrieval logic. Agent A is working on a FitChecker backend task; Agent B is working on Labs content. If memory is retrieved by similarity alone, a rule intended for Labs context could activate in a FitChecker code review. It would be the "right" rule by embedding distance but the wrong rule by project context.

This is recoverable - you add metadata tags, context filters, project namespacing. But you're now maintaining those filters across every query. And the retrieval logic grows to account for the exception cases that embeddings alone cannot handle.

Third failure mode: visibility disappears. With a shared store, memory governance becomes a data-access problem. Who can add to the store? How do you prevent conflicting rules? When memory is distributed across files that live in specific directories and get loaded in a specific order, the hierarchy is visible: global baseline, project override, scoped rule. When everything is in a vector store, governance becomes implicit. The rules are there, but how they got there and why they persist is hidden.

Isolated_Memory_-_Each_Agent_Keeps_Their_Own

The opposing architecture: each agent maintains memory scoped to the context they're working in. No shared retrieval. Each agent reads their context files at startup, not on demand.

This has a different set of failure modes.

First failure mode: memory fragmentation. If Agent A solves a problem in one project and Agent B encounters the same problem in another project, there's no mechanism for the solution to propagate. You need an explicit curator - a person or process - that reads across all the agent memories and decides what's universal enough to lift to a shared layer.

The curator's work is pattern-matching across the agent-scoped SKILL.md files and the project-scoped CLAUDE.md overrides. Look for patterns: did multiple agents hit the same bug? Did different projects invent the same workaround? That becomes a candidate for promotion to the global baseline.

Without the curator, isolated memory becomes a knowledge silo. With the curator, isolated memory becomes an architecture that scales - but it requires explicit operational work.

Second failure mode: context bloat. When each agent loads all their own memories on startup, context token count rises with the agent's tenure. The longer an agent operates, the more operational knowledge they accumulate, the more tokens they burn just loading context. The loaded context grows as the agent accumulates operational knowledge.

Governance requires an elevation rule: operational memory that an agent relies on every task gets typed into the global baseline or marked as "always-load." Operational rules that have been acted on get archived; the rest stay in scope. This keeps memory scoped and searchable.

Third failure mode: governance by drift. Without a shared retrieval mechanism, you need explicit policies for how memory is updated, who can update it, what makes something permanent. In a team of one, this is a personal ritual. In a team with multiple agents, it becomes either a bureaucracy or a breakdown.

The governance pattern: operational memory stays in the agent's scoped file until rules are stable, other artefacts reference them by path, and they would mislead if called "work-in-progress." Rules that are wrong get reset immediately; rules that are right but too context-specific stay archived as historical reference. Graduation happens when visibility matters more than volatility.

Why_the_Fleet_Chose_Isolated_Plus_a_Curator

The fleet decision was not "shared vs isolated" as a binary. It was "isolated at the edge, with a curator at the centre."

Every agent reads their own scoped CLAUDE.md and SKILL.md files at startup - no retrieval overhead, guaranteed load. Capability that's universal (TypeScript typing rules, voice vocabulary, git workflow) lives in the global CLAUDE.md that every agent reads unconditionally. Capability that's project-specific or agent-specific lives in scoped files that activate only when the agent is in that context. A capability index file (MEMORY.md) documents what's stored where, so the curator can find it.

The curator reads across all the files, identifies patterns, and promotes successful capability upward. A bug fix that multiple agents independently implemented becomes a candidate for a global rule. A project-specific workaround that's proven itself over time gets documented in the project CLAUDE.md where it stays until the underlying problem is fixed.

This architecture has real costs: it requires the curator to do periodic reads across the files, and it requires every agent to have clear scoping boundaries. But the failure modes are operational, not invisible. When something goes wrong, you can see why - the file is right there, the decision is documented, the reasoning is traceable.

The_Decision_Frame

Shared memory scales knowledge-sharing but introduces retrieval latency and governance invisibility. Isolated memory is operationally visible but requires a curator to prevent silos.

Neither is objectively superior. The decision depends on what you're optimising for.

Optimise for consistency and simplicity if your agents are mostly independent, running single-task operations in single-project contexts. A small team, a bounded problem, one coherent codebase - shared memory makes sense. The retrieval overhead is acceptable because the query scope is constrained.

Optimise for visibility and reliability if your agents are interdependent, operating across multiple projects with conflicting norms, or need guaranteed rule execution on every turn. A fleet of specialists, each with distinct capabilities and project knowledge - isolated memory is the harder architecture to maintain, but the failure modes are traceable.

The fleet chose isolated because the alternative meant losing visibility into what rules were loading when. That invisibility cost more than the curator's work.