В ноябре 2026 года LangChain опубликовала разбор своего внутреннего GTM Agent - агента на фреймворке Deep Agents, который собирает sales-документы под конкретную сделку: кастомные account plans, proof-of-value материалы, коммерческие презентации (proposal decks) и планы онбординга клиента.
Результаты за 12 недель работы: 1 540 сгенерированных артефактов, больше 100 в неделю, 337 часов сэкономленного времени репсов на документах, которые реально ушли клиентам. Сделки, где репс отправил такой артефакт, переходили на следующую стадию в 47% случаев против 16% у сопоставимых сделок без документа. 46% артефактов сопровождались звонком клиенту в течение 14 дней.
Главный тезис автора публикации Nick Bray: качество даёт контекст, который команда заложила в агента, а не тюнинг промптов. Оговорка сразу: это внутренний кейс самой LangChain, цифры компания приводит по собственной работе, независимой проверки нет. Ценность материала в другом - он показывает, из каких слоёв складывается контекст, без которого агент для продаж генерирует красивые, но бесполезные файлы.
Что такое GTM Agent от LangChain и какую проблему он решал
GTM Agent вырос из инструмента, которым репсы LangChain пользовались ежедневно: он искал информацию по новым лидам, готовил черновики персонализированного аутрича на одобрение в Slack и раз в неделю подсвечивал сигналы по аккаунтам, включая возможности расширения и риски сделок. Генерация документов стала расширением уже работающего помощника, а не отдельным ботом, которого надо было уговаривать открыть.
Список артефактов из публикации: кастомные account plans, proof-of-value документы, proposal decks, onboarding plans. Каждый документ собирается под конкретный аккаунт. Агент знает, на какой стадии стоит сделка, и предлагает нужный документ перед звонком клиенту - то есть работает как часть процесса продажи, а не как генератор текста по запросу.
Три проблемы, которые решали: разнобой версий, ручная сборка, отсутствие единого процесса
До появления генерации артефактов в компании происходило то, что знакомо почти любой sales-команде. В организации всплывали несогласованные версии одного и того же документа. Account executives собирали proposal decks руками: вытаскивали данные об использовании продукта в чат-ассистент, а потом сами склеивали презентацию. Одна и та же работа повторялась на каждой сделке и выглядела каждый раз по-разному.
Команда LangChain формулирует задачу как три одновременных условия: держать высокую планку для всего, что видит клиент; прекратить повторять ручную работу, которую делал каждый репс; следовать единому процессу. Проверьте по своей команде: если proposal deck собирается заново для каждой сделки и у двух репсов выглядят по-разному, проблема та же.
Почему это не «ещё один чат-ассистент»
Универсальный ассистент не знает, на какой стадии сделка, какие требования нужно закрыть для перехода дальше и как выглядит документ в бренд-гайдлайнах компании. Он пишет текст по описанию из промпта. GTM Agent получает стадию сделки из рабочей системы, видит, что обсуждалось с клиентом на прошлых звонках, и подставляет это в документ.
Разница видна на уровне поведения: агент сам предлагает нужный артефакт перед звонком, потому что знает позицию сделки. Универсальный чат так не делает - ему нужно объяснить ситуацию словами, и каждый раз заново.
Почему контекст важнее промптов: четыре слоя, которые дают качество
«Most of the quality comes from the context we gave the agent rather than from prompt tuning».
Перевод короткий: большая часть качества идёт от контекста, который дали агенту, а не от настройки промптов. LangChain раскладывает этот контекст на четыре составляющие.
- Вкус от sales-лидерства - представление о том, какой документ считается хорошим, сформулированное теми, кто отвечает за результат команды.
- Контекст из реальных звонков клиентам - транскрипты разговоров, то есть то, что клиент уже слышал и о чём спрашивал.
- Бизнес-логика - стадии продаж, принятые в компании.
- Конкретные требования для прохождения каждой стадии - что должно быть в документе, чтобы сделка считалась продвинутой дальше.
Дальше начинается инженерия, а не магия. Промпт без этих данных даёт генерический текст: модель не знает ни стадии сделки, ни того, что клиент сказал на прошлом звонке, ни того, какие цифры принято показывать в proof-of-value документе конкретной компании. Можно сколько угодно переписывать инструкцию, документ останется правдоподобным, но пустым.
Данные из Salesforce и транскриптов звонков
В описании кейса Salesforce указан как источник состояния сделки и её стадии, транскрипты звонков - как источник того, что реально обсуждалось с клиентом. Схему интеграции, частоту синхронизации и способ выгрузки транскриптов LangChain в открытом тексте не раскрывает, поэтому конкретную архитектуру подключения придётся проектировать под свою CRM.
Практический вывод от этого не меняется: агенту нужен доступ к актуальному состоянию сделки и к содержанию разговоров. Один слой без другого даёт перекос. Только CRM - документ с правильной стадией, но без учёта того, что клиент уже слышал. Только транскрипты - персонализированный текст без привязки к формальным требованиям стадии.
Требования к стадиям сделки и бренд-гайдлайны
«Вкус» от sales-лидерства и требования к прохождению стадий переводятся в проверяемые правила: чек-лист того, что должно быть в документе, какие разделы обязательны, какие формулировки запрещены. Шаблоны и бренд-гайдлайны задают форму, чтобы репс не переверстывал слайды после генерации.
Отсюда неприятный для многих вывод: если процесс продаж в компании не формализован, агенту нечего знать. Сначала опишите стадии и требования к документам, потом стройте агента. Обратный порядок даёт инструмент, который уверенно генерирует документы по несуществующим правилам.
Архитектура GTM Agent: skills, sandbox, память и scheduled runs
Публикация перечисляет примитивы, на которых держится решение: sandbox (песочница для выполнения кода и работы с файлами), skills (навыки под конкретные типы документов), память и запуски по расписанию. По словам LangChain, эти же примитивы доступны в Managed Deep Agents - управляемой версии фреймворка. Как устроена граница между открытым харнессом и управляемым продуктом, мы разбирали в материале о внутренних агентах LangChain для маркетинга, продаж и разработки.
Sandbox с Office-инструментами: почему агент должен собирать файлы, а не текст
Sales-артефакт - это не абзац в чате, а презентация или документ, который уйдёт клиенту. По описанию кейса, песочница даёт агенту офисные инструменты, чтобы он собирал файл целиком. Смысл понятен из исходной боли: если агент возвращает текст, репс снова руками переносит его в PowerPoint и верстает слайды, то есть та самая ручная сборка, из-за которой версии расходились, никуда не делась.
Конкретный набор библиотек и формат выходных файлов LangChain в открытом тексте не детализирует. Для повторения подхода достаточно принципа: результат работы агента должен быть готовым файлом в принятом в компании формате, а не полуфабрикатом.
Slack как интерфейс и human-in-the-loop
Репсы одобряют черновики аутрича в Slack - агент не отправляет клиенту ничего без человека. Это одновременно решение про UX и про контроль качества: инструмент живёт там, где команда и так проводит день, а решение остаётся за репсом. В кейсе человек остаётся в контуре принятия решения, полной автоматизации отправки нет.
Побочный эффект такого дизайна полезен для отладки: одобрение или правка в Slack становится сигналом о качестве документа, который можно собирать и разбирать.
Память, scheduled runs и трассировка в LangSmith
Запуски по расписанию закрывают регулярные задачи. В кейсе это еженедельное выявление сигналов по аккаунтам: возможности расширения и риски сделок. Репсу не нужно помнить, что пора посмотреть аккаунт, агент приходит сам.
Память сохраняет контекст между запусками, чтобы агент не начинал каждую неделю с нуля. Трассировка в LangSmith нужна для отладки многошагового процесса: без неё непонятно, на каком шаге документ потерял нужный раздел. Как оценивать качество длинных документов от агента и что ломается в калибровке, разобрано в кейсе Similarweb и LangSmith. Конкретные настройки памяти, расписаний и правила трассировки LangChain в публикации не раскрывает - это придётся проектировать самостоятельно.
Цикл самопроверки документов и правило остановки
Схема работы с документом выглядит так: агент генерирует черновик, проверяет его по заданным критериям, дорабатывает и останавливается по правилу остановки. Критерии проверки выводятся из того же контекста - требования стадии сделки, бренд-гайдлайны, полнота обязательных разделов.
Правило остановки нужно ровно для одной цели: не дать агенту бесконечно улучшать документ. Без ограничителя цикл «сгенерировал, нашёл замечание, переписал» крутится до исчерпания лимита шагов, сжигает токены и время, а качество на третьей-четвёртой итерации уже не растёт. Точную формулировку правила и конкретные пороги LangChain в открытом тексте не приводит, поэтому подставлять числа имеет смысл только по результатам собственных замеров: сколько итераций реально улучшают документ в вашем домене.
Финальное одобрение остаётся за человеком. Самопроверка снижает число правок, но не заменяет репса, который отвечает перед клиентом за содержание.
Метрики: как измерить, что агент приносит пользу, а не просто генерирует
LangChain раскладывает пользу на четыре категории, и каждая отвечает на свой вопрос.
| Категория | Что показывает | Значение в кейсе | Что доказывает |
|---|---|---|---|
| Volume | Объём генерации | 1 540 артефактов за 12 недель, больше 100 в неделю | Что агент работает и встроен в поток задач |
| Utilization | Доля артефактов, дошедших до клиента или звонка | 46% артефактов с последующим звонком в течение 14 дней | Что документы используются, а не лежат в папке |
| Leverage | Сэкономленное время репсов | 337 часов на артефактах, отправленных клиентам | Что экономия измерима в часах и понятна руководству |
| Outcomes | Влияние на движение сделки | 47% против 16% перехода на следующую стадию | Что связь с результатом есть, причинность не доказана |
Volume и utilization: почему счётчик сгенерированных документов ничего не доказывает
1 540 артефактов звучит солидно, и это только объём. Сам по себе он не говорит о пользе: агент может штамповать файлы, которые никто не открывает. Метрика 46% артефактов с последующим звонком в течение 14 дней - уже сигнал, что документ встроился в реальный процесс продажи, а не остался в папке.
Считать utilization сложнее, чем volume, и здесь легко обмануться. Если мерить «процент обработанных обращений» или статус в CRM, картина искажается: в разборе агента поддержки с падением медианы решения с 22 часов до 22 минут видно, как процент автоматизации расходится с фактическим результатом. Для sales-агента аналог такой проверки - доля артефактов, после которых был звонок или отправка клиенту.
Leverage и outcomes: часы и стадии сделки
337 часов сэкономленного времени - метрика, которую можно показать руководству: она переводит работу агента в понятную единицу. Outcomes отвечает на вопрос, изменилось ли что-то в сделках: 47% против 16% перехода на следующую стадию у сопоставимых сделок.
Если считать аналог в своей компании, зафиксируйте три вещи до запуска: какие стадии считаются продвижением, за какой период сравниваем и по каким признакам подбираем сопоставимые сделки (размер, сегмент, стадия на старте, репс). Методологию сопоставления LangChain не раскрывает, поэтому сравнение 47% против 16% остаётся сравнением с matched deals, а не строгим экспериментом.
Ограничения подхода: где GTM Agent не сработает
- Зависимость от чистоты данных. Стадия сделки в CRM устарела - документ описывает ситуацию, которой уже нет. Транскриптов звонков нет - агент теряет слой контекста, который в кейсе даёт большую часть качества.
- Нужен формализованный процесс продаж. Без описанных стадий и требований к переходу агенту нечего проверять, и цикл самопроверки превращается в формальность.
- Человек остаётся в контуре. Одобрение в Slack означает, что время репса экономится, но не исчезает: проверить документ всё равно нужно.
- Цифры нельзя переносить на другой бизнес. Это внутренний инструмент LangChain. 47% против 16% получены на их сделках, с их процессом и их данными.
- Корреляция вместо причинности. Репсы могут отправлять документы в более перспективных сделках, и тогда часть эффекта объясняется отбором, а не агентом.
- Стоимость запуска не раскрыта. Песочница, трассировка, поддержка контекста в актуальном состоянии - всё это требует ресурсов, но конкретных цифр в публикации нет. Придумывать их не стоит.
Как повторить подход: практический чек-лист внедрения AI-агента в бизнес-процесс
- Выберите узкий процесс с повторяемой ручной работой. В кейсе это сборка proposal decks: понятный вход, понятный выход, очевидная боль.
- Опишите стадии и требования к документам. Формализуйте, что должно быть в артефакте, чтобы сделка продвинулась дальше.
- Соберите контекст: данные CRM о состоянии сделки, транскрипты звонков, шаблоны, бренд-гайдлайны.
- Определите «вкус» вместе с sales-лидерством: какие документы считаются хорошими и почему. Это не формальность, а критерии проверки для цикла самопроверки.
- Выберите примитивы: skills под типы документов, песочница с офисными инструментами для сборки файлов, интерфейс там, где работает команда, запуски по расписанию для регулярных задач, трассировка для отладки.
- Оставьте human-in-the-loop: одобрение репсом перед отправкой клиенту и правило остановки в цикле доработки, чтобы агент не жёг ресурсы на бесконечных итерациях.
- Зафиксируйте метрики и базу сравнения до запуска: volume, utilization, leverage, outcomes.
Порядок шагов неслучаен: контекст идёт первым, промпты настраиваются последними и по остаточному принципу. Если не хочется собирать песочницу, память и расписания самостоятельно, Managed Deep Agents закрывает часть инфраструктуры. Альтернатива - своя сборка; чем она отличается по latency, стоимости и надёжности, разобрано в материале о создании AI-агента с нуля.
С чего начать, если процесс продаж не формализован
Начните с документа, а не с кода. Опишите стадии сделки, требования к переходу между ними и эталонные документы для каждой стадии - хотя бы по одному хорошему примеру с разбором, почему он хороший. Эта работа занимает время и никуда не девается: без неё агент будет генерировать правдоподобные файлы по несуществующим правилам, а репсы вернутся к ручной сборке.
Какие метрики заложить до запуска
Определите четыре числа заранее: ожидаемый объём артефактов в неделю, целевую долю артефактов, доходящих до клиента или звонка, ожидаемую экономию часов, критерий сравнения сделок с документом и без. Отдельно зафиксируйте способ подбора сопоставимых сделок. Если определить его после запуска, метрика неизбежно подгонится под желаемый результат.
Что это значит для рынка AI-агентов: ставка на вертикальные решения
Кейс показывает разницу между универсальным ассистентом и агентом под процесс. Примитивы одинаковые: skills, песочница, память, запуски по расписанию. Результат разный ровно настолько, насколько различается объём бизнес-контекста, заложенного в агента. Тот же набор примитивов в другом процессе даёт другой продукт, и это нормально.
Практический вывод для тех, кто строит агента: смещайте бюджет усилий с переписывания промптов на сбор и структурирование контекста. Формализованные стадии, чистые данные CRM, доступ к транскриптам, критерии качества от людей, отвечающих за результат, - это скучная работа, которая определяет, будет ли инструмент полезен. История с побочным продуктом, где агент для разработки закрыл более 50% исследовательских запросов аналитиков благодаря контекстной инфраструктуре, подтверждает ту же закономерность с другой стороны.
Начните с одного процесса, где ручная работа повторяется каждую сделку, и доведите контекст до состояния, в котором документ можно отправлять клиенту после беглой проверки. Если этого не получается, проблема почти всегда в данных и правилах, а не в формулировке промпта.