UAIX Memory, Long Running Tasks, And Follow Goals

UAIX’s memory model is not a hosted memory database or a runtime scheduler. Its core design is a **portable, reviewable, file-based memory layer** centered on AGENTS.md, .uai/readme.human, and typed .uai records...

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-dfd355fb/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-13/long-running-goal-execution/Improvement/UAIX Memory, Long-Running Tasks, and Follow Goals.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-06-13T17:03:26.4048587Z
Content hash	sha256:dfd355fb2b5e55b61c1f9059f6e3f9c9d92800d0ed167433502ed40131ab8281
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-13-long-ru-dfd355fb2b5e.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-06-13-long-ru-dfd355fb2b5e.txt

Current File Content

Structure Preview

• UAIX Memory, Long-Running Tasks, and Follow Goals
• Executive summary
• What UAIX memory is today
• How Follow Goals and long-running work currently fit
• Where the current guidance is incomplete
• Recommended integrated guidance for UAIX
• Strategy comparison
• Templates and example hierarchies
• Parent-goal runtime export
• Subtask prompt
• Monitoring agent prompt
• Recovery after interruption
• Proposed additions to UAIX documentation
• Open questions and limitations

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 26572
• Preview characters: 11990

# UAIX Memory, Long-Running Tasks, and Follow Goals

## Executive summary

UAIX’s memory model is not a hosted memory database or a runtime scheduler. Its core design is a **portable, reviewable, file-based memory layer** centered on `AGENTS.md`, `.uai/readme.human`, and typed `.uai` records, while **agent runtimes execute elsewhere** and write back accepted results after the run. In UAIX’s own wording, Project Handoff is the durable, reviewable project-state bundle; runtime systems handle execution, tools, approvals, delegation, traces, and session state. citeturn11view2turn11view4turn13view5turn23view3

Within that model, UAIX currently treats **Follow Goals** as a **runtime-facing export**, not as the durable source of truth. The official guidance says to keep durable project memory in repo-local UAIX files and export a short Goal / Success Criteria / Constraints block only for runtimes that benefit from structured planning. The wizard makes this explicit: when a receiver uses `/goal` or Follow Goals, `.uai/exports/follow-goal.json` becomes configuration-specific, but UAIX files remain authoritative, and the feature is **not** described as a native UAIX long-running task system or official OpenAI adapter. citeturn7view0turn7view1turn29view2turn23view5

For long-running work, the strongest current UAIX building blocks are already present, but they are spread across several pages and schemas: compact hot memory and cold-memory separation; `short-term-memory.uai`, `progress.uai`, `current-state.uai`, `next-actions.uai`, and `decisions.uai`; the `uaix.next-recursive-prompt.v1` resume artifact for code-bearing scopes; and the UAI-1 packet family for `task-status`, `blocker`, `handoff`, `memory-proposal`, and `final-report`. What is still missing is a **single, explicit orchestration recipe** that ties those pieces together for extended, interruptible, multi-step work. citeturn30view3turn9view1turn9view4turn9view5turn9view6turn39view0turn13view0turn32search0

My overall conclusion is that the best way to add guidance to UAIX is **not** to invent a second memory system for long-running tasks. Instead, UAIX should document a canonical pattern where: the parent goal lives in Follow Goals plus authoritative `.uai` files; subtasks write checkpoints into `.uai` hot memory; runtime progress is emitted through `uai.agent.task-status.v1`; blockers use `uai.agent.blocker.v1`; ownership transfers use `uai.agent.handoff.v1`; accepted durable facts move through `uai.agent.memory-proposal.v1`; and the run closes with `uai.agent.final-report.v1` plus authoritative `.uai` write-back. That pattern fits UAIX’s current support boundary and avoids turning chat/session state into durable truth. citeturn14view0turn35view0turn38view0turn36view0turn37view0turn39view1

## What UAIX memory is today

UAIX defines AI memory as a **portable working packet** for continuity, handoffs, onboarding, audits, and agent-ready context, while deeper historical documentation belongs in LLM Wiki or other cold-memory layers. The system is intentionally designed to keep current operating truth compact rather than treating raw chat history, archived reports, or broad institutional knowledge as default startup context. citeturn8view5turn11view2turn30view3turn30view4

