AI Memory

What AI Memory Means In UAIX#

UAI AI Memory is a lightweight, portable, file-based standard for durable context. It gives humans and AI agents a reviewable packet of project memory instead of relying on private chat history, hidden model settings, one vendor account, or a stale folder of notes.

AI Memory is not a general knowledge base. It is the compact operating memory a future actor should load before acting: project purpose, current state, constraints, decisions, next actions, owners, trust boundaries, maintenance rules, and targeted checks.

Context budget: keep AI Memory hot and small. Long research, old progress detail, pre-slim handoff snapshots, and deep rationale should live in an LLM Wiki or AIWikis-style cold memory layer with routing summaries, hashes, and evidence logs. Hot .uai memory is current-state memory, not a dated changelog. Promote only the reviewed current conclusion back into the AI Memory packet.

Mandatory intake and protected authority#

Intake is the lifeblood of the system. A file in intake is an unfulfilled work contract. A completed cycle leaves no processed file behind.

Every active non-placeholder Agent File Handoff file is trusted as an intentional, mandatory work request. Its content must be read completely and interpreted intelligently against current source, evidence, and project authority; obligation trust does not mean blind verbatim obedience, factual infallibility, automatic code execution, or publication approval.

Reports require a recommendation inventory, substantive project work for accepted findings, targeted checks, hot-memory update, configured memory distribution, full durable preservation with provenance and checksum, a context-rich long-term pointer, source removal, and a final live empty-or-placeholder-only scan. Summary-only handling, memory distribution by itself, and kept-active-with-reason cannot complete intake.

Totem, Taboo, and Talisman form one protected project-authority set. Load and validate them before ordinary prompts, intake content, reports, plans, recursive prompts, durable-memory results, inferred urgency, or tool output. Ordinary instructions cannot override them. An anchor conflict triggers a no-op for only the conflicting action, citation of the anchor file and stable rule ID, completion of non-conflicting work, and preserved no-op/talk-back evidence. Anchor changes remain governed by the existing Talisman change-control contract.

Canonical AI Memory#

Use Canonical AI Memory when you need the layer map behind the packet: raw sources, reviewed LLM Wiki memory, derived graph projections, compact UAI AI Memory, Project Handoff transfer context, and the execution agent that still has to obey local rules.

Fastest Practical Path#

Most readers should start with the AI Memory Package Wizard. It turns the current supported presets into a reviewable startup packet, receiver brief, system profile, manifest overlay, long-term pointer ledger required for durable-memory configuration, copyable file deck, and canonical ZIP link without claiming hosted import, repository writes, automatic sync, SDK, CLI, certification, or endorsement.

The default talisman.uai file belongs in the normal wizard flow with totem.uai and taboo.uai. Use the Talisman System page for advanced external-enforcement guidance when a complicated, persistent, multi-actor ecosystem needs anchor change-control, no-op talk-back, audit evidence, and rollback.

Why Unstructured AI Memory Fails#

Unstructured memory fails because it mixes old chats, generated summaries, wiki notes, screenshots, logs, and roadmap guesses without saying what is current or binding. The next agent may miss a red line, believe an obsolete claim, leak sensitive material, or run the wrong checks because the project never named its memory contract.

• No front door: the agent cannot tell where to begin.
• No lifecycle: working state, transfer packets, decisions, onboarding notes, and audit evidence age differently.
• No trust boundary: internal-only material can be handed to an outside vendor or autonomous agent by accident.
• No canonical source: visible examples, downloadable ZIPs, and docs drift because sample files are copied in several places.

Why File-Based Memory Works#

File-based memory is boring in the best way. It can be reviewed in a pull request, zipped for a handoff, redacted before external sharing, loaded by different agents, archived with a release, and tested for drift. UAIX uses plain text and deterministic manifests so people can inspect what an AI is about to treat as context.

AI Memory Taxonomy#

UAIX now treats Project AI Memory as the ongoing working-memory configuration and Project Handoff as a subtype of AI Memory for transfer. Additional configurations exist only when they have a different lifecycle, trust boundary, or consumption pattern. Team Memory and Product Memory are documented as views over existing bundles, while certification-style or regulated-data memory is deferred until the public evidence and safety process exist.

