Don't build a company brain. Scope memory small.

Errors in memory don’t repeat. They breed: a wrong fact gets reasoned from, and the conclusions get written back as new memory. We take that mechanism apart in detail in Memory an AI agent can inspect. This post is about the architectural consequence: the size of a memory is the size of its risk. The fix isn’t one brain that knows everything; it’s many small, isolated memories, each scoped to one cohesive use case.

Scoping reduces blast radius; it does not make a record true. A hash or retrieval receipt can help check record integrity and provenance, while factual validation remains a separate step. The current MEMA evidence status also distinguishes public source, internal implementation, and planned operating capabilities.

The tempting version: one company brain

The pitch writes itself: feed everything the company knows into one memory, and every agent can draw on all of it. Pricing next to HR, contracts next to support tickets, payroll next to the product roadmap.

The problem is the same mechanism that makes memory valuable. A memory that everything writes into has a huge surface where hallucinations can enter. Once one is in, every use case that reads from the shared store can pick it up, reason from it, and write new errors back. One wrong fact gets an organisation-wide blast radius. And because the store is enormous, no person and no automated check can realistically verify it.

Left: in one shared brain, a single wrong fact reaches every topic. Right: in scoped cells, the same error is caught inside one cell and never crosses to its neighbours.

The robust version: one memory per use case

The alternative borrows two old, boring, proven ideas from software and ship design.

The first is the bounded context: a deliberately drawn boundary inside which words have one clear meaning and the knowledge belongs together. Onboarding is one context. Pricing is another. A memory scoped to one bounded context stays small and coherent: few enough facts that a person, or a write-time check, can actually verify them.

The second is the bulkhead: the watertight wall between compartments of a ship. One compartment can flood without sinking the vessel. Applied to memory: cells are isolated, nothing reads or writes across the wall. When an error does get in, it is caught inside one cell, and the blast radius ends at the cell boundary.

Side by side:

One company brain: huge surface for hallucinations to enter, organisation-wide blast radius for every error, and too big to verify by hand or by check.
Scoped, isolated memories: small and cohesive enough to actually check, contained blast radius because an error can’t cross cells, and less memory that can tip over, so less that can compound.

How to cut the cells

The method has three steps, and the first one is the one most projects skip:

Challenge the architecture. Before giving anything a memory, ask whether the use case itself is well-cut. A memory attached to a vague use case inherits the vagueness.
High cohesion, low coupling. Inside a cell, everything should belong together; between cells, dependencies should be rare and explicit. The same rule that makes software maintainable makes memory verifiable.
One memory per bounded context. Then, and only then, attach a small, checkable memory to each use case, with its own governance and its own audit trail.

Scoping memory small is not a limitation of ambition. It makes review and containment practical: several bounded stores are easier to inspect than one shared store with a company-wide blast radius. See the architecture and its limits →