Skip to main content
Scopes partition your memory space. Every memory belongs to exactly one scope, and retrieval tools filter by it — so consulting work, side projects, and personal life stay separate even though they live under one account.

​
Defaults

New accounts start with two scopes:
  • personal — the default. remember writes here unless a scope is given or your write policy says otherwise.
  • work — for professional context.
Scopes are user-defined, not a fixed enum. You can create more, rename them, or delete them from the registry as your setup evolves.

​
Scope names and aliases

A scope name is a kebab-case string: lowercase letters, digits, and hyphens, up to 64 characters (client-acme, side-project-x). Each scope can also carry aliases — alternative names for the same area of your life. Aliases are recorded in the registry and returned by list, but they are not yet resolved on reads or writes: a remember or search that passes an alias uses that string as a scope name of its own, and set_retrieval_default / set_write_default accept only the canonical registered name (an alias is rejected as not found).

​
Managing scopes

The configure_scope tool covers the scope lifecycle: Deleting a scope is registry-only: existing memories keep their scope value. Nothing on a write path destroys memory data — see Memory model. If the deleted scope was the default of either policy, that policy moves to require in the same transaction, so unscoped calls fail closed until you choose a new default; renaming a scope carries a policy default to the new name.

​
How scopes shape retrieval

  • search accepts a scope filter, so queries can stay inside one area of your life.
  • briefing requires an explicit selector — a scope, a project, or all. There is no firehose default: a briefing for work will not pull in personal commitments.
  • remember takes the scope at write time. Without one, your write policy decides (by default, personal).
Memories also carry an optional project label, which subdivides within a scope — a scope is the broad partition (“work”), a project is the specific effort inside it.

​
Write policy: where an unscoped write lands

configure_scope with action: "set_write_default" sets a per-account write policy for remember calls that omit scope. It uses the same three modes as the retrieval policy: scope is required for default and must be null for off and require. An explicit scope on the write always wins and is used as given; it is not checked against the registry. The response’s memory.scope reports where the memory actually landed. The rejection under require happens before any write, access, or budget check, so a rejected call stores nothing and spends nothing. The policy is stored per account (one row, tenant-isolated like every other user table) and only ever read for the authenticated caller: a scope name in a request never selects another account. describe_environment reports it as writeScopePolicy, next to retrievalScopePolicy; an account that never configured one reports { "mode": "off", "scope": null }. revise does not use the write policy: a successor that omits scope inherits its predecessor’s. Import does not consult it either: an imported memory without a scope keeps the personal default.

​
Binding sessions to a scope

A practical pattern for agents: decide the scope once per session (or per client) and pass it on every write. For example, an agent doing consulting or business tasks writes with scope: work, while a life-admin assistant writes with scope: personal. Keeping the binding explicit at the call site avoids misfiled memories that are awkward to re-sort later — corrections require revising each memory, since nothing is bulk-rewritten in place. An account whose agents cannot be trusted to pass a scope can set the write policy to require, so a forgotten scope fails loudly instead of landing in personal.

​
Which account is this connector on?

A scope partitions one account; it does not name the account. Every account starts with a work scope, so two connectors that both show a work scope may still reach two different accounts — or the same one. Three things are separate and should be checked separately: When two connectors point at 3ngram and you need to know which account each one writes to, use this read-only check before writing anything:
  1. Call describe_environment on each connector and note account.id.
  2. Compare. The same id means both connectors reach one corpus, and the scope and project on each call are what separate the writes. Different ids mean two accounts, each with its own scopes, projects and memories.
  3. Only then inspect scopes, facets and retrievalScopePolicy (or configure_scope list) on the connector you intend to use, and pass the scope and project explicitly on the write.
The check never changes anything, and nothing in 3ngram acts on its result: a write goes to the account its own credential authenticated as. 3ngram does not reroute a write to another account or switch credentials because a scope is called work or personal — choosing the connector is the caller’s decision.