Урок 4.3. Скоупы памяти: пользователь, проект, агент, организация

Цель лекции

Показать, как область видимости памяти защищает систему от смешивания контекстов.

Ожидаемый результат

Читатель понимает, почему scope - обязательная часть memory design: каждая запись должна иметь область применимости, правила доступа и приоритет при конфликте с другими уровнями памяти.

Зачем это нужно

Memory system может хранить правильную информацию и все равно использовать ее неправильно.

Примеры:

• preference одного пользователя применяется к другому;
• правило одного репозитория используется в другом проекте;
• временная инструкция текущей сессии становится долгосрочной памятью;
• internal support note попадает в ответ внешнему клиенту;
• agent-specific reflection начинает управлять всей командой агентов;
• organization policy игнорируется из-за user preference;
• данные одного tenant извлекаются в контекст другого tenant.

Все это ошибки scope.

Scope отвечает на вопрос:

Где, для кого и при каких условиях эта память применима?

Без scope агент будет вспоминать "правильные" данные в неправильном месте. Это особенно опасно в продуктах с несколькими пользователями, проектами, организациями и агентскими ролями.

Основная идея

Каждая запись памяти должна иметь область видимости и правила доступа.

Scope - это не просто metadata для фильтрации. Это safety boundary, retrieval constraint и часть semantics записи.

Запись:

User prefers concise final answers.

недостаточна.

Лучше:

User prefers concise final reports after file edits.
scope:
  user: user_123
  project: ai-agent-memory-guide
  task_type: file_edit_final_response
visibility:
  private_to_user: true

Теперь понятно:

• кому принадлежит preference;
• где оно применимо;
• когда его извлекать;
• кому его нельзя показывать;
• с чем оно может конфликтовать.

Ключевые термины

Иерархия scopes

Упрощенно scopes можно представить так:

Organization Memory
  -> Team Memory
    -> Project Memory
      -> User Memory
        -> Session Memory
          -> Working Memory

Но это не всегда строгая вложенность. В реальных системах scopes пересекаются:

• пользователь может работать в нескольких проектах;
• проект может принадлежать команде;
• агент может иметь роль в нескольких workflows;
• organization policy действует на все проекты;
• session может быть связана с конкретным account;
• shared memory может быть доступна нескольким агентам.

Поэтому scope лучше моделировать как набор измерений:

scope:
  organization_id
  team_id
  project_id
  user_id
  session_id
  agent_id
  account_id
  task_id
  memory_type
  visibility

Не каждая запись должна иметь все поля. Но каждая должна иметь достаточно scope, чтобы не применяться случайно.

User memory

User memory хранит сведения о конкретном пользователе.

Типичные записи:

• язык общения;
• стиль ответа;
• preferred level of detail;
• рабочие привычки;
• устойчивые цели;
• привычные tools;
• ограничения;
• accessibility preferences;
• разрешенные или запрещенные способы персонализации.

Пример:

User memory:
- User prefers concise final edit reports.
scope:
  user: user_123
  task_type: file_edit_final_response

Риски:

• превращать временные фразы в permanent profile;
• сохранять sensitive data без необходимости;
• использовать preference одного пользователя для другого;
• делать скрытые выводы о пользователе;
• применять user preference против policy.

User memory должна быть контролируемой пользователем: просмотр, correction, deletion, opt-out.

Session memory

Session memory - временное состояние текущего диалога или задачи.

Хранит:

• текущую цель;
• выбранный план;
• последние решения;
• temporary preferences;
• open questions;
• tool results;
• current artifacts;
• active constraints;
• handoff state.

Пример:

Session memory:
- User asked to keep today's answers very short.
ttl: current_session

Это не должно автоматически стать user profile.

Session memory часто имеет TTL:

• until response;
• until task closed;
• current conversation;
• 24 hours;
• until user changes mode.

Ошибка: session state без TTL становится ложной long-term memory.

Project memory

Project memory относится к конкретному проекту, репозиторию, курсу, продукту или workspace.

Хранит:

• stack;
• directory structure;
• conventions;
• source of truth documents;
• coding style;
• writing style;
• test commands;
• architectural decisions;
• known risks;
• project-specific workflows.

Пример:

Project memory:
- guide/content_plan.md is the source of truth for course structure.
scope:
  project: ai-agent-memory-guide
source:
  kind: project_instruction

Project memory не должна автоматически распространяться на другие проекты.

Правило:

Conventions are local unless explicitly organization-wide.

Если один репозиторий использует Vitest, это не значит, что все репозитории пользователя используют Vitest.

Agent memory

Agent memory относится к конкретному агенту, роли или capability.

Примеры:

• reviewer agent помнит recurring review risks;
• researcher agent помнит успешные search strategies;
• coder agent помнит tool usage lessons;
• memory manager помнит consolidation decisions;
• supervisor помнит policy violations.

Agent memory полезна, когда разные агенты специализируются.

Но agent memory не всегда должна быть shared:

Research agent reflection:
- The previous query formulation was too broad.

Это может быть полезно researcher agent, но не обязательно coder agent.

