The context layer for AI agents
Your team's shared context, on tap for every AI agent
Everything worth knowing — pulled from the tools where it was written, versioned like code, and served to any agent over MCP. Every answer cites its source. Members propose, owners decide. Nothing is ever edited in place.
- MCP-native
- Your own container and database
- User-bound tokens, no service accounts
- Full history, readable at any revision
From the thread it was written in, to the agent that needs it
Six steps, five nouns. Simple enough to draw on a whiteboard — and time travel and audit fall out of it for free rather than being built on top of it.
Connect a source
A connector reads the layer where your team actually argues: GitHub issues, pull requests and their review threads, docs, releases. Nothing is re-typed, and nothing has to be authored twice.
It becomes a resource
One item of knowledge at a path in your tree, its content the text itself, its origin recording which source, which author, which URL, and when. The origin is what makes a citation possible three months later.
Every change is recorded
Recording a resource is a change — what, by whom, when and why — and each change produces a new revision. Nothing is edited in place, so "what did we know last Tuesday" is a read, not an archaeology project.
Your agent connects once
Point Claude, Cursor or anything else that speaks MCP at your instance with a token bound to a person. One connection, and every agent your team runs is reading the same context.
The answer cites its source
Full-text and vector retrieval, fused, filtered to what that person may see before anything is ranked. The answer arrives wearing its provenance: the revision, the resource, and the URL a human wrote it at.
Members propose, owners decide
Want the context to say something different? Open a proposal. An owner approves it into the history or rejects it without a trace. Agents get the same door — and only that door.
The GitHub connector runs today. Jira, Slack and Figma are next, in that order.
An agent cannot quietly rewrite what your team knows
This is the difference between a shared context and a data swamp with retrieval bolted onto it. Nothing enters the record because a model inferred it. Every change either came from a source, carrying its origin — or it came through a proposal that a person approved.
It is also the human-in-the-loop primitive for agents working unattended. An autonomous agent proposes; another agent, or a person, decides. Curation is the product, not a policy document somebody signed.
A proposal is decided once, and only while it is pending. Approved, its changes join the history as ordinary changes on the same straight line — there is no second kind of history for reviewed content to live in.
- Rejected means gone — no trace, no clutter, no half-state for somebody to find later and mistake for a decision.
- Reviewing is just a diff — proposed state is revision-addressable, so you read a proposal with the same call you read history with.
- Attribution survives — an agent acts as the person it serves, so the log answers "who did this" rather than "which robot".
- Re-syncing is free — writes are idempotent by content, so recording what a path already says records nothing at all.
Isolation is architecture, not a WHERE clause
Every customer runs their own container, with its own database file and its own index directory, replicated to its own storage prefix. There is no shared table with a customer column in it — so there is no filter bug that could leak one team's context into another team's answer, because there is nothing to filter.
The API has no customer id in it either. A request reaches one instance because of the hostname it arrived on and the token it carried, and that instance has only ever held one team's data — the details are here.
- Permission filtering before ranking — enforced inside the index query, never as a pass over results that already came back.
- Hidden is indistinguishable from absent — results never betray the existence of what was withheld.
- No service accounts — agents carry user-bound tokens and see exactly what their person sees, no more.
- Indexes are derived, not precious — only the record is replicated; search and embeddings rebuild from it.
Priced per team, like the infrastructure it is
You buy the context layer once and every agent your team will ever run reads it. Spend follows how much your team knows and how many sources it comes from — not how many assistants somebody signed up for this quarter.
One instance per team
The unit of pricing is the unit of isolation: your own container, database and storage prefix. That is what makes an enterprise tier a real boundary rather than a plan flag on a shared table.
Connectors and scopes expand it
Start with GitHub. Add Jira, Slack and Figma as they land, and finer permission scopes as your access model stops being uniform. Expansion follows what you connect, not how many seats you fill.
Design partners now
We are provisioning instances for teams who will use this daily and tell us where it is wrong. No public price list yet — that lands with self-serve sign-up, and saying so beats printing a number we would have to take back.
Get an instanceWeighing this against something you already run? The comparisons are written category by category — agent memory, enterprise search, platform-native memory, and plain RAG over your own documents.
Questions, answered
How is this different from agent memory?
Memory remembers what your agent said. Context records what your team knows. Memory layers store what a model inferred from its own conversations — per agent, mutable, unaudited. Xerum pulls from where the work actually happened, keeps every version, and only changes when a person approves the change. Different question, different store.
Which tools does it pull from?
GitHub today — issues, pull requests and their reviews, docs and releases, which is the richest conversation layer a software team has. Jira and Slack are next, then Figma. A connector turns what an author wrote at a source into a resource carrying its origin: which source, which author, which URL, and when.
How does an agent connect?
Over MCP, the protocol Claude, Cursor and every serious agent already speak. You point the agent at your instance's MCP URL with a token bound to a person, and it can search, read and quote the shared context immediately. There is a REST contract underneath it for everything else.
Can an agent change what my team knows?
Not directly. An agent — or a member — opens a proposal: one or more proposed changes with a message saying why. An owner approves it into the history or rejects it, and a rejected proposal vanishes without a trace. The record agents read from cannot be quietly rewritten by an agent.
What stops it from making things up?
Every answer arrives wearing its provenance: the revision it was read at, the resource it came from, and the origin URL at the source. You click from the agent's sentence back to the issue where a human actually wrote it. If a claim has no provenance, it did not come from your context.
Will an agent see things the person using it should not?
No. What a person may see is enforced inside the search query, before ranking — never as a filter over results that were already ranked — and their agent sees exactly what they see. There are no service accounts: an agent acts as the person it serves, with a user-bound token, so history always answers "who did this?"
Where does our data live?
In your own instance. Every customer gets their own container, its own database and its own storage prefix — there is no shared index with a customer column in it, so there is no filter bug that could leak across one. The isolation is architecture, not a WHERE clause.
Can we see what we knew last Tuesday?
Yes — that is just a read at an older revision. Every change is recorded and nothing is edited in place, so time travel and audit are not features bolted on top; they fall out of how the store works. Diff two revisions and you see exactly which change moved an answer, who wrote it, and what the message said.
Stop letting your agents guess
Connect one source, point one agent at it, and ask it something only your team knows.