Use casesProductivity
Add company memory to your product.
Your users already want to ask your app what happened, who decided it and what changed. That is a memory engine, and it is a year of work. Ours is four endpoints.
Dana: we are moving the launch to 14 March. Ravi owns the migration now, Priya is off it. Same scope otherwise.
- Launch date is 14 MarchReplaces the earlier value
28 Februarykept, dated - Migration owner is Ravi MenonReplaces the earlier value
Priya Ramankept, dated - Scope unchanged
Who owns the migration and when does it ship?
Ravi Menon, shipping 14 March. Both changed on 21 August, and this call is the source.
The problem
Why the memory feature stalls after the demo
01
The corpus outgrows the trick
Similarity ranking returns the twenty passages that sound like the decision, not the one that settled it. Fluent, wrong, and nobody checks.
02
One person, six identities
The same colleague is an invite, a speaker label, an email and a chat handle. Unresolved, every question about them returns a fraction of the record.
03
It stops being a feature and becomes a team
Resolution, conflicts, permissions, evals and a graph that stays current under live writes. Each is tractable alone. Together they are a roadmap.
What memory changes
The parts you would have had to build
01
Entity resolution, not string matching
People, companies and projects resolve across every source you ingest, including after someone changes job.
02
Facts that know what they replaced
The current value answers the question. The superseded one stays dated instead of competing with it.
03
Answers your users can check
Every answer comes back with its evidence, which is the difference between a feature people trust and one they stop opening.
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 platform teams pick Revo Memory
Your users need no Revo account
We are infrastructure under your product, not a login your customers see. Billing counts API calls, not seats, so it scales with usage rather than your headcount.
White label by default
There is no Revo branding in a response. What you build on top is your product.
Weeks, not a hiring plan
Four endpoints, one bearer token, one input shape. No schema to design, no vector index to run, no evals harness to stand up.
Backfill what you already store
Timestamps are backdatable and ingestion is idempotent by content hash, so replaying years of existing transcripts is one loop that can safely re-run.
Built for organizations, not users
Evidence accumulates across every member of a workspace onto one entity, rather than one memory per observer.
Cost that does not track history
A workspace with four years of meetings costs about the same per question as a new one, so your margin does not decay with your best customers.
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.