LLM Wiki vs AI Memory

An LLM Wiki is a durable internal knowledge base. AI Memory, including local .uai packages when present, is a portable file-based context bundle for a task, project, handoff, onboarding flow, audit, or agent run. Mature organizations often use both: the wiki keeps cold depth, and AI Memory keeps hot working truth.

AI Memory / .uai should remain active when paired with an LLM Wiki. The LLM Wiki provides cold depth and reviewed durable knowledge; .uai provides the hot startup packet and continuity layer. The recommended pattern is not choose one, but use both with explicit boundaries.

OKF bundles can back durable wiki memory. Compact AI Memory and Project Handoff packets remain separate boundary artifacts that should link back to reviewed wiki pages instead of copying the whole durable knowledge graph.

Use case	LLM Wiki	AI Memory
Durability	Long-lived source of truth for an organization or domain.	Portable working context for a bounded job.
Ownership	Maintained by page owners, reviewers, and governance rules.	Prepared by a project owner or tool for a recipient or agent run.
Scope	Broad institutional knowledge and operating memory.	Selected context needed right now.
Context budget	Cold memory for research, old history, source summaries, and recovery evidence.	Hot memory for current constraints, accepted decisions, next work, and checks.
Project Handoff	The wiki may provide the durable source material.	Project Handoff is a specific AI Memory transfer packet.
Relationship	Can generate or link to AI Memory bundles.	Should link back to durable wiki pages when possible.

Recommended Split Memory Setup: Hot .uai + LLM Wiki/MATM Durable Memory

LLMWikis recommends a split-memory setup for serious agent projects. Keep hot .uai files active as the local short-term operational, startup continuity, and emergency reconnect layer. Use LLM Wikis, MATM, NeuralWikis, durable docs, databases, and searchable memory systems for medium/long-term searchable memory. The correct pattern is layering, not replacement: a successful durable-memory setup does not retire .uai; it reduces what must be stored in hot .uai while making .uai more useful as a pointer, current-state, and recovery layer.

Layer	Role	Boundary
Hot .uai / AI Memory	Local short-term continuity, startup packet, current truth, current constraints, operating rules, project identity, handoff instructions, active blockers, recovery posture, emergency reconnect context, and pointers.	Stays active and is read at startup when present, including when external memory is unavailable. Keep it compact and current-state oriented; do not date active .uai files as historical snapshots or let them accumulate long dated histories.
LLM Wiki	Durable reviewed pages, source-backed synthesis, history, research, decisions, citations, knowledge graph links, and larger context.	Feeds .uai summaries and pointers. It is medium/long-term memory, not the replacement for the startup layer.
MATM	Governed reusable agent experience: proposal-only Memory Events, curator/reviewer admission, scoped durable records, trajectories, repair evidence, observations, and procedural lessons.	Consumer agents retrieve reviewed memories with scope, source, status, citations, and abstention rules. MATM is not the same as hot .uai startup memory.
RAG/search	Retrieval mechanism over selected sources.	Search helps find background context; it does not replace current operating memory.
Archives	Historical evidence and recovery material.	Not active startup memory unless explicitly invoked in a recovery path.

Anti-Confusion Rules

• Do not retire .uai because an LLM Wiki exists.
• Do not call an active local memory layer a .uai retirement path unless the human explicitly requests removal or archival outside the active memory path.
• Do not stop consulting .uai because MATM search works.
• Do not move all active memory out of .uai.
• Do not date active .uai memory files or treat them as dated historical snapshots unless the dated file is an explicit archive outside the active .uai path.
• Do not assume external memory is always reachable; if external memory is down, use .uai for minimum viable continuity.
• Do not make .uai emergency-only after successful durable-memory readback.
• Do not use migration, cutover, or retirement language unless it clearly refers to stale facts, deprecated files, archived history, or a package intentionally decommissioned by a human.
• Successful LLM Wiki/MATM ingestion, search, readback, update, or archive tests prove the durable layer works; they do not prove .uai should be disabled.
• .uai should link to durable memory and summarize the current state; durable memory should hold the larger body.

Agent Preflight Checklist

• Is the .uai file still available as active local short-term memory?
• Does it contain emergency reconnect context?
• Does it avoid dates unless explicitly requested outside active memory?
• Are medium/long-term items being stored in MATM, NeuralWikis, or LLM Wikis?
• Is the agent avoiding language like retire .uai, replace .uai, or move all memory out of .uai?
• If external memory becomes unavailable, can the agent still recover the project basics from .uai?

Recommended Positioning

• Use LLM Wiki when the organization needs a shared, durable, searchable source of truth.
• Use AI Memory when a project, agent, contractor, team, or stakeholder needs a portable context packet.
• Use governed MATM when multiple agents should reuse prior agent-generated trajectories or observations through curated scoped records.
• Use both when durable knowledge needs to become working context for a specific task, handoff, onboarding flow, audit, or agent run.
• If a project already has .uai, keep it active as the short-term/local continuity layer and use durable memory to shorten and strengthen it, not replace it.
• Use workspace.uai when one editor workspace contains multiple sites or codebases, so the target site is resolved before any site-local .uai memory loads.
• Before a handoff bundle gets large, copy old detail into cold memory with a manifest and keep the active packet focused on current truth.

UAIX memory-plan alignment

When a project uses both a compact UAIX AI Memory package and a deeper LLM Wiki, keep the boundary explicit. The optional LLM_WIKI_MEMORY_PLAN.md tells the receiver where durable wiki memory lives, how it is promoted, and why background memory does not override current project truth. Durable memory should feed .uai summaries and pointers; it should not disable the hot startup layer.

Generated file	What it should capture	LLM Wiki mapping
UAI_MEMORY_SYSTEM_PROFILE.md	Collaboration model, source authority, testing, deployment, review, evidence, conflict, risk, and rollback policies.	Map these fields to wiki governance, source policy, review gates, and release evidence.
UAI_MEMORY_RECEIVER_BRIEF.md	First-read instructions, what not to assume, support boundaries, and targeted-check expectations.	Point to the smallest useful wiki pages and the current hot-context files.
UAI_MEMORY_STARTUP_PACKET.md	One bounded startup surface for the next human, team, or AI before broad work starts.	Keep it hot and compact; link back to durable wiki pages instead of copying the whole wiki.
LLM_WIKI_MEMORY_PLAN.md	Wiki root, index, log/evidence paths, steward, source boundary, promotion rules, and update timing.	Treat wiki memory as background until reviewed and promoted into accepted project truth.