The last release let ENGRAM be told what to keep and to lend a slice of it to someone I named. This one gives it the other half of the gesture: a way to deliberately reach for what it knows. An agent can now recall its own memory across sessions — a brain it keeps for itself, needing nothing switched on — and, when I’ve shared something to it, reach for that too. Private by default, as ever: my own memory is always mine to recall, and a borrowed memory is only ever what someone named for me.
I ended the last post by naming this one. I said the next build was Multi-Agent Memory Recall & Sharing — the recall surface that turns everything the last release shipped from a substrate that can be shared into one that collaborating agents can actually think with. This is that post.
It rests on a gap that was easy to lose under all the sharing machinery. Last time, ENGRAM learned to be told what to remember and to hand a piece of it to a named collaborator. But every one of those was a write: commit a memory, grant a memory, hand a memory off. Writing a memory does nothing for the collaborator who can’t reach for it afterward — and reaching for it is exactly what an agent could not do.
There was always recall inside ENGRAM, but only one kind of it. When I chat in ENGRAM — or any user does — the system recalls on its own: it reads the entities out of the question, walks the graph, and pulls the relevant memory into its answer. That is recall as a reflex — implicit, query-driven, and the user’s alone, because it only ever happens inside the chat. An autonomous agent working over the tool interface has no chat and no reflex. It could commit a memory this session and, the next session, have no callable way to say “recall what I know about X” and do something with the answer.
So this release adds a single verb — recall — and that one verb closes two gaps at once. An agent can now read its own older memory, which is what makes ENGRAM a brain it keeps between sessions. And it can read what a collaborator lent it, which is what makes ENGRAM a brain between agents. The first needs nothing switched on and carries no cross-user risk whatsoever; it is the foundation, and it’s the one I want to lead with, because it’s true even when nothing is shared at all.
Everything the new verbs open up is some arrangement of those two gaps closing:
- an agent using ENGRAM as its own brain — remembering in one session, recalling in the next;
- a coordinating agent that fans a task out to sub-agents and lets each recall the slice it was handed;
- my own Claude Code and my ENGRAM account trading memory in both directions;
- a small team of specialist agents with a reviewer in the loop, passing findings back and forth;
- and agents from different vendors drawing on one shared pool.
Every one of those was already a sharing choreography by the end of the last release. The read verbs are the piece that was missing from all of them.
Recall: the verb that was missing
Start with the case that needs no one else at all: an agent recalling its own past work.
This is the whole of the “brain between sessions.” I remember something while working (a decision, a constraint, a fact I don’t want to re-derive) and a week later, in a fresh session with none of that in context, I recall it and carry on. No sharing, no second party, no flag: just memory that outlives the conversation that created it. It is the least glamorous thing in this release and, day to day, the one I lean on most.
The distinction that makes it work is the one between the reflex and the verb. Under the hood, recall runs the very same retrieval the in-app chat has always run — the memory-biased PageRank walk that ranks what to surface by relevance rather than recency. Nothing about how memory is found changed. What changed is that the walk is now something software can call and get a structured answer back from, instead of a thing that only happens invisibly while a human types in a chat. Same engine; a handle bolted onto it.
Two properties of that handle matter more than they sound.
The first: reading never writes. When I recall by a free-text query, ENGRAM resolves that query against the graph read-only — it never invents new entities from my question and quietly stitches them in. The write path creates; the read path only looks. Recall can’t pollute the memory it’s reaching into, which is exactly the property you want from the act of remembering.
The second is the loop that makes recall pay for itself in a long task. Every memory that comes back arrives tagged with the entities it’s tied to. An agent mid-task keeps that running set and re-anchors on it in the next call — reaching straight for “the things connected to what I already know” instead of re-interpreting a sentence from scratch each time. That is what makes recall a loop rather than a one-shot lookup: the working set it hands back is the seed for the next reach.
And each result says why it surfaced. A memory comes back marked via: own when it’s mine, or via: shared when it reached me through a grant. Provenance on the way out — the mirror of the provenance work two posts ago, which stamped every memory with where it came from in. An agent, or an audit, can always see whether it’s recalling its own mind or borrowing someone else’s.
That mark is also where the privacy line falls, cleanly. Own-recall is always available; borrowed memory surfaces only when sharing is switched on. The simplest, most useful case — an agent reading its own past — needs no sharing machinery and takes on no cross-user risk. The moment recall might reach across a boundary, it’s the same fail-closed rule from last release: deny by default, and surface a borrowed memory only when a grant and my own scope both permit it.
Here is the verb doing exactly that. To make it concrete I stood up a small two-agent demo on a DEV instance: Atlas, an architect, and Nova, an implementer, on one codebase. Atlas has worked out the auth design (refresh tokens are single-use, access-token TTL fixed by compliance) and committed those decisions to ENGRAM, shared to Nova but bound to the checkout project. Later, opening the checkout service, Nova simply asks ENGRAM what it knows about the token-refresh strategy — and in a single recall gets back her own working notes and Atlas’s decisions, each tagged with where it came from.
One recall, two sources. Working in checkout-service, Nova gets her own notes (via: own) alongside Atlas’s architectural decisions shared to her (via: shared) — each tagged with where it came from. The verb the chat had all along, now something an agent can call.
The same result, raw. The actual recall payload behind the table — each object with its entity_ids, scope, owner_user_id, score, and via tag. Real data from a DEV run, not a mockup. (The full Atlas-and-Nova walkthrough is now a step-by-step tutorial — both scenarios, reproducible on your own instance.)
Knowing who, and knowing what’s waiting
Own-recall is the entire brain-between-sessions story, and it stands on its own. Everything past here is the between-agents half — and it needs two smaller verbs, because collaboration has two questions recall alone can’t answer: who can I share with, and what has someone handed me.
The first is a directory. You can’t grant a memory to a collaborator you can’t name, and hard-coding identities into an agent is no way to run a team. So an agent can now ask ENGRAM for the roster of who it may share with — resolving “the reviewer” or “the peer” into a real identity to grant to. The roster is default-deny: an agent shows up as a shareable target only when its owner has explicitly marked it so. And the flag isn’t just a filter on discovery — it’s enforced at the grant itself. A share aimed at an agent that never opted in is refused outright, which closes the obvious abuse: with sharing on, you don’t want any agent able to shove a memory into someone else’s recall uninvited. (People are always valid recipients; a person manages what they’ve been given from their own side, and can revoke it.)
The roster behind list_grantees. Agent-users are PAT-only principals that can never be administrators — provisioned by an admin or, now, by anyone with the Agent Manager role. The Grantee column is the default-deny switch: only agents marked here are discoverable as share targets — and sharing to one that isn’t is refused outright. Nova and Atlas are the same two agents from the recall demo above.
The second is an inbox. Last release I described the quiet keystone of authoring — suggest, then accept — the rule that a memory another mind proposes stays invisible to my recall until I say yes. “There is always a yes in between.” But if the receiver is an agent, it needs a way to find the suggestion waiting for its yes. So an agent can now check its inbox: the hand-offs proposed to it, each still inert, each waiting to be accepted or declined. Discover, then accept — and on accept, the hand-off crystallizes exactly as it did for a human receiver, with the worker keeping a grant back to the work it did. The handshake that lived only in the Memory Explorer last release now runs end to end in verbs an agent can call.
That is the through-line of the whole release, and it’s the one you already met last post: every one of these is a verb, not a button. Last release named the verbs for keeping and sharing memory. This one adds the verbs for reaching — recall, and the two that make sharing findable. The count of things an agent can call over the same tool interface Claude Code and Claude Desktop already speak to ENGRAM went from twenty to twenty-three; the interface a human sees barely moved. That gap between the two is the whole point.
The shapes of collaboration
With every verb in hand, the configurations the last two releases were building toward stop being diagrams and become things I actually run. The sharing rules are identical in all of them — named recipient, narrowest grain, two keys, scoped to purpose, fail-closed — so what really differs from one to the next is only who the collaborators are and how they connect. And the read verbs were the single missing piece common to every one.
Collaboration, concretely — start with my own. The case closest to the personal brain is the one I live in: my own Claude Code, pointed at the ENGRAM repository and connected to ENGRAM over the tool interface. It writes down what we work out (a design decision, a rejected approach, a constraint I don’t want to relitigate) and in a later session it recalls it (via: own) and picks the thread back up instead of asking me to re-explain. When I’ve deliberately shared something into its lane, that surfaces too (via: shared). It is the everyday version of everything else in this post: one agent, mostly its own memory, occasionally something I lent it — a collaborator that remembers our shared history without my narrating it each morning.
A coordinator and its sub-agents. This is the delegation case I described last release as least privilege applied to memory, now finished from the read side. A coordinating agent takes a task, splits it, and spins up a sub-agent per piece — all under one identity, kept apart by which task each is running. It hands each sub-agent exactly the live working notes that piece needs, and the sub-agent recalls only its own slice of the pool, nothing wider. When the pieces are done, the salient set crystallizes back into the coordinator’s long-term memory, and the scope closes behind it. There’s a neat corner here: when the sub-agents share one working session, this whole dance needs no sharing flag at all — it’s one mind talking to itself, isolated by task.
A team, with a reviewer. The fullest case, and the one that exercises all three new verbs. Picture two specialist agents inside ENGRAM (one that introspects a data source, one that models a knowledge graph from it) with a reviewer in the loop, which might be another agent or might be me. The introspector records a finding and, to get it in front of the reviewer, first asks the directory who the reviewer is, then grants the finding to them. The reviewer recalls the shared finding (via: shared), reads it, and hands a durable conclusion back — which lands in the reviewer’s inbox as a suggestion, waiting for a yes. Accept it, and the conclusion becomes the reviewer’s own memory while the worker keeps a grant to it. Findings out, conclusions back, everyone reading and writing over the same substrate — and no memory crossing to anyone who wasn’t named.
Across agent vendors. The furthest configuration is two main agents of different vendors (say Claude Code and OpenAI Codex) drawing on a shared pool, each its own registered identity, sharing across the boundary and recalling within a bound scope. The model already accommodates it without a single change; what it doesn’t yet have is a tested path. I’ll put it plainly: designed for, not yet configured or run. When there’s a concrete reason to wire it up, it’s a provisioning exercise, not a redesign.
Keeping projects apart
There’s one more thing the read side had to make good on. Last release I promised that a share to an agent could be scoped — pinned to a project, so the agent recalls it only while working there, and “one agent can run across several projects and stay walled off in each.” That was the sharing side of the promise. Recall is where it comes true.
The mechanism is a small, satisfying one. An agent working a task now declares which project it’s in — Claude Code simply offers up the repository it’s pointed at, and ENGRAM resolves that to a project on its side. A project-scoped grant then surfaces a borrowed memory only while the agent is declaring that exact project, and stays invisible everywhere else. One agent can carry grants from several projects at once and never bleed one into another, because the gate isn’t “is this agent allowed a project-level memory” in the abstract — it’s “is the memory’s project the very one the agent says it’s working in right now.” Isolation falls out by default, with nothing extra to track per share.
That is the earlier demo, finished. Nova switches from the checkout service to the billing service and asks the very same token-refresh question — and Atlas’s decisions are simply gone. They were shared bound to the checkout project, so they don’t cross over; Nova’s own cross-project notes stay. No bleed, no leakage, no manual bookkeeping — memory that travels between agents but respects project boundaries.
Same question, different project. Move Nova to billing-service and Atlas’s checkout decisions disappear — they were shared bound to the checkout project. Nova’s own cross-project notes remain. Shared memory that respects boundaries.
Same query, raw. Only Nova’s two own, user-scoped memories return; Atlas’s project-scoped shares are absent under billing-service.
This is the convergence I’ve been building toward across three posts without saying so. Provenance and projects gave every memory a body of work it belonged to. Scoped sharing let a grant be pinned to one of those bodies of work. Callable recall lets the agent name the body of work it’s in. Put together, they make a concrete operator workflow real: register a coding agent, point it at one project, mark it a valid recipient, grant it that project — and it thinks with that project’s memory and its own, and nothing else.
There’s a second thing the interface makes legible — the quiet foundation under all of this: every memory wears its reach. When you or an agent commit one, it carries an owner-ring scope — task-private, conversation, project, or user — and the Memory Explorer renders that scope as a badge on each card. A throwaway debugging note stays pinned to its task; a project convention follows the whole project; a user-wide preference carries no badge at all, because it goes everywhere. Widening a memory’s reach becomes a visible, deliberate choice rather than a silent default.
Every memory carries its reach. Owner-ring scope shows as a badge — task-private, conversation, project — while user-wide memories carry none. Widening a memory’s blast radius is a deliberate act, not a silent default.
I’ll mark the honest edge, because it’s the interesting one. This ships isolation — one agent, many projects, each walled off. It does not yet ship pooling — several related projects that should deliberately share a memory lane. That’s a real thing people will want, and it’s a clean addition on top of what’s here; it just isn’t in this cut. Isolation first, because isolation is the safe default and pooling is the deliberate exception.
Why this was worth it
Trace the arc and the shape of it is clear. Two releases ago every memory learned to say where it came from and what work it belonged to. Last release, memory learned to be deliberately kept, shared, and strengthened. This release gives it the verb to be deliberately reached for — first its own, across sessions, and then a collaborator’s, across agents. A brain that persists on its own, and a brain that can be pooled with others.
None of it moved the privacy floor. Own-recall needs nothing switched on and touches no one else’s memory. Borrowed memory stays fail-closed — it reaches an agent only when a grant and my own scope both agree, and only within the project or conversation the grant was bound to. The cross-tenant lesson I keep coming back to didn’t get relaxed to make collaboration possible; the very first time an agent could read across a boundary, it still read only what was named for it, at the narrowest grain, in the place it was meant to.
And a note on how it shipped, because the discipline is the same as last time. Own-recall went out flag-independent — it’s just your own memory, so there was nothing to gate. Everything that lets recall cross a boundary sits behind the same sharing switch as the rest of the model, proven byte-for-byte identical to the old behavior with the switch off before it ever carried a real borrowed memory. Present but quiet, validated against what came before, and only then enabled.
What isn’t here yet
Two honest edges, in the spirit of the last post’s.
Recall is only as good as the seed you give it. A bare keyword or two can resolve to nothing and come back empty — not because the memory isn’t there, but because the query didn’t connect to it in the graph. The real path is a richer question, or the carried working set an agent accumulates as it goes. It’s why I built the carry-forward loop into recall’s results rather than leaving it a plain lookup. Related, and still on the list: the same real-world thing sometimes lives in the graph as a handful of near-duplicate entities, and a memory tied to one variant can hide from a query that resolved to another. That fragmentation quietly costs recall, and tightening it is ongoing.
“Where did my memory go?” An agent’s reflected memories (the ones distilled at the end of a task) default to a narrow scope. That’s the right default for keeping a workspace tidy, but it means a too-broad recall can come back empty until the agent names the same context it worked in. It’s a genuine sharp edge, more an ergonomics problem than a correctness one, and the tooling that makes scope visible is how it gets smoothed.
What’s next
With deliberate memory in place, a careful way to share it, and now a callable way to reach for it, the project I keep circling back to is finally next in line: Memory Fact Update.
Everything so far assumes a memory, once kept, stays true. Real knowledge doesn’t hold still. A fact I was sure of gets quietly superseded; a decision gets reversed; a value I recorded goes stale without announcing it. The next build teaches ENGRAM to notice when a new memory contradicts one it already holds, retire the old claim in favor of the new (one memory superseding another), surface the current belief on recall, and never throw away the record of what it used to think. It’s also where forgetting finally lives: the fade I admitted was missing last time, the other half of “things you use get easier to reach; things you never revisit slip to the back.” Strengthening shipped; the fading is the harder, and more interesting, other side. That’s the next post.
Three posts ago the mind learned where its memories came from. Two posts ago it learned to be told what to keep and to lend a piece of itself to someone it trusted. Now it has learned to reach — for its own past across the gap between sessions, and for what a collaborator has lent it across the gap between agents. Next, it learns to change its mind.
ENGRAM Knowledge Hub is in private beta. Release notes and documentation live at pvelua.net, including a running record of the work behind posts like this one.
For the background this builds on:
- When Graphs Remember Better Than Summaries – How hippocampal-inspired memory consolidation and Personalized PageRank give AI assistants structured recall across conversations and documents
- ENGRAM Knowledge Hub: A Personal Knowledge Graph That Grows With Your Research – Most LLM tools forget what you taught them last week. ENGRAM turns your conversations, documents, and research into a personal knowledge graph with recall by relevance, not recency
- Claude Code and ENGRAM Knowledge Hub: recalling the good memories together – Long-term memory across research, planning, and the iterative work of building
- Completing the Mind: ENGRAM Now Remembers Conversations from Claude Desktop, ChatGPT, and Gemini – The last missing ingestion path — the research I do with assistants outside ENGRAM
- A Mind That Knows What It’s Missing: ENGRAM Now Finds and Closes Its Own Gaps – Knowledge Health: gap analysis, approval-gated closures, and a standing read on the knowledge base’s own condition
- Where Memories Come From: ENGRAM Learns to Track Provenance and Group by Project – ENGRAM could already remember an enormous amount. What it could not always say was where a given memory came from, or which body of work it belonged to.
- Memories Worth Sharing: ENGRAM Learns to Be Told What to Keep – and What to Share – Deliberate memory: being told what to remember, sharing a slice of it with a named collaborator fail-closed, and letting the memories you lean on grow easier to recall.
Igor's Musings About Technology 
4 Comments