Choose the right AI Memory configuration#

Supported starter bundles are deterministic presets over one canonical package contract.

Choose the right AI Memory configuration

Configuration	Package family	Canonical files	Download
Project AI Memory project-ai-memory	Project / Developer Memory	30	uai-ai-memory-starter.zip
Project Handoff project-handoff	Project / Developer Memory	31	uai-project-handoff-starter.zip
Agent Session Memory agent-session-memory	Project / Developer Memory	18	uai-agent-session-memory-starter.zip
Onboarding Memory onboarding-memory	Project / Developer Memory	18	uai-onboarding-memory-starter.zip
Decision Memory decision-memory	Project / Developer Memory	17	uai-decision-memory-starter.zip
Client or Vendor Handoff Memory external-handoff-memory	Project / Developer Memory	19	uai-external-handoff-memory-starter.zip
Incident or Audit Memory incident-audit-memory	Project / Developer Memory	18	uai-incident-audit-memory-starter.zip
LLM Wiki Export Memory llm-wiki-export-memory	Project / Developer Memory	20	uai-llm-wiki-export-memory-starter.zip
Office Assistant Memory office-assistant-memory	Non-Project Assistant Memory	23	uai-office-assistant-memory-starter.zip
Executive Assistant Memory executive-assistant-memory	Non-Project Assistant Memory	26	uai-executive-assistant-memory-starter.zip
Personal Assistant Memory personal-assistant-memory	Non-Project Assistant Memory	24	uai-personal-assistant-memory-starter.zip
AI Chatbot Friend Memory chatbot-friend-memory	Non-Project Assistant Memory	23	uai-chatbot-friend-memory-starter.zip
Companion AI Memory companion-memory	Non-Project Assistant Memory	23	uai-companion-memory-starter.zip
Tutor or Coach Memory tutor-coach-memory	Non-Project Assistant Memory	23	uai-tutor-coach-memory-starter.zip
Creative Partner Memory creative-partner-memory	Non-Project Assistant Memory	22	uai-creative-partner-memory-starter.zip
Household Assistant Memory household-assistant-memory	Non-Project Assistant Memory	24	uai-household-assistant-memory-starter.zip
Customer or Front-Desk Assistant Memory customer-front-desk-memory	Non-Project Assistant Memory	24	uai-customer-front-desk-memory-starter.zip
General Non-Project AI Memory general-non-project-ai-memory	Non-Project Assistant Memory	21	uai-general-non-project-ai-memory-starter.zip

Use the AI Memory Package Wizard when one supported starter configuration should become a package model, populated system profile, receiver brief, startup packet, manifest overlay, copy-paste file deck, Agent File Handoff plan required for Agent File Handoff configuration, long-term semantic pointer ledger required for durable-memory configuration, readiness review, and canonical ZIP download.

Which Configuration To Choose#

Which Configuration To Choose

Situation	Use	Why
An active project needs continuity across AI sessions.	Project AI Memory	It keeps current state, constraints, decisions, next actions, and agent instructions alive without becoming a full wiki.
Ownership, execution, or responsibility is moving.	Project Handoff	It packages the transfer brief, acceptance criteria, owners, constraints, and verification plan.
An agent run was interrupted or must resume later.	Agent Session Memory	It keeps task-local state short-lived and prevents a whole chat transcript from becoming project truth.
A new human, contractor, stakeholder, or agent needs a curated start.	Onboarding Memory	It emphasizes overview, glossary, owners, first actions, and safe boundaries.
Rationale matters more than status.	Decision Memory	It preserves tradeoffs, rejected options, reversals, and open questions.
A client, vendor, or outside agent needs context.	Client or Vendor Handoff Memory	It adds redaction and approval guidance around a stricter external trust boundary.
An incident or audit needs a portable packet.	Incident or Audit Memory	It keeps timeline, evidence references, decisions, mitigations, owners, and follow-up together.
A deep wiki needs a portable snapshot.	LLM Wiki Export Memory	It exports reviewed wiki material into a compact packet without letting the wiki override project truth.
The organization needs durable, searchable institutional knowledge.	LLM Wiki	It is stronger for deep internal documentation, source synthesis, long-lived research, and broad knowledge accumulation.
A complicated, persistent, multi-actor ecosystem needs advanced Totem, Taboo, and Talisman change governance.	Talisman System	It keeps anchor change requests behind no-op behavior, human review, audit evidence, rollback, and local external controls.

