> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xysq.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Context Lake
> One context lake per user or team, holding many context graphs: Personal, Teams, and Agents. Agents read from one or many graphs and write only to their own.
In the product, a context graph is called a **vault**. Same thing: your vaults in the app are the context graphs in your lake.
Your context lake is the one place all your context lives. You (or your team) have exactly one lake. Inside it sit many **context graphs**, each one an independent body of memory built by the [Memory Engine](/concepts/memory-engine).
## Three kinds of graphs
| Graph | Owned by | Typical content |
| ------------ | ----------------- | ------------------------------------------------------------------------------ |
| **Personal** | You | Your AI-tool sessions, uploaded files, things you asked your tools to remember |
| **Teams** | A team | Decisions, playbooks, and context the team builds together; survives turnover |
| **Agents** | One agent you run | What that agent has seen and done, across every session |
The read/write rule is simple:
* **Agents read from one or many graphs, and write only to their own.** You grant an agent read access to the graphs it needs. Its writes always land in its own graph, so one agent can never pollute another's memory or yours.
* Your Personal graph is walled off from agent keys. An agent key you hand out reads and writes agent graphs; it cannot reach into your personal memory.
## What a graph contains
Every context graph is the same three things, layered:
* **Pages.** Readable, block-structured pages that hold the distilled state of a topic. Real prose a human can read, not entity dumps.
* **Facts.** Ledger rows with recency (valid from when, superseded by what) and lineage (verbatim evidence, dependency chains). A fact on a page is a rendered ledger row.
* **Entities.** First-class records with canonical names and aliases, so "the auth service", "authsvc", and "AS" resolve to one node instead of fragmenting your graph.
Underneath each graph sits its own immutable verbatim log (the raw pushes, byte for byte), and each graph lives in its own version-controlled vault, so every change is a commit you can diff.
## Getting context in and out
Your AI tools talk to the lake through four MCP tools (or the equivalent SDK calls):
| Tool | What it does |
| --------------- | ------------------------------------------------------------------------------------- |
| `userinfo` | Confirms the connection and reports the state of your memory |
| `push_context` | Ships a session in, verbatim; the engine distills it server-side |
| `pull_context` | Ranked semantic recall: fresh log content plus committed graph pages, merged by score |
| `share_context` | Proposes a share; nothing crosses until you approve it in the app |
Two properties matter here. Recall is fresh in seconds because pushed content is indexed immediately, before distillation finishes. And the calling tool does no orchestration: it ships verbatim content in and gets assembled context out. Everything in between happens in the engine.
## Ownership
A graph is plain markdown pages plus a ledger, in a vault owned by you or your team. You can export it anytime. The direction we're building, rolling out now: bring your own drive (the graph mirrored to storage you control, readable in standard markdown tools) and private deployment inside your own boundary. That is stated direction, not a shipped guarantee.
## Where to go next
Share a page, a graph, or everything; revoke anytime; audit every change.
Build agent graphs over the Python SDK, no MCP server required.