# Рабочие области и проекты

> Как устроены аккаунт, проекты и рабочие области MMW, как ключ привязывается к проекту и что такое область default.

Из этой страницы вы узнаете:

1. как вложены друг в друга аккаунт, проект и рабочая область;
2. как ключ ограничивает агента одним проектом;
3. когда заводить отдельную рабочую область и что делать с ошибками доступа.

Пример на всю страницу: вы ведёте два проекта — **backend** и **mobile**. Агенту в репозитории backend незачем видеть заметки по мобильному приложению, а архитектурные решения и журнал инцидентов хочется держать раздельно.

## Как всё вложено

```text
  Аккаунт (личное пространство)        Организация (отдельное пространство)
  │                                      │
  ├── Проект default  ◀── ключ без привязки
  │     └── workspace default
  ├── Проект backend  ◀── ключ «backend»
  │     ├── workspace default
  │     ├── workspace decisions
  │     └── workspace incidents
  └── Проект mobile   ◀── ключ «mobile»
        └── workspace mobile-notes
```

- **Аккаунт** — ваше личное пространство. Аккаунты полностью изолированы друг от друга.
- **Проект** — граница доступа для ключа. Лимит записей тарифа считается на проект.
- **Рабочая область** (`workspace`) — именованная коллекция записей внутри проекта. По умолчанию — `default`.

## Проекты и ключи

У каждого аккаунта есть проект по умолчанию — он создаётся автоматически при первом обращении. Ключ, не привязанный к проекту, работает в нём.

Ключ можно **привязать к проекту** в кабинете. Агент с таким ключом читает и пишет только записи этого проекта: `search` не вернёт записи соседнего проекта, `forget` не сможет их удалить. Это настоящая граница доступа, в отличие от ярлыка `scope`.

Для нашего примера: выпустите два ключа — «backend» и «mobile» — и пропишите каждый в конфигурацию MCP соответствующего репозитория или клиента. Подробнее о ключах — [Ключи и OAuth](/account/api-keys-and-oauth/).

Хотите, чтобы Claude Code, Cursor и Codex видели одну память? Используйте в них ключи одного проекта. Разные проекты — разная память.

## Рабочие области

Рабочая область создаётся сама при первой записи в неё: достаточно вызвать `remember` с новым `workspace`.

```json
{
  "content": "Решили хранить сессии пользователей в Redis, а не в PostgreSQL: нужен TTL",
  "workspace": "decisions",
  "fact_key": "backend.sessions.storage"
}
```

Что важно знать:

- **Поиск идёт в одной области.** `search` ищет только в переданном `workspace` (по умолчанию `default`). Если агент сохранил решение в `decisions`, а ищет в `default` — он его не найдёт. Пропишите имена областей в инструкции агенту (см. [Правила для агентов](/memory/best-practices/)).
- **Поиск не создаёт область.** Если области ещё нет, `search` вернёт ошибку `workspace '…' is not active`. Сначала нужна хотя бы одна запись.
- **Конфликты считаются внутри области.** Две записи с одним `fact_key` в разных областях не конфликтуют.
- **Имя области уникально в аккаунте.** Область принадлежит проекту, в котором она создана. Если `decisions` создана ключом проекта backend, ключ проекта mobile получит `403 Forbidden: workspace access denied for project`. Для mobile выберите другое имя, например `mobile-decisions`.
- **Удалённое имя не используется повторно.** После удаления области её имя занять снова нельзя: `workspace '…' was deleted and cannot be reused`.

## Когда заводить отдельную область

Заводите, если у записей **разный жизненный цикл или разный читатель**:

| Область | Что в ней | Зачем отдельно |
| --- | --- | --- |
| `default` | Текущие факты проекта: как собрать, как выкатить, где что лежит | Основное место поиска |
| `decisions` | Архитектурные решения с причинами | Не тонут среди мелких фактов |
| `incidents` | Разборы инцидентов | Можно периодически чистить через `forget` по `source_id` |
| `docs` | Факты, извлечённые из документов с `source_id` | Удобно проверять свежесть через `validate_memory` |

Не заводите по области на каждую задачу или день — агенту станет сложно понять, где искать.

## Лимиты

Лимиты зависят от тарифа: число записей на проект (Free — 250, Starter — до 5 000 на проект, Pro — до 100 000, Enterprise — до 1 000 000) и число вызовов в минуту. Кроме того, ограничено число записей в одной рабочей области и в аккаунте в целом. Когда лимит достигнут, `remember` отклоняется с понятной ошибкой, а чтение продолжает работать. Подробно — [Лимиты](/reference/limits/).

## Организации

Организация — отдельное пространство со своими проектами и записями. У человека один логин, личное пространство и любое число организаций; переключатель — в кабинете. Организация никогда не становится пространством по умолчанию.

Сотрудник выпускает ключ для работы в организации сам; администратор видит и может отозвать ключи, но не раскрыть их. Внутри организации, помимо проекта, действует **видимость** записи (автор, отдел, проект, вся организация). См. [Организации](/organizations/overview/) и [Видимость](/organizations/visibility/).

## Что дальше