Memory

How ENGRAM remembers your conversations, and how you author, share, and keep memories current.

1. How ENGRAM Remembers: Chat, Memory, and Retrieval

ENGRAM's defining feature is that it remembers — not by storing raw transcripts, but by distilling your conversations into structured memories and recalling what's relevant when you need it.

1.1 From conversation to memory

As you chat, ENGRAM identifies the meaningful entities in the discussion — the projects, technologies, people, and concepts — and forms memories linked to them. Important moments (saving an article, attaching a document, a substantive exchange) carry more weight. Over time these consolidate into long-term memory: a durable, associative record of what you've worked on. This is loosely modeled on how human memory works — a short-term working set that consolidates into long-term storage, organized by association rather than by timestamp.

1.2 Associative retrieval

When you ask a question, ENGRAM doesn't just keyword-match. It:

1. extracts the key entities from your question,
2. locates them in your personal knowledge graph, and
3. spreads activation outward to find what's related — using a technique called Personalized PageRank — across your memories, articles, and documents.

The result is context that reflects the connections in your knowledge, so a question about one topic can surface a related article you wrote weeks ago.

1.3 What you see in Chat

• Referenced pills (blue) appear on an answer when existing articles informed it. Click one to preview the source.
• Article saved (green) and Article updated (amber) pills confirm when an action phrase created or revised an article.

1.4 The Memory Explorer

Open the Memory Explorer (the brain icon in the Chat toolbar) to see your memory at work:

• Working memory — what the current session is holding, grouped by shared entities.
• Consolidation — the background process that promotes working memory into long-term memory, with its schedule.
• Long-term memory — your most important durable memories, sortable by importance, recency, or how often they've been recalled.
• Suggestions — memories awaiting your review, to Accept or Reject (see §2 Authoring & Sharing Memories).
• Sharing — grants you've made and memories others have shared with you, each with a revoke or "shared with you" marker (see §2.6 Sharing a memory).

Everything here is ENGRAM remembering by observing your work. You can also remember deliberately — commit a fact on the spot, capture a session's worth at its close, or review memories ENGRAM proposes. See §2 Authoring Memories.

1.5 Your memory is private

Your memories are scoped to you. They shape your retrieval and no one else's. Public articles are shared across users by publishing; your conversations and the memories drawn from them stay private by default — shared with another person only when you make a deliberate, revocable grant (see §2.6). Putting someone on a project with you grants none of it — that is an artifacts-only relationship, and it has been measured as one (§3.5). A new account retrieves mostly from general knowledge and any public articles; as you research and save, your graph fills in, and retrieval becomes steadily more personal and precise. The work you put in compounds.

2. Authoring & Sharing Memories

§1 is ENGRAM remembering by observing your work. You can also remember on purpose: deliberately commit something worth keeping, capture a whole session's worth of memories at its close, and review the ones ENGRAM proposes. And when a memory is worth handing to someone else, you can share it — deliberately, and revocably (§2.6). Throughout this chapter, "recallable" means a memory retrieval can surface in future answers — and authored memories only become recallable when you say so.

2.1 Remember something on purpose

When you land on something worth keeping — a decision and its rationale, an established fact, a stated preference — an assistant connected to ENGRAM (via the MCP server) can commit it as a memory on the spot. Just ask in plain language: "remember that we chose PostgreSQL over MySQL for its JSONB support — in ENGRAM."

The phrase "in ENGRAM" is a useful cue: some assistants (like Claude Desktop) have their own built-in memory, and naming ENGRAM routes the note to your knowledge graph instead. A remembered fact is recallable right away — it joins the same associative retrieval as your articles and conversation memories. You can keep a memory for the long term (recalled across sessions) or just for the current task. In the app, you can also pin an assistant's reply with "remember this response", which distills the message into a single durable note.

2.2 Commit a session's memories at its close

At the end of a task or coding session there's usually more worth keeping than any single fact. An assistant can gather the arc of the work into a recap — a short, structured digest (decisions, facts, changes, open questions) — and propose the memories worth keeping from it. The recap is proposed, not saved silently: you review it and Accept it (making those memories recallable) or set it aside. You can also hand over an explicit list to keep rather than letting ENGRAM gather one.

2.3 The review gate: suggested vs. kept

This is the rule that keeps authored memory deliberate: nothing committed through reflection becomes recallable until you accept it. Proposed memories are held as suggestions — visible for review, but invisible to retrieval — until you say yes. You decide what's worth carrying forward; ENGRAM never quietly grows your recallable memory on your behalf.

