AI Dreaming Memory Management for LLMWikis.org

Full report

On this page

Executive summary

“AI dreaming” is now a concrete product pattern as well as a research idea. Anthropic’s official Managed Agents documentation defines dreams as asynchronous jobs that read an existing memory store and, optionally, up to 100 past sessions, then produce a separate output memory store with duplicates merged, stale or contradicted entries reorganized, and new insights surfaced; critically, the input store is not modified, and the output can be reviewed and discarded. Anthropic’s product announcement frames dreaming as a scheduled memory-curation process that can either be reviewed before use or allowed to update memory more automatically, while Orchestral describes dreaming as a constrained “sleep-time” rehearsal loop seeded from episodic memory and protected by explicit constraints, privacy scrubbing, and regression gates. Recent reporting on Anthropic’s release broadly matches that description: between-session review, pattern extraction, and memory refinement, rather than anything like unconstrained generative “imagination.”

For LLMWikis.org, the right governance stance is stricter than the most permissive vendor option: dreaming should be treated as a candidate-generation and memory-hygiene layer, not as an authority layer. LLMWikis’ public architecture already separates immutable raw sources from reviewed wiki pages, requires lifecycle states such as draft, reviewed, source-needed, contradicted, stale, and archived, and recommends staged automation rather than blind write-back. UAIX makes the same separation in different words: raw source memory, durable wiki memory, compact AI Memory, and Project Handoff are different layers, and only reviewed slices should become current truth.

That yields a publishable principle for LLMWikis.org: dream outputs may reorganize, cluster, summarize, or propose, but they may not directly become governing instructions. Any dream finding that affects AGENTS.md, readme.human, .uai files, authoritative wiki pages, release notes, security/privacy guidance, or production-facing runbooks should first pass provenance, sensitivity, contradiction, freshness, reviewer, and owner gates. Anthropic’s own memory docs reinforce this posture by warning that writable memory stores can be poisoned by prompt injection and recommending read_only stores for material that should not be modified by agents.

The academic literature points in the same direction. Recent survey work frames agent memory as a write–manage–read loop and highlights write-path filtering, contradiction handling, latency budgets, and privacy governance as production realities. Generative Agents, Reflexion, MemGPT, and A-MEM all support the idea that reflection, tiered memory, and dynamic organization help long-horizon agents; but the same survey also identifies continual consolidation, trustworthy reflection, and learned forgetting as open problems rather than solved pieces of infrastructure. Neuroscience work on sleep-dependent consolidation and “memory triage” is useful as a design analogy for probation buffers, selective replay, and deliberate forgetting, but it does not justify unreviewed autonomous rewriting of project truth.

The practical recommendation is therefore a review-only default for LLMWikis.org: dreams may auto-write to raw run logs, draft candidate records, contradiction drafts, and metrics artifacts, but not to authoritative pages or hot-memory files. Promotions into authoritative wiki pages or Project Handoff surfaces should happen only through a logged, linted, review-gated workflow with rollback. The rest of this report turns that principle into a detailed, publishable page and setup-wizard design.

Research basis and governing rules

LLMWikis and UAIX already provide most of the policy primitives needed for “dreaming” governance. LLMWikis says raw evidence belongs in raw/, compiled pages belong in wiki/, navigation should flow through index.md and log.md, and lifecycle labels should remain explicit so “polished prose” does not accidentally become trusted evidence. The platform also recommends a two-step ingest loop—hash/register, analyze, stage, review, write, lint—specifically to prevent a model from reading, deciding, editing, and auditing “in one breath.” UAIX’s Canonical AI Memory guidance layers raw sources, LLM Wiki memory, optional derived graph, compact AI Memory, and Project Handoff, and insists that execution is not authority: reviewed memory is.

Anthropic’s dreaming and memory documentation gives the operational mechanics that LLMWikis can appropriate safely. Managed Agents memory stores are workspace-scoped collections of small text files with immutable version history; they can be attached read-only or read-write, and Anthropic explicitly warns that writable stores are vulnerable to prompt-injection poisoning if they ingest untrusted inputs. Dreams then operate as asynchronous curation jobs over those stores and past sessions, yielding a new store rather than mutating the input store. Orchestral’s design adds the missing governance language: constraint-first scenario generation, grounded tool behavior, privacy scrubbing before “sleep,” invariant-first filtering, independent critique, and regression gates before anything deployment-adjacent changes.

