Product Update

Memory Policies: Control What Your AI Remembers

Most AI memory systems fail in one of two ways: they remember too little and feel forgetful, or they remember too much and become noisy. Memory Policies give you a control plane between those extremes.

Marius Ndini

Founder · Mar 8, 2026

The problem Memory Policies solve

Long-term memory is only useful when the right things are stored. Without guardrails, assistants start saving low-signal details: greetings, temporary phrasing, one-off requests, or incidental context that should never become part of a durable user memory.

That leads to memory drift. Over time, recall gets noisier, extraction gets less trustworthy, and teams lose confidence in what the system is learning.

Memory Policies solve that by letting you define what counts as worth remembering before the memory is written.

What a Memory Policy actually is

A Memory Policy is a scoped extraction rule set. It tells Mnexium what kinds of information should be persisted, what should be ignored, and how strict the system should be when deciding whether a candidate memory is high enough quality to save.

In practice, it gives you two layers of control:

  • Instructional controlvia policy text, so the extraction model understands the intent of what your application wants to learn.
  • Deterministic filteringvia config, so extracted candidates still have to pass explicit thresholds before they are persisted.

Why scope matters

Not every workflow should learn the same way. A support assistant, a sales copilot, and a personal planner all need different memory behavior. Even within the same app, one chat may require stricter extraction than another.

Memory Policies are scoped at three levels:

  • Project scope for baseline behavior across the whole product.
  • Subject scope when one user or account needs specialized extraction rules.
  • Chat scope for workflow-specific behavior inside a single active thread.

This means you can set safe defaults once, then tighten or relax learning only where it makes sense.

What users can accomplish with it

Memory Policies are not just a configuration feature. They change what kinds of products you can build reliably.

  • Support teams can preserve durable preferences, account constraints, and standing user instructions without storing every support exchange as memory.
  • Compliance-sensitive appscan constrain what is learned and reduce the chance that transient or inappropriate details become long-lived memory.
  • Workflow assistantscan run strict chat-specific extraction during a live task, then fall back to broader project defaults elsewhere.
  • Product teams can improve recall quality over time because less noise enters the memory layer in the first place.

The practical controls

Memory Policies let you tune extraction along a few dimensions that matter in production:

  • Kinds so you can allow or block categories like facts, preferences, notes, context, events, or traits.
  • Confidence thresholdsso weak extractions do not get persisted.
  • Importance thresholdsso only information with enough long-term value makes it into memory.
  • Per-turn caps so one message does not flood the system with too many new memories at once.

Request-level control still matters

Scoped defaults are the steady-state behavior. But real products still need one-off control. Some flows need a temporary override. Some need learning enabled but policy application disabled. Some need one exact policy for a specific operation.

That is why mnx.memory_policy matters. It lets your app decide whether to auto-resolve defaults, force one policy, or skip policy application on a single request.

// Auto-resolve defaults for this request
"mnx": { "subject_id": "user_123", "learn": true }

// Force one explicit policy
"mnx": { "subject_id": "user_123", "learn": true, "memory_policy": "mp_support_assistant" }

// Disable policy application while keeping learn enabled
"mnx": { "subject_id": "user_123", "learn": true, "memory_policy": false }

What this means for Mnexium

Memory Policies push Mnexium further away from generic chat persistence and closer to a real memory operating layer. The important shift is not just that the system can remember. It is that the system can remember with intent.

That makes memory quality tunable. It makes extraction behavior explainable. It gives teams a credible path to scaling memory without accepting uncontrolled accumulation of low-value context.

Start with one policy, then get stricter where it matters

The simplest rollout is one project default policy first, then subject or chat overrides for the workflows that need tighter control.

View Memory Policies DocsOpen Memory Policies