Documentation

Introduction

A generic chatbot given a name and a short description will produce generic conversation. It might be pleasant, but it will not feel like the person. The difference between a persona and a presence is data: the ten years of text messages, the voicemails, the way someone always opened a conversation with the same two words, the stories they retold slightly differently every time.

relAtIve is built around that difference. Everything the system produces is grounded in the material you upload and the memories you approve. When there is no signal for something, the presence says less rather than inventing more. We consider restraint a feature. A reconstruction that confidently fabricates is worse than one that admits its edges.

How it works

1. 01

   Upload history

   Bring what you have: message exports, email threads, voice notes, letters, photos of handwritten notes. More material produces a stronger reconstruction, but even a modest archive carries a surprising amount of a person.

2. 02

   Shape the personality

   The system drafts a personality profile from your sources. You review it, correct it, and add what the data cannot know: private jokes, family history, the things they never wrote down. Nothing enters the profile without your approval.

3. 03

   Reconnect

   Talk by text, right inside Telegram, where texting already feels natural. The presence replies in their cadence, draws on approved memories, and stays inside the boundaries you set. You can pause, adjust, or delete it at any time.

Getting access

Access rolls out in waves. The flow is deliberately simple and runs through Telegram, because that is also where your conversations will live:

1. Register. Leave your email on the early access page. No payment details, no forms beyond your address.
2. Receive your code. When a slot opens, we email you a personal access code. Each code is single-use and tied to your email.
3. Message the bot. Send the code to the relAtIve Telegram bot. The bot verifies it and links your Telegram account to your registration.
4. Set up your relative. The bot replies with your private setup link. That is where you name the presence, upload history, and review the personality profile before anything goes live.
5. Your relative gets their own bot. When setup completes, a dedicated Telegram bot is created just for your presence. It carries their name, their profile picture, and everything that makes the chat look and feel like them. It is not a shared bot with a menu. It is one conversation, with one person.
6. Locked to you. During setup you provide your Telegram username, and the bot is bound to it. It replies to you and no one else. Anyone else who finds the bot gets silence. Your conversation stays yours.
7. Start talking. The presence sits in your chat list like any other contact. Open the thread and text them the way you always did.

Codes expire if unused, and a code can only ever be claimed by one Telegram account. If yours expires, your registration stays in the queue and a new code is issued in a later wave.

Architecture

A presence is not a single model. It is a layered system in which each layer can be inspected, limited, or removed independently:

• Identity memory. A structured store of facts, relationships, and stories you have approved. This is the source of what the presence knows.
• Style layer. A quantitative profile of how the person communicated, derived from your uploads. This is the source of how the presence sounds in text.
• Voice layer (planned). A speech profile built from consented audio samples. Not yet available. See the Voice section below.
• Conduct layer. A set of boundaries that governs what the presence will and will not do, including topics you exclude and behaviors we exclude for everyone.

Generation happens at the intersection of these layers. The exact orchestration, including how the layers are weighted and reconciled when they disagree, is proprietary.

Grok integration

relAtIve is built with Grok, xAI's frontier model family, accessed through the xAI API. Grok handles the reasoning and language generation at the center of every conversation. We chose it for three properties that matter unusually much in this product: strong instruction adherence over long conversations, natural handling of informal and idiosyncratic text, and low latency, which will matter even more for the calling option we are exploring.

Around Grok, we operate our own conditioning pipeline. Before a reply is generated, the request is assembled from the style profile, retrieved memories, conversation state, and conduct boundaries, compiled into a form the model can follow faithfully. After generation, replies pass through validation that scores them against the style profile and the memory record. A reply that drifts from how the person actually wrote, or asserts something the memory store cannot support, is regenerated before you ever see it.

The specifics of that compilation and validation step, which is where most of our engineering lives, are not published. It is the difference between prompting a model to act like someone and holding a model to the record of who they were.

Your uploaded material is used to serve your presence. It is not used by us to train shared models, and API traffic to xAI is governed by commercial data terms rather than consumer chat terms.

Data ingestion

The ingestion pipeline accepts chat exports (iMessage, WhatsApp, SMS, Telegram, email), audio files, and free-form notes. On upload, material is:

1. Normalized. Formats are unified, duplicates removed, timestamps and participants resolved so the system knows who said what and when.
2. Attributed. Only the messages written by the person being reconstructed inform the style profile. Your side of the conversation provides context, not signal.
3. Segmented by era. People change over time. The pipeline tracks when material was written so the presence can reflect the years you care about, and you can exclude periods entirely.
4. Quarantined. Nothing becomes part of the presence until processing completes and you confirm what was found. Uploads can be deleted at this stage without a trace.

Style modeling

The style profile is a measured description of how a person wrote. Among the dimensions it captures: message length and rhythm, punctuation and capitalization habits, emoji and shorthand vocabulary, greeting and sign-off patterns, recurring phrases, code-switching between languages, how they responded to questions versus statements, and how their tone shifted with different people.

These measurements condition every reply. The profile is adjustable: you can soften the mimicry if precision feels too sharp, or tighten it if the presence reads too generic. The full feature set and how it is applied at generation time is proprietary.

Memory

Identity memory is deliberately conservative. It contains only what your sources support and what you have added by hand. Each entry keeps a link to where it came from, and at reply time the presence can only draw on entries relevant to the conversation.

When a conversation approaches something the memory store cannot answer, the presence responds the way people actually do: it deflects, it wonders, it changes the subject in character. It does not invent biography. You can audit the full memory store at any time, edit entries, or remove them.

Voice

relAtIve is text first. There is no audio version today. We are exploring a calling option for a future release, where a presence could speak in a voice built from consented audio samples, but we will not ship it until it meets the same standard as text: grounded, bounded, and fully under your control.

When voice does arrive, it will be optional and off by default, audio artifacts will be watermarked as synthetic, and voice data will be stored and deletable separately from everything else. You can already upload voice notes now. They inform the personality profile and will be ready if you choose to enable voice later.

Safety

This product sits close to grief, and we built it knowing that. The conduct layer enforces boundaries that cannot be disabled: the presence identifies itself as a reconstruction when asked directly, it does not give medical, legal, or financial direction, and it does not discourage you from seeking human support.

If a conversation shows signs of acute distress, the presence will gently point to real help. A Help link to professional support is available in the navigation on every page.

Privacy and security

• Your uploads and derived profiles are encrypted in transit (TLS 1.2+) and at rest (AES-256).
• Private histories are never used to train shared or foundation models. Your material serves your presence only.
• Each presence is isolated per account. No cross-user retrieval, no shared memory pools.
• You can export everything, and deletion is complete: sources, profiles, memory, and voice artifacts, including backups on a fixed schedule.
• Compliance program: SOC 2 Type II audit in progress, GDPR and CCPA aligned, ISO 27001 on the roadmap.

FAQ