AI Grief Companion: Chat History Ingestion, LoRA Persona Training & RAG Memory

Client Request

A US grief-tech startup asked for something a general chatbot cannot do: let someone who has lost a parent, a partner or a child keep talking to them, in the voice that person actually had. You bring what you already own - WhatsApp threads, an iPhone backup, Facebook and Instagram exports, Discord logs, a letter you typed out - and about twenty minutes later there is a private chat that answers the way they did. We built the whole thing: web and mobile apps, the ingestion layer that reads eight kinds of chat history, and the AI platform that turns those messages into a personality profile, a graph of facts and a fine-tuned adapter of one specific person.

Problem Solution

Web client in React and Vite, iOS and Android in React Native, a Node and Express API on PostgreSQL for accounts, subscriptions and message storage, and a two-tier AI stack behind it. A Python gateway parses ten chat-export formats into one normalised message table, works out which participant is the person being remembered, and encrypts every message at ingest with per-message AES-256-GCM under a KMS envelope key. Above it an ML platform runs the pipeline as a chain of contracts - personality profile, ten hard facts, dataset build, LoRA SFT and LoRA CPT on Qwen2.5-7B with 4-bit QLoRA, RAG preparation and a fact graph in Neo4j - with vLLM loading the right adapter at request time. Two companions fill the gaps the browser cannot reach: an Electron app that lifts iMessage out of an iPhone backup, and a Chrome extension that exports Discord history.

Final Result

The result is a product where the hard part is invisible. A user uploads a file and waits about twenty minutes; underneath, seven contract types run across CPU and GPU workers, an adapter lands in S3, a graph of facts lands in Neo4j, and the chat picks up whichever stage is ready - base model, personality only, LoRA SFT, or LoRA CPT - so a conversation is always possible even when training is not finished. The same platform carries the parts a grief product cannot avoid: encryption at ingest, one-click deletion of everything, US-state billing rules checked on every payment, and prompts that live in the database with a version history so the tone can be tuned without a release.

Project overview

The founder came with a clear line he did not want to cross. This is not a deepfake and not a voice clone - no synthesised audio, no video, nothing that pretends to be a living person. It is a text companion built on the words that person actually wrote to you, and the framing throughout is the grief-research idea of continuing bonds rather than closure. Every product decision followed from that: the app never says goodbye for you, it prompts toward professional help when the conversation needs it, and deleting an epitaph deletes the data behind it.

The first hard problem is getting the material in. People do not have a tidy dataset of a dead relative; they have a WhatsApp export, a phone backup they never opened, an Instagram archive and a folder of letters. We wrote parsers for ten formats behind eight buttons - WhatsApp exports and live sync, Facebook Messenger, Instagram DMs, Discord, iMessage from an iPhone backup, Android SMS, pasted text and a plain .txt - and normalised all of them into one message table. Then the harder half: working out which of the two participants is the person being remembered. A role detector reads the export's own identifiers, the account the user connected and the shape of the dialogue; when it still cannot tell, it stops and asks rather than guessing, because getting this wrong trains the model on the wrong person. Photos are read too - a vision model writes a short description of what each picture was, so the persona can react to a photo the way someone who was there would.

Training is a chain of contracts, not a script. A Control Plane holds a runs table as the single source of truth, and each stage is a typed contract that produces artifacts for the next: a personality profile written in the first person from the thread, exactly ten short factual statements, a dataset built into JSONL on S3, a LoRA SFT adapter on Qwen2.5-7B with 4-bit QLoRA, then a LoRA CPT pass that scores loss only on the remembered person's own lines, then RAG preparation and a fact graph in Neo4j. Celery workers pick the stages up - ETL on CPU, training on GPU - and completion travels back by callback through the gateway to the API and out to the browser over a websocket. Our own GPU server does the work, with RunPod serverless images for training, CPT, inference and photo recognition when it runs out of capacity.

Inference degrades on purpose. There are four stages - base model only, base plus personality profile, LoRA SFT, LoRA CPT - and the system resolves the best one available for that person on every request, so a chat is possible minutes after upload and gets closer to them as the pipeline finishes. vLLM loads the adapter at runtime rather than restarting on a new model, and CPT takes priority over SFT: one adapter per request, never both. Memory comes from three retrieval layers over Neo4j - a Cypher shortcut across a closed vocabulary of nine fact predicates, a rare-term substring fallback, and a vector search over context-rich windows - competing for five slots in the prompt.

Around the model sits an ordinary product that still had to be built: registration and transactional email, Stripe and Apple in-app purchases with A/B price groups, a billing-address check against a per-state allow list that is read fresh on every payment, an admin panel for prompts, users, training runs and token spend, and iOS and Android builds submitted to both stores. Plus the two companions - an Electron app shipped as Mac (Apple Silicon and Intel) and Windows builds from the site's own download page, and a Chrome extension for Discord - because iMessage and Discord history simply cannot be reached from a web app.

Client: A US grief-tech startup (B2C subscription)
Industry: Grief technology, digital legacy, consumer AI
Scope: Full product - web, iOS, Android, backend, AI platform, desktop and browser companions, admin panel, payments, store submissions
Front end: React 18, Vite, TypeScript, Tailwind; React Native 0.80 for iOS and Android
Back end: Node.js 22, Express, Drizzle, PostgreSQL, Stripe, Apple IAP, AWS KMS and S3
AI platform: Python, FastAPI, Celery, PostgreSQL, Neo4j, Redis, MLflow, vLLM, LiteLLM, Qwen2.5-7B with 4-bit QLoRA, LoRA SFT and LoRA CPT, RunPod serverless workers
Companions: Electron desktop app (macOS arm64 and x64, Windows), Chrome extension
Sources: WhatsApp export and live sync, Facebook, Instagram, Discord, iMessage, Android SMS, pasted text, .txt
Security: Per-message AES-256-GCM under a KMS envelope key at ingest; no shared models trained on user data

Key features we implemented

Eight Ways to Bring Them Back

WhatsApp, Facebook, Instagram, Discord, iMessage from an iPhone backup, Android SMS, pasted text and a plain .txt - ten parsers behind eight buttons, all normalised into one message table.

A Chat That Sounds Like Them

The same adapter answers on web and on the phone - their humour, their rhythm, the way they said your name - with a websocket carrying each reply back as it lands.

Who They Were, Written by the Pipeline

Before any training the model reads the thread and writes a first-person profile - relationship, personality, communication style, interests, hard facts - and it goes into every system prompt after that.

Every Prompt, Versioned in the Database

The prompts that drive personality, facts, topic labelling, dataset building and inference live in Postgres with a version history, editable from the admin panel without a release.

Training Runs You Can See

Every epitaph carries the state of its run - new, training, done, failed - so support can tell in one screen whether a person's model finished, and which stage it died at.

Source Management

One screen to add material as it surfaces: pick a source, upload or paste, and the parser decides the format, resolves the two participants and asks when it cannot tell who is who.

Accounts You Can Revoke

Connected messengers are listed with a single switch each, and turning one off revokes the app's access rather than deleting anything - erasing data is a separate, deliberate action.

iMessage Without the Phone

iMessage cannot be exported from an iPhone, so we shipped a desktop utility - Mac (Apple Silicon and Intel) and Windows builds, served from the product's own download page with an install guide for the Gatekeeper prompt.