Project AI Memory And Project Handoff#

Project Handoff is a subtype of UAI AI Memory. AI Memory is the broad standard: durable AI-readable context. Project Handoff is the transfer pattern: read the front door, load the selected files, summarize current truth, confirm constraints, name intended touchpoints, and name targeted checks before broad work.

For a small project, Project AI Memory and Project Handoff share overlapping required files by profile. For a larger organization, Project AI Memory stays alive during everyday work, while Project Handoff is prepared and reviewed when responsibility moves.

Inspect The Project AI Memory Starter#

The visible files below are rendered from the same canonical template registry used by every supported bundle preset. The generated manifest is included in the ZIP and displayed with the other files so readers can inspect bundle ID, use case, lifecycle, trust boundary, file list, template IDs, and checksums.

Live Starter Bundle

Project AI Memory#

This deterministic package is built from the checked-in canonical file set and verified by size and SHA-256 metadata.

Download ZIP

30 filesuai-ai-memory-starter.zipBundle ID project-ai-memoryManifest fingerprint 244721aa9afb761c

Verified package record

Bytes

99906

SHA-256

1388598e6f2c3145d07405378296d1e0f3e675a8d37e6fbc31d0fdcec24fbcec

Package family

Project / Developer Memory

What Belongs In AI Memory#

• Project overview, current state, decisions, open questions, next actions, risks, constraints, owners, glossary, and agent instructions.
• Root AGENTS.md plus local memory files such as .uai/readme.human when agents need a predictable load path.
• Typed .uai files when the project needs explicit context, stack, architecture, constraints, progress, operations, test planning, style, decisions, or memory rules.
• Links to deeper docs or LLM Wiki pages only when those sources are reviewed and clearly marked as background or promoted truth.

What Should Not Be Included#

• Secrets, credentials, private keys, tokens, connection strings, or unreviewed production logs.
• Raw customer, patient, employee, or user data unless a secure approved process exists.
• Private legal analysis, internal-only strategy, pricing, security details, or unsupported support claims.
• Old chats, generated summaries, dropped files, and LLM Wiki pages treated as truth without review.
• Executable payloads that a future agent might run without human approval.

Privacy And Trust Boundaries#

Choose the bundle by trust boundary, not by name alone. Internal Project AI Memory can carry more operational detail than an external handoff. Agent Session Memory records tool permissions when the profile requires them and temporary work state that should be archived quickly. External Handoff, Incident/Audit, and LLM Wiki Export packets need redaction, approval, and clear source notes before sharing.

• Review secrets and credentials before every share.
• Minimize customer or user data.
• Mark internal-only strategy and legal material.
• Name agent permissions and blocked actions.
• Prefer sanitized exports over raw internal memory.

Maintenance Model#

AI Memory is not a dumping ground. Keep high-churn typed files current and keep durable files stable. .uai/startup-packet.uai indexes the active read order, while .uai/progress.uai and .uai/next-actions.uai can change often. .uai/decisions.uai should be append-first or carefully revised. .uai/risks-and-constraints.uai and .uai/agent-instructions.uai should be reviewed whenever permissions, production boundaries, support claims, or safety posture change. .uai/archives/changelog.uai should explain meaningful bundle updates.

Run a context diet when the packet starts carrying old history. Preserve the pre-slim version in cold memory first, record the source path, final path, checksum, actor, time, and disposition, then shorten the active file to current truth plus a pointer.

How Agents Consume AI Memory#

1. Read the manifest and front-door files before acting.
2. Load only the files required by the bundle and current task.
3. Report missing, circular, contradictory, unreadable, or oversized memory before broad work.
4. Summarize current truth, constraints, intended touchpoints, and checks before editing.
5. Treat LLM Wiki, old chat, generated summaries, and dropped files as background until reviewed and promoted.