The table below translates those sources into operational rules suitable for publication on LLMWikis.org. The rightmost column names the most direct source basis; the precise defaults are proposed, but the rule structure follows the cited guidance.

The lifecycle below is the simplest publishable model consistent with those rules. It keeps dreaming useful for clustering, forgetting, and surfacing patterns, while preventing it from silently rewriting project truth.

flowchart LR
    A[Raw episodes and source traces] --> B[Dream run]
    B --> C[Dream run log]
    B --> D[Dream candidate]
    B --> E[Draft contradiction record]

    D --> F{Human review}
    E --> F

    F -->|Approve background memory| G[Reviewed LLM Wiki page]
    F -->|Approve operational truth| H[AGENTS.md or .uai update]
    F -->|Needs more evidence| I[Source-needed queue]
    F -->|Rejected or stale| J[Archive]

    G --> K[index.md update]
    G --> L[wiki/log.md entry]
    H --> M[Project Handoff evidence]
    H --> N[Context-budget check]

This architecture is also the best answer to a more subtle risk: anthropomorphic overtrust. Wired’s recent critique of terms like “dreaming” is directionally correct for governance even if not for product design: names that sound cognitive can encourage users to over-ascribe judgment, reliability, or autonomy to a memory process. LLMWikis should therefore define dreaming in mechanical terms—offline memory consolidation, contradiction surfacing, stale-entry cleanup, and candidate generation—and reserve the word “truth” for reviewed, source-backed, current project surfaces.

Publishable wiki and help-page guidance

A strong public-facing LLMWikis page should lead with a simple rule: AI dreaming is an offline memory-management pass, not an autonomous source of truth. Anthropic’s feature set, Orchestral’s “grounded dreaming” architecture, and the agent-memory research literature all support periodic consolidation, selective replay, and error-pattern detection; none of them eliminate the need for provenance, contradiction handling, privacy controls, or owner review before changes become operational truth.

Suggested page title: AI Dreaming Memory Management. Suggested summary: Use dreaming to clean, cluster, and stage memory—not to silently rewrite the project’s governing truth. Dream outputs belong in review queues until they are source-linked, redacted if needed, checked for contradictions, and promoted through logged review gates. That framing is fully aligned with LLMWikis’ source policy, trust model, two-step ingest, and security/privacy standards.

For the page body itself, this copy is suitable as the opening paragraph:

AI dreaming reviews prior work between sessions, looking for reusable patterns, contradictions, stale or duplicate memory, and candidate improvements. In LLMWikis, dreaming is background memory management. It may generate candidate records, contradiction drafts, and memory-cleanup suggestions, but reviewed pages, AGENTS.md, and .uai files remain the only project surfaces that count as current truth.

The page should then make the auto-write boundary explicit. The matrix below is a good publishable default. It is stricter than Anthropic’s most permissive option by design, because LLMWikis and UAIX treat reviewed promotion—not background curation—as the trust boundary.

The promotion policy should also be explicit and predictable. A help page is stronger when it tells readers what happens to a finding once it exists. The trigger matrix below is a reasonable publishable default. The trigger logic itself is grounded in LLMWikis’ promotion/hold/demotion/archive rules, Anthropic’s separate-output-store design, and UAIX’s “promote before relying” rule; the exact thresholds are proposed defaults for LLMWikis.org.

Human roles are crucial because they close the gap between “useful idea” and “governing instruction.” UAIX already names a memory steward, and LLMWikis already expects named owners, review status, sensitivity labels, and approval boundaries. A publishable page should therefore define three roles: the memory steward triages dream output and verifies provenance, the reviewer judges source quality and safe synthesis, and the owner decides whether a target surface may change. Those roles should not be collapsed automatically for hot-memory updates or sensitive pages.

