Skip to main content
A Virtual Memory turns any mix of documents, tables, and feeds into something queryable. It gives your agents context that never runs out: instead of loading data into a prompt, an agent asks the memory for exactly what it needs — in words, by query, or by meaning — and the memory answers only from what it declares. Memories are built from any combination of room data, connectors, and APIs, and they are kept current incrementally: each run folds in only what arrived since the last one. Nothing is rebuilt, and nothing is paid for twice.
Virtual Memory is currently in beta. It lives inside a Room — open the Memory surface from the room’s surface switcher, next to Chat, Playbooks, and Workflows.

​
Two kinds of memory

Agents need to know two different things about your data: how things connect, and what resembles what. A memory gives you either — or both — off the same sources.

Relational memory

Explored as a graph. 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. Answers “Who is involved in this, and what does it touch?”

Semantic memory

Explored as a space. 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. Answers “What else in here resembles this?”
A few properties of each kind worth knowing:
  • Relational — nodes are the things in your data, not your files or tables. You can traverse from an invoice to the contract clause that priced it. Entity IDs are deterministic, so later runs dedupe without a merge pass.
  • Semantic — you decide what one entity is before anything is embedded. It finds records that agree in meaning but share no keyword. New data is embedded and added; nothing is re-embedded.

​
What you get either way

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.

​
Building a memory

1

Point it at your sources

Click Build a memory on the Memory surface. Choose the kind (relational or semantic), describe what this memory is about, and attach any mix of room data sources, connectors, and vault APIs. No export step, no schema first.
2

Agree the plan

The builder reads samples from your sources and proposes a plan, then waits for your yes:
  • Relational — a proposed ontology (the entities, relationships, and measures it found). You can also seed the ontology yourself, or leave it empty and review the deduced proposal. Optionally make it searchable, which lets the memory answer natural-language questions as well as graph traversals at the cost of an embedding pass.
  • Semantic — a proposed plan: what one entity is, what it’s formed by, and which model it’s embedded with. You can pin a specific embedding model or let the builder pick one.
Review the proposal on the memory’s Schema (or Plan) panel and click Review & approve.
3

Let it accumulate

Once approved, a pipeline fills the memory and keeps filling it — extending the same tables on every run. The memory moves through Reading your sources → Working out what to remember → Waiting for you → Building the memory → Ready.
Memories grow, they don’t rebuild. Add data and run again, and only what arrived since the last run is processed, written into the same tables. If a source changed underneath it — a renamed or retyped column — the memory tells you what changed and asks how to handle it before extending.

​
Exploring a memory

Each memory has its own detail page:
  • Memory tables — the entity, relationship, and embedding tables the memory writes, readable like any other Corvic Table.
  • Graph / Space explorer — a visual explorer for the memory’s contents: traverse the graph of a relational memory, or navigate the embedding space of a semantic one.
  • Query Builder — compose graph or space queries directly against what the memory declares.
  • Talk to this memory’s builder — every memory has a dedicated builder agent that owns its history. Ask it to adjust the ontology, explain a decision, or process everything that arrived since the last run.

​
Asking a memory 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.
A memory answers only from what it declares — and says so rather than answering something adjacent. ask_memory runs a full model turn, so it is slower and metered; knowledge_graph_search compiles a query without one, so reach for it when you want precise numbers or relationships.

​
Where a memory sits

A memory is fed by the surfaces that clean and schedule your data, and read by the ones that put it to work: a Document Lens turns a pile of documents into the clean fields a memory then accumulates, a scheduled Workflow keeps it current, and Playbooks and agents query it as they run.

Document Lens

Turn messy documents into the clean fields a memory accumulates.

Workflows

The pipeline underneath a memory, keeping it current on your schedule.

Playbooks

Put the memory to work in a plan that runs the same way every time.

Spaces

The embedding representations behind semantic memories.

Graph Builder

Build graph structures from Corvic Tables by hand.

MCP Overview

Reach memories from your own agents and applications.