Статьи
Андрей с ноутбуком рядом с рейлом одежды и чемоданом

Halo: как я собираю рабочую память команды

Последние недели я делаю Halo — рабочий прототип, который собирает контекст команды из Tracker, Wiki, встреч и других внутренних источников. Его можно спросить «что изменилось за неделю?», «почему мы так решили?» или «кто сейчас за это отвечает?» и получить ответ с датами, ссылками и объяснением, на чём он основан.

Посмотреть проект можно на странице Halo. А здесь я подробнее разберу, зачем вообще понадобилась рабочая память, почему обычного поиска оказалось мало и как я собираю прототип под реальные вопросы design‑команды.

Контекст есть, но он размазан

Команда каждый день производит много полезного контекста. В Tracker меняются статусы и ответственные. Во встречах обсуждаются риски и принимаются решения. В Wiki живут цели, процессы и спецификации. В Staff можно понять роли людей, а в Calendar — восстановить последовательность событий.

Проблема не в отсутствии информации. Проблема в том, что для ответа на один рабочий вопрос часто приходится вручную пройти несколько систем:

  1. найти задачу и посмотреть историю статусов;
  2. вспомнить, на какой встрече её обсуждали;
  3. открыть саммари и найти формулировку решения;
  4. свериться с Wiki, не изменились ли цели;
  5. уточнить, кто теперь отвечает за следующий шаг.

Каждая система по отдельности работает нормально. Теряется именно связь между ними. Через пару недель задача остаётся, а причина решения уже живёт только в саммари встречи или в памяти нескольких участников.

Что я называю рабочей памятью

Halo — не ещё одна Wiki и не чат, который «знает всё». Я смотрю на него как на слой поверх уже существующих рабочих систем. Он не просит команду перенести процессы в новое место, а связывает сущности, которые уже есть:

  • задачи и изменения их статусов;
  • встречи, участники и зафиксированные решения;
  • страницы Wiki, цели и проекты;
  • люди, роли и зоны ответственности;
  • ссылки между всеми этими объектами.

Рабочая память — это не архив документов. Она должна уметь показать, что произошло, когда, с чем это связано и откуда взят факт. Поэтому в Halo важны не только тексты, но и события: задача перешла из inProgress в closed, на встрече зафиксировали решение, у проекта сменился ответственный.

Почему граф, а не просто поиск

Поиск хорошо отвечает на вопрос «где встречается эта фраза?». Но большинство рабочих вопросов устроено иначе. «Что изменилось по проекту после синка?», «какие решения связаны с этой задачей?», «кто участвовал в обсуждении и кто отвечает сейчас?» — это вопросы про связи и время.

Поэтому я собрал контекст отдела в граф. В нём задача может быть связана с проектом, встречей, решением, человеком и страницей Wiki. У связей есть источник, а у изменений — дата. Такой слой помогает не только найти документ, но и пройти по цепочке:

проект → встреча → решение → задача → изменение статуса
                         ↘ ответственный

Граф не делает ответ автоматически истинным. Он лишь задаёт проверяемую структуру: каждый вывод можно вернуть к конкретной задаче, странице или встрече.

Как выглядит ответ Halo

Я хочу, чтобы ответ был полезен сразу, но не скрывал неопределённость. Поэтому у него несколько слоёв:

  • Короткий вывод — ответ на вопрос человеческим языком.
  • Факты и даты — что именно произошло и в какой момент.
  • Источники — ссылки на Tracker, Wiki и встречи.
  • Почему этот ответ — какие изменения и связи поддерживают вывод.
  • Ограничения — чего не хватает, если данных недостаточно.

Например, на вопрос «что изменилось по компоненту?» недостаточно пересказать текущее описание задачи. Важно показать историю: когда её создали, после какой встречи поменялся статус, где зафиксировано решение и кто стал ответственным.

Если нужного факта нет в графе, Halo должен прямо сказать: «не нашёл». Для рабочего инструмента честный пробел полезнее уверенного правдоподобного текста. Такой ответ подсказывает, что именно нужно проверить или добавить в источники.

От чата к исследованию

Чат — удобная точка входа, но не весь продукт. После ответа часто появляется следующий вопрос: что это за задача, как менялся её статус, кто участвовал, какие документы лежат рядом?

