Tenant scope
Customer-specific facts stay inside the customer boundary.
guide · governed memory
Governed memory for long-running AI agents.
The longer an agent runs, the more memory helps. The same memory also becomes a risk unless scope is explicit.
Memory boundaries
Useful memory is not the same thing as global memory.
A long-running AI agent needs memory. It should remember deployment targets, user preferences, project decisions, recurring workflows, and previous investigations. Without memory, every conversation starts from zero and the agent wastes tokens reconstructing context. But if memory is just a growing text pile, it quickly becomes unsafe. The agent may recall a fact from the wrong customer, apply a personal preference to a shared workspace, or leak a sensitive incident note into an unrelated answer.
Governed memory starts with scope. A fact should say where it belongs: tenant, workspace, user, role, session, or global. It should also say how it was created, when it was last used, and whether it is safe to promote. That turns memory from vague context into auditable data.
Workspace scope
Project and repository decisions apply to the right working area.
User scope
Preferences and personal notes follow the user, not every teammate.
Role scope
Operational context can be filtered by what the current actor is allowed to know.
Session scope
Temporary facts can help a conversation without becoming permanent memory.
Retrieval
Fast recall should still be explainable.
As memory grows, substring scans and giant JSON histories become slow and expensive. A governed agent needs indexed retrieval that can filter by scope before ranking results. That is why Muster moved memory search toward SQLite/FTS with scope columns. The goal is simple: keep retrieval fast as memory grows, while making it clear which scoped facts entered the prompt.
The token ledger completes the loop. If memory recall helps answer a question with fewer tokens, the ledger should show that. If memory recall adds too much context and creates replay waste, the ledger should show that too. This is how a team can improve retrieval over time without guessing.
Governed AI agents do not need infinite memory. They need memory that can be searched, scoped, tested, promoted, expired, and audited. That is the difference between personalization and leakage.
Promotion is especially important. A user may mention a temporary detail during a session: "use the staging site today" or "ignore that report until payroll closes." That should help the current conversation, but it should not automatically become durable user memory. A more durable fact, such as "this workspace deploys to uat-erp.example.com," may deserve promotion after confirmation or repeated use. The harness should make that distinction explicit.
Time also matters. Some memories should decay. A pricing rule, incident status, deployment target, or authentication detail can become stale. A governed memory system should store timestamps and provenance so retrieval can prefer fresh facts, warn about stale facts, and avoid presenting old operational details as certainty.
Finally, memory should be testable. If a leakage bug is found, it should become a regression fixture: this user should not recall that tenant's fact, this session-only note should not appear after reset, and this promoted memory should be visible only in the intended scope. That is why governed memory belongs in the harness. The model may use the memory, but the harness must prove the boundary.
Good memory UX is also part of governance. Users should be able to name sessions, inspect what was remembered, search memory directly, and understand why a fact was recalled. Operators should be able to reset, promote, or remove memory without editing raw files. When a conversation starts, a named history gives the agent a cleaner reference point than a vague global transcript. That improves personalization while making the interface easier to trust.
The strongest memory systems will combine fast indexed retrieval with policy-aware filtering and optional reranking. The first filter should be scope: do not rank what the user is not allowed to see. Then retrieve candidates efficiently. Then, if needed, rerank a small set. This keeps memory fast as it grows and prevents the common failure where a clever retriever finds a fact that should never have entered the candidate pool.