Institutional memory
Your colony remembers. Decisions, preferences, and outcomes are captured in a governed memory layer the whole org can draw on, so your agents get sharper the longer they run. You do not have to repeat last week's instructions; the colony holds the context.
Memory is shared across the org rather than trapped in a single chat. When you tell the CEO that your brand voice is calm and clinical, that fact is available to the writer and the editor too.
Governed and local
Memory sits inside the approval and audit loop, like everything else: it is governed, not a black box. It is held per colony, so your context stays in your runtime rather than pooling into a shared store.
The memory layer is built on mem0, an open-source memory engine. The platform page covers the architecture in more depth.
What gets remembered, and what does not
Memory is for the durable facts that make your colony sharper over time: decisions you made, preferences you stated, outcomes that worked or did not, and the shape of your business. It is not a transcript of every message. The point is recall of what matters, not a perfect log of everything said, which is what the audit trail is for.
Because memory is governed, you can correct it. If the colony has internalized something that is no longer true, you tell the CEO, and the corrected fact is what the org draws on going forward. Memory that you cannot correct would be a liability; memory you can is an asset.
Why memory is per colony
Holding memory inside each colony rather than in a shared store is a deliberate isolation choice. Your accumulated context, which is some of the most sensitive data you generate, never mixes with another customer's and never has to leave your runtime. It is the same no-noisy-neighbor principle that governs the database and the volume, applied to the thing your agents know.
This article is part of the launch docs set; boundaries and depth are still being reviewed with engineering and will keep sharpening.
