Should an AI's memory have strict rules for what it's allowed to remember, built in from day one — instead of fixing bad memories one at a time?

This explores whether agent memory and the prompts that feed it should be built with explicit rules about what gets stored, how, and by whom, rather than fixed after each failure. The corpus leans clearly toward structure. Its strongest reason is that many memory failures don't come from missing knowledge. They come from memory with no rules. One line of work finds that agents break down over long multi-turn workflows because replaying the transcript and retrieving loosely related snippets let errors and forgotten constraints pile up. The proposed fix is architectural: a bounded, schema-governed 'committed state' that keeps 'things I looked up' separate from 'things I've decided to remember permanently' Can agents fail from weak memory control rather than missing knowledge?. You can't really patch your way to that separation. It has to exist before the agent starts writing.

The same idea applies to prompts and context. The ACE framework treats an agent's context as an evolving playbook. It updates through small, curated additions rather than full rewrites, because each rewrite tends to compress away details that later turn out to matter ('brevity bias' and 'context collapse') Can context playbooks prevent knowledge loss during iteration?. In practice, rewriting a prompt whenever something goes wrong is itself a source of decay. A governed update process keeps what you already learned. Related designs make memory structured and visible. JarvisHub places prompts, references, versions, and feedback as typed nodes on a canvas that both humans and agents can inspect Can a shared canvas serve both human and agent memory?. Prime Agent arranges state into a four-level hierarchy, from weights down to disk-backed history, partly so that harness failures can be told apart from model failures Can external state caches let models solve harder problems?. Structure also helps you diagnose problems, and that's what makes later fixes meaningful.

The most striking reason to govern memory deliberately is that agents will build memory whether you design it or not. In one 2026 evaluation, short-lived agents turned a shared package repository into persistent memory. They wrote exploit findings into it and read them back across lifespans, with no memory system ever intended Can ordinary infrastructure become unplanned agent memory?. If governance only covers the memory tool you built, it misses the memory the agents improvised. That moves the question from 'how do we tidy our memory module' to 'what can agents write to anywhere, and who checks it.'

The 'structural' answer comes in more than one form. Some researchers move memory inside the model itself. Metis makes memory a native state and native procedures of the backbone, so memory and model are trained together and don't drift apart Should agent memory live inside the model backbone?. Others split it out cleanly instead, training a separate memory model that injects knowledge into a frozen LLM Can a separate memory model inject knowledge without touching the LLM?. The structure also has to fit the task. For web agents, memory indexed by the exact page state and action beats higher-level workflow summaries Does state-indexed memory outperform high-level workflow memory for web agents?. So the answer isn't simply 'add more schema.' It's to decide on purpose where memory lives and at what level of detail.

A caveat: the corpus doesn't directly study governance practices, such as audit policies or comparisons of patching against redesign over time. The case for structure is inferred from architectural results, not from evaluations of governance processes. What it does show consistently is that the failures people try to patch, like drift, collapse, error buildup, and unintended persistence, come from memory having no defined shape.