A self-improving memory loop sounds like a clear win until you watch it rewrite something correct with something outdated. The agent remembered a fact. You verified it. A later consolidation pass ran against a stale context window, decided the memory was imprecise, and replaced it with a weaker version. The original was better. You lost ground.

This is the failure mode that belief-aware memory was built to prevent. Not "agents write wrong things" — that's a model quality problem. The specific failure is: the improve loop, running unsupervised, overwrites correct content it should have left alone. A loop that can degrade its own best work is worse than no loop at all.

akm 0.8.0 ships <code>captureMode</code> and <code>beliefState</code> as first-class frontmatter fields on memory assets. Together they tell the consolidation pass what each memory is, what the agent believes about it, and whether it is eligible to be rewritten.

<h2>
 
 
 The Two Capture Modes
</h2>

Every memory asset now carries a <code>captureMode</code> field. It has two values.

<code>hot</code> means the memory was written or explicitly confirmed by a human. The improve loop treats hot memories as read-only. No consolidation plan, no merge proposal, no rewrite. If every memory in a chunk is <code>captureMode: hot</code>, the consolidation pass skips the LLM call for that chunk entirely — the chunk is counted as <code>judgedNoAction</code> before a single token is spent. This is the all-hot chunk early-exit.

<code>background</code> means the memory was generated by an agent — promoted during a prior consolidation run, written by an inference pass, produced by <code>akm remember</code> without explicit human review. Background memories are eligible for improvement. The consolidation pass can propose merges, rewrites, deletions, or upgrades.

When no <code>captureMode</code> is set, the memory is treated as eligible for consolidation. Memories that existed before 0.8.0 are treated this way on first encounter. 


<div class="highlight js-code-highlight">
<pre class="highlight yaml"><code>---
captureMode: hot
beliefState: asserted
description: Primary LM Studio endpoint moved to Shredder (192.168.0.99:1234)
---
</code></pre>

</div>





<div class="highlight js-code-highlight">
<pre class="highlight yaml"><code>---
captureMode: background
beliefState: active
description: Approximate token throughput for qwen3.5-9b on RTX 4060 Ti
---
</code></pre>

</div>



The distinction matters most for memories that are both accurate and stable: architectural decisions, confirmed configuration facts, verified benchmarks. You write them once, mark them hot, and the improve loop stops touching them.

<h2>
 
 
 The Belief States
</h2>

<code>beliefState</code> describes the agent's current belief about the memory's accuracy. The field has five non-archived values.

<code>active</code> is the default when no <code>beliefState</code> is set. The memory is currently believed to be true. The consolidation pass treats it normally according to its <code>captureMode</code>.

<code>asserted</code> is the human-authority variant of <code>active</code>. The improve loop sets this when you use <code>akm remember</code> explicitly. Like <code>active</code>, the consolidation pass treats it as eligible based on <code>captureMode</code> — but <code>asserted</code> is never automatically downgraded to <code>active</code> during consolidation. It carries a stronger signal that a human touched this memory directly.

<code>deprecated</code> means the memory has been superseded. The content is no longer the current best representation, but it is not wrong — it describes something that was true and has since evolved. Deprecated memories are frozen historical state — the consolidation pass will not refresh them to <code>active</code>, but they are candidates for merge into a more current memory.

<code>superseded</code> is the system-assigned equivalent of deprecated. The improve loop writes this when it determines a memory has been replaced by a newer one. Unlike <code>deprecated</code>, <code>superseded</code> can be refreshed if the superseding memory is later retracted.

<code>contradicted</code> means the memory is known to be wrong. It conflicts with something else in the stash that the agent now believes more strongly. A contradicted memory is never promoted, never merged into a primary, and is queued for deletion on the next consolidation pass that touches it. 


<div class="highlight js-code-highlight">
<pre class="highlight yaml"><code>---
captureMode: background
beliefState: contradicted
contradictedBy:
 - memory:lm-studio-server-topology
description: Old belief that Don was the consolidation LLM endpoint
---
</code></pre>

</div>



The <code>contradictedBy</code> field is an array of refs — the memories that supersede this one. It chains revisions explicitly. You can read the chain backward: follow each <code>contradictedBy</code> ref to find the current belief. The <code>beliefState</code> field is indexed as a frontmatter tag, so <code>akm search "beliefState:contradicted"</code> or <code>akm search "beliefState:deprecated"</code> surfaces everything the agent currently believes is wrong or outdated, which is useful for auditing stale content before a long session.

<h2>
 
 
 What the Improve Loop Actually Checks
</h2>

When <code>akm improve</code> starts a consolidation chunk, it evaluates <code>captureMode</code> before making any LLM call. The sequence is:

<ol>
<li>Load the memory pool for the chunk.</li>
<li>Check <code>captureMode</code> for every memory in the chunk.</li>
<li>If all memories are <code>hot</code>, record the chunk as <code>judgedNoAction</code> and skip to the next chunk. No model call.</li>
<li>If any memory is <code>background</code> (or has no <code>captureMode</code> set), proceed to the LLM consolidation prompt — but pass the belief state metadata alongside each memory so the model knows what it is working with.</li>
<li>The model sees <code>beliefState: contradicted</code> on a memory and knows not to use it as a merge primary. It sees <code>beliefState: deprecated</code> and treats the memory as a merge candidate rather than a standalone to preserve.</li>
</ol>