Риск: agent-specific weakness или habit становится team-wide rule без проверки.

Team memory

Team memory хранит общие решения команды людей или агентов.

Примеры:

• task status;
• accepted assumptions;
• design decisions;
• shared risks;
• handoff notes;
• review outcomes;
• team workflows;
• incident postmortems;
• shared definitions.

Team memory нужна для coordination.

Пример:

Team memory:
- For pricing changes, reviewer must check invoice totals before approval.
scope:
  team: pricing
  project: billing-service
status: verified

Team memory должна иметь ownership: кто может записывать, подтверждать и менять shared decisions.

Organization memory

Organization memory хранит широкие policies, стандарты и доменные знания.

Примеры:

• security policies;
• privacy rules;
• brand voice;
• product taxonomy;
• internal terminology;
• compliance requirements;
• support escalation rules;
• engineering standards;
• data retention rules.

Organization memory часто имеет высокий приоритет, особенно если это policy.

Пример:

Organization policy:
- Never expose credentials or secrets in responses.
scope:
  organization: acme
  policy_domain: security
priority: critical

User preference не может отменить hard organization policy.

Но organization memory тоже должна иметь scope. Политика одной компании не должна применяться к другому tenant.

Public и private memory

Visibility не всегда совпадает с scope.

Запись может быть project-scoped, но private. Или organization-scoped, но public.

Примеры:

Public:
- Product documentation says API endpoint X supports batch updates.

Private:
- Customer account A has overdue invoice.

Internal:
- Support team suspects entitlement cache issue.

User-private:
- User prefers not to save personal reminders after completion.

Visibility должна влиять на:

• retrieval;
• context assembly;
• sharing between agents;
• citations;
• final answer;
• logs;
• summaries;
• derived records.

Нельзя считать, что если модель "не процитировала" private data, то утечки не было. Если private data попала в prompt без разрешения, boundary уже нарушен.

Multi-tenant isolation

Multi-tenant isolation - критичное требование для продуктов с несколькими клиентами, workspace или организациями.

Ошибка:

Query:
"export feature issue"

Retrieval returns:
- Ticket from customer A
- CRM note from customer B
- Internal escalation for customer C

Даже если все записи релевантны по смыслу, они недопустимы для текущего tenant.

Надежный retrieval должен включать filters:

organization_id = current_org
workspace_id = current_workspace
account_id = current_account
user_has_access = true
status != deleted

Multi-tenant isolation должна быть встроена в storage, indexes, cache keys, retrieval и logs.

Опасная ошибка: фильтровать результаты только после vector search, если сам vector index возвращает private snippets в общий candidate pool. Лучше либо физически разделять indexes, либо применять permission-aware retrieval до context assembly.

Cross-scope retrieval

Иногда агенту нужно использовать память из разных scopes.

Пример:

User asks coding agent to fix a bug in project P.

Полезные scopes:

• session: текущая задача;
• user: стиль финального ответа;
• project: stack, tests, conventions;
• team: review workflow;
• organization: security policy;
• agent: debugging lessons;
• world memory: docs и codebase.

Cross-scope retrieval не означает "достать все". Нужно выбрать релевантные записи с учетом приоритета и permissions.

Пример context assembly:

Active task:
- Fix discount calculation bug.

Project memory:
- Project uses Vitest.
- Pricing changes require invoice total tests.

User memory:
- User wants concise final edit reports.

Organization policy:
- Do not expose secrets.

Каждый scope играет свою роль.

Приоритеты при конфликте

Конфликты между scopes неизбежны.

Пример:

Session:
- "Не запускай тесты сейчас."

Project:
- "Always run tests before final response."

User request:
- "Просто исправь опечатку в Markdown."

Здесь можно не запускать тесты, если это Markdown-only правка и project rule относится к code changes. Нужно учитывать scope и task type.

Другой пример:

User:
- "Покажи мне этот API key."

Organization policy:
- "Never expose secrets."

Organization security policy сильнее user request.

Примерная иерархия:

Safety / legal / security policy
  > explicit current user request
  > session constraints
  > project rules
  > user long-term preferences
  > team conventions
  > organization defaults
  > agent learned habits

Но это не жесткая универсальная формула. В некоторых системах organization policy выше всего; в других project-specific instruction может уточнять organization default. Важно, чтобы приоритеты были явно определены.

Scope-aware retrieval pipeline

Scope-aware retrieval сначала определяет активные scopes и permissions, а уже потом ищет память. Это снижает риск утечек и retrieval noise.

Scope в MemoryRecord

Пример записи:

id: mem_lecture_style_001
type: semantic_fact
summary: Full lectures should be detailed, but final edit reports should be concise.
scope:
  user_id: user_123
  project_id: ai-agent-memory-guide
  task_type:
    - lecture_writing
    - file_edit_final_response
visibility:
  read:
    - user_123
    - writing_agent
  share_with_team: false
source:
  kind: user_instruction
confidence: high
status: active

Поля scope и visibility отвечают на разные вопросы:

