Scopes
A scope determines who a memory belongs to and who is allowed to recall it. Scopes are how MemMesh keeps a personal preference from leaking into a shared project, while still letting an organization share knowledge deliberately.
The six scopes
MemMesh has six scopes, from broadest to narrowest:
| Scope | Belongs to | Use it for |
|---|---|---|
platform | An entire platform / org | Always-true rules shared across every project under the org. |
project | A project / workspace | Decisions, rules, and facts specific to one codebase or product. |
location | A site / tenant-location | Facts scoped to one physical or logical location within a project (e.g. a single store or region). |
agent | A single assistant / bot | What one specific agent has learned or is configured to know. |
user | A single person | Personal preferences and rules that follow you across projects (e.g. “always use pnpm”). |
session | One conversation | Ephemeral, per-conversation context that shouldn’t outlive the thread. |
Recall and scope
A search filters by the scope you pass in (plus the matching tenancy
identifiers). Pass user and you see user-scoped memory; pass project and you
see project-scoped memory. There is no automatic most-specific-first cascade in
the retrieval path — you select the scope you want, or omit it to search across
what your identifiers grant.
Some higher-level surfaces build on this deliberately. Onboarding-context
assembly, for example, inherits memory along an entity’s org chain
(member_of / part_of) so a new person’s agent can be briefed from
team- and org-level knowledge without per-user setup — but that inheritance is
an explicit feature of that endpoint, not a property of every recall.
Identifiers
Memories are addressed by a combination of identifiers — a platformId, an
optional projectId, and optionally locationId, agentId, userId, and
sessionId. The exact identifiers a call requires depend on the scope it
targets. Over REST, tenancy is resolved from your Bearer token and the
{projectId} in the path; the finer identifiers are passed in the request body
or query.
Why scopes matter for onboarding
Because broader scopes can be shared deliberately, a brand-new user inside an existing project or org can immediately recall the shared context — the “agent already knows the company” experience — without any per-user setup.