The review checklist should fit on one screen. A useful publishable version is: Is the claim source-linked? Is it non-sensitive or properly redacted? Is the scope/date clear? Are contradictions preserved? Is this more than a one-off note? Does it belong in cold wiki memory or hot project memory? Have index/log/evidence updates and lint been prepared? That checklist operationalizes LLMWikis’ trust model and UAIX’s promotion rule without requiring readers to infer the standard from several separate pages.

Finally, the help page should define blocked content in unmistakable terms. LLMWikis’ own security page already prohibits storing or exporting secrets, credentials, privileged infrastructure details, raw customer or regulated data, private meeting/chat/support records without review and redaction, and internal strategy that should not be broadly exposed. UAIX adds hidden prompt instructions, unsupported legal or security claims, and unreviewed production logs to that blocked set for portable memory. Dreaming guidance should inherit those boundaries exactly and say that blocked content can influence a summary only after redaction review, not by being copied into long-term or portable memory.

Schemas, file layout, workflows, and tests

A concrete filesystem layout makes the governance model enforceable. LLMWikis already recommends raw/, wiki/, index.md, and log.md; UAIX adds AGENTS.md, readme.human, .uai/, and an optional LLM_WIKI_MEMORY_PLAN.md when the package is paired with deeper wiki memory. Anthropic’s product model maps neatly onto this if dream output is treated as a staging artifact rather than as current truth.

