Evaluate Alvia

This page is for founders, engineering leads and architects deciding whether to adopt Alvia. It describes what Alvia does and what stays in your application, how data moves through it, where its boundaries are, what to plan for and how to evaluate it in one day.

What Alvia does and what your application keeps

Alvia is hosted memory infrastructure for AI agents and applications: it tracks what is true, what changed and when. Your server sends what it learns: a statement, a passage or a whole conversation. Alvia forms memories from it, classifies how each new fact relates to what it already holds (it replaces a memory, adds detail to it, repeats it, contradicts it, relates to it or is new) and keeps each memory’s lineage. When your application asks a question, Alvia returns context that reflects what applies now.

Your application keeps everything else:

Identity. Who the user is. Your sign-in establishes identity, and Alvia uses the scope IDs your server sends as given.
Authorization. What each user may see and do. Alvia authorizes a request against its project only.
Authoritative records. Account balances, orders, permissions and other records of fact stay in your own systems. A memory is context, not a system of record.
Transactions. Payments, refunds, bookings and other changes of state run in your application.
Acting on answers. Alvia returns context; your application or agent decides what to do with it. Alvia does not reply to users or run your workflow’s steps.

Architecture and data flow

Your server calls Alvia over the REST API at https://api.alvia.ai, or an agent calls it through the MCP server. Both use a project API key.

Write. Your server sends text. Alvia records the submission and answers 202 at once.
Form memories. In the background, Alvia takes the durable facts out of the text, screens each fact against the project’s memory policy, normalizes its wording and dates, compares it with the memories in the same project and scope, classifies how it relates to them and commits the result. See Memory formation.
Read. Your server asks a question. Search and recall return ranked memories. Context writes a short answer from the best match and its related and contradicting memories.

What Alvia stores

the text of every submission, kept until you delete the project
memories, each with every version, the outcome of its classification and the classifier’s explanation
relationships between memories, and your feedback on them
a search index of each memory’s current text
a record of each API-key call, kept for 90 days

Security describes how long each is kept and what deleting a memory, a project or the account removes.

Where a language model runs

Forming memories sends the submitted passage or conversation, and the facts taken from it, to language models. Context sends the question, the best match and its related and contradicting memories. Reads that search send the query and memory text to a hosted search index.

The language models run at third-party inference providers. For your security review, ask Alvia which providers process your data, where they run and what they retain.

Isolation and boundaries

Projects isolate. Each project is a separate set of memories. A request reaches only the project of the key that sent it. A request for a memory in another account gets the same 404 as a request for one that does not exist.
API keys belong to one project. A key can store, read, forget and give feedback on every memory in its project, in any scope. Keys, projects and account settings stay in the dashboard.
Scope filters within a project. A write stores its memories under exactly the scope you send, and formation compares a new fact only with memories in that scope. A read returns memories that match every scope field you send; a read without scope covers the whole project. Projects are the access boundary, so your server takes scope from the signed-in session.
Policies belong to a project. Every key and scope in a project shares one memory policy.
Capacity belongs to the account. Rate limits and monthly allowances are shared by every project and key in the account, so plan capacity for the account as a whole.

Use separate projects for production and testing, and for customers whose data must be kept apart. See Projects and scope and Security.

Design notes

Writes are asynchronous. A memory becomes readable after formation finishes, not when the write returns. Formation finishes in less than a minute.
Alvia resolves what your application sends. Send every fact you want it to answer from.
Reads return what applies now. Date bounds filter memories by when they were stated or occurred, and each memory’s history, versions and relationships are available through the API and in the dashboard. See Change over time.
Context is generated. A language model writes each context answer from the current memories, and a new version of a memory it used shows in the next answer. See Get context.
Every classification is explained. Alvia classifies whether a new fact replaces, adds detail to, repeats, contradicts or relates to what it holds, or is new, and records the classifier’s explanation with each outcome, shown in the dashboard. See Memory formation.
Contradictions stay visible. When two facts contradict each other, Alvia keeps both and picks no winner; context reports both. Your application forgets the one that no longer applies.
Retry only failed requests. Retry network errors, 5xx responses and 429 responses (after the wait in Retry-After). A 202 means Alvia accepted the write, so do not send it again. When you retry, send the same content and occurred_at. Each accepted request uses writes. See Retries in Store memories.
Calls come from your server. The API serves server-side calls, so your API key stays on your server. See Authentication.

Operations

Rate limits. Each account has one bucket for reads and one for writes. REST responses carry RateLimit-Remaining. See Rate limits.
Allowances. Each plan has monthly reads and writes and a stored-memory limit. On every plan, reads or writes are refused once the monthly allowance is used up, until it resets; the stored-memory limit is a hard stop. See Limits and allowances.
Usage headers. REST memory calls carry Server-Timing, the time Alvia spent on the request, and Alvia-Usage, the reads and writes the call used.
Activity log. In the dashboard, a project’s Activity page lists each API-key call with its operation, status and scope, and the query text and ranked results of reads, for 90 days.
Version history. Each memory keeps every version, how each was classified with the classifier’s explanation, and its relationships. Your application reads history, versions and relationships through the API, and the dashboard shows the same history with a Graph view.

See Production checklist for keys, retries and monitoring.

Build or buy

A prototype that stores messages and retrieves similar ones and a dependable memory are different engineering problems. A dependable memory must recognize repeats, notice when a fact replaces or contradicts an earlier one, keep when each fact was stated, separate users, size retrieval to a prompt, delete on request and control cost. Alvia does that work; your team owns the integration, the policy and what the application does with each answer.

Alvia fits beside your own systems. Keep conversation history, profile rows and authoritative records in your database and documents in your search engine; Alvia holds the facts your application learns over time and keeps them current. See Why memory for AI is hard and Alvia compared with other approaches.

Evaluate it in one day

Use invented data throughout.

See it answer. In the dashboard, open Demo Project, then Playground. Ask about a fact that changed, then open the memory under Memories to see its versions. See Try it in the dashboard first in the Quickstart.
Integrate. Follow the Quickstart in your own project: store a fact, store its change and ask for context.
Test a memory policy. In a separate test project, follow Filter memories: confirm that an allowed fact forms a memory and that keyword and meaning exclusions keep restricted facts out.
Test isolation. Run the test in Prove isolation and recovery behavior: two projects, two users and a server that chooses the scope.
Measure latency. Time context, recall and search from your server under representative load, and compare the total with Server-Timing. Measure separately how long a new write takes to become readable.

curl -s -o /dev/null -D - https://api.alvia.ai/v1/memories/context \
  -H "Authorization: Bearer $ALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "Which database does the Atlas service use?"}' \
  -w 'total=%{time_total}s\n' | grep -i -E '^(server-timing|alvia-usage|total)'

Server-Timing reads app;dur= followed by milliseconds: the time from when Alvia receives the request to when it starts the response. The difference from total is the network and connection time between your server and Alvia.

Playground calls and every step here count against your read and write allowances.