Give your agents infinite context.
A context window fills up. A Virtual Memory does not. It turns your documents, tables and feeds into context an agent can ask for — relational, so it knows how things connect, and semantic, so it knows what resembles what — and it keeps growing as your data does.
Two kinds of context, from the same data
Agents need to know how things connect, and what resembles what. A memory gives you either — or both — off the same sources.
- Relational memoryExplored as a graph
“Who is involved in this, and what does it touch?”
Pulls the entities out of your data — companies, people, products, claims — and the relationships between them, held to an ontology you approve before a single extraction runs.
- Nodes are the things in your data, not your files or tables
- Traverse from an invoice to the contract clause that priced it
- Entity IDs are deterministic, so later runs dedupe without a merge pass
- Semantic memoryExplored as a space
“What else in here resembles this?”
Forms entities out of your sources — passages, whole records, a single column — embeds them, and gives you a space where similarity is a measurable distance.
- You decide what one entity is before anything is embedded
- Finds records that agree in meaning but share no keyword
- New data is embedded and added; nothing is re-embedded or re-paid for
Try it yourself
One supplier dataset, both memories. Traverse the graph from an invoice to the amendment that repriced it, then switch tabs and ask the space a question none of the records word the same way.
Entities and the relationships between them. Ask how things connect, and follow the answer hop by hop.
Select an entity to traverse
What you get either way
The parts that make a memory worth keeping are the same for both kinds — the sources, the approval, and the fact that it never starts over.
Any data, one memory
Documents, slides, spreadsheets, images, warehouse tables, APIs.
Grows, never rebuilds
Each run folds in only what arrived since the last one.
You approve the schema
The ontology or space plan is agreed on samples before the spend.
Notices when sources drift
A renamed or retyped column is raised for a decision, not guessed at.
Answers only from itself
It replies from what it declares, or says it does not know.
Bounded by the room
A memory can only ever see the sources its room was given.
How a memory gets built
- 1
Point it at your sources
Any mix of room data, connectors and APIs. No export step, no schema first.
- 2
Agree the plan
It reads samples, proposes an ontology or a space plan, and waits for your yes.
- 3
Let it accumulate
A pipeline fills it and keeps filling it, extending the same tables on every run.
Memories grow. They don’t rebuild.
Add data and run it again and it processes only what arrived since the last run, writing into the same tables. If a source changed underneath it, it tells you what changed and asks how to handle it before extending — so the second year of a memory costs a fraction of the first, and nothing is ever paid for twice.
Ask it from anywhere
This is what makes the context unbounded. Nothing has to be loaded into a prompt up front — your own agents reach the memory over MCP and pull exactly what they need, in words, by query, or by meaning.
ask_memoryAsk one memory a question in words and get an answer grounded in what it declares.knowledge_graph_catalogRead back the entities, relationships and measures the memory makes available.knowledge_graph_searchSkip the model and compile a query against those declarations yourself.semantic_searchSearch a space by meaning and get the closest rows back, ranked by similarity.
Where a memory sits
It is fed by the surfaces that clean and schedule your data, and read by the ones that put it to work.