---
title: "ИИ-агент в общем чате: что предусмотреть до запуска"
metaTitle: "ИИ-агент в общем чате: до запуска"
description: "Что нужно настроить в правилах участия, доступе и управлении поручениями, прежде чем агент войдёт в рабочий чат команды."
date: 2026-09-26
tags: [agentic-ai, team-workflows, ai-implementation]
cover: cover.webp
coverAlt: "Рисованная сотрудница с пропуском стоит у турникета перед открывающимся проходом"
draft: false
sources:
  - https://x.com/DhravyaShah/status/2103668051468300701
  - https://github.com/supermemoryai/company-brain
  - https://github.com/supermemoryai/company-brain/blob/0071d6164991ce5dccddbd645bcac631ee477572/docs/guide/permissions.md
  - https://github.com/supermemoryai/company-brain/blob/0071d6164991ce5dccddbd645bcac631ee477572/src/brain/memory/read-scope.ts
  - https://github.com/supermemoryai/company-brain/blob/0071d6164991ce5dccddbd645bcac631ee477572/src/brain/slack/active-turn-gate.ts
  - https://github.com/supermemoryai/company-brain/blob/0071d6164991ce5dccddbd645bcac631ee477572/src/brain/turn/compute.ts
---

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

## Откуда взялся этот кейс

