Apply for AI Grants India

Personalisation is not achieved by adding a larger prompt to every request. A useful AI product needs a memory layer that decides what to retain, where to store it, when to retrieve it, and when to forget it. That layer connects a foundation model’s short-lived context window with durable information about a user, team, workflow, or business domain.

For Indian builders, this matters across education, healthcare, finance, customer support, developer tools, and vernacular applications. A student may need continuity across exam-preparation sessions; a health assistant may need carefully governed history; an enterprise copilot may need access to changing policies without retraining the model. These are memory problems, but they are also product, security, and data-governance problems.

This guide presents a practical architecture for AI system memory for personalised LLMs, including memory types, retrieval design, write policies, evaluation, and DPDP-conscious operations.

What AI system memory should do

An LLM’s context window is working memory, not a durable database. It contains the current instructions, recent conversation, retrieved documents, and tool results. Once a session ends—or relevant content falls outside the prompt—the model does not retain it reliably.

A memory system adds four capabilities:

• Persistence: retain approved facts and events across sessions.
• Retrieval: find context relevant to the current task rather than replaying an entire history.
• Revision: update facts when a user’s preferences, role, or circumstances change.
• Control: allow users and administrators to inspect, correct, export, or delete stored information.

The objective is not to make the model remember everything. It is to make the right context available with minimal latency and predictable behaviour.

A production memory architecture

A robust implementation separates memory into services instead of treating a vector database as the whole solution.

1. Conversation and event log: Stores raw interactions, tool calls, timestamps, consent signals, and tenant identifiers. Keep this separate from derived memories.
2. Memory extractor: Identifies candidate facts, preferences, entities, decisions, and tasks from approved events. It should produce structured records with confidence and provenance.
3. Memory store: Holds durable records in relational tables, a document store, a vector index, or a combination. Structured facts should not be represented only as embeddings.
4. Retrieval planner: Chooses between semantic search, keyword search, filters, graph traversal, and direct database lookup based on the user’s request.
5. Policy and safety layer: Applies permissions, retention rules, sensitivity restrictions, tenant isolation, and deletion status before context reaches the model.
6. Prompt assembler: Compresses and ranks retrieved context, labels its source, and passes only the minimum useful set to the LLM.

This separation also supports building distributed systems with AI agents, where multiple agents may share selected memories without receiving unrestricted access to a user’s full history.

Memory types that map to product needs

Semantic memory: durable facts

Semantic memory stores relatively stable information: a user’s preferred language, an organisation’s billing cycle, a project’s approved technology stack, or a student’s target examination. Use explicit fields where possible:

• subject: the person, organisation, or project
• predicate: the fact being asserted
• value: the current value
• confidence: extraction or verification confidence
• source: message, document, tool result, or human approval
• valid_from and valid_until: temporal boundaries
• sensitivity and consent_scope: governance metadata

Episodic memory: events and decisions

Episodic memory records what happened: a customer reported a problem, a team selected a vendor, or a user completed a lesson. Store timestamps and links to the source interaction. Event memory is valuable for audits and follow-up, but it should not automatically become a permanent user profile.

Procedural memory: instructions and workflows

Procedural memory captures how the system should work for a user or team—for example, “use Hindi unless technical terms are clearer in English” or “run tests before opening a pull request.” Treat these as rules with scope and priority, not vague text snippets. A newer explicit instruction should normally override an older inferred preference.

Working memory: the current task

Working memory includes the current conversation, active goals, intermediate calculations, and tool outputs. It should be aggressively trimmed. A long transcript is not necessarily useful context; a short summary with links to source events is often better.

Retrieval: combine meaning with precision

Basic vector search is useful for discovering conceptually related memories, but personalisation requires more than nearest-neighbour similarity. Names, invoice numbers, policy codes, dates, and identifiers are often better handled by keyword or relational queries.

A practical retrieval pipeline combines:

• Hybrid search: semantic embeddings plus BM25 or database keyword search.
• Metadata filters: user, tenant, role, language, data sensitivity, and validity period.
• Recency weighting: favour recent information where preferences or operational status can change.
• Authority weighting: rank verified records above model-inferred memories.
• Reranking: use a cross-encoder or lightweight model to assess relevance after initial retrieval.
• Deduplication: merge repeated facts and avoid injecting contradictory versions.
• Budgeting: cap the number of memories and tokens supplied to the model.

