It stands on its own
A kept fact carries its own subject and its own meaning. It does not need the twenty messages around it to make sense, which is what lets it be given to an assistant that has never seen the conversation it came from.
Product
A conversation goes in. What is still true comes back out.
MemoryAgent reads what your assistant was told, keeps the part that will still matter next month, and hands it back when it is asked for. Everything it holds for you lives in a space of your own — one that no other customer's request can reach into.
What a memory is
A memory here is a fact, not a transcript
A transcript records a conversation: everything said, in the order it was said, including the half that stopped being true an hour later. A memory is the smaller thing underneath — a statement that is still the case, written so it can be read on its own.
It is written once
The same thing said in four sessions is one memory, not four. Wording that agrees with what you already hold refines it; wording that contradicts it replaces it, and what was replaced stays in the raw record rather than disappearing.
Filler does not survive
Greetings, acknowledgements, thinking out loud, and the part of a conversation that only mattered while it was happening never become memories. Nothing is served by remembering that someone said it sounded good.
How it works
Three layers, each one smaller than the one below it
Nothing is discarded on the way in. Each layer is derived from the layer beneath it, so a later improvement in how facts are read can be applied to everything you have already sent.
The record
What you sent, kept as it arrived. It is never edited, and routine cleanup never destroys it, because it is the only thing that makes every layer above it reproducible. Better extraction later is worth nothing without it.
The facts
Durable statements, read out of the record and checked against what you already hold so the same thing is not kept twice. Each is filed by who or what it is about, which is what makes a later question answerable without reading anything else.
The picture
Facts about one subject gathered into something readable in a single pass: what is consistently true of a person, a project or a customer. This is the layer an assistant reaches for when it needs orientation rather than one specific answer.
Coming back out
Retrieval is a question, not a download. Your assistant asks what is relevant to the task in front of it and receives a short, current set — found by meaning and by the exact words at the same time, then ranked together, so a memory phrased differently from the question still comes back.
retrieve
pfmem search --memory-type user --user-id u_42 --query "deploy process"Extraction runs behind you
Sending a conversation returns a task id immediately; the facts appear once the job has run. Nothing your user is doing waits for us, and you can ask a task how it went at any point.
Separation
Separation you can point at
Most services keep every customer's information in one big list and tell one customer from another with a label. That works until a single request forgets to check the label — and a request that forgets looks entirely ordinary to the person reviewing it.
One big list, and a label
Everybody's information in the same place, held apart by a label that every request has to remember to check. The failure is silent: the request comes back with an answer, it is simply not only yours.
A space of your own
What we hold for you sits in a space that holds nothing else. A connection opened on your behalf is pointed into that space, and nowhere else, before the first request is even assembled. There is no label to forget, because there is nothing else in there to confuse yours with.
A key resolves to one workspace, on our side
Your API key is what tells us whose space to open. A client never names a workspace and never names a filter — there is no field in which it could. So there is no way for it to name somebody else's.
Deleting a workspace removes everything in it
The contents stop existing. Not a flag set on an entry, not a view with something filtered out of it, and not something a later request could quietly include again.
Leakage is tested on every change
Against the same shared connection handling we run in production, because that is the only setting in which this kind of bug appears at all. A test on a simpler setup would pass and prove nothing, which is worse than no test.
Your data
Reading it back, and getting rid of it
The claims worth making about somebody's data are the ones they can act on without asking us first.
Read it back
Every memory we hold is reachable through the API and the CLI: search it, fetch one by id, edit it, delete it. What a key of yours can reach is the whole of what sits in your workspace, and nothing outside it.
search · get · edit · deleteDelete it, properly
Deleting a workspace removes everything in it, outright. It is irreversible, we call it irreversible everywhere it appears, and doing it takes typing the workspace's name. Routine cleanup only ever marks; deletion is the only thing that destroys.
irreversible, and said soA record of what was done
Creating a workspace, issuing a key, suspending one, deleting one — each is recorded. Deletion strips the identifying details out of those records but keeps the events themselves, because an audit trail that can delete the evidence of its own deletion is not one.
events kept, names removedA single-call export is not built yet
Today you read your data back a question at a time, through search and get. One call that returns everything held in a workspace is on the list and is not shipped. We would rather say so on this page than have you discover it at the moment you needed it.
See what survives a conversation
Create a workspace, send one transcript, and read back what was kept. If it was not for you, delete the workspace and there is nothing left of it to ask us about.