Как устроено сохранение контекста задачи
Контекст задачи — это набор сведений, без которых нельзя правильно продолжить работу: цель, исходные данные, принятые решения, ограничения, ответственные, текущий статус и следующий шаг. Он может включать переписку с клиентом, комментарии сотрудников, документы, договорённости после встреч и историю изменений.
Обычно эти сведения распределены между почтой, мессенджерами, CRM, таск-трекером, таблицами и личными заметками. Формально задача существует в одной системе, но важное уточнение может остаться в сообщении руководителя, а причина принятого решения — только в памяти участника встречи. Из-за этого человеку приходится заново собирать картину перед каждым следующим действием.
Ручная нагрузка появляется не только при поиске информации. Нужно отделять актуальные договорённости от устаревших, переносить выводы из переписки в карточку задачи, фиксировать изменения и проверять, не противоречат ли новые указания прежним условиям. Чем дольше живёт задача и чем больше людей в ней участвует, тем труднее поддерживать её историю в понятном состоянии.
Проблема особенно заметна при передаче работы другому сотруднику. Новый участник видит десятки сообщений, несколько версий документа и короткое описание задачи, которое уже не отражает реальное положение дел. В результате он либо задаёт вопросы заново, либо начинает действовать по неполной картине.
Сохранение контекста не означает накопление всей доступной информации. Хороший контекст помогает принять следующее решение, а не превращает карточку задачи в архив. В нём должны оставаться существенные факты, источники этих фактов и понятная связь между прошлым решением и текущим состоянием.
Какие шаги можно поручить ИИ-агенту
Самый простой подход — поручить сотруднику вручную поддерживать краткое описание задачи. Он читает новые сообщения, обновляет статус и записывает договорённости. Такой порядок понятен, но зависит от дисциплины: при высокой загрузке записи быстро отстают от реальности.
Обычная автоматизация работает по заранее заданной схеме. Например, после смены статуса она создаёт напоминание или копирует поле из CRM в таск-трекер. Это полезно, когда входные данные структурированы, а действие всегда одинаково. Но жёсткое правило не умеет самостоятельно разобраться, является ли фраза в переписке новым решением, предположением или просто обсуждением.
Чат-бот действует по запросу пользователя. Ему можно передать переписку и попросить сделать сводку, но человек каждый раз сам выбирает материалы, формулирует запрос и решает, куда сохранить ответ.
ИИ-агент отличается тем, что работает не с одним сообщением, а с последовательностью действий и заданной целью. Он может получать новые материалы из разрешённых источников, находить изменения, обновлять сводку и передавать результат в рабочую систему. Подробнее общий принцип разобран в статье «Что такое ИИ-агент для бизнеса».
На практике агенту можно поручить сбор новых сообщений и документов, выделение решений, подготовку краткого описания текущего состояния, поиск расхождений и формирование следующего шага. Например, после встречи он сопоставляет расшифровку разговора с карточкой проекта и предлагает обновление: срок изменён, появился новый ответственный, один вопрос остался открытым.
Создание ИИ-агента имеет смысл не ради ещё одной красивой сводки. Практическая ценность появляется, когда результат возвращается туда, где сотрудники продолжают работу, а история обновлений остаётся доступной для проверки.
Какие задачи подходят агенту, а какие требуют решения человека
Лучше всего агент справляется с повторяемыми действиями, где можно описать ожидаемый результат. Он может собирать материалы по одной задаче, убирать повторы, группировать сообщения по темам, отмечать новые договорённости и готовить черновик обновления. Ему также можно поручить проверку комплектности: приложен ли нужный файл, указан ли ответственный, зафиксирован ли срок.
Подходящая задача допускает проверку по понятным признакам. Если агент пишет, что срок перенесён, рядом должна быть ссылка на сообщение или документ, из которого это следует. Если он сообщает о противоречии, человеку нужно видеть обе версии. Такая прослеживаемость важнее уверенного тона ответа.
Не стоит самостоятельно отдавать агенту решения, связанные с обязательствами компании, деньгами, юридическими последствиями, кадровыми вопросами или неоднозначными обещаниями клиенту. Фраза «постараемся закончить к пятнице» не равна согласованному сроку. Обсуждение скидки не означает, что скидка утверждена. Агент может обнаружить такие фрагменты и подготовить варианты, но окончательное толкование должно остаться за ответственным сотрудником.
Риск возникает и там, где источники неполны. Если часть переговоров прошла по телефону и не была зафиксирована, система не сможет восстановить отсутствующий факт. Она способна отметить пробел, но не должна заполнять его правдоподобной догадкой.
Поэтому уровень самостоятельности лучше привязывать к последствиям ошибки. Низкорисковые обновления можно сохранять автоматически. Значимые изменения сначала попадают в черновик, который подтверждает человек. Спорные случаи отправляются ответственному с исходными фрагментами и пояснением, почему агент не смог сделать однозначный вывод.
Какие данные, правила и интеграции нужны системе
Основа системы — источники, в которых действительно живёт работа. Это могут быть карточки проектов, письма, сообщения, документы, записи встреч и внутренние справочники. Подключать всё сразу необязательно. Часто полезнее начать с двух источников, между которыми сотрудники регулярно переносят сведения вручную.
Затем нужна единая структура контекста. Для одной компании достаточно полей «цель», «статус», «решения», «открытые вопросы» и «следующий шаг». Для другой понадобятся бюджет, версия документа, согласующий сотрудник или обязательства перед клиентом. Структура должна соответствовать реальной работе, иначе агент будет создавать аккуратные, но бесполезные тексты.
Правила объясняют системе, какие события считать важными. В них можно указать, что изменение срока требует подтверждения, предположение нельзя записывать как факт, а при конфликте источников нужно показать обе версии. Отдельно задаются права доступа: какие проекты разрешено читать, что можно изменять и кому отправлять спорные случаи.
Интеграции связывают источники с местом, где хранится актуальное состояние задачи. Технически это может быть API — программный способ обмена данными между сервисами. Для бизнеса важен не сам термин, а предсказуемый маршрут: откуда пришла информация, как она была обработана и куда записан результат.
Полезно сохранять журнал действий. В нём видно, какой материал использовал агент, что предложил изменить и кто подтвердил обновление. Такой журнал помогает разбирать ошибки без догадок. Также нужен механизм версий, чтобы предыдущее состояние можно было посмотреть и при необходимости вернуть.
Как проверить результат на небольшом пилоте
Для пилота лучше выбрать один повторяемый процесс с заметной ручной передачей информации. Это может быть сопровождение клиентского проекта, подготовка коммерческого предложения или работа с внутренними задачами после регулярных встреч. Подход к выбору подробно описан в материале «Как выбрать процесс для первого AI-пилота».
До запуска стоит зафиксировать исходное состояние. Сколько времени сотрудники тратят на поиск и восстановление истории? Какие сведения чаще всего теряются? Сколько раз приходится уточнять уже обсуждённое? Здесь не нужны показатели ради отчёта. Достаточно нескольких наблюдаемых критериев, связанных с реальной работой.
Затем выбирают ограниченный набор однотипных задач и заранее определяют правильный образец результата. Например: сводка не пропускает подтверждённые решения, отделяет факты от предположений, указывает источники и не меняет значимые поля без согласования.
Во время пилота полезно оценивать не красоту текста, а рабочую точность. Сотруднику должно быть легче понять состояние задачи, проверить вывод и продолжить действие. Отдельно стоит считать пропущенные факты, ошибочные трактовки, лишние уведомления и случаи, когда исправление ответа заняло больше времени, чем ручная работа.
Первый шаг простой: взять несколько завершённых задач, скрыть их итоговые карточки и проверить, сможет ли агент восстановить понятную хронологию только по разрешённым материалам. Сравнение с фактическим итогом покажет, где идея уже применима, а где сначала нужно привести в порядок источники и правила фиксации решений.