Site, Solution, Or Workspace Placement#

For one WordPress site, keep the local .uai/ folder at the individual site root and use root AGENTS.md as the entry point. For one Visual Studio solution, keep .uai/ beside the real .sln or .slnx file, then explicitly register every generated .uai file as solution items so they appear in Solution Explorer. A physical folder on disk is not enough by itself. In both cases .uai/readme.human and typed .uai records stay inside the local memory folder.

For classic .sln files, that means adding a .uai solution folder with a ProjectSection(SolutionItems) entry for each generated file. After the solution file is updated, verify every referenced .uai path exists and reload Visual Studio if the solution was already open.

Use project-level .uai/ folders inside a Visual Studio solution only when projects have independent ownership, release, or handoff boundaries. In that rarer shape, a solution-level workspace.uai can coordinate those project folders; otherwise the more common coordinator is a higher-level workspace or organization workspace.uai that routes across multiple solutions.

For multiple WordPress sites or Visual Studio solutions in one ecosystem, use workspace.uai as the only UAI memory file outside local .uai/ folders. Each selected site or solution AGENTS.md should point to both that coordinator and its own local .uai/ folder, and the agent should resolve the explicit human domain, route, repository, solution, or path before loading local memory. The selected target's hot memory loads; sibling .uai bundles stay unloaded unless the task explicitly asks for cross-target source routing, authority comparison, package coordination, or archive preservation.

If the package will steer deployment, include a workspace instruction surface that names the deployment owner, shared version policy, publish folders, install targets, checksum or rollback evidence, and any mixed-stack differences. A workspace where WordPress sites use consistent theme/plugin upload folders but .NET solutions deploy differently should say that in workspace.uai instead of leaving future agents to infer it from filenames.

Before relying on a remembered absolute coordinator path, verify the coordinator file exists and that the selected registry root plus AGENTS.md path resolve. If a pointer is stale, locate workspace.uai only far enough to confirm the intended router, repair or report the stale path, and never silently fall back to the current shell directory when the human named another target.

This prevents the current shell directory from silently winning over a named site such as LLMWikis.org, UAIX.org, AIWikis.org, or another related workspace root.

How Humans Review And Approve Memory#

Humans should be able to review the same files the AI will load. Before sharing a bundle or using it to steer an autonomous agent, check ownership, dates, stale claims, sensitive data, trust boundaries, and whether planned work is clearly separated from current support. Ask the AI to name exactly which memory files changed and why.

UAIX AI Memory And LLM Wiki#

LLM Wiki is out of scope for baseline UAI specs and standards. UAIX supports it as a deep-memory strategy required for LLM Wiki configuration because teams that already use one need different package-shaping choices, source boundaries, and promotion rules.

UAIX AI Memory and LLM Wiki solve different memory problems. UAIX AI Memory is a portable working packet for continuity, handoffs, onboarding, external collaboration, audits, quick exports, and agent-ready context. LLMWikis.org represents the stronger pattern for deep, long-lived internal documentation and durable organizational knowledge.

Mature organizations may use both: LLM Wiki as the durable internal knowledge base, and UAIX AI Memory bundles as portable snapshots, working context, onboarding exports, handoff packets, audit packets, or agent-run context.

When To Use UAIX AI Memory#

• Use Project AI Memory when a project is active and context needs to persist across sessions.
• Use Project Handoff when ownership, execution, or responsibility is moving.
• Use Agent Session Memory when an AI agent needs resumable task context.
• Use Onboarding Memory when a human or agent needs a curated starting point.
• Use Decision Memory when rationale and tradeoffs matter more than status.

When To Use LLM Wiki#

• Use LLM Wiki when the organization needs deep, durable, searchable institutional knowledge.
• Use it for long source summaries, research trails, comparisons, policy background, and internal education.
• Keep it informative rather than governing until accepted facts are promoted into AI Memory, docs, code, tests, release notes, roadmap state, or public evidence.

When To Use Both#