The early-exit on all-hot chunks is a real cost reduction in practice. A stash where the majority of permanently-settled memories are marked hot will skip a significant fraction of chunks without touching the model at all. Those skipped chunks still count in the run's telemetry — the <code>judgedNoAction</code> counter — so <code>akm health</code> can show you the proportion of work that was bypassed via belief state rather than processed.

<h2>
 
 
 Enabling Belief-Aware Memory
</h2>

Belief-aware memory is active by default in 0.8.0. For most setups, nothing changes on upgrade. Existing memories without a <code>captureMode</code> field are treated as eligible for consolidation, and existing memories without a <code>beliefState</code> field resolve to <code>active</code> — both match prior behavior.

The <code>memory.belief_aware</code> configuration flag (enabled by default; not surfaced in <code>akm config list</code> — check release notes if you need to toggle it) (documented in the release notes) gates the pre-write validation path. Leaving it on is the right default. The validation overhead is negligible. The protection against overwriting confirmed content is the point.

<h2>
 
 
 The Workflow in Practice
</h2>

The intended workflow is straightforward. Run <code>akm improve</code> or <code>akm remember</code> normally. When the improve loop promotes a memory that you verify and want to lock, open the asset and set <code>captureMode: hot</code>. That is the only required human action. 


<div class="highlight js-code-highlight">
<pre class="highlight shell"><code># Review a promoted memory
akm show memory:lm-studio-server-topology

# Lock it against future rewrites
# Edit the frontmatter: captureMode: hot
</code></pre>

</div>



When something in the stash becomes wrong — you find a configuration fact that has changed, a benchmark that does not reflect the current hardware — mark it contradicted and point it at the memory that replaced it: 


<div class="highlight js-code-highlight">
<pre class="highlight yaml"><code>---
captureMode: background
beliefState: contradicted
contradictedBy:
 - memory:shredder-throughput-2026-05
description: Initial throughput estimate for Shredder before thermal tuning
---
</code></pre>

</div>



The contradicted memory stays in the stash until the consolidation pass processes it. It does not disappear immediately. That is intentional — the chain of belief updates is itself a record of how your agent's understanding evolved. You can review it, audit it, and delete it explicitly when you are satisfied the current belief is stable.

For deprecated memories, the same pattern applies, but with a lighter touch. A deprecated memory is not wrong — it is outdated. The consolidation pass will eventually merge it into something more current. You can accelerate this by pointing the <code>contradictedBy</code> field at the successor, but it is not required.

<h2>
 
 
 What This Protects Against
</h2>

The improve loop is powerful because it runs continuously and without supervision. That is also the source of the failure mode. An unsupervised loop that can propose changes to anything in the stash will, given enough time and enough edge cases, propose a change to something it should not touch.

Hot memories are immune. They require no ongoing maintenance. They do not need to be defended against the loop because the loop is not allowed to reach them.

Background memories with <code>beliefState: active</code> or <code>asserted</code> are in normal rotation. The loop can improve them. That is the intended behavior — background memories accumulate in agent sessions and benefit from periodic consolidation.

The contradicted and deprecated states give the loop a way to reason about quality without conflating "eligible for improvement" with "currently correct." A background, active memory is eligible and believed correct. A background, contradicted memory is eligible and believed wrong — the right action is deletion or absorption, not refinement.

The combination — two capture modes, five belief states, and an explicit contradiction chain — gives you fine-grained control over what the loop does. The loop becomes an asset rather than a liability when it has enough information to distinguish what it should improve from what it should leave alone.




Belief-aware memory is part of akm 0.8.0. The full field reference is in <a href="https://github.com/itlackey/akm/blob/main/docs/configuration.md" rel="noopener noreferrer">docs/configuration.md</a>. The improve pipeline and consolidation pass behavior are covered in the <a href="https://dev.to/itlackey/your-agent-has-a-memory-that-runs-while-you-sleep-20oh">improve pipeline debugging post</a> and the <a href="https://dev.to/itlackey/akm-080-cli-redesign-task-assets-and-belief-aware-memory-335a">0.8.0 release notes</a>. For a walkthrough of the improve loop setup and scheduling, see <a href="https://dev.to/itlackey/the-improvement-loop-how-akm-keeps-your-agent-sharp-2d4d">The Improve Loop: Continuous Memory Curation</a>.

تم تقديم ميزة جديدة تُسمى الذاكرة الواعية بالمعتقدات لمنع الوكلاء من استبدال المعلومات الصحيحة بمحتوى قديم خلال عمليات دمج الذاكرة. تتضمن هذه الميزة وضعين للتسجيل وحقولًا تُخبر الوكيل عن دقة الذكريات وما إذا كانت مؤهلة لإعادة الكتابة.

Se ha introducido una nueva función llamada memoria consciente de creencias para evitar que los agentes sobrescriban información correcta con contenido obsoleto durante los procesos de consolidación de memoria. Esta función incluye dos modos de captura y campos que informan al agente sobre la precisión y la elegibilidad de los recuerdos para ser reescritos.

Une nouvelle fonctionnalité appelée mémoire consciente des croyances a été introduite pour empêcher les agents de remplacer des informations correctes par des contenus obsolètes lors des processus de consolidation de la mémoire. Cette fonctionnalité comprend deux modes de capture et des champs qui informent l'agent sur l'exactitude et l'éligibilité des souvenirs à être réécrits.

A new feature called belief-aware memory has been introduced to prevent agents from overwriting correct information with outdated content during memory consolidation processes. This feature includes two capture modes and fields that inform the agent about the accuracy and eligibility of memories for rewriting.