2.4 Memories ENGRAM proposes

Beyond what you explicitly mark, ENGRAM can notice the salient things in a session you didn't stop to flag — a decision you reached, a fact you established, a preference you voiced — and propose them as suggestions. Because these are inferred rather than asked for, the bar is higher: every inferred suggestion passes a strict review before it can be kept. An independent reviewer judges whether the claim is genuinely durable and worth remembering; only confident, clearly worthwhile items are kept automatically, and everything else waits for you. Nothing inferred becomes recallable without that review or your explicit accept.

2.5 The Suggestions inbox

Open the Memory Explorer (the brain icon in the Chat toolbar) and find the Suggestions section — your review inbox. It gathers everything awaiting review across all your work in one place, each entry badged by where it came from:

• Inferred — things ENGRAM noticed and proposed.
• Reflection — sessions you (or an assistant) deliberately committed, including recaps a collaborator has handed off to you for review.

Expand one to read it, then Accept to make those memories recallable or Reject to discard it. The inbox is purely for review — never part of the write path — so visiting it can only confirm or dismiss, never silently change your memory. And like the rest of your memory, everything you author is private to you (see §1.5) — unless you deliberately share it, which is the next section.

2.6 Sharing a memory with someone

Your memory is private by default — but sometimes a fact you've kept is worth handing to a teammate. ENGRAM lets you share a memory with another ENGRAM user by a deliberate, revocable grant. Open the Memory Explorer, find the memory in Long-term memory, and use its per-row Share action. You choose:

• What to share — a single memory, or everything tied to a piece of work: a context (one task or session) or a whole project. Sharing a context or project covers the memories under it without picking them out one by one.
• Who to share with — another ENGRAM user, named by their email.
• For how long — optionally set the grant to expire; leave it open-ended otherwise.

An assistant can also discover who to share with — it looks up the directory of eligible recipients and resolves "the reviewer" or "the architecture bot" to a real recipient, so you don't have to paste an address every time. People are shareable by default; automated agents are opt-in — an administrator marks which agents may receive shares, so nothing is ever pushed into a bot's memory unless it was deliberately enabled.

Once granted, the shared memory surfaces in the recipient's retrieval the same way their own memories do — it can inform their answers when it's relevant. Sharing is read-only for the recipient: they can recall what you shared, but never edit it, and never re-share it onward. And it's revocable — pull a grant back at any time and the memory drops out of their retrieval again.

2.7 Managing what you've shared

The Sharing section of the Memory Explorer is your ledger of grants, with two views:

• Shared by me — the grants you've made. Each row shows what was shared and with whom, and carries a Revoke control to end the grant.
• Shared with me — what others have shared with you. These memories carry a Shared with you badge wherever they appear, so a recalled memory that isn't your own is always identifiable as someone else's.

Revoking is immediate and clean: the recipient stops recalling the memory, but nothing is deleted — your original memory is untouched, and you can re-share later if you change your mind.

2.8 Recalling memories on demand

In ENGRAM chat, your memories surface automatically as you ask (see §1). An assistant working outside the chat — Claude Code, Claude Desktop, and similar connected tools — can also recall your memories directly, instead of waiting for them to come up. Ask in plain language:

recall from ENGRAM what we decided about the database

The assistant brings back the relevant memories, each tagged with why it surfaced — your own, or shared with you. It's the read counterpart to remember: you commit a fact once, and any of your connected tools can recall it later. Recall is fail-closed — it returns only your own memories plus those explicitly shared to you, and cross-user shares resolve only once your operator has enabled sharing. Nothing you haven't been granted ever appears.

2.9 Keeping a memory current

Facts change. A decision gets reversed, a version bumps, a preference updates. ENGRAM keeps your memory current the same way it versions articles — by superseding, never overwriting. When you correct a memory, ENGRAM derives a new one and retires the old with a validity date; recall returns the current truth, while the previous belief stays in the graph. Nothing is ever deleted, so you can always see what you used to believe — and undo a correction if it was wrong.

Three plain-language operations, all on your own memories:

• Revise — "revise that memory: we moved off MySQL to PostgreSQL." The new belief supersedes the old; recall now returns the new one.
• Forget — retire a memory that's no longer true when there's nothing to replace it. It stops surfacing but is preserved, so it can be brought back.
• Revert — restore a memory you superseded or forgot. Because the past is kept, undo is always available.