Practically, UAIX organizes this memory through typed `.uai` files with specific scopes and update triggers. The universal launch-baseline set includes `.uai/memory-maintenance.uai`, `.uai/identity.uai`, `.uai/world-context.uai`, `.uai/totem.uai`, `.uai/taboo.uai`, `.uai/talisman.uai`, and `.uai/short-term-memory.uai`. Project and handoff scopes then add records such as `.uai/context.uai`, `.uai/constraints.uai`, `.uai/progress.uai`, `.uai/operations.uai`, `.uai/current-state.uai`, `.uai/next-actions.uai`, `.uai/decisions.uai`, `.uai/owners.uai`, `.uai/agent-instructions.uai`, `.uai/risk-register.uai`, and `.uai/test-plan.uai`; code-bearing scopes also require `.uai/next-recursive-prompt.uai`. citeturn9view3turn9view0turn10view0turn10view1turn10view2turn10view3turn10view4turn10view5

The file guide is unusually useful because it doubles as a **write policy**. For example, `short-term-memory.uai` is for compact working state, newest decisions, active blockers, and next-read pointers; it is updated after meaningful work, handoff, deployment, intake processing, or context compaction. `progress.uai` changes after meaningful work segments, test passes, blocker resolution, or release-preparation steps. `current-state.uai` changes after each test run, deployment, blocker change, or other meaningful status change. `next-actions.uai` changes whenever priority or blocker state changes. `decisions.uai` changes when a durable decision is accepted, replaced, reversed, or proven stale. These triggers strongly imply a checkpoint model even though UAIX does not yet publish one consolidated “checkpoint cadence” page. citeturn9view0turn9view1turn9view4turn9view5turn9view6

UAIX also publishes a strict read order. The file guide says to start with `AGENTS.md` or `.uai/readme.human`, then `.uai/memory-maintenance.uai`, identity, world context, and the active instruction anchors (`totem`, `taboo`, `talisman`), then `short-term-memory.uai`, then profile-required files, and only after that consult long-memory pointers. This read order matters for long-running systems because it prioritizes current truth and boundaries over large background context. citeturn10view0

Security and mutation boundaries are part of the memory model itself. The `uaix.memory-maintenance.v1` schema and example say `.uai/taboo.uai`, `.uai/totem.uai`, and `.uai/talisman.uai` are protected when present, with `operator_explicit_only` access and an `agent_default` of `forbidden`; the validator must not scan them, and packages missing valid `memory-maintenance.uai` are non-compliant. That means long-running automation cannot safely treat all memory surfaces as equally mutable. citeturn18view0turn18view1

UAIX’s retention policy is qualitative rather than numeric. The context-budget guide repeatedly says hot files should remain compact and current, while long research, old chats, audits, and pre-slim snapshots should move to cold memory with source paths, checksums, summaries, and dated logs. I did **not** find a primary-source numeric token/KB/MB limit for UAIX memory files. The only explicit size-related limit I found was on the machine API surface, where oversized POST bodies can trigger problem+json errors; that is an API behavior, not a memory-file quota. citeturn30view3turn30view4turn30view5

## How Follow Goals and long-running work currently fit

UAIX’s official Follow Goals guide positions the feature as **runtime guidance, not the memory system**. The guide explicitly says to export a short Goal / Success Criteria / Constraints block for environments that support structured planning while keeping durable project memory in `AGENTS.md`, `.uai/readme.human`, and relevant `.uai` files. The runtime goal block should be derived from current handoff truth, not from old chats or broad archive material. citeturn7view0turn7view1turn23view3

The wizard reinforces the same boundary. In its receiver step, the “Alternative: Follow Goals” option is off by default, is described as an “OpenAI-compatible runtime goal export,” and produces `.uai/exports/follow-goal.json` only when selected. The page explicitly says this is not an official OpenAI adapter, hosted importer, SDK, CLI, certification surface, or native API goal field. The wizard also says it saves only a **local browser draft** and never uploads, imports, syncs, or writes to a repository. citeturn29view2turn29view0turn29view3

