← Documentation

Memory

Memory lives in pages. The old knowledge graph is retired: its tools are gone, and this page keeps its text for reference.

Memory

The knowledge graph is retired. Memory lives in pages: each person, pet, organization, project, or thing has an entity page, and its facts are the page's properties. Find a page with search, read it with view, and create or change it with artifact_exec. The rest of this page is about the old graph: its knowledge tools, the directory, the cards, and the constellation are gone. The text stays for reference until the old tables are removed. Owners and admins can still forget a person on the Memory page, and that also removes the person's pages.

Memory is what this workspace has decided exists, and what it believes about it -- kept separate from chat transcripts and drive documents on purpose. A card is one row for one real thing: a person, a pet, an organization, a project. A fact is one typed, sourced statement about a card -- a phone number, a species, who owns whom. Facts are never edited: a correction updates the old one, so the history of what the workspace believed stays readable. A link is a citation edge (this document mentions that card) -- navigation only, never a fact of its own.

Nothing is written directly

Every change is a suggestion, and a gate decides what happens to it, in code, with no LLM in the loop. Almost every suggestion commits immediately -- memory is meant to grow at the speed people actually say things, not at the speed of a review queue. A suggestion waits for a human only when it's a real conflict:

  • It contradicts what a card already says -- two values can't both be true, so something has to give.
  • Two cards turn out to be the same thing -- combining them is a judgment call, and hard to undo.
  • It's a new fact type -- growing the type system is a deliberate choice.
  • It's about forgetting a person -- always a human decision, explained below.

A low-confidence or unsourced suggestion still lands, but it renders visibly weaker on the card -- a well-sourced fact wins if the two ever disagree. An owner or admin can switch a workspace back to reviewing every suggestion before it lands.

Protected facts (anything a person could later ask to be forgotten -- a phone number, an address) never touch the permanent record in plain text: they're held behind a reference that can be revoked, so forgetting someone is possible without rewriting history.

Being protected is a storage decision, not a visibility one: a protected value's row keeps its ••• chip, and a small reveal control next to it shows the current value for that moment only -- nothing is cached, nothing is written down twice. Once a person is forgotten, revealing returns nothing, permanently.

Forgetting a person

Open a person's card and choose Forget this person… (workspace owners and admins). It asks you to type the person's name to confirm, because it cannot be undone.

That doesn't erase anything yet -- it sends a suggestion, and forgetting is the one decision this system will never make on its own, at any confidence, attended or not. It waits in Needs a look until a workspace owner or admin approves it. The card is marked as destructive so it can't be approved by reflex.

On approval, in one stroke: every stored value about that person is destroyed -- not hidden, the rows are deleted -- every fact about them and every fact pointing at them is retracted, their name is replaced with a neutral marker, and every contact linked to them is unlinked. Their card keeps only its kind and a Forgotten marker; the directory, the constellation and your agent's own context stop showing them entirely, and their name stops appearing on anyone else's card.

What remains is the honest shape of what happened: the log still records that a card was created, that facts were believed, and that on this date a person was forgotten -- with nothing left in it that says who they were. History is not rewritten, and it cannot bring them back: the record points at values that no longer exist anywhere, including in any view of the past.

Being forgotten is scoped to memory. Conversations, message transcripts and the contact rows themselves follow their own retention rules and are not deleted by this action.

Every agent also has its own memory

There are exactly two memories, and the difference between them is who has agreed to what.

The workspace memory above is shared truth: everyone acts on it, so nothing enters it without the gate. An agent's own memory is its private graph -- what it believes, notices, or wants to carry forward. It writes there directly, with no suggestion and no review, because it is the only writer and there is nothing to arbitrate. Want a memory nobody else's agent shares? Create your own agent; privacy here is ownership, not a setting.

An agent can keep private facts about things the workspace already knows -- its own read on a person, sitting beside the shared facts without touching them -- or create things only it can see. No other agent can read its memory or write into it. It never becomes shared truth by accident: promoting a private fact means suggesting it, and the gate decides like it does for anything else. One deliberate limit: a private note an agent adds to a shared card never enters search -- not even for the agent that wrote it. Search keeps one text per card, so anything only one agent can see stays out of it. The note still shows on the card, marked as that agent's.