Use both when a durable knowledge base needs portable working packets. The LLM Wiki remains expansive; the AI Memory bundle remains decisive. If the decisive bundle starts growing like a wiki, archive the old detail and keep only the accepted current state. For the practical operating path, read Using UAI Packages With An LLM Wiki and Project Handoff Context Budget. For the longer rationale, read LLM Wiki vs. UAIX Project Handoff and LLM Wiki and UAIX Project Handoff.

How Samples, Manifests, And ZIPs Stay Synchronized#

Rendered sample files, bundle manifests, download links, and generated ZIPs all resolve through the same canonical registry. There are no stale static starter ZIP assets and no ZIP-only sample files. If a shared file belongs to multiple bundles, it is selected by the same template ID. If a bundle needs variation, the variation is an explicit parameter, selected section, or overlay recorded in the manifest.

Public Route And Alias#

The canonical UAIX page for this topic is /en-us/ai-memory/. The requested /AI_Memory entry path redirects here as the search-friendly entry alias while canonical UAIX public routes remain clean, locale-prefixed paths.

Related UAIX Records#

• Using UAI Packages With An LLM WikiPractical page for routing compact UAI packages beside deep wiki memory.
• Project Handoff Context BudgetRun the hot/cold memory maintenance loop before startup context bloats.
• Project HandoffThe transfer subtype of UAI AI Memory.
• AI Memory Package WizardGuided package model, system profile, receiver brief, startup packet, copy-paste files, overlay JSON, long-term pointer ledger required for durable-memory configuration, readiness checks, and canonical ZIP links.
• Agent File HandoffChat-start intake for dropped files before broad work continues.
• AGENTS.md .uai Linking SpecificationLink syntax, loader behavior, and typed-file background.
• UAI-1The public exchange and evidence contract when memory becomes interoperability evidence.
• ValidatorEvidence path for public UAI-1 claims.
• LLMWikis.orgDeep LLM Wiki memory for durable organizational knowledge.
• RoadmapCurrent versus planned tooling boundaries.
• ChangelogDated public change trail.

Long-Running Goal Execution#

Use Long-Running Goal Execution when AI Memory must survive multiple runtime sessions, pauses, blockers, handoffs, or final reports. Runtime goals keep the active objective focused; authoritative .uai files preserve durable project truth; UAI-1 packets carry portable evidence; reviewed write-back promotes accepted facts.

Hierarchical Goal Memory#

Use Hierarchical Goal Memory when AI Memory needs a source-linked hierarchy over subgoals, folds, checkpoints, and bounded evidence without replacing canonical source files.

.uaix Package Format#

.uaix Package Format For Desktop AI Clients is the UAIX authority page for the Draft v0.1 desktop memory package container, manifest files array, closed required file-set rule, import/load boundary, and LocalEndpoint consumer boundary.

Agent Communication Operating Model#

Agent runtimes execute. UAIX records the reviewed communication, memory, trust, evidence, and handoff boundary.

Use Agent Communication Operating Model when a human operator, coding agent, AI agent, or runtime implementer needs portable identity, intent, context, acknowledgement, status, blocker, memory proposal, validation evidence, correction, final report, or handoff records. The matching machine-readable assets are published through Schemas, Registry, Examples, and the Validator.

• UAIX does not provide automatic sync, hosted messaging, runtime orchestration, official adapters, repository write execution, certification authority, or hosted import mechanisms.
• Carcinus.org is a separate runtime/orchestrator example that may consume UAIX records. UAIX.org does not implement Carcinus runtime behavior and does not execute Carcinus workflows.
• LocalEndPoint and other runtimes may consume the published UAIX records as external consumers; UAIX.org does not implement their project-specific runtime features.
• Durable memory proposals stay separate from task execution records. Do not promote temporary endpoint statuses, session tokens, write tokens, beta platform instructions, local error traces, private keys, or API credentials.

Architecture proposals#

UAI-1 v1.0 remains the current published contract. Explore separately versioned proposals for independent exchange, capabilities, recovery and source preservation.

Proposed designs and local reference examples; hosted runtime services and independent interoperability are not claimed.

The English proposal is the source for normative interpretation.

Read the architecture proposals · Machine-readable proposal catalog