Entity Memory

An entity keeps a long-term memory that survives across all of its conversations. It decides on its own what is worth remembering, and you can inspect, curate or clean up everything from the Entity → Memory panel.

Memory is always active for a Digital Entity — it comes with the upgrade and cannot be switched off, together with the entity's state, attention and todo list.

Conversations are temporary, memory is not

A conversation is a temporary container — it ends, and some of the entity's own activations happen in conversations you never open. Only what the entity deliberately writes down survives: a durable fact goes into Memory, something to keep in mind right now goes into Attention, and work to be done later becomes a Todo.

So when you tell an entity something lasting, it stores it in the same turn instead of merely acknowledging it:

You: I am the owner of ERP.BG.

Entity: Noted and remembered — you own ERP.BG.

The stored item then appears in the Memory panel as a fact about you, and comes back in later conversations without you repeating it.

Each memory item has:

• a type — fact, episode, relationship, preference, procedure, observation, decision or generic;
• a subject — who or what the item is about (a person, a company, a project);
• the text of the memory, plus optional structured data;
• importance and confidence, so the entity can prefer strong, reliable memories;
• an optional validity period, for things that are only true for a while;
• an optional related user — the person the memory is about.

Examples of what an entity typically stores:

• preference — "Ivan prefers short, bullet-point answers and no small talk."
• fact — "Pileto Ltd's fiscal year starts on 1 April."
• episode — "On 12 August we walked through the supplier-import problem and agreed to retry the batch next Monday."
• decision — "We decided not to use automatic price rounding for wholesale orders."

Storing versus recalling

An entity only writes to memory when you actually tell it something new or changed. Questions are not stored:

You: What is my name?

Entity: (searches its memory) You are Ivan Argentinski.

Storing the same knowledge twice is also prevented — if the entity tries to save something it already holds, the existing item is kept and nothing new is created. When the knowledge has genuinely changed, the entity updates the existing item instead of adding a second one, so recall stays clean.

The entity looks into its memory before answering, instead of relying on what happens to be in the current conversation — and what it remembers takes precedence. If you once corrected the spelling of your name, that correction is used from then on, even if your name appears differently elsewhere in the conversation or in your profile.

How the entity recalls things

The text of every memory item is semantically indexed at the moment it is stored, so the entity can retrieve relevant memories by meaning, not only by exact words. Each entity keeps its own private memory search — memories are never mixed with other entities or with the shared knowledge indexes. Each item has an indexing state:

• New — stored, waiting to be indexed (normally only for a moment).
• Indexed — searchable semantically.
• Archived — kept in memory, but removed from the semantic search. The entity can archive old or noisy items to stay focused and to conserve resources; archived items are still visible in the panel and can be restored at any time.

Example: you tell the entity "I prefer short answers in the morning." It is saved and indexed immediately, so a later question like "how should you write to me?" finds it right away, without any manual indexing step.

Who a memory is about

Preferences, relationships and observations are always attributed to a person. By default the entity attributes them to whoever it is talking to, so several people can work with the same entity and each gets their own preferences back:

• preference, related user Ivan — "Prefers short, bullet-point answers."
• preference, related user Kalina — "Wants every number confirmed against the source document."

When a memory is about someone else, the entity records that person instead. Facts and procedures usually have no related user at all.

Memories about other people and things

A memory can be attributed to someone other than the person talking:

• Another Operator user — the entity looks the colleague up by name and links the memory to their account, so their preferences come back for them and not for you.
• Anyone or anything else — a customer, a contact, a family member, a team, a project or a company is stored as a plain "related to" label, e.g. related to Dr. Georgiev or related to Project Atlas.

Either way, you can ask "what do you know about X" and the entity filters its recall to that subject.

What kinds of things it remembers

Memories are filed by kind, and each kind is used differently:

• Facts — durable information believed to be true, checked before the entity asks you something it may already know.
• Preferences — how you or someone else wants things done when there is more than one reasonable option. Only what you state or clearly establish; a one-off choice does not become a rule.
• Procedures — reusable methods, conventions and rules for getting something done. Not the steps of a single task.
• Episodes — significant, instructive or unusual events worth referring back to. Routine activity is not kept as history.
• Relationships — what experience has taught the entity about working with a person or organization: reliability, responsiveness, what works well together. These impressions never override permissions, obligations or business rules.

Each memory can also record who or what it is about — a colleague with an Operator account, or any other person, customer, team, project or company by name.

It checks its memory before acting

Recall is not only for questions. Before the entity does something — creating or carrying out a reminder, writing or answering an email, arranging a calendar entry, changing data or preparing a report — it first looks for what you have already told it about that kind of work and about the people involved.

That means a standing instruction only has to be given once:

You: Before meetings, prepare an agenda and email it to me 30 minutes before.

Entity: Remembered. I will do that for your meetings from now on.

From then on, whenever a meeting appears, the entity finds that preference on its own, schedules the work for the right moment and sends the agenda — without you repeating the request. If something you ask for right now conflicts with a remembered preference, the current request wins and the entity mentions the difference.

Recent memories come first

Recall favours what is fresh: among memories that match a question equally well, the ones updated most recently are returned first. A strongly matching old memory still wins over a weak recent one, and nothing becomes unreachable with age — for questions clearly about the past, the entity switches the recency preference off.

Managing memory yourself

In the Entity → Memory panel you can search the memory, filter by person, archive or restore items, delete items permanently, and trigger re-indexing after bulk changes. Deleting is final — the entity will genuinely no longer know that thing.