# Workspaces and projects

> How MMW accounts, projects and workspaces fit together, how a key is bound to a project, and what the default workspace is.

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

```text
  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](/account/api-keys-and-oauth/).

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`.

```json
{
  "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](/memory/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](/reference/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](/organizations/overview/) and [Visibility](/organizations/visibility/).

## Where next