What the Memory API is

We support any kind of text input (structured or not): emails, meeting transcripts, Slack messages, support threads, CRM notes, documents. Revo identifies the people, companies, projects, and facts in that material, resolves them against what the workspace already knows, and updates the graph as new information arrives.

For example:

• February: "Nadia confirmed the pilot ships March 14. Budget is 32k."
• July: "Budget moved to 40k."

Ask for the Acme budget in July and Revo returns 40k, with the July email as evidence. The February value remains available as dated history.

Revo only sends what is currently true so that you don't have to handle conflicting information.

The API

The API has four core endpoints and one ingestion model.

• POST /ingest accepts raw text plus a timestamp. Extraction, entity resolution and graph maintenance happen on Revo's side.
• GET /ingest/{ingestionId} reports ingestion progress. Poll it until settled is true before reading.
• /recall returns ranked, sourced evidence to use as reasoning.
• /answer performs recall and answering together. It returns the answer, the evidence used to establish it, and the dollar cost of the call. If the memory does not contain enough evidence, it returns abstained: true instead of a guess.

Nothing else is required. Revo does a lot internally so that all the complexity of memory handling is done on our side rather than yours. Thanks to that, integrating Revo is easy and starting takes 5 minutes.

Information is deduplicated across the organization

A workspace has one connected graph rather than a collection of isolated user memories. Information about the same person, company or project is deduplicated across every channel it arrives from.

A person mentioned in one employee's email and in another employee's meeting stays a single person, and a company observed in Slack, the CRM and support history stays a single company with a single state. The same entities accumulate evidence across channels and observers.

For example, all of these can resolve onto the same person as evidence accumulates:

• nadia@acme.com in email
• Nadia Rahman in a meeting transcript
• Slack member U03H8KHU60L, displayed as @nadia
• nadia@newco.com six months later

That gives the application one place to ask what we know about Nadia, what our company last agreed with Acme, who owns the relationship now, or what changed after the July meeting, without first deciding which user's memory, thread, application or source contains the answer.

The graph is shared; each reader only retrieves what they are allowed to see. Per-user memory is a filtered view of the same graph.

Identity is part of memory

Retrieval quality is not enough if the system does not know which real-world entity a fact belongs to. Consider:

• Nadia Rahman works at Acme.
• nadia@acme.com approved the pilot.
• Nadia moved to NewCo.
• nadia@newco.com asked about the previous project.

A useful memory holds one person, her relationship to two companies, and facts learned about her at different points in time.

Revo performs entity resolution during ingestion and continues resolving new observations against the existing graph. This makes identity resolution a maintained property of memory rather than a retrieval-time prompt. The same mechanism applies to companies, projects and other entity types.

Revo tracks which fact is current

Semantic search asks which stored material resembles this question. Memory often has to answer a different question: which fact currently holds. Suppose the history contains:

All three statements are relevant to Acme budget but only one is currently true.

A retrieval pipeline or a RAG can return all three and delegate reconciliation to the model consuming them. Revo maintains the relationship between those facts as the graph changes, so a recall can return the current state while retaining previous values, dates and sources as history.

This applies to more than numbers:

• Alice owns the account. Bob took over the account.
• Launch is March 14. Launch moved to March 28.
• Nadia works at Acme. Nadia joined NewCo.
• We will include migration. Migration was removed from scope.

For these questions, semantic relevance and temporal validity are separate problems. Revo handles both before the evidence reaches the downstream model.

The answer API is part of the memory contract

Some memory systems stop after producing context. Revo exposes both layers. Use /recall to let the application's own model or logic reason over the memory. Use /answer to have Revo determine whether the graph establishes an answer and return it with supporting evidence.

The output contract is answer, evidence, abstained and usage. This matters for applications where memory is used to draft, recommend or act.

The distinction between "I found related context" and "the available evidence establishes this answer" should not have to be reconstructed independently by every caller. Neither should the third case, "the memory does not know": abstained: true makes it explicit.

Revo backs every memory with evidence

Every fact is dated and sourced. When a current value is returned, the application can inspect the evidence from which that value was learned. This allows the caller to:

• cite the source to a user
• inspect when the information was learned
• compare present and historical values
• debug an incorrect result
• apply its own product or policy rules before using the fact

The graph stays traceable to the source material. A useful memory result is:

rather than an unsupported statement that the budget is 40k.

Revo builds one memory for the whole team

A shared graph matters when knowledge is distributed across people. Suppose an account executive discusses pricing by email, a founder changes the scope on a call, engineering posts the new delivery date in Slack, and support learns that the customer changed project owners. No single employee has the full history.

A per-user memory architecture can preserve what each person observed, but the application still has to decide how those separate memories combine into company knowledge. In Revo, those observations contribute to the same entity and fact graph, subject to audience visibility.

The question can therefore be "what does our company currently know about the Acme launch?" rather than "which users might know something about Acme, and how should I merge their retrieved context?". This distinction becomes more important as the number of users and connected systems grows.

Revo saves input tokens and agent turns

Without resolved memory, answering a question means sending a model a large slice of history and letting it work out what is currently true: identify the same entity across passages, remove duplicates, notice contradictions, interpret dates, decide what superseded what. That work is repeated on every query and paid for in input tokens and extra agent turns.

Revo resolves what is currently true once, at ingestion. A query returns the small set of current, sourced facts relevant to the task, so there is no history to re-read and nothing left for the agent to reconcile.

In the documented /answer example, the answer model receives roughly 2,100 input tokens and the response reports answerCostUsd: 0.000431 and recallCostUsd: 0.000214, about $0.00065 combined. The example is not intended as a general cost estimate. The useful property is that /recall and /answer report their own dollar cost, so cost can be measured per active mailbox, per generated draft or per question on a real workload. /ingest does not currently return usage fields.

Database, RAG or Revo?

These systems solve different problems.

Use search for (contact us if you want Revo to also serve as a RAG): finding the emails that mention the Acme pilot, locating the document that contains the migration plan, or showing discussions about pricing.

Use memory for: what price we finally approved, who owns the account now, what changed since the original proposal, which commitments are still open, what this person currently prefers, what we knew at the time, and which source establishes the answer.

If the problem is only semantic retrieval, use a mature search or vector stack. The Memory API is for applications where identity, time, state and evidence are part of correctness.

Custom domains

The default ontology includes common entities such as people, companies, projects and decisions. It is not fixed. A workspace can use a custom ontology so domain-specific entities and relationships are extracted and resolved as first-class parts of the graph.

A legal application might care about matters, clauses, obligations, counterparties and amendments. A sales application might care about accounts, opportunities, champions, commercial terms and commitments.

Custom ontology configuration is handled with Revo during early access. There is not yet a public endpoint for changing it.