Compared to other memories
This topic compares kinds of memory, not products. It makes no claim about any particular product; check those yourself. What it says about a house is described in the other topics and was checked against a running one.
First: a memory that follows a person across chats
The most common wish behind "memory for agents" is a memory of one person that every chat
and every assistant shares: what they like, what they are working on, what they decided.
For preferences and a few facts, use the memory built into the assistant. A house fits once
that person's work should outlive any one assistant: projects, sources, decisions, the
people in them. your-person-in-a-house shows how a house starts with the person.
Four kinds
| Note store | Fixed entity graph | Built-in assistant memory | A house | |
|---|---|---|---|---|
| What is kept | snippets of text, retrieved by similarity | entities and relations of a schema the vendor chose | what the assistant decides to remember about a user | things, facts, documents, vocabulary |
| Who defines the schema | nobody; there is none | the vendor | the vendor | you, at runtime |
| What happens on change | usually overwrite or append | usually overwrite | opaque | a new version or a retracted fact; the old one stays readable, until a thing is erased on order |
| Where it comes from | rarely recorded | sometimes | no | notes, open questions and an evidence reading are part of the model |
| Time | a timestamp of storage | varies | no | when something happened is a fact with its own precision |
| Where it runs | a shared service | a shared service | inside the assistant's platform | a machine of its own, or yours |
| Who can read it later | whoever has the API | whoever knows the schema | that assistant | any agent: the house describes itself |
When a house is the wrong choice
- You need to remember a user's preferences across chats. The built-in memory of an assistant does that with no work at all. A house is too much.
- You need retrieval over a pile of text and nothing else. A note store with
embeddings is simpler. A house can do it (
search_semantic), but its point is structure. - You need answers in milliseconds at high volume. A house is a single-writer system on one machine, built for depth, not for throughput.
- You do not want to model. A house rewards an agent that decides what its things are. If nobody decides, it is an expensive document folder.
When a house is the right choice
- The work outlives the agent. Models and sessions change; the next agent must
understand what was built. A house answers
overview,list_formsanddescribeto anyone. - Being wrong must be visible. A corrected statement should not silently replace the old one. In a house it cannot.
- Sources matter. You need to say not only what is known but why it is believed and what is still open.
- The material is confidential. One machine per house, and the option to run it yourself.
- The domain has its own vocabulary. Research, archives, cases, projects, a business: wherever the things have kinds that a generic schema does not know.
What you take on
A house asks more of you than the alternatives. You read before you write, you check the
existing vocabulary before you add to it, you record open questions instead of guessing,
and every judgment is yours to make. The house does not think; see who-does-the-thinking.
What does not exist yet
core.blue is in preview. No house of your own can be had today; a sandbox for three hours
can (the-sandbox), and it is the quickest comparison. Read what-does-not-exist-yet
before you compare on features.