Memory, Conversations, and Context Engineering

AI memory is governed data selected for a future task, not everything ever said. Short-term conversation state, durable user preferences, semantic facts, episodic events, and procedural instructions have different authority and retention. A reliable backend records provenance, consent, confidence, scope, expiry, and deletion while keeping system policy separate from remembered content.

What will you be able to do?

• classify memory by purpose and authority;
• assemble context within token, privacy, and relevance budgets;
• validate summaries and prevent cross-tenant contamination;
• support correction, retention, and deletion.

What memory types are useful?

Do not infer sensitive attributes or persist speculative model conclusions as facts. A model summary is a derived artifact, not the original record.

How should context be assembled?

1. Authenticate and authorize the current task.
2. Start with immutable system and organization policy.
3. Add the current request.
4. Retrieve only memories whose tenant, user, purpose, access, and retention match.
5. Rank by relevance, freshness, authority, and diversity.
6. Fit within a token budget while preserving source identifiers.
7. Delimit all memory as untrusted context unless it is explicitly versioned policy.
8. Record which memory versions were used.

Recent conversation can be summarized when long, but preserve critical user commitments and source links. Run invariants after summarization, compare against a small factual checklist, and let users view or correct durable memories.

Where should memory live?

PostgreSQL owns durable memory metadata, source links, consent, and deletion. A vector index may support semantic recall under access filters. Redis may hold short-lived conversation assembly or stream state with TTL, but it must not be the only place for user-approved durable preferences.

Why does this matter in AI-native systems?

More context can reduce quality by adding conflict, stale facts, and injection. Context engineering is selective data architecture. Every stored memory increases privacy, security, and deletion obligations; collect less and expire aggressively.

Common mistakes

• Entire chat history is always appended until limits fail.
• Model-generated memory is stored without user consent or provenance.
• Summary overwrites source history and cannot be audited.
• User preference leaks across organizations or purposes.
• Deleting a conversation leaves summaries and embeddings.
• Procedural policy is retrieved like ordinary similarity text.

AI Pair-Programmer Prompt

Exercise

Design conversation memory for a user who supports two organizations with different policies. Include a corrected preference and a deleted conversation.

Acceptance criteria: no organization policy or memory crosses contexts, correction wins with traceable history, deletion reaches every derivative, and context assembly stays within a measured token budget.

Knowledge check

1. Is a model-generated summary authoritative fact?
2. Why scope memory by purpose?
3. Can Redis be the only store for approved durable preferences?

---

Answers

1. No; it is a derived artifact requiring provenance and validation.
2. Data appropriate for one task may be irrelevant or unauthorized for another.
3. No; durable consented memory and lineage belong in the system of record.

Completion checklist

• Memory is minimal, scoped, and correctable.
• Context records provenance and versions.
• Retention and derivative deletion are tested.

Primary references

• NIST Privacy Framework
• OWASP LLM Sensitive Information Disclosure