Modeling People as First-Class Entities in Agent Memory
Flat memory can't answer relational questions like 'how has my relationship with X been trending?'. The entity-layer design behind iRemember: alias resolution across languages, evolving profiles, sentiment timelines, and privacy by construction.
Ask a flat vector-memory assistant "how has my relationship with my co-founder been trending?" and watch it fail. The evidence exists — twenty scattered memories mention Karim, Karim M., "my cofounder," and "he" — but similarity search returns fragments, never a trend.
This is why iRemember models people as first-class entities. Every AI remembers you; almost none remember the people around you. That gap turned out to be where personalization actually lives.
The entity layer sits between chat and memory
Pipeline position matters. Entities resolve during extraction (from the LangGraph pipeline), not at query time:
candidate memory: "Karim apologized for missing the launch dinner"
-> entity_resolution: "Karim" == person:karim_m (alias match)
-> write memory(entity=karim_m, type=relationship, sentiment=-0.2)
-> update profile(karim_m): recent_events += apology; trend updated
Each person node carries: canonical name + aliases, relationship type, stable traits, ongoing commitments, and a sentiment timeline aggregated from relationship-type memories.
Alias resolution across languages
Real life is multilingual. The same person appears as "Youssef," "يوسف," "yoss," and "my cousin." Deterministic signals (shared phone, explicit "that's my cousin Youssef") merge confidently; ambiguous name matches get LLM judgment with a conservative default: when unsure, keep separate. A wrongly merged person corrupts every downstream answer; a split entity just loses some aggregation until corrected.
Relational queries become traversals
With the graph in place, "has my relationship with Karim improved since spring?" decomposes cleanly:
- Resolve karim_m
- Pull relationship-type memories in range
- Aggregate the sentiment timeline
- Answer with cited memories attached
No magic. The query engine stops being "hope the right chunks rank top-k" and becomes navigation over structure — the same insight driving ontology-guided RAG research in 2026.
Privacy by construction
Person profiles concentrate sensitive inferences about third parties who never consented to being remembered. Non-negotiables:
- Profiles are scoped per-user; nothing crosses accounts
- Sensitive inference categories are excluded at extraction, not filtered later
- Full export and deletion include derived profile data, not just raw memories
Trust is the product here. A memory system people can't trust with names is a memory system they won't give anything worth remembering.
What's next
The natural endpoint is temporal knowledge graphs over people — entities, relations, validity intervals — with retrieval routing between graph-first paths (relational questions) and dense-first paths (fact lookups), budget-aware. That router is what we're building toward next.
FAQ
Why does flat vector memory fail on people-related questions?
Evidence about one person scatters across dozens of memories under different names, pronouns and languages. Vector similarity retrieves some fragments but never consolidates them, so relational questions (trends, history, sentiment) become unanswerable.
How do you resolve the same person mentioned different ways?
Entity resolution combines deterministic signals (shared phone, explicit links) with LLM-judged merges on name variants, conservative by default — uncertain cases stay separate rather than risk wrong merges.
What are the privacy implications of modeling people?
Serious ones. Person profiles concentrate sensitive inferences about third parties who never consented. We scope profiles per user, exclude sensitive categories at extraction, keep everything exportable and deletable, and never surface one user's data to another.