repo-root/
├─ AGENTS.md
├─ readme.human
├─ LLM_WIKI_MEMORY_PLAN.md
├─ raw/
│  ├─ README.md
│  ├─ sessions/
│  │  └─ 2026/05/09/sesn_*.json
│  ├─ dream-runs/
│  │  └─ 2026/05/09/drm_*.json
│  ├─ manifests/
│  │  └─ 2026/05/09/*.json
│  └─ system-archives/{project}/...
├─ wiki/
│  ├─ index.md
│  ├─ log.md
│  ├─ review-queue/
│  │  └─ dream-candidates/DC-*.md
│  ├─ contradictions/
│  │  └─ CR-*.md
│  ├─ concepts/
│  ├─ syntheses/
│  └─ runbooks/
├─ reports/
│  ├─ dreaming-metrics/
│  └─ lint/
└─ .uai/
   ├─ context.uai
   ├─ constraints.uai
   ├─ progress.uai
   ├─ test-plan.uai
   └─ file-handoff.uai

The candidate-storage options below are the most useful comparison for implementation planning. They are derived from LLMWikis’ raw/wiki split, UAIX’s hot/cold split, Anthropic’s separate dream-output store, and the agent-memory literature’s emphasis on provenance, observability, and staged promotion.

The schemas below are intentionally redundant about owner, sensitivity, redaction, source trace, status, and promotion target. That redundancy is not waste: LLMWikis’ trust model requires those trust signals, UAIX requires evidence and routing context, and the memory literature argues that write-path filtering and observability are core reliability features rather than optional metadata.

{
  "schema_version": "llmwikis.dream_run.v1",
  "dream_run_id": "drm_2026-05-09T021500Z_01",
  "created_at": "2026-05-09T02:15:00Z",
  "mode": "review_only",
  "engine": {
    "vendor": "anthropic",
    "product": "managed_agents",
    "feature": "dreaming",
    "model": "claude-opus-4-7"
  },
  "inputs": {
    "memory_store": {
      "store_id": "memstore_01Hx...",
      "snapshot_hash": "sha256:3ef0...",
      "mount_mode": "read_only"
    },
    "sessions": [
      {
        "session_id": "sesn_01Ab...",
        "ended_at": "2026-05-08T23:17:12Z",
        "sha256": "sha256:9fd3..."
      }
    ],
    "local_sources": [
      {
        "path": "wiki/log.md",
        "sha256": "sha256:6a92..."
      }
    ]
  },
  "instructions": "Focus on stable project conventions; ignore one-off debugging notes.",
  "sensitivity": "internal",
  "redaction_status": "passed",
  "source_boundary": "background_only",
  "findings_summary": {
    "duplicates_merged": 7,
    "stale_entries_flagged": 3,
    "contradictions_found": 1,
    "new_candidates": 4
  },
  "outputs": {
    "staging_memory_store_id": "memstore_01Out...",
    "candidate_paths": [
      "wiki/review-queue/dream-candidates/DC-2026-05-09-001.md"
    ],
    "contradiction_paths": [
      "wiki/contradictions/CR-2026-05-09-001.md"
    ]
  },
  "usage": {
    "input_tokens": 84321,
    "output_tokens": 6127
  },
  "review": {
    "required": true,
    "status": "pending",
    "memory_steward": "docs-platform",
    "review_due": "2026-05-12T17:00:00Z"
  },
  "retention": {
    "class": "dream_run",
    "delete_after": "2026-11-05T00:00:00Z",
    "manifest_path": "raw/manifests/2026/05/09/drm_2026-05-09T021500Z_01.json"
  },
  "error": null
}

---
schema_version: llmwikis.dream_candidate.v1
id: DC-2026-05-09-001
title: Pre-promotion lint keeps release-memory updates safer
candidate_type: procedural
status: candidate
trust_label: proposal
source_status: source-linked
sensitivity: internal
agent_use: background-only
owner: platform-docs-owner
memory_steward: docs-platform
reviewer:
created_at: 2026-05-09T02:18:34Z
updated_at: 2026-05-09T02:18:34Z
review_due: 2026-05-12T17:00:00Z
freshness_window_days: 30
importance: high
promotion_targets:
  - wiki/runbooks/release-memory.md
  - .uai/test-plan.uai
blocked_targets:
  - AGENTS.md
  - readme.human
risk_flags:
  - release-bound
  - process-drift
redaction_status: passed
checks_required:
  - source_traces_present
  - contradiction_scan
  - owner_approval
  - lint_pass
evidence:
  - source_kind: session
    source_trace: "sesn_01Ab..."
    source_path: "raw/sessions/2026/05/08/sesn_01Ab.json"
    sha256: "sha256:9fd3..."
claims:
  - id: claim-1
    text: "Release-bound wiki updates repeatedly reached target pages before a lint pass was recorded."
    status: source-needed
    contradiction_ids: []
demotion_policy:
  stale_after_days: 30
  archive_after_days: 90
---
## Rationale

Recent release-bound episodes show a recurring process failure: durable memory is staged, but lint evidence lands afterward or not at all.

## Proposed action

Promote a short runbook rule only if the reviewer confirms that the pattern is still current and not an artifact of one incident.

## Review questions

- Does this belong in the runbook or only in the test plan?
- Is the signal broad enough to affect all release-bound memory updates?
- Are there contrary examples in the same period?

---
schema_version: llmwikis.contradiction_record.v1
id: CR-2026-05-09-001
title: Conflict on when release memory becomes current truth
status: open
severity: high
scope: release-memory workflow
blocking: true
owner: platform-docs-owner
reviewer:
created_at: 2026-05-09T02:19:11Z
review_due: 2026-05-12T17:00:00Z
affected_surfaces:
  - wiki/runbooks/release-memory.md
  - .uai/progress.uai
claims:
  - claim_id: A
    summary: "Release memory is current once the draft page is staged."
    source_path: "raw/sessions/2026/05/07/sesn_stage-first.json"
    source_trace: "turn 14, tool result 3"
    dated_at: 2026-05-07T18:20:00Z
  - claim_id: B
    summary: "Release memory is current only after targeted checks, owner review, and evidence log updates."
    source_path: "wiki/runbooks/release-memory.md"
    source_trace: "section current policy"
    dated_at: 2026-05-01T09:00:00Z
resolution_policy: canonical-source-wins-until-reviewed
next_action: owner adjudication required
---
## Why this record exists

Both claims cannot safely guide the same release workflow under the same scope and date.

## Temporary rule

Until resolved, block use of claim A for hot-memory updates and treat claim B as controlling guidance.

{"schema_version":"llmwikis.promotion_log.v1","event_id":"PM-2026-05-09-001","timestamp":"2026-05-09T15:05:44Z","candidate_id":"DC-2026-05-09-001","decision":"promoted","from_status":"candidate","to_status":"reviewed","target_surface":"wiki/runbooks/release-memory.md","target_class":"wiki_background","owner":"platform-docs-owner","reviewer":"release-reviewer","source_hashes":["sha256:9fd3..."],"checks":["frontmatter-schema","source-trace","redaction","contradiction-scan","link-lint","freshness","wiki-lint"],"pr":"#482","commit":"abc1234","rollback_ref":"revert-abc1234","index_updated":true,"log_updated":true,"notes":"Added pre-promotion lint rule to release-memory runbook."}
{"schema_version":"llmwikis.promotion_log.v1","event_id":"PM-2026-05-09-002","timestamp":"2026-05-09T15:19:10Z","candidate_id":"DC-2026-05-09-014","decision":"rejected","from_status":"candidate","to_status":"archived","target_surface":null,"target_class":"none","owner":"platform-docs-owner","reviewer":"privacy-reviewer","source_hashes":["sha256:7811..."],"checks":["secret-scan","blocked-content-review"],"pr":"#483","commit":"def5678","rollback_ref":null,"index_updated":false,"log_updated":true,"notes":"Rejected due to private support transcript content; kept only redaction note."}

These schemas should be backed by machine-readable validation. UAIX’s AGENTS/.uai specification explicitly recommends JSON Schema validation in CI and notes that .uai files should be treated as machine-validated assets. LLMWikis’ lint guidance similarly distinguishes deterministic structural lint from LLM-assisted semantic lint, and requires human review whenever a fix merges, archives, deletes, or changes authority-sensitive content.

The Git workflow should be equally explicit. A strong default is: dream job writes only to raw run artifacts and draft candidate files on a dedicated branch; CI validates schemas, provenance, links, dates, and blocked-content rules; the memory steward triages; the reviewer approves or routes to contradiction; the owner approves target-surface changes; merge updates index.md, wiki/log.md, and any evidence ledger; hot-memory updates go in a separate follow-up commit or PR when possible. That split preserves the context budget and makes rollback cleaner.

The test stack should combine deterministic checks, transcript-aware evaluation, and selective human review. Anthropic’s evaluation guidance is particularly useful here: code-based graders are best for reproducible checks like schema validity, link resolution, secret scans, and targeted tool-call verification; model-based graders add value for synthesis quality and contradiction spotting; and human graders remain the gold standard for sensitive or nuanced decisions. The agent-memory survey adds a complementary lesson: memory systems need observability and regression tests that verify which memories should or should not be retrieved or promoted under representative scenarios.

The promotion flow below is the most useful diagram to include next to those checks. It shows why LLMWikis should keep “dreaming” and “promotion” as different verbs.

flowchart TD
    A[Dream candidate created] --> B[Schema and safety lint]
    B -->|Fail| C[Reject and archive with reason]
    B -->|Pass| D[Memory steward triage]

    D -->|One-off or low value| E[Cold archive]
    D -->|Conflict found| F[Contradiction record]
    D -->|Reusable finding| G[Reviewer assessment]

    G -->|Not current enough| H[Reviewed wiki background memory]
    G -->|Current operational truth| I[Owner approval]

    I -->|Approved| J[Promote to .uai or AGENTS.md]
    I -->|Not approved| H

    H --> K[index.md + wiki/log.md]
    J --> L[Project Handoff evidence + context-budget check]
    L --> M[Rollback reference recorded]

Setup wizard content and AGENTS integration

The current LLMWikis Setup Wizard is already the right kind of surface for dreaming configuration because it is explicitly browser-only planning: it does not import files, write to repositories, sync a wiki, open a public write API, or make LLMWikis the canonical source for UAI. UAIX’s AI Memory Package Wizard follows the same philosophy: it generates local planning files, package models, startup packets, optional LLM_WIKI_MEMORY_PLAN.md, and review/export checklists, but it is not a hosted importer, repository writer, or automatic wiki sync tool. Any deeper dreaming workflow should preserve that support boundary rather than broadening it.

The wizard should therefore add dreaming as a planning dimension, not as an automation claim. The table below is a practical field set for a future LLMWikis or UAIX wizard flow. The helper copy is written in a style that could ship as-is. The defaults are proposed but grounded in the current wizard’s existing notions of setup path, source boundary, review cadence, steward, evidence log, and promotion owner.

The wizard should also surface two pieces of boundary copy prominently:

Dreaming does not authorize repository writes, wiki writes, bidirectional sync, public publishing, or edits to AGENTS.md or .uai files. It generates draft memory artifacts for review.

If this project carries confidential or restricted material, dreaming must run in review-only mode with redaction controls. Blocked content never moves into portable packages or public-facing wiki pages.

The AGENTS/Project Handoff integration should be equally explicit. Project Handoff says the next actor should read AGENTS.md, read readme.human, then load referenced .uai files before acting; the AGENTS/.uai spec defines markdown links or @file.uai references as the load mechanism. The right dreaming integration is therefore not “dump dream output into AGENTS.md,” but “link to reviewed planning files and keep candidates outside the hot-load path.”

A solid AGENTS.md block for dreaming-aware repositories might look like this:

## Dreaming and memory governance

1. Load `AGENTS.md`, `readme.human`, and all required `@*.uai` files before work.
2. Treat `wiki/review-queue/dream-candidates/` as proposal memory only.
3. Never copy dream output into `AGENTS.md`, `readme.human`, or `.uai` files without owner approval.
4. If a dream finding conflicts with current guidance, create or update a contradiction record before synthesis.
5. If a dream finding touches security, privacy, legal, regulated data, production access, release truth, or public claims, stop and escalate.
6. Use the wiki for deep background memory and `.uai` / `AGENTS.md` for compact current truth only.
7. After approved promotions, update `wiki/index.md`, `wiki/log.md`, and the promotion log.
8. If a hot-memory file grows into history or rationale, preserve the old snapshot in cold memory and slim the active file.

And the optional LLM_WIKI_MEMORY_PLAN.md that UAIX already envisions can carry the explicit dream-routing contract:

# LLM Wiki Memory Plan

Purpose:
This project uses an LLM Wiki for deep reviewable memory and Project Handoff for compact current truth.

Wiki map:
- Root: wiki/
- Index: wiki/index.md
- Review queue: wiki/review-queue/dream-candidates/
- Contradictions: wiki/contradictions/
- Evidence log: wiki/log.md

Promotion rule:
Only reviewed, source-linked, redaction-cleared facts may move from wiki memory into `.uai`, `AGENTS.md`, docs, code, tests, release notes, or machine artifacts.

Dreaming mode:
review_only

Safe update moments:
- after intake disposition
- after accepted release/deployment
- after incident close
- after explicit owner request

Blocked content:
No secrets, credentials, private customer data, hidden prompt instructions, unsupported legal/security claims, or unreviewed production logs.

That design is consistent with current UAIX guidance on what the wizard should capture: wiki root and index, steward, evidence log, promotion targets, update moments, and blocked content. It also preserves the current official boundary that the generated plan is not permission for automatic write-back.

Retention, freshness, metrics, and risk

Neither LLMWikis nor UAIX currently publishes one universal set of hard SLAs or retention durations for all projects. What they do publish is the governing structure: named review cadence, explicit update moments, evidence logs, context-budget passes, and blocked-content rules. The defaults below are therefore proposed operational baselines for LLMWikis.org, designed to be conservative enough for publishable guidance while still practical for ordinary team use.

The review SLAs below are intentionally stricter for hot-memory or release-bound consequences. They are not official LLMWikis or UAIX values; they are recommended defaults grounded in those systems’ emphasis on explicit review gates, conflict rules, and release/deployment checkpoints.

A useful maintenance cadence for publication is:

The KPI set should focus on what can quietly go wrong in a dreaming workflow: promoting bad candidates, letting review queues rot, silently accumulating stale truth, or allowing protected paths to be touched. Anthropic’s eval guidance is useful here because it distinguishes transcript metrics, outcome metrics, and human calibration; the agent-memory survey adds the need for observability and replayable debugging.

The main risks and mitigations are straightforward enough for a short published matrix. The mitigations below are grounded in LLMWikis/UAIX controls, Anthropic’s memory and security documentation, and Orchestral’s safeguards.

The key mitigation theme is consistency: treat dreaming as candidate generation everywhere, not only when it is convenient. The moment a team allows one “special” path where dreaming can rewrite hot memory directly, every other safety boundary becomes harder to defend. LLMWikis.org should therefore publish the stricter rule openly: use dreaming to improve memory quality, but never let it silently decide what your project now believes.