AI Memory

/AI_Memory -> /en-us/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 source summaries, hashes, and dated logs. Promote only the reviewed current conclusion back into the AI Memory packet.

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, wiki plan required for LLM Wiki 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#

These supported starter bundles are presets over one canonical file-template registry. Shared files come from the same template IDs; bundle-specific guidance is added through metadata and overlays.

Configuration	Use when	Lifecycle and trust boundary	Download
Project AI Memory project-ai-memory	Use when a project is active and context must persist across many AI sessions without turning the bundle into a full knowledge base.	Lifecycle: Maintained continuously; current-state and next-action files change often, decisions and constraints change carefully. Trust: Internal or controlled collaboration by default. Review before sharing externally or giving to an autonomous agent.	uai-ai-memory-starter.zip
Project Handoff project-handoff	Use when the next actor must take over a project safely and needs current state, constraints, decisions, checks, and ownership context.	Lifecycle: Prepared before transfer, reviewed at acceptance, and updated when responsibility or support boundaries change. Trust: Can be internal or external, but external handoffs must be sanitized and approved before sharing.	uai-project-handoff-starter.zip
Agent Session Memory agent-session-memory	Use when an agent or tool needs to resume a task with enough state to continue without replaying a whole chat transcript.	Lifecycle: Created for a run or task, updated frequently, then merged into project memory or archived when the task closes. Trust: Often operational and sensitive. Keep permissions, tool access, blocked actions, and cleanup state explicit.	uai-agent-session-memory-starter.zip
Onboarding Memory onboarding-memory	Use when the first job is orientation rather than ownership transfer, incident review, or deep rationale capture.	Lifecycle: Reviewed before each onboarding cohort or external introduction; kept concise and introductory. Trust: Usually shareable after review, but remove internal strategy, customer data, credentials, and privileged operations.	uai-onboarding-memory-starter.zip
Decision Memory decision-memory	Use when rationale and tradeoffs matter more than current task status.	Lifecycle: Append-first and review-heavy; reversals should explain what changed rather than erase history. Trust: Contains internal strategy when the source bundle records it. Review before exposing externally or to agents with broad write permissions.	uai-decision-memory-starter.zip
Client or Vendor Handoff Memory external-handoff-memory	Use when a client, vendor, partner, or outside agent needs enough context to continue work without receiving internal-only memory.	Lifecycle: Prepared as an export, redacted, approved, shared, and archived with a dated changelog entry. Trust: Strict external boundary. Remove secrets, credentials, private customer data, legal strategy, internal pricing, and unsupported claims.	uai-external-handoff-memory-starter.zip
Incident or Audit Memory incident-audit-memory	Use when facts, timestamps, mitigations, owners, evidence links, and follow-up commitments need to travel together.	Lifecycle: Opened during review, updated as evidence is confirmed, closed with follow-up owners and a retained audit trail. Trust: Potentially sensitive. Sanitize customer data, security details, credentials, legal material, and private evidence before external sharing.	uai-incident-audit-memory-starter.zip
LLM Wiki Export Memory llm-wiki-export-memory	Use when a large internal wiki needs a small, reviewable, portable packet for a project, handoff, onboarding, or agent task.	Lifecycle: Generated from reviewed wiki material, checked against source citations, then promoted or discarded after use. Trust: Wiki material is background until reviewed. Cite sources, flag uncertainty, and redact private material before export.	uai-llm-wiki-export-memory-starter.zip
Office Assistant Memory office-assistant-memory	Use when an AI supports office administration without making the package primarily a software project handoff.	Lifecycle: Maintained continuously; updated when preferences, contacts, workflows, recurring tasks, boundaries, or authority change. Trust: Often private or internal. Minimize personal data, credentials, financial information, HR details, legal content, and private communications.	uai-office-assistant-memory-starter.zip
Executive Assistant Memory executive-assistant-memory	Use when priorities, people, meetings, decisions, and follow-through need durable assistant context.	Lifecycle: Continuously maintained with frequent updates to priorities, people, commitments, and communication rules. Trust: Highly sensitive. Requires strong redaction and authority boundaries before sharing.	uai-executive-assistant-memory-starter.zip
Personal Assistant Memory personal-assistant-memory	Use when privacy and freshness matter more than project history.	Lifecycle: Continuously maintained; privacy and freshness are more important than project history. Trust: Private by default. Avoid unnecessary sensitive personal data.	uai-personal-assistant-memory-starter.zip
AI Chatbot Friend Memory chatbot-friend-memory	Use when social memory and relationship boundaries are the central assistant context.	Lifecycle: Continuously maintained; relationship boundaries and consent rules are stable while interests and current-life context change over time. Trust: Private and consent-bound. Must include boundaries that prevent manipulation, dependency reinforcement, identity deception, unsupported professional authority claims, and unsupported memory claims.	uai-chatbot-friend-memory-starter.zip
Companion AI Memory companion-memory	Use when the package needs durable continuity without pretending the assistant is human or a replacement for professional help.	Lifecycle: Continuously maintained with frequent review of boundaries, crisis guidance, consent, and user preferences. Trust: Private, sensitive, and safety-bound. Keep support boundaries explicit.	uai-companion-memory-starter.zip
Tutor or Coach Memory tutor-coach-memory	Use when learning progress and coaching boundaries matter more than repository state.	Lifecycle: Updated after learning sessions, milestones, assessments, topic changes, or goal changes. Trust: Educational or coaching context. Avoid sensitive records unless explicitly reviewed and necessary.	uai-tutor-coach-memory-starter.zip
Creative Partner Memory creative-partner-memory	Use when style, canon, constraints, assets, audience, or creative direction need to travel together.	Lifecycle: Updated when style, canon, constraints, assets, audience, or creative direction changes. Trust: May contain private drafts, unreleased work, IP-sensitive ideas, brand strategy, or client material.	uai-creative-partner-memory-starter.zip
Household Assistant Memory household-assistant-memory	Use when home context, recurring routines, and privacy boundaries need durable assistant memory.	Lifecycle: Updated when routines, household members, constraints, vendors, schedules, or safety rules change. Trust: Private household memory. Minimize addresses, children data, health details, financial data, and access codes.	uai-household-assistant-memory-starter.zip
Customer or Front-Desk Assistant Memory customer-front-desk-memory	Use when public-facing or semi-public assistant memory needs public claims, source material, privacy, and escalation boundaries.	Lifecycle: Updated when public hours, services, policies, contacts, escalation paths, forms, scripts, or boundaries change. Trust: Public-facing or semi-public. Must not expose internal-only notes, customer private data, credentials, legal/security details, or unsupported claims.	uai-customer-front-desk-memory-starter.zip
General Non-Project AI Memory general-non-project-ai-memory	Use when no specific non-project assistant preset matches but the package still needs portable assistant memory.	Lifecycle: Maintained as the assistant role, user preferences, boundaries, recurring context, and active memory change. Trust: Determined by declared sensitivity and assistant role; private by default until reviewed.	uai-general-non-project-ai-memory-starter.zip

Views and presets over supported bundles#

• Team Memory: A lightweight shared team view over Project AI Memory plus owner and onboarding records. Model this as a view until UAIX has stronger role, permission, and multi-project guidance.
• Product Memory: A durable product or feature-area view over project state, roadmap, decisions, and constraints. Model this as a view because the underlying files are the same as Project AI Memory plus Decision Memory.

Deferred configurations#

• Certification Memory: Evidence packet for formal certification or endorsement workflows. Deferred because UAIX does not currently publish certification, endorsement, or hosted validation support.
• Regulated Data Memory: Memory that intentionally carries restricted personal, customer, legal, or compliance-sensitive material. Deferred until secure storage, redaction, access-control, and approval processes are outside the starter-bundle boundary.

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, LLM Wiki memory-plan file required for LLM Wiki configuration, readiness review, and canonical ZIP download.

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.

Starter Bundle Unavailable

The AI Memory bundle defines duplicate sample path ".uai/readme.human".

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 files current and keep durable files stable. .uai/current-state.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/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, LLM Wiki plan required for LLM Wiki 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.

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.