Memory

Friday has three layers of memory: a visitor identity, the current conversation, and a small slice of identity facts that get into every prompt. There's nothing else — no quiet background learning, no cross-site profile. Visitors are scoped to one host.

Visitor identity

The first time a visitor opens Friday on your site, the widget sets a first-party cookie called fr_vid (90 days, SameSite=Lax). That cookie is the visitor's identifier on your site — not their name, not their email; just a random ID.

If the visitor tells Friday their name, email, or phone number during the chat (or it's extracted from a form they filled), those get linked to the fr_vid in our database. That's what shows up under Visitors in the dashboard.

Conversation history

Every message the visitor sends and every reply Friday gives is stored against their fr_vid. When the visitor returns later, the widget loads the last N turns and the model sees them as context — so Friday knows what they asked about last time.

You can read the full transcript in Dashboard → Visitors. You can delete a visitor (and all their messages) from that same view.

Identity-only memory in prompt

The full conversation history can be long. To keep prompts small and fast, Friday extracts and reuses only a tight identity block at the top of each prompt:

• Name, email, phone (if known).
• What the visitor has explicitly told us they're interested in (one or two short notes).
• The last N exchanges verbatim (default N = 6).

Older turns aren't deleted from storage, but they're not in the prompt by default. This keeps latency down and means Friday doesn't hallucinate "as you mentioned last week..." from things she can't actually recall.

Per-host session scoping

Visitor data is scoped to a single workspace, which is scoped to a single host (the domain that loaded the widget). Three implications:

• Friday on site A never sees a visitor's history from site B, even if both sites are yours.
• The extension creates per-domain workspaces specifically to maintain this boundary.
• Visitor deletion is per workspace — deleting them in workspace A doesn't touch their data in workspace B.

What gets sent to the LLM

For each visitor message, the model receives: the identity block, the last N exchanges, the current page scan, your vocabulary, and the new message. That's it. No CRM lookups, no cross-site joins, no background searches.

Deletion

A visitor can ask the website owner to delete their data. The owner clicks Delete visitor in the dashboard, which removes the fr_vid, all linked identity fields, and all conversation history. The cookie on the visitor's device is independent — they can clear it themselves any time.