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.