memory

Prompt file imported from carlos17031691/base-ai (.github/prompts/memory.prompt.md). Copyright stays with the author.

AI Memory (Project Memory & Application Memory)

Apply structured memory at two levels:

1. Project memory for coding agents (.ai/memory.md)

Coding sessions are ephemeral. Use project memory so every agent (Antigravity, Claude, Cursor, Copilot, Codex) retains critical context across sessions:

• What to record:
  • Confirmed domain invariants, business rules and naming conventions.
  • Non-obvious service quirks, local setup gotchas and resolved incident root causes.
  • Active Epic/Story context and cross-service coordination notes ([PROJ-123]).
• What NEVER to record:
  • Secrets, API keys, tokens, credentials, internal private URLs or personal data (PII).
  • Durable architectural decisions — those belong in an immutable ADR (adr skill), not only in memory.
• Commands:
  • Record a note: base-ai memory add "<concise learning>" [--ticket PROJ-123] [--tag domain] [--service <name>]
  • List notes: base-ai memory list [--service <name>]
  • Search across memory, ADRs, RFCs and contracts: base-ai context search "<query>"

2. Memory architecture for AI applications & agents (src/<name>)

When building chatbots, copilots or autonomous agents inside a service, separate memory into clear tiers:

1. Short-term / working memory (session state):

   • Keep active conversation turns and tool execution state in a fast store (e.g. Redis or session table) keyed by tenant_id + user_id + session_id with an explicit TTL.
   • Control token growth with a sliding window + incremental rolling summary (summarize older turns asynchronously once context crosses a token threshold, keeping recent turns verbatim).

2. Long-term memory (cross-session):

   • Episodic memory: past interactions, decisions or events stored with timestamps and embedded for semantic + recency retrieval (rag skill).
   • Semantic / profile memory: structured facts and user/tenant preferences extracted into explicit key-value or relational records (updated idempotently, avoiding contradictory duplicates).
   • Procedural memory: versioned system prompts, few-shot examples and tool-use playbooks stored in code/config.

3. Security, privacy & hygiene (mandatory):

   • Strict tenant & user isolation: every memory read/write must filter by authenticated tenant_id and user_id at the database query level.
   • Memory poisoning defense: never allow untrusted external content (emails, web pages, shared docs) to write directly into long-term user/system instructions without validation.
   • Right to be forgotten & retention: provide an explicit deletion API (DELETE by user_id / session_id), enforce TTLs and redact PII/secrets before persisting memories.