Поэтому в прототипе есть Explore. Из ответа можно перейти к задаче, человеку или решению и посмотреть историю связей. Это важное отличие от обычного AI‑саммари: пользователь не остаётся внутри сгенерированного текста, а может исследовать исходный рабочий контекст.

Сценарии вместо одного пустого поля

Не каждому рабочему вопросу нужен свободный чат. Многие задачи повторяются: недельный апдейт, подготовка к 1:1, возвращение после отпуска, поиск блокеров или сбор решений со встреч.

Для них я делаю сценарии — готовые рецепты поверх той же памяти. Пользователь выбирает период, участников или проект, а Halo знает, какие источники и связи проверить. Это делает результат стабильнее и снижает порог входа: не нужно каждый раз изобретать идеальный промпт.

Что происходит под капотом

Сейчас в прототипе уже крутятся несколько частей:

  • Ingest забирает доступные данные из рабочих систем и приводит их к общей модели.
  • Граф контекста связывает задачи, встречи, документы, людей, решения и события.
  • Чат переводит вопрос в поиск по контексту и собирает ответ.
  • Explore показывает сущности, историю изменений и соседние связи.
  • Evals проверяют, находит ли система нужные факты, не теряет ли источники и умеет ли признавать отсутствие данных.
  • MCP отдаёт тот же контекст агентам, чтобы им не приходилось начинать работу с пустого окна.

Отдельно важны права доступа. Halo должен видеть ровно то же, что и пользователь в исходных системах. Если у человека нет доступа к задаче или странице, они не должны появиться ни в ответе, ни в списке источников.

Зачем здесь MCP и агенты

Я почти каждый день работаю в Cursor и вижу одну закономерность: агент ускоряет работу, когда у него есть качественный контекст. В репозитории это архитектура, rules, документация и понятная задача. В команде аналогичный контекст обычно размазан по тикетам, Wiki и саммари встреч.

Если дать агенту только формулировку задачи, он может написать код или текст, но не узнает, почему команда отказалась от похожего решения месяц назад. Если передать ему рабочую память, он сможет сначала проверить связанные решения, актуальные цели и ответственных.

Поэтому Halo я проектирую не только как интерфейс для человека. MCP‑слой позволяет агенту задать тот же вопрос и получить структурированный контекст со ссылками на источники. Человек и агент работают не из двух разных пересказов, а из одной проверяемой памяти.

Почему я начал с design‑scope

Сейчас Halo — не продукт «для любой компании». Это рабочий прототип под контекст дизайн‑направления. Узкий scope здесь полезен: я знаю реальные сущности, язык команды и вопросы, которые возникают каждый день.

Можно проверять систему не на абстрактных демо‑запросах, а на практических:

  • что изменилось в дизайн‑системе за неделю;
  • какие решения приняли на последних синках;
  • почему поменяли процесс или статус;
  • какие задачи связаны с целями квартала;
  • что нужно знать человеку после отпуска;
  • где данных недостаточно для уверенного ответа.

Так быстрее становятся видны настоящие проблемы: дубли сущностей, устаревшие связи, неполные саммари, неоднозначные имена и события без даты. Именно эти детали определяют качество рабочей памяти сильнее, чем эффектный интерфейс чата.

Что я проверяю сейчас

Для меня главный вопрос не «может ли модель красиво ответить?». Современные модели умеют это и без Halo. Я проверяю другое:

  • экономит ли ответ время по сравнению с ручным поиском;
  • можно ли быстро проверить каждый важный вывод;
  • восстанавливает ли система последовательность изменений;
  • отличает ли зафиксированное решение от предположения;
  • замечает ли противоречия между источниками;
  • умеет ли остановиться, когда данных мало;
  • помогает ли тот же контекст агентам выполнять реальные задачи.

Ответы на эти вопросы появляются только в использовании. Поэтому сейчас мне важнее постепенно подключать реальные сценарии, собирать evals и смотреть, где Halo ошибается, чем быстро расширять список интеграций.

Куда проект движется

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

Пока это живой прототип: что‑то уже работает, что‑то меняется после первых реальных вопросов. Я буду периодически писать о том, как Halo ведёт себя на практике, какие связи действительно полезны и где идея рабочей памяти ломается о реальность.

Открыть страницу Halo →