Workspaces and projects

On this page you will learn:

1. how accounts, projects and workspaces nest;
2. how a key limits an agent to one project;
3. when to create a separate workspace and how to read access errors.

Running example: you run two projects, backend and mobile. The agent in the backend repository has no business seeing mobile app notes, and you want architecture decisions kept apart from the incident log.

How it nests

  Account (personal space)              Organization (separate space)
  │                                      │
  ├── Project default  ◀── key with no project binding
  │     └── workspace default
  ├── Project backend  ◀── "backend" key
  │     ├── workspace default
  │     ├── workspace decisions
  │     └── workspace incidents
  └── Project mobile   ◀── "mobile" key
        └── workspace mobile-notes

• Account — your personal space. Accounts are fully isolated from each other.
• Project — the access boundary for a key. Your plan’s record limit is counted per project.
• Workspace (workspace) — a named collection of records inside a project. Defaults to default.

Projects and keys

Every account has a default project, created automatically on first use. A key that is not bound to a project works in it.

A key can be bound to a project in your account. An agent using such a key reads and writes only that project’s records: search will not return records from another project and forget cannot delete them. This is real access control, unlike the scope label.

For the running example: issue two keys, “backend” and “mobile”, and put each into the MCP config of the matching repository or client. More on keys: API keys and OAuth.

Tip

Want Claude Code, Cursor and Codex to share one memory? Give them keys of the same project. Different projects mean different memory.

Workspaces

A workspace is created automatically on its first write: just call remember with a new workspace.

{
  "content": "User sessions are stored in Redis rather than PostgreSQL because we need TTL",
  "workspace": "decisions",
  "fact_key": "backend.sessions.storage"
}

What to know:

• Search covers one workspace. search looks only in the workspace you pass (default default). If the agent saved a decision in decisions but searches default, it will not find it. Name your workspaces in the agent’s instructions (see Best practices).
• Search does not create a workspace. If it does not exist yet, search returns the error workspace '…' is not active. It needs at least one record first.
• Conflicts are per workspace. Two records with the same fact_key in different workspaces do not conflict.
• Workspace names are unique per account. A workspace belongs to the project it was created in. If decisions was created with a backend key, a mobile key gets 403 Forbidden: workspace access denied for project. Pick another name for mobile, such as mobile-decisions.
• Deleted names are not reused. Once a workspace is deleted, its name cannot be taken again: workspace '…' was deleted and cannot be reused.

When to create a separate workspace

Create one when records have a different lifecycle or a different reader:

Workspace	What goes in	Why separate
default	Current project facts: how to build, deploy, where things live	The main place to search
decisions	Architecture decisions with reasons	Not buried among small facts
incidents	Incident write-ups	Easy to clean up with forget by source_id
docs	Facts extracted from documents, with source_id	Easy to check freshness with validate_memory

Do not create a workspace per task or per day — the agent will not know where to look.

Limits

Limits depend on your plan: records per project (Free 250, Starter up to 5,000 per project, Pro up to 100,000, Enterprise up to 1,000,000) and calls per minute. The number of records per workspace and per account is also capped. When a limit is hit, remember is rejected with a clear error while reads keep working. Details: Limits.

Organizations

An organization is a separate space with its own projects and records. A person has one login, a personal space and any number of organizations; the switcher is in your account. An organization never becomes the default space.

Members issue their own keys for working in an organization; admins can see and revoke keys but cannot reveal them. Inside an organization, on top of the project, each record has a visibility (author, department, project, whole organization). See Organizations and Visibility.

Where next

Core concepts Record fields, statuses and relations.

API keys and OAuth Issuing a key and binding it to a project.

Best practices A ready instruction with workspace names.