Сначала процесс, потом агент
Три месяца ничего не писал сюда.
Не потому что тема ИИ-аутрича закончилась. Скорее наоборот: она стала слишком маленькой.
Раньше я смотрел на аутрич как на цепочку задач:
— собрать базу
— обогатить компании и людей
— найти сигналы
— написать первое сообщение
— найти message-market fit
— разобрать ответы
— передать тёплые лиды продавцу
Это всё ещё важно. Но сейчас мне кажется, что это только частный случай более крупной темы.
И тема эта - агентные рабочие процессы.
Главный сдвиг в том, что мы перестаём строить отдельные автоматизации вокруг инструментов. Вместо этого мы начинаем описывать саму работу: откуда берётся задача, какие источники важны, где лежит правда, какие решения надо принять, что можно сделать автоматически, а где нужен человек.
Аутрич был удобной песочницей, потому что там всё видно: есть база, есть компания, есть человек, есть гипотеза, есть письмо, есть ответ, есть следующий шаг.
Но если посмотреть глубже, это не “аутрич”.
Это рабочий объект (ну или work item).
У него есть контекст, источники, цель, ограничения, действие, состояние и память.
И вот вокруг таких объектов будут строиться нормальные ИИ-системы.
Агент - это не промпт с доступом к инструментам
Плохая версия агента выглядит так:
“Вот тебе промпт, вот тебе доступ к почте, срмке и базе, делай полезные вещи”.
Это почти всегда ломается.
Не потому что модель тупая. А потому что рабочий процесс не описан.
Модель не знает:
— какой источник главный
— где данные устарели
— что можно менять, а что только читать
— когда нужен человек
— что считать хорошим результатом
— что надо запомнить на будущее
— что делать, если инструмент вернул мусор
— как понять, что задача застряла
Инструменты дают агенту руки. Но не дают ему понимание работы.
Если дать агенту доступ к хабспоту, почте и таблицам, он не становится оператором. Он просто получает поверхность для ошибок.
Нормальный агент начинается не с промпта.
Он начинается с карты рабочего процесса.
Рабочий процесс важнее инструмента
Последние годы мы строили операционные системы компаний в интерфейсах.
Правило в одном сервисе. Таблица в другом. Статус в срмке. Решение в телеге. Контекст в почте. Финальная версия в документе. Настоящая причина решения - у человека в голове.
Потом приходит ИИ, и мы делаем вид, что ему достаточно “подключиться к инструментам”.
Но проблема не в том, что инструментов мало.
Проблема в том, что работа размазана между ними.
Например, в аутриче:
— срмка знает, что компания есть в пайплайне
— почта знает, что им уже писали
— таблица знает, какой был сегмент
— обогащение знает, кто там работает
— прошлый ответ знает, почему они не купили
— продавец помнит, что фаундер просил вернуться через два месяца
Если агент видит только одну часть, он делает красивую, но бесполезную работу.
Он может написать хорошее письмо не тому человеку.
Может предложить не тот угол.
Может повторить уже проверенную гипотезу.
Может открыть старую рану в отношениях с клиентом.
Может создать ещё один “почти правильный” текст, который человеку всё равно надо полностью перепроверять.
Поэтому главный вопрос теперь не:
“Какой инструмент подключить?”
А:
“Как выглядит рабочий объект, который агент должен вести?”
Что такое рабочий объект (work item)
Рабочий объект - это не запись в базе и не задача в таск-трекере.
Это минимальная единица реальной работы.
Для аутрича это может быть “компания, с которой мы хотим начать разговор”.
Для продаж - “сделка, которую надо сдвинуть”.
Для фаундера - “возможность, которую нельзя потерять”.
Для медиа-команды - “бриф от рекламодателя, из которого надо собрать предложение”.
У нормального рабочего объекта есть несколько слоёв.
Первый слой - источники.
Откуда мы знаем, что происходит? Почта, CRM, звонок, документ, таблица, сайт, заметка, прошлый ответ.
Второй слой - доверие.
Какой источник главный? Что устарело? Что является фактом, а что выводом? Что сказал клиент, а что мы сами предположили?
Третий слой - состояние.
На каком этапе работа? Кто владелец? Что уже сделано? Что ждём? Где застряли?
