AI
ИИ-агент в общем чате: что предусмотреть до запуска
Прежде чем агент войдёт в общий чат, нужно решить четыре вещи: когда он вмешивается, что ему видно, кто вправе изменить поручение и что происходит, если он не успел доделать работу. Без этого агент может отвечать невпопад, смешивать чужие данные или продолжать выполнять задачу, которую уже отменили.
Откуда взялся этот кейс
26 сентября 2026 года инженер Dhravya Shah открыл исходный код проекта Company Brain - ИИ-агента для корпоративных чатов. По его словам, сервис закрылся, потому что он решил сосредоточиться на API памяти - инструменте, который позволяет приложениям хранить и извлекать контекст между сессиями, как записная книжка для модели. Исходники лежат на GitHub под лицензией Apache 2.0, и в них хорошо видно, как авторы решали конкретные архитектурные задачи: инициатива агента, границы доступа, смена поручения на ходу.
Это чужой инженерный кейс, не проект Majento. Мы читали код на зафиксированном коммите, но не разворачивали систему и не проводили аудит безопасности - гарантировать отсутствие уязвимостей нельзя. Зато кейс хорошо иллюстрирует решения, которые придётся принимать любой команде при запуске агента в общем чате.
Когда агент молчит, а когда отвечает
Первое, что нужно настроить, - правила участия. Агент получает сообщения в пределах своих прав и подключений, но это не значит, что он должен реагировать на каждое из них.
В коде Company Brain события сначала фильтруются: проверяются тип сообщения, отправитель, режим участия в канале и ограничения частоты. Только после этого агент оценивает, стоит ли вмешаться. Авторы описывают внутренние оценки полезности, уверенности, срочности, «шума» и стоимости вмешательства - под которой понимается отвлечение участников разговора, - и по ним программно выбирают один из трёх исходов: ответить, тихо проверить информацию без сообщения в чат или пропустить.
Прямое обращение обрабатывается иначе, чем фоновое наблюдение. Если кто-то написал агенту напрямую, нужен внятный ответ. Если агент сам решил что-то проверить в фоне и ничего не нашёл - он может промолчать, не выдавая «ничего не нашёл» как отдельное сообщение. Но молчать после прямого обещания нельзя: пользователь ждёт результата.
«Тихий канал» в этой логике - не неактивный чат, а канал с настройкой ограниченного участия. Агент там может работать в фоне, но не вмешиваться в разговор без явного обращения. Это настраивается командой, а не определяется автоматически.
Уровень инициативности регулируется по каналам. Например, в канале поддержки можно настроить агента так, чтобы он реагировал на входящие вопросы - но это конкретная настройка, а не гарантия ответа на любой запрос. В канале общих обсуждений разумнее ограничить участие явным обращением.
Что агент видит, а что нет
Второй вопрос - доступ к данным. Он неочевиден, потому что в чате несколько контекстов.
В Company Brain это решается через область чтения. Механизм описан в документации проекта и реализован в read-scope.ts (permissions.md, read-scope.ts):
| Контекст | Что читает агент |
|---|---|
| Публичный канал | Общая память команды |
| Закрытый канал | Общая память и память этого канала |
| Личный диалог | Общая память, личная память сотрудника и закрытые каналы, к которым у него есть доступ |
Последняя строка - самая важная. В личном диалоге сотрудник может спросить агента о данных из закрытого канала, к которому у него есть права. Агент ответит. Но разрешение читать закрытый источник не означает разрешения публиковать найденное в общий канал - это отдельное правило, которое команда устанавливает сама.
Запись при этом всегда идёт в одну область - туда, откуда пришёл разговор. Агент не записывает в общую память то, что узнал в личном диалоге.
Это описанный механизм конкретной реализации, а не универсальная гарантия изоляции данных. Любую систему нужно проверять под свои сценарии - подробнее о том, как устроены разрешения, мы разбирали в материале «Права доступа в корпоративном ИИ».
Общие подключения к внешним сервисам работают только на чтение. Запись - через личное подключение конкретного сотрудника. Внешние действия (отправить письмо, создать задачу) требуют отдельной политики доступа.
Агент видит только то, что подключено и к чему у него есть права, а не всё, что есть в компании. Это стоит проговорить с командой до запуска, потому что ожидания часто расходятся с реальностью в обе стороны.
Память и живые данные - разные вещи
Агент запоминает устойчивые вещи: решения команды, роли, контекст проекта. Это полезно. Но вчерашняя запись в памяти не доказывает сегодняшнее состояние задачи.
Если нужно знать статус последнего письма или актуальный этап согласования - это нужно проверять в подключённом приложении, а не доставать из памяти. Агент, который отвечает на основе устаревшего воспоминания, создаёт иллюзию осведомлённости там, где её нет.
Это не баг конкретной системы - это принципиальное ограничение. Память хороша для контекста, живые данные нужны для статуса. Смешивать их опасно.
Поручение изменилось: что происходит с задачей
Общий чат - живая среда. Люди уточняют, переформулируют, отменяют. Агент должен понимать, как новое сообщение соотносится с тем, что он уже делает.
В Company Brain для этого есть логика обработки входящих сообщений во время активной задачи (active-turn-gate.ts). Она различает три варианта. Новое сообщение не относится к текущей задаче - агент его игнорирует. Новое сообщение совместимо с текущей задачей - оно добавляется к ней. Новое сообщение противоречит текущей задаче - задача заменяется. Остановку задачи автор описывает отдельно, как самостоятельный механизм.
Важная деталь: логика учитывает, кто отправил сообщение. Тот, кто поставил задачу, может перезапустить её несовместимым уточнением. Чужое несовместимое изменение встаёт в очередь, а не немедленно меняет ход работы. Это значит, что команда коллеги не всегда сразу влияет на то, что агент делает прямо сейчас.
Попросили агента написать черновик письма Иванову. Потом написали «добавь в копию юриста» - это совместимое уточнение, оно добавляется. Потом написали «нет, адресат Петров, не Иванов» - это несовместимое изменение, задача заменяется с учётом правила об авторстве. Потом написали «стоп, пока не готовь письмо, условия сделки меняются» - это остановка, агент приостанавливается.
Результат должен учитывать актуальное поручение, а не то, с чего началась работа. Кто именно вправе изменить или остановить чужую задачу - правило команды, которое нужно прописать до запуска.
О том, как правильно формулировать поручения агенту с самого начала, чтобы потом меньше переформулировать, - читайте в статье «Как составить задачу для ИИ-агента».
Подтверждение действия: когда оно нужно
Перед отправкой важного письма или созданием задачи стоит убедиться, что агент делает именно то, что имелось в виду.
Подтверждение нужно для действий, которые попадают в зону риска по принятой в команде политике. Заранее одобренные рутинные действия агент может выполнять автоматически - не нужно требовать подтверждения на каждый шаг.
Авторы Company Brain описывают сохранение задачи в состоянии «ожидает одобрения» с приостановкой выполнения. После решения та же задача продолжается с того места, где остановилась. Это описанный механизм - насколько надёжно он работает на практике, нужно проверять отдельно. Если согласование отклонено, действие не выполняется.
Запрос на подтверждение должен показывать конкретное действие, получателя и данные - иначе человек не может принять осмысленное решение. «Агент хочет что-то отправить» - плохой запрос. «Агент отправит черновик договора Иванову на ivan@example.com» - понятный запрос.
Отдельно стоит проверить сценарий, который легко упустить: действие выполнено, но подтверждение потерялось, и задача возобновилась. Нужна проверка факта действия и защита от повторной отправки. Это критерий приёмки, который команда должна проверить на тестах, - не утверждение о том, что любая готовая система это умеет.
Долгая работа: инструменты, шаги, восстановление
Агент в чате иногда берётся за задачи, которые занимают несколько шагов: поискать информацию, сверить с документом, написать черновик. Здесь важно понимать, что «я работаю» - не то же самое, что результат.
Инструменты (поиск, память, внешние приложения) подключаются по необходимости, а не все сразу. Это уменьшает нагрузку на контекст и упрощает выбор - агент не перебирает десятки доступных действий на каждом шаге. Скрытие лишних инструментов не заменяет серверную проверку прав: разрешения нужно проверять отдельно, на уровне логики доступа.
Автор описывает бюджет шагов: перед тем как исчерпать лимит, агент предупреждает и переключается в режим ответа по собранному. Это разумный компромисс для ограниченных ресурсов в конкретной реализации, но не универсальная рекомендация обрезать сложные задачи. Если ресурс кончился раньше, чем задача решена, агент должен сообщить, что проверено и что осталось, - а не выдавать частичный результат за полный.
Промежуточные обновления полезны, когда задача долгая. Обновление ради обновления («я ещё работаю») раздражает. Обновление по существу («нашёл три варианта, проверяю четвёртый») - полезно.
Контрольные точки помогают восстановить задачу после сбоя. Но восстановление - это не магия: агент возобновляет работу с последней сохранённой точки, и нужно убедиться, что уже выполненные действия не повторятся.
Как проверить, что всё работает
Прежде чем запускать агента на реальный поток, стоит пройти несколько конкретных сценариев вручную. Это редакционные рекомендации Majento, а не результаты испытаний Company Brain.
- Проверьте фоновое участие агента в обсуждении, где коллега уже ответил: агент не должен добавлять такой же ответ без новых сведений. На прямой повторный вопрос ответить допустимо.
- Спросите из публичного канала о данных из закрытого - проверьте, что агент не выносит лишнего.
- Уточните адресата письма после того, как агент начал работу, - посмотрите, как обрабатывается несовместимое изменение.
- Напишите «стоп» в середине задачи - убедитесь, что работа приостанавливается.
- Откажите в согласовании - действие не должно выполниться.
- Проверьте поведение после сбоя во время внешнего действия - особенно сценарий с потерянным подтверждением.
- Дайте задачу на основе устаревших данных в памяти - агент должен запросить актуальные данные в исходной системе.
- Запустите задачу, которая явно превысит лимит шагов, - проверьте, что агент сообщает о частичном результате.
Измерять стоит четыре вещи: сколько задач агент выполнил с результатом, который команда смогла использовать, сколько раз вмешался без запроса там, где это было не нужно, сколько раз корректно отказался от действия при отклонённом согласовании и сколько раз повторил уже выполненное действие. Целевые цифры каждая команда ставит под свой процесс.
Пилот лучше начинать в одном канале на одном процессе. Сначала - обучение команды и общие правила участия, потом - реальный случай с понятными критериями приёмки. Подробнее о том, как организовать такой пилот, - на странице пилотного внедрения ИИ в команде.
Вопросы и ответы
Агент в общем чате получает все сообщения?
Область получения сообщений определяется правами и подключением. Присутствие человека в одном канале не даёт агенту автоматического доступа к остальным. Фоновое наблюдение и прямое обращение обрабатываются по-разному. Что именно агент вправе читать и записывать - определяется настройками доступа.
Можно ли ограничить агента одним каналом?
Участие агента можно ограничить настройками и подключением: область чтения и запись настраиваются по контексту, публичный канал, закрытый канал и личный диалог дают разный уровень доступа. Это не равнозначно изоляции памяти только одного канала: описанная схема включает общую память команды, которая доступна из разных контекстов. Строгую изоляцию источников по каналам нужно настраивать отдельно.
Что делать, если агент начал выполнять задачу, а поручение изменилось?
Совместимое уточнение добавляется к текущей задаче. Несовместимое требование может заменить её - с учётом того, кто отправил сообщение. Кто вправе менять или останавливать чужую задачу - это правило команды, его нужно прописать до запуска.
Self-hosted значит, что данные никуда не уходят?
Для этого проекта - нет. README репозитория Company Brain описывает программную часть на Cloudflare Workers и Durable Objects, но память и модели используют внешние API. Данные туда уходят. Стоимость инфраструктуры и внешних сервисов тоже остаётся. Перед развёртыванием стоит разобраться, какие данные и куда передаются.
Если хотите разобрать конкретный сценарий или подготовить команду к запуску агента - пишите в t.me/shimaoz или на hello@majento.ai. Как организовать пилотный запуск с критериями приёмки - на странице «Команда и ИИ: пилотный запуск».