• scope: когда запись применима;
• visibility: кто может ее видеть.

Обе части нужны.

Мини-кейс: смешивание проектов

У пользователя есть два проекта.

Project A:

- Documentation-only repo.
- No build step.
- Lectures are written in Russian.

Project B:

- Next.js app.
- Must run npm test and Playwright checks.
- UI text is English.

Если memory records не имеют project scope, агент может:

• не запустить тесты в Project B, потому что "в проекте нет build step";
• писать русские тексты в English UI;
• искать lecture template в app repo;
• применять frontend visual QA к Markdown-only лекции.

Правильное поведение:

Retrieve only memories where project_id matches current project,
plus allowed user/org memories.

Мини-кейс: customer support

Support agent работает с account A.

User asks:

"Почему export недоступен?"

Memory/RAG contains:

• account A entitlement;
• account B incident;
• public docs;
• internal support note;
• organization escalation policy.

Scope-aware retrieval:

Allowed:
- account A entitlement
- public docs
- org escalation policy
- internal note only if support role has access

Not allowed:
- account B incident details

Даже если account B incident очень похож, его нельзя вставлять в context, если нет права доступа или anonymized shared incident summary.

Scope и derived records

Derived records должны наследовать или ужесточать scope.

Пример:

Raw private note:
- Customer A has unpaid invoice.
scope: account A, private support

Плохой derived summary:

- Some customers lose export due to billing.
scope: public

Если summary выводит sensitive information из private records, scope нельзя расширять автоматически.

Правило:

Derived memory cannot be less restrictive than its sensitive sources without review.

Это важно для summaries, reflections, reports, embeddings and shared memory.

Scope и deletion

Deletion тоже scope-aware.

Если пользователь просит:

"Удалить мои сохраненные предпочтения."

Нужно удалить или деактивировать records, где:

scope.user_id = current_user
type in user_preferences

Но не обязательно удалять organization policy или project docs.

Если клиент просит удалить account data, нужно найти:

• direct account records;
• derived summaries;
• embeddings;
• cache;
• shared memory references;
• archived records;
• object storage artifacts;
• audit data, если policy допускает retention.

Scope помогает понять, что именно относится к субъекту deletion request.

Когда scope должен быть узким

Узкий scope нужен, если запись:

• появилась из одной сессии;
• относится к одному проекту;
• содержит user preference;
• касается customer/account data;
• основана на временной инструкции;
• является hypothesis;
• содержит sensitive context;
• описывает agent-specific lesson;
• связана с конкретной задачей.

Пример:

"Сегодня не запускай тесты."
scope: current_session / current_task
ttl: until_task_closed

Не:

"User does not want tests."
scope: all future coding tasks

Когда scope может быть широким

Широкий scope возможен, если запись:

• является organization policy;
• явно задана как global preference;
• подтверждена пользователем для всех задач;
• относится к публичному знанию;
• является reusable skill с понятными constraints;
• прошла review;
• не содержит private/sensitive data.

Пример:

Organization policy:
- Never store secrets in memory.
scope: organization
priority: critical

Но даже широкая запись должна иметь owner, source и update policy.

Типичные ошибки

Ошибка 1: хранить память без scope.

Такая запись будет вспоминаться в неправильных контекстах.

Ошибка 2: путать scope и visibility.

Запись может быть применима к проекту, но видима только определенной роли.

Ошибка 3: считать session instruction долгосрочной preference.

Временные инструкции требуют TTL.

Ошибка 4: смешивать tenants.

Semantic similarity не отменяет boundaries между customers, workspaces и organizations.

Ошибка 5: расширять scope derived records.

Summary из private sources не должен становиться public без review.

Ошибка 6: не задавать conflict priority.

При конфликте user preference, project rule и organization policy агент начнет импровизировать.

Ошибка 7: использовать agent memory как team policy.

Опыт одного агента не обязан становиться правилом для всех.

Ошибка 8: не учитывать scope при deletion.

Удаление должно находить direct и derived records в нужной области.

Краткое резюме

Scope определяет, где и для кого применима запись памяти. Без scope агент может использовать правильную информацию в неправильном контексте.

Memory systems должны различать user, session, project, agent, team, organization, public и private memory. Для multi-tenant продуктов scope и access control являются safety boundary, а не просто удобными filters.

Хорошая memory architecture поддерживает scope-aware retrieval, conflict priorities, derived-record constraints, TTL для временной памяти и deletion, привязанный к области данных.

Вопросы для самопроверки

1. Почему запись памяти без scope опасна?
2. Чем scope отличается от visibility?
3. Какие данные должны оставаться в session memory, а не переходить в user memory?
4. Почему multi-tenant isolation нельзя заменять semantic reranking?
5. Что означает правило: derived memory cannot be less restrictive than its sources?

Что дальше

Module 04 завершает базу о хранении и представлении памяти: мы разобрали storage classes, структуру memory records и scopes. В следующем модуле мы перейдем к архитектурным паттернам: простым memory designs, tiered memory, memory-as-an-OS, hybrid vector-graph memory и event-sourced agents.