Org Memory

Org memory is shared context for the whole organization.

Every non-viewer agent in the org sees a summary of pinned facts plus recent log entries in its system prompt. Org admins curate facts from Settings → Org Memory and review agent proposals on the Proposals tab. Members can read and search; viewers are blocked entirely.

Org memory is separate from profile memory. Profile MEMORY.md is per-bot continuity that agents update themselves. Org memory is team-wide facts that admins maintain.

On disk

Org memory lives at the organization level, alongside profile directories:

~/.nakama/orgs/{orgId}/MEMORY.md
~/.nakama/orgs/{orgId}/memory-archive/
~/.nakama/orgs/{orgId}/memory-history/

Archived bullets move into monthly .md files under memory-archive/ without deleting history.

Change history snapshots live under memory-history/ — one JSON metadata file and one markdown snapshot per revision (up to 50 entries, oldest pruned automatically). This is separate from memory-archive/, which stores bullets removed from the live pinned list.

Platform-admin data exports include org memory as part of the org workspace in the ZIP.

Format

Use this structure:

## Org Memory

## Pinned

- Acme Corp is our primary customer in APAC.

## 2026-07-31

- Support hours are 9am–6pm SGT, Mon–Fri.

Prompt injection

After the profile soul stack and knowledge base catalog, Nakama appends a ## Org Memory section for every role except viewer.

When the summary exceeds the cap, trailing bullets are dropped and the agent sees a hint to call org_memory_search for the full history (including archives).

See Agent prompts for the full assembly order.

Agent tools

Three org memory tools are automatically available on every profile. They are not assigned from the dashboard like other builtins.

Viewers cannot call these tools. Automations and sub-agents run with member-level org context.

Agents propose durable org facts via propose_org_memory; proposals land in a staging queue until an admin approves or rejects them in Settings → Org Memory → Proposals. Admins can still add facts directly from the UI (bypasses the queue). Do not propose secrets, credentials, or PII.

When an admin approves a proposal, Nakama merges the new fact into live memory:

1. LLM merge (when a provider is configured) — the server asks the model to update MEMORY.md, replace superseded facts, and keep unrelated bullets intact.
2. Mechanical fallback — if the LLM call fails or no provider is available, Nakama appends the fact to pinned or the recent log and removes near-duplicate bullets using token overlap.

Use Pin on approve in the review dialog when the fact should always appear in the injected summary.

Proposal rows live in the SQLite database and are not included in workspace ZIP exports yet.

Admin UI

Org admins manage org memory from Settings → Org Memory (/settings).

The card has three tabs:

A badge on Proposals shows the pending count.

Every write logs a snapshot (manual edits, approvals, pin/unpin, archive, and restores). Undo latest rolls back to the previous revision. Restore on an older row replays that snapshot as the new live memory (and logs the restore as a new history entry).

Use Archive when the pinned list grows large — it keeps the live file within limits while preserving history under memory-archive/.

For per-bot continuity the agent manages itself, use the profile update-profile-memory skill — see Profiles.

HTTP API (admin)

Org admins can also manage memory via the REST API (X-Org-Id required):

Members can read and search; viewers are blocked on all org memory routes.

Roles and access

Cross-org requests return 404 — the path orgId must match the active organization.

Org memory vs profile memory

Next steps

• Multi-tenancy — org boundaries and roles
• Profiles — per-profile soul files and memory
• Agent prompts — how org memory joins the system prompt
• Builtin tools — org_memory_search, org_memory_list, and propose_org_memory