Контекст ИИ-агента в CRM: передача между ролями

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

Контекст ИИ-агента в CRM: передавать основания, а не только красивый ответ

Контекст ИИ-агента в CRM — это сведения, необходимые для конкретной задачи: объект, цель, подтверждённые факты, источники, ограничения и состояние работы. При передаче между ролями следующий агент должен получить не только текст предыдущего ответа, но и основания, актуальную версию данных и нерешённые вопросы. Иначе предположение одного исполнителя превращается в уверенное утверждение другого.

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

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

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

Почему единый чат не решает передачу контекста

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

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

ИИ-роли: ответственность определяется результатом

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

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

Когда два агента делают одно и то же без понятной границы, компания получает дополнительные расходы и спор о правильном ответе. Разделять роли стоит там, где различаются источники, критерии качества или права. Если один короткий процесс легко выполняется одним исполнителем, второй агент не делает его автоматически надёжнее. Сложность должна иметь рабочее объяснение.

В описании исследовательской мультиагентной системы Anthropic важное место занимает координация распределённой работы. Это пример для инженерного анализа, а не готовый шаблон отдела продаж. При переносе идеи в CRM нужно заново определить коммерческие роли, права и критерии результата.

Человек остаётся участником передачи

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

Для каждого перехода укажите принимающего. Им может быть другой агент или сотрудник, но должен существовать критерий готовности входа. Фраза «передать в продажи» слишком общая. Лучше «передать владельцу выбранного сегмента карточку с проверенными фактами и вопросом для первого контакта». Так понятно, какая работа завершается и какая начинается.

Пакет контекста: семь элементов, которые нельзя терять

Первый элемент — идентичность объекта. Нужны устойчивый идентификатор и связь с компанией, контактом или сделкой. Второй — цель текущего этапа. Третий — подтверждённые сведения с источниками. Четвёртый — гипотезы и неизвестное. Пятый — границы действий. Шестой — версия и время чтения. Седьмой — ожидаемый результат следующей роли. Такой пакет можно оформить в интерфейсе, таблице или структурированной записи.

Не обязательно показывать пользователю технический формат. Важно, чтобы человек мог открыть основания, увидеть пробелы и понять, что разрешено дальше. Сотруднику полезен читаемый бриф; системе нужны устойчивые поля. Эти представления должны согласовываться. Если интерфейс показывает «подтверждено», а в записи хранится только агентская догадка, визуальная аккуратность скрывает ошибку процесса.

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

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

Условная цепочка: от найденной компании до подготовки менеджера

Возьмём учебный сценарий. Исследователь нашёл компанию с несколькими филиалами и единым номером записи. Маркетолог предполагает, что ей может быть полезен общий контроль коммуникаций. Копирайтер готовит короткую формулировку предложения. Продажник уточняет канал и следующий шаг. Ассистент собирает бриф для сотрудника. Это пример проектирования, не описание готовой автоматической цепочки в любой AI-CRM.

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

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

Пример потери смысла на одном переходе

Исследователь пишет: «На сайте упоминаются пять филиалов; единая CRM не подтверждена». Следующий агент сокращает: «Компания с пятью филиалами использует единую CRM». Третий строит предложение интеграции с этой системой. Ошибка возникла при сокращении, а последующие шаги лишь её развили. Проверка пакета должна остановить передачу утверждения без источника, даже если весь текст выглядит правдоподобно.

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

Более подробно исследование компаний разобрано в материале о поиске B2B-клиентов с ИИ. Здесь важен сам переход: какие элементы следующая роль обязана сохранить и какие может дополнить. Она не должна повторять весь поиск, если пригодный проверяемый пакет уже существует.

Версии и память: что хранить между задачами

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

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

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

Когда информация устаревает

Разные сведения имеют разный срок пригодности. Реквизиты проверяют по своим правилам, повестку встречи — ближе к разговору, наличие вакансии — перед использованием как сигнала. Универсальный срок «хранить актуальным месяц» не отражает эти различия. Для важных источников обозначают дату проверки и событие, после которого требуется пересмотр.

Не удаляйте старую договорённость только потому, что появилась новая. Для истории важно, что именно изменилось. Но следующий исполнитель должен получить действующее состояние, а не два противоречащих срока без пояснения. Читаемый пакет может содержать одну актуальную строку и ссылку на изменение. История хранит детали, рабочий контекст — нужное решение.

Если объём памяти растёт, применяйте отбор по задаче. Для подготовки встречи нужны текущие условия и открытые вопросы; для разбора причины отказа — соответствующие события; для поддержки — доступные правила продукта. Принцип «весь архив всем агентам» увеличивает шум и расходы, не гарантируя лучшего понимания. Подготовка общей базы рассмотрена в материале о базе знаний для ИИ-агента.

Права: общий процесс не означает общий доступ ко всем данным

У каждой роли должно быть достаточное, но ограниченное представление. Копирайтеру для черновика первого контакта не обязательно читать все финансовые условия клиента. Аналитику может требоваться история событий, но не право отправить сообщение. Ассистенту нужны данные для подготовки конкретного сотрудника, а не доступ ко всем подразделениям. Передача контекста не должна обходить исходные ограничения.

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

Полезно сохранять, кто инициировал задачу и от чьего имени выполняется операция. Иначе агент поддержки может получить поручение из контекста другого отдела и использовать данные, которые не относятся к текущему обращению. Граница организации, команды и объекта проверяется не только в начале цепочки, но и при переходе к следующему действию.

Частичный сбой: не терять уже проверенную работу

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

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

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

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

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

Второй признак — все ответы имеют одинаковую общую структуру, хотя роли решают разные задачи. Аналитик должен объяснять основания, копирайтер — формулировать текст, ассистент — готовить сотрудника. Если каждый выдаёт обзор компании с одинаковыми пунктами, система не использует специализацию. Названия ролей становятся оформлением одного общего запроса.

Третий признак — никто не отвечает за приёмку перехода. Результат считается готовым, потому что модель закончила генерацию. Следующий этап получает непроверенные сведения, а ошибка обнаруживается у клиента. Контроль входа должен быть привязан к значимым ограничениям: правильный объект, источники, актуальность и допустимое действие. Не нужна проверка ради проверки, нужна защита конкретного решения.

В рекомендациях Anthropic по эффективным агентам предлагается начинать с простых решений и усложнять их по необходимости. Для CRM это полезная инженерная позиция: многоролевая цепочка оправдана, когда её части дают измеримый вклад, а не когда она эффектно выглядит на схеме.

Проверка передачи: тестировать границы, а не только финальный текст

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

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

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

Что согласовать для агентской CRM

При обсуждении Цифры начните с одной цепочки и её реальных задач. Какие роли доступны сейчас, какие сценарии требуют настройки, откуда поступают данные и какие действия разрешены? Не нужно обещать все названия профессий сразу. Полезнее показать один объект, источники, переход и результат для сотрудника, включая сложный случай с недостаточной информацией.

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

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