Кейс SellOut+: строим второй мозг проекта в Gramax
Мы в Gramax делаем среду для работы с документацией и ИИ-агента поверх нее, поэтому много смотрим на реальные кейсы: где модель действительно помогает команде, а где только красиво пересказывает хаос.
Один из самых сильных кейсов принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию Gramax с агентами. На реальном проекте команда собрала «второй мозг» из десятков встреч с заказчиком. А потом использовала его, чтобы восстановить требования, проверить спорные места и собрать цельную картину проекта поверх уже существующих задач, описаний и договоренностей.
Для нас этот кейс оказался важен не только как история про ИИ. Он очень точно показывает, зачем в агентских сценариях нужен Gramax: модель может разобрать сырье, но результат должен стать нормальной базой знаний. Ее должны читать аналитики, править менеджеры, проверять команда, показывать заказчику и поддерживать после каждого нового созвона. Без этого «второй мозг» быстро остается набором файлов, понятным только тому, кто его собрал.
На Хабре уже вышла подробная версия этой истории: там больше про транскрибации, локальную модель, скиллы, журнал разбора и маршрутизацию знаний. Здесь хочу оставить более короткий разбор: почему одних агентов недостаточно, как проектная память превращается в рабочую базу знаний и какую роль в этом сыграл Gramax.
Проблема
Команда SellOut+ внедряла у крупного клиента систему планирования: автоматизировала работу с розничными сетями, контракты, инвестиции, коммерческие условия и связанную финансовую логику. У заказчика уже была старая система, и проект стартовал с формулировки: «Сделайте так же, но лучше».
Важно: это не история про «никто не написал ТЗ, а потом все удивились». На проекте были задачи, описания, демо, согласования и регулярная фиксация требований. Но в проектах вокруг старых систем формальное ТЗ почти никогда не содержит всего живого контекста.
На практике рядом с документами всегда остаются:
Старая система
Показы заказчика на звонках
Устные пояснения
Исключения, которые «и так понятны» тем, кто давно работает в процессе
Решения, которые всплывают между делом на демо или в обсуждении спорного сценария
Первые месяцы все выглядело нормально. Но ближе к запуску старая система окончательно отключилась, сроки стали поджимать, и внимание заказчика к новой системе резко выросло. Тут и началась плотная обратная связь: оказалось, что часть ожиданий команда и заказчик понимали по-разному.
Именно тогда появилась идея собрать базу знаний не только из официальных артефактов, но и из реальной истории проекта: из записей встреч.
С чего началось решение
Незадолго до этого вышел материал про подход LLM Wiki от бывшего директора по ИИ в Tesla и сооснователя OpenAI Андрея Карпати. Это идея о том, что можно брать исходные записи, прогонять их через языковую модель, раскладывать по нормализованной структуре и потом работать уже не с хаосом источников, а с упорядоченной базой знаний.
Эта идея вдохновила команду. Под базу знаний проекта завели отдельный репозиторий: туда складывали записи встреч, транскрибации, проектные термины, справочники и нормализованные статьи. Задача была не заменить YouTrack, демо и обычные проектные документы, а собрать под ними слой проектной памяти. Такой слой, из которого можно уточнять требования, проверять спорные места и обновлять основные статьи без гадания по воспоминаниям.
Полное описание автоматизации через агента читайте на Хабре.
Как выглядел процесс без деталей пайплайна
Если сильно сжать, схема была такой:
Команда брала запись встречи с заказчиком.
Получала транскрибацию и чистила ее от очевидных ошибок.
Агент извлекал из встречи факты, договоренности, открытые вопросы и противоречия.
Эти знания раскладывались не по встречам, а по основным статьям базы знаний.
Человек проверял результат, спорные места и структуру.
Готовая база становилась доступна команде и заказчику в Gramax.
Самый важный вывод: второй мозг не появляется из одного удачного промпта. Он появляется, когда у команды есть устойчивый контур: источники отдельно, нормализованные знания отдельно, открытые вопросы отдельно, изменения видны, а человек может проверить, откуда взялся конкретный факт.
Именно тут Gramax оказался полезен. Агенту удобно работать с файлами, структурой репозитория и правилами обработки. Людям удобно видеть статьи, разделы, ссылки, таблицы, историю изменений и опубликованный портал. Gramax связал эти два мира: оставил базу знаний в открытом Markdown и Git, но дал поверх нее визуальный интерфейс, ревью изменений, поиск и публикацию.
Что оказалось самым интересным
Внутри кейса было много технических деталей, но для продуктовой версии важнее четыре наблюдения.
Агенту нужна структура, а не просто большой контекст
Первую структуру базы агент построил по самым заметным темам первых встреч. Она была логичной, но не очень пригодной для долгой жизни проекта. Когда встреч становится много, база должна отвечать не на вопрос «что мы обсуждали в начале», а на вопрос «где человеку и агенту искать нужный тип знания».
В итоге базу перестроили вокруг разных слоев:
Быстрый старт и пользовательские сценарии
Инструкции и рабочие действия
Бизнес-процессы и правила системы
Проектный контекст, решения и минутки со встреч
Это хороший пример того, почему визуальная работа со структурой важна не меньше самого ИИ. Модель может предложить раскладку, но человек должен быстро увидеть ее как базу знаний: где разделы, где статьи, где дубли, где слишком длинно, где не хватает навигации.
Доверие появляется через дифф
Когда агент меняет базу знаний, самая страшная часть не в том, что он ошибется. Ошибки поправимы. Страшнее, если непонятно, что именно он поменял и почему.
Поэтому рабочий процесс постепенно пришел к редакторской логике: агент предлагает изменения, человек смотрит дифф, принимает полезное, отклоняет лишнее и вручную правит спорное. Это ускоренный режим работы с проектной памятью.
В интерфейсе Gramax мы сфокусированы на удобной работе с изменениями, чтобы ничего не прошло мимо глаз автора.
База знаний должна быть видна заказчику
Пока результат живет только в локальном репозитории, он полезен технической команде, но плохо подходит для совместного ревью. А в этом кейсе было важно показать заказчику не папку Markdown-файлов и не архив расшифровок, а понятный портал документации.
И это резко меняет качество обсуждения. Заказчик смотрит не «что там агент насобирал», а нормальную базу знаний: со структурой, поиском и связанными статьями. Замечания становятся предметными, потому что обсуждается уже не сырье, а оформленная картина проекта.
Что получилось в итоге
Когда архив встреч прогнали через этот контур, команда получила не просто набор конспектов, а рабочую проектную базу знаний. Ее отдали заказчику на ревью в виде портала документации с поиском. Результат оказался хорошим: заказчик прислал лишь несколько крупных замечаний, а по остальным материалам, по сути, подтвердил, что база правильно фиксирует требования и логику системы.
После этого история не закончилась. Команда перешла в режим текущей эксплуатации: новая встреча, новая транскрибация, предложение изменений в конкретных статьях, проверка человеком, обновленная база для всех участников проекта.
Документация перестала быть разовым восстановлением требований перед запуском. Она стала живым контуром, который обновляется вместе с проектом. А Gramax в этом контуре нужен как место, где человек видит не абстрактный ответ модели, а конкретные изменения в конкретных статьях.
Что это изменило в работе команды
Пропало бутылочное горлышко. В виде одного человека, который держит весь проект в голове. Раньше таким человеком сначала был один коллега, потом другой. К ним все ходили за ответами, а они сами не всегда были уверены на сто процентов. Теперь у команды есть общий слой проектной памяти, к которому можно задавать вопросы. Если ключевой носитель контекста уходит на больничный, в отпуск или просто переключается на другую задачу, проект не останавливается.
Сократилось число лишних встреч. В одном из эпизодов команда спорила о том, как именно работает старая логика. Без базы знаний это легко могло закончиться новым звонком с заказчиком на час. Вместо этого руководитель проекта задал вопрос агенту: он сначала ответил по базе знаний, потом по просьбе сходил глубже в сырые источники и за несколько минут подтвердил правильную трактовку.
Отдельно мне понравился человеческий момент: руководитель ожидал один ответ, а агент подтвердил, что прав коллега. То есть второй мозг оказался полезен не только для доказательства своей позиции, но и для проверки собственной памяти.
Ускорился онбординг. Новый участник проекта смог не устраивать серию вводных созвонов, а сначала задать свои вопросы агенту и уже потом прийти с очень коротким хвостом уточнений. Для сложных проектных команд это огромная экономия внимания.
В чем здесь польза Gramax
Базовую механику можно повторить и без Gramax: локальная модель, репозиторий, редактор и аккуратный процесс уже дадут пользу. Но без Gramax такая схема остается техническим пайплайном вокруг файлов. Gramax превращает ее в рабочее место для команды: с визуальным чтением, ревью, поиском, ссылками и публикацией.
Вот где это было особенно заметно:
Чтение и правка без боли от Markdown. Большой объем Markdown неудобно читать в текстовом виде. Особенно таблицы. Gramax стал способом смотреть на ту же базу знаний в нормальном, читаемом виде, спокойно ее вычитывать и при необходимости править через визуальный редактор. Это особенно важно в команде, где не все хотят жить в VS Code.
Контролируемые изменения. Важен режим, где агент не меняет базу молча: он предлагает правки, а человек видит, что именно поменялось, и только потом принимает, отклоняет или правит руками. На таком процессе держится доверие к базе знаний.
Поиск в двух режимах. В этом кейсе пользовались не только агентом, но и обычным поиском по ключевым словам. В одних случаях нужен быстрый поиск по слову, в других — вопрос к агенту с учетом всей базы знаний. Оба сценария оказались полезны.
Совместная работа и публикация без лишней инфраструктуры. Не нужно было идти в GitLab, поднимать отдельный портал или придумывать обходной путь: можно было просто отправить ссылку на редактор Gramax коллеге, попросить комментарий, а заказчику отдать читаемый портал с поиском и понятной структурой. Это снимало типичный конфликт между «нам удобно хранить знания в репозитории/заказчику нужно видеть нормальную документацию».
Единый источник для людей и агента. Агенту нужны Markdown-файлы, структура, индексы и правила маршрутизации. Людям нужны статьи, разделы, понятные ссылки и возможность быстро проверить результат. В Gramax это один и тот же каталог, а не две расходящиеся копии базы знаний.
Если смотреть на это уже с продуктовой стороны, то здесь особенно хорошо сработали несколько архитектурных особенностей Gramax:
Открытый текстовый формат, поверх которого вообще можно строить агентную работу
Возможность работать с локальным каталогом как с обычным репозиторием
Визуальный редактор поверх Markdown, который делает такую базу пригодной не только для разработчиков
Наглядный дифф и история коммитов для отслеживания эволюции базы знаний
В этом кейсе Gramax выступает как рабочий слой между локальной агентской автоматизацией и живыми людьми, которым нужно читать, обсуждать, искать, комментировать и публиковать знания.
Где человек все еще незаменим
В этом кейсе ИИ не заменил аналитика. Человек все равно:
Оценивал удачность структуры
Решал, когда статья слишком длинная
Принимал решения по спорным трактовкам
Вычитывал результаты
Корректировал стиль и плотность текста
Проверял, что агент не придумал лишнего
Как видите, магии в духе «ИИ ведет проектную документацию сам» нет. Я бы сказала:
ИИ превращает десятки часов исходных материалов в черновик проектной памяти, который человек может быстро довести до рабочего состояния
Что за MVP агента Gramax
Как я уже писала в начале статьи, мы сейчас строим ИИ-агента Gramax. Он сможет делать многое из того, что сейчас делают локальные агенты, но в визуальном интерфейсе. В первой версии уже закрывается важная часть сценария SellOut+, но не весь контур целиком.
Агент работает в визуальном редакторе.
Можно подключить локальную модель для NDA-проектов.
Агент может дополнять существующие статьи, создавать новые, менять структуру документации
Можно загружать в агента файлы как источники новых знаний
Вести термины и переиспользуемые определения через фрагменты
Разделять типы страниц и метаданные через свойства каталога
Принимать изменения через понятный интерфейс визуального диффа
Публиковать порталы для заказчиков или экспортировать доки в PDF или DOCX
Что пока остается за пределами идеального сценария:
Встроенная транскрибация как часть продукта
Совсем бесшовная загрузка и разбор исходных материалов
Встроенный журнал разбора как объект продукта, а не только как пользовательский прием
Полная стабильность сложных многошаговых агентных пайплайнов
Нативная интеграция со связанными системами вроде таск-трекера.
Что я вынесла из этого кейса
Это история про то, что в сложных проектах самый дефицитный ресурс — не текст как таковой, а восстановимая память. Пока память живет в головах, минутках с созвонов и недописанных постановках, проект остается хрупким.
Как только у команды появляется второй мозг, с которым можно разговаривать, который помнит историю решений, умеет показать пруфы и постоянно обновляется по новым встречам, меняется сама скорость коллективного мышления.
И, пожалуй, именно это мы строим в Gramax. Рабочую среду, где командная память перестает жить в голове одного человека и становится доступной, проверяемой и пригодной для ежедневной работы.
Следующий шаг для нас очевиден: продолжать собирать такие реальные кейсы, переносить из них лучшие практики в продукт и убирать техническое трение там, где сегодня людям все еще приходится собирать пайплайны вручную.
Если у вас уже есть похожий сценарий работы с документацией через агентов, Cursor, Claude Code, локальные модели или Markdown-репозитории — пишите! Просто обсудим или отгрузим вам Gramax для пилота:)