> ## Documentation Index > Fetch the complete documentation index at: https://docs.corvic.ai/llms.txt > Use this file to discover all available pages before exploring further. # Virtual Memory > Everything a room knows, made queryable — as a graph of the things in your data and how they connect, or as a space where meaning is a distance. 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](/features/rooms) — 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. **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?"* **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 Documents, slides, spreadsheets, images, warehouse tables, APIs. Each run folds in only what arrived since the last one. The ontology or space plan is agreed on samples before the spend. A renamed or retyped column is raised for a decision, not guessed at. It replies from what it declares, or says it does not know. A memory can only ever see the sources its room was given. ## Building a memory 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. 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**. 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](/concepts/feature-views). * **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](/integrations/mcp-overview) and pull exactly what they need. | Tool | What it does | | ------------------------- | ------------------------------------------------------------------------------------------------------------ | | `list_memories` | List a room's memories with their title, subject, kind, and searchability. | | `ask_memory` | Ask one memory a question in words and get an answer grounded in what it declares. | | `knowledge_graph_catalog` | Read back the entities, relationships, and measures the memory makes available. | | `knowledge_graph_search` | Skip the model and compile a precise query against those declarations yourself. Results land as a new table. | | `semantic_search` | Search a space by meaning and get the closest rows back, ranked by similarity. | 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](/features/document-lens) turns a pile of documents into the clean fields a memory then accumulates, a scheduled [Workflow](/features/workflows) keeps it current, and [Playbooks](/features/playbooks) and [agents](/features/agents) query it as they run. ## Related Documentation Turn messy documents into the clean fields a memory accumulates. The pipeline underneath a memory, keeping it current on your schedule. Put the memory to work in a plan that runs the same way every time. The embedding representations behind semantic memories. Build graph structures from Corvic Tables by hand. Reach memories from your own agents and applications.