Using an agent is not browsing its memory. Only the agent and the people who manage it can read an agent's own memory: its owner, and anyone with full access to the agent (workspace owners and admins have full access to every agent). They see it on cards as Agent notes, with the agent's name. Other members can use the agent and get its help, but they cannot browse its memory.

A fact keeps the audience of its source. A fact from a chat whose memory is private or off, or from a file that only some people can see, does not go into the workspace memory or into an agent's own memory. It stays with the people who could already see it.

Forgetting reaches all of it. When a person is forgotten, every fact about them is destroyed in every agent's memory too, in the same stroke, by the same mechanism.

People, across every channel

A contact is one channel identity -- one email address, one WhatsApp number. A person's card is the human behind them. Saying "this contact is this person" is what makes "she emailed last week and messaged this morning" one story instead of two: the person's card shows every channel they're reachable on, and their conversations all point at the same person.

A mention is not a person. Inbound messages create contacts freely and link nothing -- deciding that this address is that human is a judgement, so it goes through the gate like everything else. A contact is never silently re-pointed at a different person; if two people turn out to be one, combine the duplicates and every linked channel follows the survivor.

The Memory page

A searchable directory of cards, grouped by kind, with a live count per kind. Forgotten people are not listed. A Needs a look tab shows what's waiting for a human -- a real conflict, a duplicate-card decision, a new fact type, or forgetting someone -- and, for a conflict, what the workspace currently believes next to what's being suggested. A workspace owner or admin can approve or reject; everyone can see the queue. Click any card to open it: every fact, the channels it's reachable on, what it's linked to, what it's connected to, its recent history, and anything still pending on it. A Constellation tab draws the same thing as a graph.

Drive items carry a Linked memory row: which cards a document is about, and a way to add one. Contacts carry a Memory chip pointing at the person they belong to.

Using memory as an agent: the knowledge.* tool family

Three places a fact can go, and the choice is usually obvious: something private you noticed or believe → knowledge.remember (your own memory, commits immediately); something the whole workspace should act on → knowledge.propose_claim (shared, through the gate); a document, a how-to, or anything longer than one typed fact → the drive, not either of these. Facts are short and typed; documents are everything else, and belong there instead — linked to the people or things they're about, not stuffed into a fact's value.

  • knowledge.lookup -- find cards by name, optionally narrowed to a kind. Look up before creating: a duplicate card is expensive to undo.
  • knowledge.read_card -- read one card fully: facts, channels, relations, linked artifacts, recent history, pending suggestions.
  • knowledge.propose_claim / propose_referent / propose_supersede -- state a fact, declare a new card, or correct a live fact. Scored by the gate as above. Always cite a source: it's what makes a fact checkable, and a sourced fact renders stronger and wins if two ever disagree.
  • knowledge.propose_identity -- say that a contact belongs to a person ("this contact is this person"). Scored like a fact; never re-points a contact already linked to someone else without a human.
  • knowledge.propose_merge -- say that two cards are the same thing (combine duplicates). Always waits for a human, whatever confidence you have.
  • knowledge.propose_vocab -- grow the type system with a new kind, property, or relation. Reuse an existing fact type before proposing a new one; always reviewed by a human either way.
  • knowledge.add_link / remove_link -- navigation edges, written immediately (never gated -- a link carries no fact).
  • knowledge.list_proposals -- read the queue.
  • knowledge.remember -- write a fact into your OWN memory. Commits immediately, works unattended: your own memory is not the workspace's, so the gate has nothing to arbitrate. knowledge.read_card and knowledge.lookup return it back to you marked as yours.
  • knowledge.update_memory -- change or remove a fact in your OWN memory. Commits immediately, like remember. It reaches nothing but your own; the workspace's facts change through the gate.
  • knowledge.rule -- approve or reject, on behalf of the human present in the conversation. Refused on any unattended run: a pending suggestion exists precisely because code could not decide, and only a human breaks that tie.
  • knowledge.resolve_value -- reveal a protected value, for this one read, ephemerally. Any workspace member can look, but only when a human is present in the conversation, the same rule rule follows. A forgotten value resolves to nothing, forever.

There is deliberately no tool for forgetting a person. An agent cannot suggest it, cannot approve it, and cannot describe a person in the record of it. A human starts it from the card and a human approves it.

See the knowledge-keeper skill (equipped by default) for the full write etiquette -- look up before creating, cite sources, reuse fact types, and what to do on a bounce or conflict.