Skip to content

Overview

Alvia gives AI agents and applications memory that stays true as facts change. Your application sends Alvia what it learns. Alvia classifies how each new fact relates to what it already holds, keeps every earlier version with its date and resolves what applies now. When your application needs context, it gets one current answer, not a pile of old and new facts for the model to sort out. We call this Point-in-Time Reasoning for AI™.

Why an application needs it

Section titled “Why an application needs it”

A model call sees only what you send in that call. Nothing carries over to the next conversation unless your application stores it and sends it again.

Storing text is only the start; keeping it true as facts change is the work Alvia does. Facts change: a customer changes plans, a team replaces a database, a policy gets a new threshold. A store that saves text and searches it keeps every version side by side, so the model receives the old fact and the new one together and has to guess which one holds. Duplicates, contradictions, dates, per-user boundaries and deletion are part of the same engineering problem. See Why memory for AI is hard.

How it works

Section titled “How it works”
  1. Write. Your application sends text: a statement, a passage or a whole conversation. Alvia accepts it at once and forms memories from it in the background.
  2. Resolve. Alvia compares each new fact with the memories it holds and classifies how they relate: the fact replaces an earlier memory, adds detail to it, repeats it, contradicts it, relates to it or is new. The earlier version stays in the memory’s history, available through the API and in the dashboard.
  3. Read. Your application asks a question. Alvia returns resolved context in one to three sentences, or the memories themselves: the single best match or a ranked list, each at its current version.

Your application stays in control: Alvia supplies the context, and your code or agent decides what to do with it. Your server calls the REST API at https://api.alvia.ai, or an agent such as Claude Code, Codex or Cursor calls Alvia’s tools over MCP. Each project’s memory policy controls what becomes memory.

A changed fact, two ways

Section titled “A changed fact, two ways”

An application records that the Atlas service uses MySQL 8 in March, then that it moved to PostgreSQL 17 in September. Later it asks: “Which database does the Atlas service use?”

A similarity search over the saved text returns both statements, ranked by how closely they match the question, not by which one still holds:

Similarity search over saved text (illustrative)
0.91  The Atlas service uses MySQL 8 as its primary database.
0.88  The Atlas service moved its primary database from MySQL 8
      to PostgreSQL 17.

In this example, Alvia classifies the September fact as replacing the March one and records it as the memory’s next version, so its context call answers from the current version. A language model writes the answer, so its wording varies; a typical one reads:

Response
{
  "context": "The Atlas service uses PostgreSQL 17 as its primary database. It moved from MySQL 8 on September 23, 2026."
}

The Quickstart runs this example against your own project. Alvia answers from what your application sent it; see Evaluate Alvia for how it works end to end.

Choose your path

Section titled “Choose your path”
Try it without codeAsk questions of the Demo Project in the dashboard's Playground.
QuickstartCreate an API key, store two facts and ask for context, over REST.
Connect a coding agentGive Claude Code, Codex or Cursor memory across sessions over MCP.
Add memory to an LLM appFetch context before each model call and send each turn back.
Build with an AI assistantPaste a prompt that has a coding assistant add Alvia to your app.
Evaluate AlviaArchitecture, data flow, boundaries and a test plan.
Compared with other approachesVector databases, model provider memory, framework stores and more.

Use cases

Section titled “Use cases”

Next steps

Section titled “Next steps”