Use casesRetail & E-commerce
Shopping that remembers the shopper.
Preferences, sizes, past baskets and what someone rejected last month, kept as a dated record rather than a session cookie.
Returned the 42 as too small and reordered the same trainer in a 43. Filtered to darker colourways both times.
- Shoe size is 43Replaces the earlier value
42, returned as too smallkept, dated - Prefers darker colourways
- One return, for sizing
Which size do we show first?
43, from the 16 August reorder. The 42 stays dated in the history as the size that was returned.
The problem
Why the shopping assistant keeps starting over
01
Years of signal, thrown away every session
Orders, returns and service contacts going back years, and the assistant opens with questions the customer has already answered.
02
The stale preference outranks the current one
A returned 42 and a reordered 43 sit in the store with nothing saying which came later. Half the time it recommends the return.
03
One shopper, four accounts
Guest checkout, logged-in account, app session and support ticket are four records of one person, and none holds the whole story.
What memory changes
A shopper record that keeps up
01
Preferences with dates on them
The current size is the one from the most recent evidence. The old one stays in the history instead of competing with it.
02
One shopper across identities
Addresses, handles and account identifiers resolve onto one node as evidence accumulates, including after an address change.
03
Recommendations you can explain
Every answer carries the evidence it rests on, which is what makes a suggestion auditable rather than a black box.
Economics
The bill does not grow with the history.
The usual alternative is to send the whole record to the model on every question, so cost climbs with every message you have ever stored. We read a roughly fixed amount per question whether the record holds a hundred thousand tokens or ten million.
- 23x cheaper per question than sending 1M tokens of history, on the same model
- 232x cheaper at 10M tokens, where no production model can hold the context at all
- Around 96% less context read per question at 1M tokens of history
Integration
Three calls, and nothing to host.
One input shape: text plus a timestamp. You do not pick an embedding model, chunk anything, maintain entity tables or write prompts that decide which of two conflicting statements is current.
- Four endpoints and one bearer token, called directly over HTTP
- Ingestion is idempotent by content hash, so a crashed backfill just re-runs
- SOC 2 Type II, ISO 27001 and ISO 27701, with the API inside that same scope
Why Revo Memory
Why commerce teams pick Revo Memory
Your shoppers need no Revo account
The API is billed on what it does rather than on how many people touch it, so the people using your store never sign up for anything.
Cost stays flat as history grows
A shopper with ten years of orders costs about the same to query as one with four weeks.
Idempotent ingestion
Re-sending unchanged events costs nothing, so a catalogue or order sync can safely re-run.
Nothing to host
No vector index to operate, no embedding model to choose, no chunking to tune.
Certified platform
SOC 2 Type II, ISO 27001 and ISO 27701, and your data is never used to train models.
Four endpoints
Ingest, recall, answer and delete, called directly over HTTP with one bearer token.
More use cases
The same engine, other shapes of work.
Tell us what you are building.
Keys are issued by hand while the API is in early access. Bring your volumes and the shape of your integration, and we will tell you straight whether it fits yet.