26 сентября 2026 года инженер Dhravya Shah [открыл исходный код](https://x.com/DhravyaShah/status/2103668051468300701) проекта Company Brain - ИИ-агента для корпоративных чатов. По его словам, сервис закрылся, потому что он решил сосредоточиться на API памяти - инструменте, который позволяет приложениям хранить и извлекать контекст между сессиями, как записная книжка для модели. Исходники лежат на GitHub под лицензией Apache 2.0, и в них хорошо видно, как авторы решали конкретные архитектурные задачи: инициатива агента, границы доступа, смена поручения на ходу.

Это чужой инженерный кейс, не проект Majento. Мы читали код на зафиксированном коммите, но не разворачивали систему и не проводили аудит безопасности - гарантировать отсутствие уязвимостей нельзя. Зато кейс хорошо иллюстрирует решения, которые придётся принимать любой команде при запуске агента в общем чате.

## Когда агент молчит, а когда отвечает

Первое, что нужно настроить, - правила участия. Агент получает сообщения в пределах своих прав и подключений, но это не значит, что он должен реагировать на каждое из них.

В коде Company Brain события сначала фильтруются: проверяются тип сообщения, отправитель, режим участия в канале и ограничения частоты. Только после этого агент оценивает, стоит ли вмешаться. Авторы описывают внутренние оценки полезности, уверенности, срочности, «шума» и стоимости вмешательства - под которой понимается отвлечение участников разговора, - и по ним программно выбирают один из трёх исходов: ответить, тихо проверить информацию без сообщения в чат или пропустить.

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

«Тихий канал» в этой логике - не неактивный чат, а канал с настройкой ограниченного участия. Агент там может работать в фоне, но не вмешиваться в разговор без явного обращения. Это настраивается командой, а не определяется автоматически.

Уровень инициативности регулируется по каналам. Например, в канале поддержки можно настроить агента так, чтобы он реагировал на входящие вопросы - но это конкретная настройка, а не гарантия ответа на любой запрос. В канале общих обсуждений разумнее ограничить участие явным обращением.

## Что агент видит, а что нет

Второй вопрос - доступ к данным. Он неочевиден, потому что в чате несколько контекстов.

В Company Brain это решается через область чтения. Механизм описан в документации проекта и реализован в `read-scope.ts` ([permissions.md](https://github.com/supermemoryai/company-brain/blob/0071d6164991ce5dccddbd645bcac631ee477572/docs/guide/permissions.md), [read-scope.ts](https://github.com/supermemoryai/company-brain/blob/0071d6164991ce5dccddbd645bcac631ee477572/src/brain/memory/read-scope.ts)):

| Контекст | Что читает агент |
|---|---|
| Публичный канал | Общая память команды |
| Закрытый канал | Общая память и память этого канала |
| Личный диалог | Общая память, личная память сотрудника и закрытые каналы, к которым у него есть доступ |

Последняя строка - самая важная. В личном диалоге сотрудник может спросить агента о данных из закрытого канала, к которому у него есть права. Агент ответит. Но разрешение читать закрытый источник не означает разрешения публиковать найденное в общий канал - это отдельное правило, которое команда устанавливает сама.

Запись при этом всегда идёт в одну область - туда, откуда пришёл разговор. Агент не записывает в общую память то, что узнал в личном диалоге.

![Развилка архивных проходов: фонарь освещает папку в отдельной секции](/blog/team-ai-agent-shared-chat/fig-scoped-search.webp "Учебная иллюстрация: поиск ограничен разрешёнными источниками")

Это описанный механизм конкретной реализации, а не универсальная гарантия изоляции данных. Любую систему нужно проверять под свои сценарии - подробнее о том, как устроены разрешения, мы разбирали в материале [«Права доступа в корпоративном ИИ»](/ru/blog/company-brain-permissions/).

Общие подключения к внешним сервисам работают только на чтение. Запись - через личное подключение конкретного сотрудника. Внешние действия (отправить письмо, создать задачу) требуют отдельной политики доступа.

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

## Память и живые данные - разные вещи

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

Если нужно знать статус последнего письма или актуальный этап согласования - это нужно проверять в подключённом приложении, а не доставать из памяти. Агент, который отвечает на основе устаревшего воспоминания, создаёт иллюзию осведомлённости там, где её нет.

Это не баг конкретной системы - это принципиальное ограничение. Память хороша для контекста, живые данные нужны для статуса. Смешивать их опасно.

## Поручение изменилось: что происходит с задачей

Общий чат - живая среда. Люди уточняют, переформулируют, отменяют. Агент должен понимать, как новое сообщение соотносится с тем, что он уже делает.

В Company Brain для этого есть логика обработки входящих сообщений во время активной задачи ([active-turn-gate.ts](https://github.com/supermemoryai/company-brain/blob/0071d6164991ce5dccddbd645bcac631ee477572/src/brain/slack/active-turn-gate.ts)). Она различает три варианта. Новое сообщение не относится к текущей задаче - агент его игнорирует. Новое сообщение совместимо с текущей задачей - оно добавляется к ней. Новое сообщение противоречит текущей задаче - задача заменяется. Остановку задачи автор описывает отдельно, как самостоятельный механизм.

Важная деталь: логика учитывает, кто отправил сообщение. Тот, кто поставил задачу, может перезапустить её несовместимым уточнением. Чужое несовместимое изменение встаёт в очередь, а не немедленно меняет ход работы. Это значит, что команда коллеги не всегда сразу влияет на то, что агент делает прямо сейчас.

Попросили агента написать черновик письма Иванову. Потом написали «добавь в копию юриста» - это совместимое уточнение, оно добавляется. Потом написали «нет, адресат Петров, не Иванов» - это несовместимое изменение, задача заменяется с учётом правила об авторстве. Потом написали «стоп, пока не готовь письмо, условия сделки меняются» - это остановка, агент приостанавливается.

Результат должен учитывать актуальное поручение, а не то, с чего началась работа. Кто именно вправе изменить или остановить чужую задачу - правило команды, которое нужно прописать до запуска.

О том, как правильно формулировать поручения агенту с самого начала, чтобы потом меньше переформулировать, - читайте в статье [«Как составить задачу для ИИ-агента»](/ru/blog/ai-agent-task-brief/).

## Подтверждение действия: когда оно нужно

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

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

Авторы Company Brain описывают сохранение задачи в состоянии «ожидает одобрения» с приостановкой выполнения. После решения та же задача продолжается с того места, где остановилась. Это описанный механизм - насколько надёжно он работает на практике, нужно проверять отдельно. Если согласование отклонено, действие не выполняется.

Запрос на подтверждение должен показывать конкретное действие, получателя и данные - иначе человек не может принять осмысленное решение. «Агент хочет что-то отправить» - плохой запрос. «Агент отправит черновик договора Иванову на ivan@example.com» - понятный запрос.

Отдельно стоит проверить сценарий, который легко упустить: действие выполнено, но подтверждение потерялось, и задача возобновилась. Нужна проверка факта действия и защита от повторной отправки. Это критерий приёмки, который команда должна проверить на тестах, - не утверждение о том, что любая готовая система это умеет.

## Долгая работа: инструменты, шаги, восстановление

Агент в чате иногда берётся за задачи, которые занимают несколько шагов: поискать информацию, сверить с документом, написать черновик. Здесь важно понимать, что «я работаю» - не то же самое, что результат.

Инструменты (поиск, память, внешние приложения) подключаются по необходимости, а не все сразу. Это уменьшает нагрузку на контекст и упрощает выбор - агент не перебирает десятки доступных действий на каждом шаге. Скрытие лишних инструментов не заменяет серверную проверку прав: разрешения нужно проверять отдельно, на уровне логики доступа.

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

Промежуточные обновления полезны, когда задача долгая. Обновление ради обновления («я ещё работаю») раздражает. Обновление по существу («нашёл три варианта, проверяю четвёртый») - полезно.

Контрольные точки помогают восстановить задачу после сбоя. Но восстановление - это не магия: агент возобновляет работу с последней сохранённой точки, и нужно убедиться, что уже выполненные действия не повторятся.

![Экран с приостановленной передачей файла и отсоединённый кабель накопителя](/blog/team-ai-agent-shared-chat/fig-interrupted-transfer.webp "После сбоя нужно проверить, что уже выполнено, прежде чем повторять действие")

## Как проверить, что всё работает

Прежде чем запускать агента на реальный поток, стоит пройти несколько конкретных сценариев вручную. Это редакционные рекомендации Majento, а не результаты испытаний Company Brain.

- Проверьте фоновое участие агента в обсуждении, где коллега уже ответил: агент не должен добавлять такой же ответ без новых сведений. На прямой повторный вопрос ответить допустимо.
- Спросите из публичного канала о данных из закрытого - проверьте, что агент не выносит лишнего.
- Уточните адресата письма после того, как агент начал работу, - посмотрите, как обрабатывается несовместимое изменение.
- Напишите «стоп» в середине задачи - убедитесь, что работа приостанавливается.
- Откажите в согласовании - действие не должно выполниться.
- Проверьте поведение после сбоя во время внешнего действия - особенно сценарий с потерянным подтверждением.
- Дайте задачу на основе устаревших данных в памяти - агент должен запросить актуальные данные в исходной системе.
- Запустите задачу, которая явно превысит лимит шагов, - проверьте, что агент сообщает о частичном результате.

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

Пилот лучше начинать в одном канале на одном процессе. Сначала - обучение команды и общие правила участия, потом - реальный случай с понятными критериями приёмки. Подробнее о том, как организовать такой пилот, - на странице [пилотного внедрения ИИ в команде](/ru/team-ai-pilot/).

## Вопросы и ответы

### Агент в общем чате получает все сообщения?

Область получения сообщений определяется правами и подключением. Присутствие человека в одном канале не даёт агенту автоматического доступа к остальным. Фоновое наблюдение и прямое обращение обрабатываются по-разному. Что именно агент вправе читать и записывать - определяется настройками доступа.

### Можно ли ограничить агента одним каналом?

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

### Что делать, если агент начал выполнять задачу, а поручение изменилось?

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

### Self-hosted значит, что данные никуда не уходят?

Для этого проекта - нет. README репозитория Company Brain описывает программную часть на Cloudflare Workers и Durable Objects, но память и модели используют внешние API. Данные туда уходят. Стоимость инфраструктуры и внешних сервисов тоже остаётся. Перед развёртыванием стоит разобраться, какие данные и куда передаются.

*Если хотите разобрать конкретный сценарий или подготовить команду к запуску агента - пишите в [t.me/shimaoz](https://t.me/shimaoz) или на [hello@majento.ai](mailto:hello@majento.ai). Как организовать пилотный запуск с критериями приёмки - на странице [«Команда и ИИ: пилотный запуск»](/ru/team-ai-pilot/).*