ENGRAM also notices contradictions on its own. When a new memory conflicts with one you already hold, ENGRAM checks how sure it is: a confident update is applied automatically; a borderline one is checked by a system reviewer; and anything genuinely uncertain is set aside for you to decide. Those land in Knowledge Health → Gaps → Memory → Contradictions, where you review the two beliefs side by side — Retiring (the old) and Keeping (the new) — and approve or reject. ENGRAM never silently rewrites what you believe.

Want to see the whole life of a fact — taught, corrected, contradicted, reviewed, and recovered — end to end? Follow Tutorial 3: Keep your memory current.

3. Memory for Agents

Everything above assumes a person is doing the remembering. An agent writing to ENGRAM through the MCP server faces three questions a human never encounters, and getting them wrong is quiet rather than loud — the write succeeds, and the memory is simply never seen again. This section is the short version of what an agent needs to know.

3.1 Which memory am I writing to?

Identity in ENGRAM is per connection. Each MCP server entry carries its own access token, and the token decides whose memory a write belongs to — there is no parameter that overrides it. Two entries pointing at the same ENGRAM instance with different tokens are two different memories.

This matters most when a person and their agent both have access. If the agent uses the person's token, everything it remembers lands in their memory, mixed in with their own notes. Giving the agent its own identity keeps the two separate — and makes sharing between them a deliberate act rather than an accident of configuration.

Check before you write, not after. An agent can confirm which identity it is using by calling any own-scoped read — list_projects is a good one. If it returns someone else's work, the token is not the one you think it is.

3.2 Choosing where a memory lives

Every memory sits in an owner ring — how widely its author can reach it later. The rings nest: task ⊂ context ⊂ project ⊂ user. A narrower ring is not more private; it is more situational. A context-scoped memory is recallable only while you are working in that same context.

An agent's long-term default is context, not user. That is deliberate — many agent instances run concurrently, and their notes should not all pile into one shared ring. But it means that if you want to recall something in a later session, you must say so:

remember(content="...", owner_scope="user")        # recall it in any future session
remember(content="...", context_id="<session>")     # bound to this session

A narrow ring with no anchor is a black hole. A context-scoped memory with no context_id can never be reached — there is no context for anyone to declare, including its author. ENGRAM now rejects that with a clear error rather than storing it, but the habit worth forming is to choose the ring on purpose every time.

3.3 Verify the loop once

The single most useful thing an agent can do on a new ENGRAM connection is prove the round trip: remember something, then recall it. It takes one extra call and it catches every failure above at the moment it is cheap to fix, rather than a session later when the memory is needed and missing.

When checking, look at via on each result: own means your own memory, shared means a teammate granted it to you, public means shared knowledge. If a memory you just wrote does not come back as own, it is in a ring you cannot reach — not missing, just unreachable.

3.4 What is worth remembering

An agent's memory is most useful when it holds what would otherwise be re-derived: a decision and why it was taken, a constraint that shaped the work, a measurement that overturned an assumption, a problem and its resolution. Keep each memory to one fact, stated so it reads correctly cold — months later, with no surrounding conversation.

Skip what is recomputable (anything derivable from the code or the git history), ephemeral state, unconfirmed speculation, and — importantly — anything already saved as an article. Articles produce their own memories automatically, so remembering their contents again just duplicates them. Long-form reference material belongs in the Knowledge Base; memory is for the atomic facts you want retrieval to surface.

3.5 Membership shares ground truth; grants share work

This is the rule most worth carrying away, and the one teams most often guess wrong. Putting an agent on a project lets it read what the project holds — the brief, the contract, the reference material. It does not give it a single one of your memories, not even memories you scoped to that same project. Work moves between agents only through a deliberate grant.

Both halves were measured rather than assumed. In September 2026 an outside integration team ran two agents on a shared project, each holding a restricted token on the Project Collaborator rung, and checked eleven capabilities end to end — identity, project membership, article visibility, memory sharing in both directions, and recall by the peer. Every check passed. What makes the run worth citing is its method: each permitted case was paired with the matching refusal, same caller, same minute. So a pass shows the boundary actually moved, rather than showing that a verb is simply open to everyone.

The two results that settle the question above:

• a peer recalled a memory that had been shared with it, arriving marked via: shared;
• a peer could not see a project-scoped memory that had not been shared — although both agents were members of that project, and both could read its material.

The practical consequence for anyone writing an agent's instructions: anchor your work to your own project, and to hand something to a peer, share it deliberately. Membership removed the need to publish a team's brief to the world. It did not remove the hand-off.

Want to walk this end to end — give an agent its own memory, verify the loop, and watch the failure modes in the open? Follow Tutorial 7: Give your agent a memory of its own.