For long-running work more broadly, UAIX’s strongest formal mechanism is the **agent communication packet family**. The operating model says to acknowledge requests, execute work elsewhere, report evidence with task status, blockers, risks, screenshots and validation output, propose memory changes separately from task execution records, and then hand off, finalize, or correct. It also states that durable memory proposals must be separated from task execution, and that session tokens, write tokens, local error traces, private keys, credentials, and other secret-like values must not be promoted into durable memory. citeturn13view0turn14view0

The packet schemas are already expressive enough for asynchronous workflows. `uai.task.status.v1` carries generic task state such as `task_id`, `state`, `progress`, `status_message`, result references, and updated fields. The newer `uai.agent.task-status.v1` adds a clearer agent-operations shape with `percent_complete`, `current_action`, and `estimated_completion_utc`, plus correlation, idempotency, timeout, and fallback metadata. `uai.agent.blocker.v1` handles authorization, ambiguity, resource exhaustion, missing context, secret, destructive-action, and boundary conflicts. `uai.agent.handoff.v1` carries a target actor, context summary, handoff reason, exact next action, and delegated authorization reference. `uai.agent.memory-proposal.v1` enforces `task_execution_separation: "memory_proposal_only"`. `uai.agent.final-report.v1` preserves changed files, tests, skipped checks, blockers, risks, validation evidence, memory updates proposed, memory updates skipped, and an exact next action. citeturn15view1turn33view0turn35view0turn38view0turn34view0turn37view0

Capability profiles also matter. The `uai.client.workflow-agent.v1` schema and example explicitly model clients that can run long tasks, but the example sets `can_store_memory` to `false` and lists “Cannot store durable memory without a separate memory proposal” among known limits. That is a clean fit with UAIX’s philosophy: long-running execution is allowed, but durable memory updates are separate, reviewable acts. citeturn17view0turn17view1

## Where the current guidance is incomplete

The first gap is that UAIX documents the pieces of long-running work, but not a **single canonical flow** that joins Follow Goals, `.uai` checkpoints, agent task-status packets, blockers, handoffs, memory proposals, and final reports. The result is that implementers can see the parts, but not the recommended choreography. citeturn7view0turn13view0turn32search0

The second gap is that Follow Goals guidance is strongest at **run startup**, weaker in **mid-run continuity**. The guide explains how to derive a concise goal block from the handoff bundle, but it does not presently publish a standard for checkpoint frequency, partial-progress write-back, retry semantics, timeout handling, or interruption recovery for Follow Goals sessions. UAIX does publish those ideas across other records — especially through `progress.uai`, `current-state.uai`, `next-actions.uai`, `uai.agent.task-status.v1`, and `uai.agent.blocker.v1` — but not as one Follow Goals operating recipe. citeturn7view2turn9view1turn9view4turn9view5turn33view0turn35view0

The third gap is asymmetry between code and non-code scopes. Code-bearing packages have a formal resume artifact in `uaix.next-recursive-prompt.v1`, which clearly says it is derived hot memory, that authoritative `.uai` records win on conflict, that related active intake can supersede it, and that accepted work should regenerate it from authoritative records. I did not find an equivalent, formal, non-code resume artifact for broader long-running goals. citeturn39view0turn39view1

The fourth gap is around conflict resolution. UAIX publishes the building blocks — local policy wins, human instruction overrides, active intake can supersede stored next-loop plans, protected anchors are immutable without exact authorization, and startup packets name `memory_conflict_unresolved` as a no-op trigger — but it does not yet publish a single conflict-resolution ladder for long-running workflows. citeturn19view1turn18view1turn39view1

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: UAIX Memory, Long-Running Tasks, and Follow Goals; Executive summary; What UAIX memory is today; How Follow Goals and long-running work currently fit; Where the current guidance is incomplete; Recommended integrated guidance for UAIX; Strategy comparison; Templates and example hierarchies. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-1080 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAIX Memory, Long Running Tasks, And Follow Goals",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-dfd355fb/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-06-13/long-running-goal-execution/Improvement/UAIX Memory, Long-Running Tasks, and Follow Goals.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:dfd355fb2b5e55b61c1f9059f6e3f9c9d92800d0ed167433502ed40131ab8281",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-06-13T17:03:26.4048587Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-1080",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}