Agent memory for companies

What it is

A knowledge graph with a semantic index beside it. Named things, people, companies, tickets, deals, repositories, documents, are entities with aliases and the identifiers other systems know them by. Facts about them are typed, carry a confidence and an importance, and record where they came from: the tool, the system, the record and the URL. Relations join them: who works where, who owns what, who promised what in which meeting. Retrieval is hybrid, vector similarity fused with full-text rank and weighted by recency and importance, then widened to the entities the question mentions and one hop of the graph around them.

Nothing here is a pipeline you run. There is no vector database to operate, no embedding key to buy and no ingestion job to write: the index, the encoder and the cross-encoder that ranks what reaches the model are part of Memtro.

• KindA fact, a decision, an event, a procedure or a preference — a hedged remark and a contract term do not rank against each other as equals.
• Two clocksWhen it held in the world, and when Memtro believed it. Keeping them apart is what makes history answerable.
• ProvenanceThe tool, the system, the record id and a URL that opens it.
• CorroborationHow many independent sources assert it. Two systems agreeing is the strongest signal a memory system has.
• Confidence and importanceHow sure the extractor was, and how much the fact should weigh when it competes for a slot.
• UseHow often retrieval has handed it to a model. A memory that keeps earning its place is worth more.

An entity gets the same treatment: a nightly pass writes its card — two or three sentences on what it is and what currently matters about it, from the facts memory holds — and the card is what the entity is then found by, so which customer keeps missing payments reaches a card that says so. Amounts, dates and counts are lifted onto the entity as well, so a question that compares or totals is answered from recorded values rather than from reading every sentence and hoping none was missed.

Where it comes from

• Conversations. After each reply, the exchange and the tool results it used go through an extractor that keeps only what is durable: facts, decisions and their rationale, events, procedures and preferences. It runs only when something durable was plausibly said, and never twice for the same exchange.
• Connected systems. Connector results are anchored into the graph deterministically, without a model call: a CRM contact becomes a person keyed by its id, a ticket becomes a ticket joined to its customer. An hourly sync pulls recent records across 144 connectors, and the ones that can also walk backwards towards a horizon a year back, so memory knows the company's shape before anyone asks.
• Agent runs. A multi-step investigation saves the durable facts it learned on the way, never secrets. Any SQL that ran and returned rows is kept with the tables it touched, so the next person asking a similar question starts from a query that already worked.
• Imports. What ChatGPT or Claude already remember about you can be pasted or uploaded, stored under the scope you choose, and run through the same extraction.
• The organisation itself. Every hour its members and teams become entities too, so a question about who owns billing has somebody to point at.

The exchange an extractor read is kept too, so a better extractor is a query away from everything it has not seen: a nightly pass reads the backlog again, under the scope the first reading had, so a private conversation re-read cannot publish to the organisation.

How it gets to the model

Retrieval is the part of a memory system that decides whether the rest of it was worth doing. Four ways in are fused on one scale, then what reaches the prompt is filtered twice.

1. 01Vector and full-text, together. Semantic similarity over memories and entity cards, fused with Postgres full-text rank, so a question that names an invoice number and a question that describes a situation both land.
2. 02The entities the question names. Plus one hop further out: who is Priya's manager is answered by a fact attached to Dan, not to Priya.
3. 03The question read in its conversation. “And who does she report to?” scores 0.17 against the memory that answers it and 0.67 with its antecedent restored. A thin message is searched with the names already mentioned — no model call, nothing to configure.
4. 04A cross-encoder reads each pair. An embedding never sees the question, which is why it mistakes a shared word for an answer. A cross-encoder scores question and memory together: −6.7 for the plausible-but-wrong fact against +9.6 for the one that answers. It runs on the same machine, in about 70 ms for forty candidates.
5. 05A relative gate, and a spread. Hits are kept relative to the best this query could find, and a second phrasing of a fact already taken loses its slot to a distinct one. When nothing comes close, the context block says so rather than handing the model eight facts that merely share a word.

Ranking then multiplies relevance by what memory knows about the memory itself: a six-month recency half-life, importance, how often it has been used, how many independent sources assert it, and a heavy discount once a stated validity has run out — ranked below what holds now, and labelled rather than hidden.

The handful of facts that bear on every question — what the company does, who is who, what matters this quarter — cannot be retrieved, because bearing on every question means being closest to none of them. An organisation writes those by hand, and they ride in the cacheable prefix of every prompt along with the confirmed glossary.

Personal, team and shared

Every write has a scope, and the request's memory setting is a ceiling. In a shared request the extractor classifies each fact: company, customer, system and colleague knowledge stays shared, while your own preferences, working style and reminders are stored as personal. In a personal request nothing is promoted. A personal statement never supersedes a shared fact, and a shared one never overwrites what is yours.

There is a third scope between them: a team's. It is written when somebody leaves and their working knowledge is handed to the people who need it next — one of three choices offered on removal, with a receipt either way. And everything personal is personal within an organisation, so somebody who belongs to two has two separate memories, which is the only reading of personal that cannot leak one client's notes into another client's answers.

The registers

Five things a memory can keep once it holds the whole company in one place, each an entity in the graph rather than a separate store, each read nightly from what memory already holds, and each off until an organisation turns it on.

• CommitmentsWho promised what, in a meeting or a channel, by when, and whether the other systems show it landed.
• ContradictionsTwo things the company believes that cannot both be true, found by reading memory against itself and settled by answering.
• JargonThe words your business uses in its own way, found where they recur across systems, with what they point at.
• DecisionsThe reasons behind the code, read from pull requests and threads, kept against the code and posted back on request.
• MetricsA question you keep asking, saved as a figure measured on a schedule and remembered with its provenance.

Time travel

Pin a request to a date and memory is read as it stood at the end of that day: what was believed then, with nothing recorded or corrected since. Ask for one entity's timeline and see the facts recorded and superseded in a window, oldest first, each with what replaced it. Looking back never rewrites the present: an as-of request learns nothing from the exchange, and does not even raise the use counts of the memories it read. It is how a decision made in March is audited against what was known in March.

See Time travel.

Erasure

"Delete everything you know about this person" is answered across every store: the entity with its aliases and identifiers, every relationship, every recorded value, every fact that mentions them, the kept exchanges whose transcripts do, and whole conversations that do. The preview shows what would go before anything does, every name the person is known by is searched, and a receipt records what went — checked by running the same searches again inside the same transaction, before the commit. The same work is available over the API, for the people who answer such requests without being administrators.

See Privacy and erasure.