Sharing & hand-off

Grants, not ownership

A share is a grant of recall. It doesn't copy the memory or transfer it; it lets a second principal recall the owner's memory alongside their own, marked with its provenance so it's always clear the memory was borrowed rather than authored. Revoke the grant and the memory disappears from the grantee's recall at once. Grants are reified — each is a first-class record carrying what was shared, with whom, by whom, and when — so sharing is queryable and auditable, not an invisible flag.

Two keys, fail-closed

A shared memory reaches a grantee only when both keys turn: an active grant from owner to grantee, and an owner-ring scope that reaches far enough to permit it. An individual, per-memory grant is a deliberate act and overrides the ring; a bulk grant — a whole conversation or project — is where the scope floor bites, so a broad share can never quietly expose a task-private memory the owner didn't mean to include. Absent the grant, or absent the operator flag that enables sharing at all, recall returns only the caller's own memories.

Agents are default-deny targets

Humans are always valid recipients. Automated agents are not — an administrator must mark an agent as a shareable grantee before anything can be shared to it. That single rule closes the malicious-sharing vector: nothing is ever pushed into an agent's memory unless someone deliberately opted that agent in. Assistants can query the grantee directory to resolve "the reviewer" or "the architecture bot" to a real, opted-in recipient.

Hand-off and grant-back

Beyond sharing a single fact, a worker can hand off a whole piece of work. At a task's close it commits a recap addressed to a receiver; the recap lands in the receiver's inbox as a suggestion, never silently added. When the receiver accepts, they own the resulting long-term memories — and because the work started with the worker, each accepted memory is automatically granted back to the worker, so it keeps recalling what it produced. It's the same review gate as any suggestion: nothing becomes recallable for the receiver until they say yes.

Working-memory sharing

For hot-path orchestration — an orchestrator fanning work out and collecting results — ENGRAM also supports ephemeral, record-grained sharing of live working memory. The named records are snapshotted at share time, so the sharer's later edits don't leak; sharing can be one-to-one or a group pool, is read-only for recipients, bounded by a short time-to-live, and revocable. A recipient can turn what it received into its own durable memory when it wants to keep it.

For the day-to-day flow — creating shares, the Suggestions inbox, and managing grants — see Authoring & Sharing Memories, or read the story behind it on the blog.