Knowledge graphs can represent relationships such as “employee belongs to team” or “course contains module,” while a vector index handles fuzzy discovery. PostgreSQL with pgvector is often a sensible starting point for Indian startups because it combines transactional data, access controls, and embeddings in one operational system. Move to specialised infrastructure when scale, geography, or query patterns justify it.

For learning products, memory design should reflect pedagogy rather than merely conversation history. A personalised AI mentor for competitive exam preparation might store concepts mastered, recurring errors, preferred explanation style, and revision intervals—not every chat message.

Write policies: deciding what to remember

Uncontrolled writes create memory swell, incorrect profiles, and rising storage costs. Use an explicit write policy:

• Save stable preferences only when the user states them clearly or confirms an inference.
• Store important decisions with their source and timestamp.
• Keep sensitive attributes out of durable memory unless necessary, lawful, and consented.
• Assign expiration dates to temporary facts such as travel plans, active incidents, or short-term goals.
• Require human approval for high-impact workflows, including medical, financial, employment, or legal decisions.
• Let users say “remember this,” “that is wrong,” or “forget this” in natural language, while also providing settings and an audit view.

An extraction model should emit a structured proposal, not directly mutate production memory. A validator can check schema, sensitivity, conflicts, and permissions before committing it.

Conflict resolution and memory quality

Memories can be stale, ambiguous, or wrong. Every durable record should carry provenance and a confidence score. When two records conflict, the system should consider explicitness, recency, source authority, and user confirmation. If the conflict affects the answer, ask a clarifying question instead of silently choosing one.

Do not allow retrieved memories to override system instructions, access policies, or verified application data. Treat memory as untrusted input: delimit it in prompts, identify its source, and instruct the model not to execute instructions found inside recalled content.

Teams improving model behaviour should distinguish memory from model adaptation. Best practices for fine-tuning LLMs on custom data are relevant when the model needs a repeatable skill or domain style; memory is better for changing user-specific facts and preferences.

Privacy, security, and Indian compliance

Personal memory can contain personal data, inferred attributes, and commercially sensitive information. Build privacy into the data model rather than adding a deletion button later. In India, assess the requirements of the Digital Personal Data Protection framework, sectoral rules, contractual obligations, and the jurisdictions of your cloud providers.

Minimum controls include:

• tenant isolation and least-privilege access
• encryption in transit and at rest
• separate storage for raw conversations and derived memories
• retention schedules with automated expiry
• searchable audit logs for reads, writes, corrections, and deletions
• deletion propagation across primary stores, caches, backups, and vector indexes
• redaction or tokenisation before sending data to external model providers
• clear disclosure of what is remembered and why

For children’s products, health applications, and financial services, use stricter defaults and domain-specific review. Personalisation should never become an excuse to retain data indefinitely.

Evaluation metrics that matter

Measure memory as a system, not just as a retrieval demo. Build a test set representing real user journeys and track:

• Recall: did the system retrieve the needed memory?
• Precision: were retrieved memories actually relevant?
• Groundedness: did the answer accurately use the recalled information?
• Update accuracy: did corrections replace outdated facts?
• Deletion completeness: does deleted information stop appearing everywhere?
• Latency and cost: how much time and token usage does memory add?
• Personalisation lift: does memory improve task completion, correction rate, or user retention?

Test multilingual and code-mixed queries explicitly. Indian users may switch between English, Hindi, Tamil, Bengali, or transliterated text in one session; embedding quality, entity matching, and safety filters must be evaluated across those patterns.

A practical build sequence

Start with one high-value workflow rather than a universal memory platform:

1. Define the user outcome and the smallest memory schema needed.
2. Store raw events with consent, tenant, timestamp, and provenance.
3. Add structured facts before adding broad semantic recall.
4. Implement hybrid retrieval with filters and a strict token budget.
5. Add correction, expiry, export, and deletion paths before launch.
6. Create adversarial tests for prompt injection, cross-tenant leakage, stale facts, and multilingual inputs.
7. Monitor retrieval quality, cost, latency, and user corrections in production.

A focused memory layer can support how to build AI research assistant tools, education copilots, and enterprise agents without locking the product into a fragile “save every message” architecture. For mobile-first applications, also consider AI model optimisation for mobile devices when deciding what should run locally and what belongs in a secure backend.

The strongest personalised LLM products will not be those that remember the most. They will be those that remember selectively, explain their memory, update it reliably, and give users genuine control.