Memory for agent teams

Every agent owns its memory

In ENGRAM, a memory belongs to a principal — a human, an orchestrator, or a sub-agent — and is private to that owner by default. Ownership isn't a tag bolted on afterwards; it's how the store is scoped. Each memory sits on a nested ring — task, context, project, user — that decides how widely it surfaces in its owner's own recall, and a missing scope fails closed rather than leaking. Nothing an agent learns is visible to another agent until someone deliberately shares it.

Sharing is deliberate

Memory crosses from one agent to another only through an explicit grant, and a grant only takes effect when two independent conditions are both met — an active grant from owner to grantee, and an owner-ring scope that reaches far enough to permit it. Absent either, recall returns an agent only its own memories. That is the whole safety model: fail-closed, revocable, and auditable. The Sharing & hand-off page covers it in full.

Orchestrators, sub-agents and projects

An orchestrator can grow its own team. With the Agent-Manager role it provisions sub-agents it owns, delegates work down a tree (capped at two levels, with the human at the top accountable for it), and scopes each finding to a project so one unit of work's memory never bleeds into another's. The orchestrator then recalls its team's findings a project at a time. See Roles & Agent Management for how this is set up.

Two ways to give an agent an identity

The simplest way to get started: hand an agent a human user's access token. It then acts as that human — everything it remembers is the human's, attributed to them — which is exactly right for a single-user setup and the fastest path to a working integration.

For a team of agents, provision each one its own token. Every sub-agent gets a server-pinned identity of its own, owns its own memory, and shares through grants. Same server, same audit trail — you choose per-agent identity when you want isolation, impersonation when you want speed.

How much a token may do

Identity answers who. Authority answers how much. A token can carry less than the account behind it: mark it Restricted and it still reads everything that account reads and still adds articles, documents and memories — but it cannot create accounts or hand out credentials. No minting a sub-agent, no issuing or rotating a token, no changing a user.

This matters most in exactly the case above, where an agent runs on a human's own token. That is the fastest path to a working integration, and it hands the agent everything the human can do. If the agent reads anything you did not write — a document it was pointed at, a web page, a webhook payload, another party's message — restricting its token leaves it working as before while taking account creation and credential minting off the table. An orchestrator that genuinely needs to grow its own team is the case for an owner token; a worker almost never is.

Which credential wrote it

Because one principal can hold several tokens, "who wrote this" was not always a precise enough question. Every memory and article now records which token wrote it, on the record itself — so the coding agent learned this while working in the repo is distinguishable from the desktop assistant was told this by a document it ingested. Those carry different evidential weight, and now they read differently.

The practical value is scope. If a surface is ever compromised, everything that credential wrote is a single query rather than a review of everything the account ever produced. Writes with no credential behind them — a signed-in human in the browser, or one of ENGRAM's own background jobs — say so explicitly rather than being left blank, so an unattributed record means something specific instead of meaning nothing in particular.