Memory / carry what matters across the break

State lives in a session — memory survives it. A `remember` step extracts preferences at session end and injects them at start. The system now knows returning users, but cannot reach outside the context window.

Architectural Position

Before

fn(query_user, prompt_rewrite, schema, state) → query_structured

search(query_structured) → context

fn(query_user, prompt_summarise, context, state) → response

After

(, prompt_rewrite, schema, , ) → query_structured

search(query_structured) →

(, prompt_summarise, , , ) →

(, , ) →

fn: The LLM call — rewrite, respond, and remember are all fn calls, each with their own prompt
query_user: The current user message
prompt_extract: The system prompt for extraction — instructs fn to identify durable preferences from the session transcript
state: The current session history
memory: Persistent user profile — written at session end, loaded at session start
context: Retrieved phone data plus the loaded user profile
response: A personalised response — informed by what the system knows about this user

Step by Step

# The failure from Layer 5

Session 1 (yesterday):
  User: "I want a phone for my elderly mother,
         budget ₹20k, prefer Indian brands"
  System: [recommends Moto G84]

Session 2 (today):
  User: "show me some options"
  System: "Here are some popular phones..."

# Session state was wiped
# System forgot everything

State covers the current session. When it ends, everything is gone. Returning users start blank.

1 / 5

Implementation

What you build

remember at session end: fn extracts durable preferences from the transcript into user_profile.json
Session start: user_profile.json loaded and injected into rewrite and respond as memory
UI: personalised from the first query in a returning session

What it fixes

System recognises returning users. Preferences persist across sessions. Recommendations improve over time.

Key Concepts

User profile: A structured store of facts extracted from past sessions — preferences, budget, personas. Persists across sessions in `user_profile.json`.
remember: The final fn call in the pipeline — fires at session end. Its job: extract durable preferences from the full transcript and write them to the user profile.
Memory extraction: Using an LLM to identify what from a conversation is worth persisting. Not everything a user says is a durable fact.
Memory decay: The policy for removing or down-weighting stale memories over time. Preferences change; old memories should not override new signals.

The Failure

The Forgetting Law
Models forget everything not in context. The question is what to keep.

Session 1: the user establishes they want a phone for elderly mother, budget ₹20,000, prefers Indian brands. Session 2 (the next day): "show me some options." The pipeline has no idea who this user is. It starts from scratch. The user has to re-explain context they already gave. In a traditional app, the database remembers. In an LLM pipeline without memory, every session is a first meeting.

What it reveals

The pipeline can read and write a user profile — but it is still sealed. Cannot check live stock, fetch current prices, or book anything.

Implication

Ability LLM can extract and summarise user preferences from conversation. The Forgetting Law applies — what isn't in context is gone.

Behaviour What gets remembered shapes all future behaviour. Memory extraction logic is a behaviour design commitment, not just engineering.

Code remember step added. Profile read/write logic. Session lifecycle management. Three fn calls per session.

Design Personalisation becomes visible to the user over time. The product appears to know them. That is a trust moment.

Economics remember = one additional fn call per session. Cost is bounded. Return on investment is higher engagement and conversion.