Memory and continuous accumulation

Back to development handbook · Shared flow · Record templates

The library has no out-of-the-box long-term memory database, user profile merging service, or automatic learner of business experience. Core provides execution contracts, Support helps assemble context and calls, and Kits such as Knowledge/Answering provide local processing once adopted. Whether to record, how to assign ownership, and when to update and delete are all explicitly implemented by the App; not recording is also a valid choice.

Different data needs different rules

Data	Recommended use	Should not be equated with
Recent Q&A	Session continuity, disambiguation	Tool execution logs, permanent knowledge
Accumulated user preferences	Addressing, expression preferences, ongoing topics	Identity, permissions, public facts
Business experience candidates	Inducing reusable suggestions and failure patterns from results	Proven rules, automatic authorization
Published knowledge	Business facts with explicit sources, scope, and versions	Unverified user self-descriptions
Original materials and extraction results	Current task evidence or authorized archives	Automatically shared knowledge

Do not use one source-less large summary to hold all categories. Each record category should at least have stable identity, ownership, source, version, status, and retention policy. Template fields are only a starting point; the App defines and validates them, and they are not a new Core protocol that all consumers must follow.

Application flow for updating user preferences

Select final Q&A allowed to be recorded, and the watermark
  → Old summary + new Q&A + explicit merge rules
  → Model extraction of candidates under budget constraints
  → Parsing and length/source/sensitive-scope checks
  → Commit summary and new watermark on the premise of the old version
  → Subsequent requests read by identity and mark it as low-trust memory

Do not mix the model's internal reasoning, corrections, or unexecuted actions into user profiles. When new expressions conflict with old preferences, apply the App's explicit rules; authoritative human facts are still provided by the corresponding data source. On model failure or version conflict, keep the old summary and the unconsumed watermark and retry with bounds, avoiding lost messages or duplicate merges. Scheduled tasks, storage transactions/CAS, leases, and retries are implemented by the App; the Core per-request budget cannot be assumed to cover background jobs.

Application flow for experience growth

Register extraction, validation, query, and publication implementations with a fixed task type; adding an experience record is only a data change and does not automatically add a handler. Candidates should be associated with actual sources and results, retain applicability scope, counterexamples, and conflicts, and not treat one success as a universal rule.

Candidate formation → deduplication/conflict checks → business validation or human confirmation → versioned publication → controlled reading, consistent with the shared flow. To integrate with Knowledge, the App converts permitted records into KnowledgeDocument, compiles a new catalog, and switches the request reference; active requests keep using the old snapshot.

prepare-source.mjs is used to organize text candidates during development. Runtime persistent learning can reuse its compilation logic and source constraints, while storage, concurrency, and publication policies are provided by the App.

Decisions required before runtime integration

Record scope and user choices, tenant isolation, visibility scope, retention and deletion, source priority, update conflicts, idempotency keys/consumption watermarks, failure recovery, and which content is forever candidate-only. Without these implementations, documentation and interfaces should state clearly "used for this round/session" or "manually maintained", and must not claim automatic learning.