Time travel
Read memory as of any date, follow how a fact changed, and ask what the company believed in July.
Most memory overwrites. A fact changes, the old one disappears, and the record of having believed it goes with it. Memtro supersedes instead: the old fact stays, stamped with the day it stopped being current, so memory can be read as it stood on any date.
That is the difference between a memory you can audit and a memory you can only trust.
Two clocks, not one
Every memory carries two time axes, and keeping them apart is what makes the question answerable. The first is when the fact held in the world: its validity dates, where the text stated them. The second is when Memtro believed it: from the moment it was recorded until a newer memory replaced it.
A renewal can move to September in a June email. The fact about September is valid from June; the fact about July was believed until June. Systems with one clock have to pick which of those two to keep, and lose the other.
The two clocks mean a statement has two separate endings, and they mean different things:
| What it means | How it reads | |
|---|---|---|
| Ended | Memtro still believes the statement; what it describes is over. | "The contract ran until June." Still worth saying, and ranked below what holds now. |
| Revised | Memtro has withdrawn the statement; something replaced it. | "The renewal is in July", corrected to August. Only an as-of read surfaces it. |
Both can be true of one statement — a fact about a contract that ended in June can itself have been corrected in July — so neither is ever reported as though it were the other.
Memories arrive in the prompt tagged with the day they were recorded, whether they are shared or personal, the system they came from, how many independent sources have confirmed them, and whichever of those two endings applies: ENDED 2026-06-30, or revised 2026-07-14. The tag is all that stops an old fact being read as a current one, so it is never left off.
Three ways to read the past
Pin a request to a date
Memory is read as it stood at the end of that day: what was believed then, with nothing recorded or corrected since, and recency measured from that day rather than today. The injected context is headed with the date, and a memory revised since is marked with the day it was.
{ "model": "memtro", "memtro": { "as_of": "2026-07-31" },
"messages": [{ "role": "user",
"content": "What is BigCo's renewal worth, and when is it due?" }] }
The date is a calendar date, YYYY-MM-DD; anything else is refused with a clear error rather than quietly read as today. The model is told explicitly that memory is pinned, and to say which date its answer reflects.
Ask for one entity's history
memtro_timeline walks how knowledge changed: the memories recorded or superseded in a window, oldest first, each with when it was recorded, when and by what it was replaced, and the dates it was valid for. Name an entity to follow one thing, or leave it out for everything that changed. It is the only read that returns superseded memories.
Supersession is many-to-one — consolidation folds two memories into one replacement — so what comes back is a connected group rather than a strict line. It still reads as a chain: what was believed, then what corrected it, then what corrected that.
From any client
as_of works on the memtro_search and memtro_explore tools too, so Claude Code, OpenCode, Cursor and your own agents read the past through the same MCP server. The model reaches for these on its own when a question is about the past or about change.
On the page
Dashboard → Memory → Timeline draws it: one spine down the window you choose, a corrected statement greyed and joined by a line to the statement that replaced it. Above it, how many statements the window recorded, how many it withdrew, and how many describe something now finished.
Pick a window — 7, 30 or 90 days, or two dates — or focus one entity to follow a single deal, customer or decision through its corrections. A chain that starts before the window or continues after it says so, rather than beginning mid-story with no explanation.
The page is read-only, deliberately. Corrections are made where they are learned, or on the Contradictions tab; a history that could be edited from the page that renders it would not be a history.
Relationships rewind too
For a while the facts rewound and the graph around them did not: somebody who left in March still worked at the company, whatever date you asked about. An edge now carries the same two clocks a memory does, so an as-of read sees the organisation as it was shaped then — who worked where, who owned what, who was on which team.
Endings are recorded when the text states one, and whether a later assertion undoes an ending depends on who is asserting: a person saying the relationship holds revives it, an hourly sync that has not caught up does not. Present-day answers are given the live relationships; the explorer shows the ended ones, marked.
Looking back never rewrites the present
An as-of request learns nothing from the exchange. No extraction runs, and it does not even raise the use counts of the memories it read — so interrogating March leaves no trace on what the company knows today. That is the difference between an audit trail and a mess.
What people use it for
- Audit a decision. You chose a vendor in March. What did you know in March? Not what you know now, with hindsight attached: what was actually on the table.
- Settle a disagreement. Two people remember the renewal figure differently. One of them is remembering the figure from before the seats were added, and the timeline shows exactly when it changed and which email changed it.
- Catch up after two weeks away. Not a summary of everything, which you already knew most of. The facts that were recorded or corrected while you were gone, oldest first.
- Show your work. Every fact carries the tool, record and URL it came from, and every correction carries the day it arrived. An answer about the past can be followed back to the record that produced it.
- Watch a deal move. One entity, one quarter: every figure and date it was given, and what replaced each one.
What it does not do
- It is memory's history, not your systems'. As of July means what Memtro believed in July. It cannot show you a CRM record as it stood then unless memory had recorded it by then.
- Connector tools stay live. A pinned request still reads today's mailbox if the model calls a connector, because the connector has no past tense. What is pinned is memory.
- Erasure is not undone by it. Rows removed by an erasure are gone from every date; the receipt is the record that they existed.
- A merge cannot be unwound. Two entities folded into one are one entity in every reading, which is why a merge needs a shared identifier or a model's explicit agreement before it happens.
Supersession is how memory stays tidy as well as honest: a correction replaces a fact instead of sitting next to it, so retrieval is not picking between two truths. The history is a by-product of doing that properly. See how history works under Memory, and the API reference for as_of.
Also worth reading
- Memory — how facts arrive, how they are ranked, and what every answer is told.
- Contradictions — two things the company believes that cannot both be true.
- Privacy and erasure — the one thing that does remove history.