Why remember at all
Good shop assistants remember. They know you wear a 10 wide, that you hate the feel of wool, that the last blender you bought was too loud. An AI assistant that forgets everything between visits makes the shopper do that work again, every time.
So Concierge keeps notes on what a shopper tells it: preferences, sizes, circumstances, things to avoid. Every note records where it came from, such as “the shopper said so on this date”, so the assistant can tell a stated fact from a guess, and so the shopper can see why it believes something.
Memory is also where an assistant can do the most harm. The rest of this article is about the design decisions that keep it on the shopper’s side.
Whose memory it is
We made one decision before any other: a shopper’s memory is held by HawkShift for the shopper, not for the store. A store that uses Concierge never receives a shopper’s remembered preferences, their conversations, their price watches or a record of what Concierge did for them. Stores learn what shoppers want in aggregate, as we describe in Insights without surveillance, and never who wanted it.
That shapes how consent is worded, too. The question a shopper is asked is never “share your preferences with this store?”. It is “use your preferences on this store?” The preferences stay with Concierge; the store gets better recommendations, not the data behind them.
And a shopper doesn’t need to find a settings page to stay in control. They can ask Concierge what it remembers about them, correct a note, or tell it to forget something, in the same conversation.
Same browser, different person
Most shoppers aren’t signed in when they start talking to an assistant. Concierge can still remember them across visits, tied to their browser. The interesting moment is when they sign in: should the anonymous history join their account?
The obvious rule is yes: an account was just signed into, in a browser that has history, on the same store. Join them. We shipped a version of that rule, and it was wrong in a way that is easy to miss. Every part of it is about a browser, not a person.
Think of a shared family laptop. One person spends an evening browsing running shoes and mentions a knee injury. The next morning someone else signs in to their own account on the same laptop. Under the obvious rule, the first person’s injury is now in the second person’s memory, and the assistant may bring it up.
So we wrote down what does and doesn’t count as evidence that two histories belong to one person:
| Accepted as evidence | Refused as evidence |
|---|---|
| The store explicitly vouches that this browser session belongs to this signed-in customer | Same browser, same device, same session |
| The shopper confirms, against an offer that names both histories | Same network address |
| A support request we have verified | Same email or same name typed into the chat |
| Similar behaviour, or a model’s judgment that they seem alike |
We also had to resist a comforting argument: joins can be undone, so a wrong one isn’t serious. Our system can undo a join, and that matters. But being able to reverse a mistake after someone notices it is a recovery tool, not a prevention tool. By the time it is noticed, the second person has already seen the first person’s notes.
A yes has to name names
When the shopper is asked to confirm a join, their answer can’t be a simple yes. A stored “yes, merge my history” carries no information about whose history. If it were cached in a shared browser, it could authorise joining one person’s history into another’s.
Instead, the server creates a signed, short-lived offer that names both histories. The shopper’s confirmation returns that offer, and the server reads which two histories to join from its own signed record, never from anything the browser claims.
Forget means forget
Shoppers change things. “Actually, call me Sam.” “Forget my name.” Each of those is a correction to an earlier note, and corrections depend on what they correct.
Our memory is an append-only history: new notes replace old ones by pointing at them, and forgetting erases a note’s contents while keeping the fact that something was there. That design is good for accountability, and it hid a bug. When a shopper asked to forget a note that had itself replaced an older one, the system skipped the erased note entirely, including its link to the older note. The older note came back to life.
In practice: a shopper gave their name, later corrected it, then asked Concierge to forget their name. Concierge then answered with the original name. Now an erased note still applies its link to what it replaced before its contents are skipped, so forgetting the latest note doesn’t resurrect an earlier one.
Forgetting a correction must not revive what it corrected.
What should never travel
We are designing for a future where a shopper’s preferences can come with them from one store to another, with their permission each time. That raises a question stores and assistants will increasingly face: what should be allowed to travel?
Our answer starts with what shouldn’t. A name never travels. A set of preferences such as “prefers wide fit, avoids wool, budget-conscious on electronics” helps any store serve someone well. Attach a name and it becomes a dossier. So identity notes stay inside the store where they were given, and what travels is capped to a small number of short statements the shopper can see.
We also decided that a travelling profile has to be presented by the shopper, never inferred. No email address, name, browser or model judgment is allowed to decide that this shopper is the same person as a profile somewhere else.
Keys the browser controls
One more rule sounds technical and matters a great deal. Browsers often generate a random ID for a visitor and send it with each request. It is tempting to use that ID to look up memory. We don’t, because the browser controls it: anyone can send someone else’s ID and read their notes.
Memory is looked up only by an identifier our server issues and signs. The browser can carry it back to us, but it can’t forge one or alter one without the signature failing. A client-made ID is refused as a memory key, by design.
The principles
- Held for the shopperStores never receive a shopper’s memory, conversations, watches or actions.
- Consent says “use”, not “share”The store gets better recommendations, not the data behind them.
- Co-presence is not identitySharing a browser, device, network or name is never enough to join two histories.
- Confirmation names both sidesA yes that doesn’t say whose history can be replayed for someone else.
- Forgetting follows the chainErasing a note must not revive what it replaced.
- Names stay homePreferences may travel with permission. Identity doesn’t.
- Only server-signed keysAnything the browser can set, the browser can fake.
Memory makes an assistant useful. Getting it wrong makes it creepy, or worse. Almost every decision above came from asking one question about a real situation: if this goes wrong, who sees something they shouldn’t?
HawkShift Research · . Numbers are from our own tests while building Concierge; small samples are marked as small.