LangChain собрала трёх внутренних AI-агентов и использует их каждый день: GTM Agent для продаж, OpenSWE для инженерии и Content Studio для маркетинга. Компания описывает эффект коротко: агенты полностью изменили работу этих команд. Практическая ценность кейса в другом: все три системы собраны из одного набора примитивов, и этот набор можно воспроизвести у себя.
Примитивы такие:
- агент живёт в Slack, где люди уже работают;
- у агента есть идентичность: он действует от лица вызвавшего пользователя (on-behalf-of, OBO) или под собственным сервисным аккаунтом;
- память делится на глобальную, общую для всех, и пользовательскую, привязанную к конкретному человеку;
- код исполняется в песочнице, а запросы к сервисам с аутентификацией идут через прокси секретов;
- значительная доля прогонов запускается по расписанию или событию, помимо прямого запроса человека.
Кто есть кто. GTM Agent это проактивный агент для продаж: следит за письмами и отвечает на них, обрабатывает новые квалифицированные лиды, присылает ежедневные сводки, отвечает на вопросы по аккаунтам и выполняет исходящие действия. OpenSWE это инженерный агент: работает над PR, готовит черновики PR и прогоняет код-ревью по всем PR. Content Studio это маркетинговый агент: готовит черновики блогов, изображений, презентаций и видео в стиле компании и с учётом её позиционирования. Все формулировки задач взяты из описания «company harness» в блоге LangChain, опубликованного 25 октября 2026 года.
Три агента, один набор примитивов: что именно построила LangChain
Общий набор примитивов означает, что командам не пришлось изобретать каналы, память и права заново. Различия между агентами сводятся к задачам, набору инструментов и решениям по идентичности. Ниже сводная картина, дальше разбор по частям.
Почему все три агента живут в Slack
У каждого агента своё Slack-приложение, к нему можно обратиться в личных сообщениях или отметить его в канале. Логика простая: агент появляется там, где люди уже работают. Не нужен отдельный интерфейс на старте, не нужно учить команду новому инструменту и держать вкладку открытой.
Плата за это решение тоже понятна. Чат плохо подходит для пакетных операций и для задач, где нужно отслеживать десятки однотипных объектов: сообщения тонут в истории, статусы приходится держать в голове. LangChain упёрлась в это на практике, отсюда появились приём breakout и отдельный UI для части сценариев, о них ниже.
Сводная таблица: три агента и их решения
| Агент | Команда | Задача | Идентичность при прямом запросе | Идентичность в фоне | Режим запуска |
|---|---|---|---|---|---|
| GTM Agent | Продажи (GTM) | Письма, новые квалифицированные лиды, ежедневные сводки, вопросы по аккаунтам, исходящие действия | Фиксированные учётные данные для Salesforce; доступ к почте от лица пользователя только в личных сообщениях | В описании не уточняется | Проактивный, постоянно работает: события (письма, лиды) и расписание (сводки) |
| OpenSWE | Инженерия | Работа над PR и черновиками PR, код-ревью всех PR | От лица пользователя: PR открывается с его GitHub-хэндлом | Собственное GitHub-приложение | По запросу и по событиям (новые PR) |
| Content Studio | Маркетинг | Черновики блогов, изображений, презентаций, видео в стиле компании | От лица пользователя в Notion | Публикация в Twitter через общий аккаунт с ограниченным списком допущенных пользователей | По запросу |
Ячейки с пометкой «не уточняется» оставлены пустыми намеренно. В опубликованном описании LangChain этих деталей нет, и достраивать их по догадке смысла нет.
Идентичность агента: OBO или собственный сервисный аккаунт
Первый вопрос при проектировании: от чьего имени агент пишет в CRM, открывает PR или публикует пост. В индустрии есть два основных подхода, и LangChain формулирует их прямо. On-behalf-of: агент действует от лица пользователя, который его вызвал. Fixed credentials: у агента фиксированный набор учётных данных, например сервисный аккаунт, одинаковый независимо от того, кто поставил задачу.
Выбор привязан к сервису и сценарию, идеологии здесь мало. OBO даёт точную атрибуцию: в логах и интерфейсе видно, кто инициировал действие, а права наследуются от человека. Минус в привязке к живой сессии и согласию конкретного сотрудника. Сервисный аккаунт удобнее для фоновых прогонов и поддержки, зато размывает ответственность: формально действие совершил агент, и разбираться в инциденте сложнее. LangChain применяет оба подхода в одном продукте.
OpenSWE: PR от имени пользователя, фон под своим GitHub-приложением
При получении сообщения OpenSWE действует от лица пользователя: например, открывает PR с его GitHub-хэндлом. Когда тот же агент работает в фоне, скажем, прогоняет код-ревью, он действует под собственной идентичностью через своё GitHub-приложение.
Смысл гибрида в том, что авторство остаётся за человеком: PR в истории репозитория связан с конкретным инженером, который попросил агента о работе. Фоновые прогоны при этом не зависят от того, кто запустил агента и открыта ли у него сессия. Побочный вопрос для собственного проекта: кто владеет действием в аудите, человек или агент, и что попадёт в отчёт при разборе инцидента.
GTM Agent: фиксированные учётные данные для Salesforce, OBO для почты только в личных сообщениях
Для Salesforce агент использует фиксированные учётные данные. Доступ к почте от лица пользователя он получает только в личных сообщениях. Разделение по каналу выглядит логично: переписка это чувствительная зона, и работать с чужой почтой в общем канале, где сообщения видят коллеги, не стоит.
Компромисс здесь честный. Фиксированные креды для CRM проще поддерживать: не нужно проводить OBO-авторизацию на каждого сотрудника, интеграция не ломается, когда человек в отпуске или сменил роль. Плата за это в том, что в Salesforce действия выглядят как работа одного сервисного пользователя, и по записи не всегда понятно, кто инициировал изменение. OBO точнее по правам, но зависит от активности и согласия человека.
Content Studio: OBO в Notion, общий аккаунт Twitter с ограниченным списком
В Notion агент действует от лица пользователя. Публикация в Twitter идёт через общий аккаунт, но с ограниченным списком допущенных пользователей.
Публичный канал отличается от внутреннего тем, что ошибка стоит дорого и удаляется плохо. Поэтому доступ сужается списком, а не раздаётся всей команде. Это организационная мера поверх технической. В описании LangChain механизм ведения списка не раскрыт: не сказано, как именно проверяются допущенные пользователи и кто обновляет перечень.
Память, песочница и запуск: что делает агента агентом, а не чат-ботом
Три оставшихся примитива отвечают за то, чтобы система работала как сотрудник, а не как окно чата с промптом.
Двухуровневая память: глобальная и пользовательская
Память в описании LangChain имеет два скоупа. Глобальная общая для всех пользователей агента: стиль компании, позиционирование, правила. Пользовательская привязана к конкретному человеку: его предпочтения, контекст задач, история обращений.
Разница видна на Content Studio. Требование «писать в стиле компании» закрывается глобальным слоем, а конкретика вроде «этот автор готовит анонс для одного сегмента и не любит длинные вступления» должна жить в пользовательском. Если слои перепутать, личный контекст утечёт в общие ответы для всей команды. В описании кейса механизм защиты от такого смешения не детализирован, поэтому это задача для проектирования, а не готовое решение, которое можно скопировать.
Как разделение прав и памяти реализуется в родственной инфраструктуре, видно по обзору Managed Deep Agents 0.8 с user-level memory и user-owned credentials. Отдельная проблема долгоживущих агентов, разрастание контекста, разобрана в материале про context engineering в Deep Agents.
Песочница и прокси секретов: как агент ходит в сервисы
Код выполняется в песочнице. Запросы к сервисам, которым нужна аутентификация, идут через прокси секретов: агент не держит сырые ключи в исполняемом коде и не тащит их в контекст модели.
Практический смысл в двух вещах. Утечка через сгенерированный код или попавший в промпт лог становится маловероятной. Доступ можно ограничивать и отзывать централизованно, не меняя код агента. Какими конкретно средствами это сделано у LangChain, в описании не раскрыто: не названы ни реализация прокси, ни хранилище секретов, ни модель изоляции песочницы.
Запуск по расписанию и событиям, а не только по запросу
Значительная доля прогонов у этих агентов запланирована, а не вызвана человеком. В источнике такие системы называют ambient agents, то есть агенты, работающие в фоне.
Примеры: GTM Agent отправляет ежедневные сводки, следит за письмами и новыми квалифицированными лидами; OpenSWE прогоняет код-ревью по всем PR. Для архитектуры это меняет три вещи. Нужен планировщик (cron) или обработчик событий. Нужна идентичность для фоновых прогонов, потому что живого пользователя в этот момент нет. И нужен способ доставлять результат туда, где его увидят, иначе работа в фоне остаётся незамеченной.
Breakout и кастомный UI: где заканчивается чат
Работа в Slack упирается в гигиену канала. Агент, который отвечает в общем треде, перемешивает свои сообщения с обсуждением людей, и через десяток реплик ветку читать невозможно.
Решение LangChain называет breakout: агент выносит разговор в отдельный тред в канале, а человеческая дискуссия продолжается без мусора. Приём дешёвый и заметно снижает раздражение команды, что для внутреннего инструмента важнее красивых демо.
Когда одного Slack недостаточно
Второй сюжет кейса: для разбора большого бэклога писем, которые GTM Agent предлагает отправить, LangChain сделала кастомный UI. Причина приземлённая. Одно письмо в Slack посмотреть нормально, десятки писем с действиями по каждому отслеживать в сообщениях неудобно.
Отсюда критерий, который можно примерить к своему проекту. Разовый запрос живёт в чате. Пакетная работа с состоянием, где нужно сравнивать элементы, держать статусы и подтверждать действия, требует отдельного интерфейса. Формальной методологии LangChain тут не предлагает: вывод собран из описанного опыта.
Managed Deep Agents: что платформа берёт на себя
Deep Agents это открытый харнесс LangChain: среда исполнения агента с инструментами, управлением контекстом и субагентами. Managed Deep Agents это инфраструктура над ним, которая закрывает каналы (Slack), cron-задачи, песочницы, память и идентичность.
Все три агента LangChain используют один и тот же набор примитивов, и именно этот слой берёт их на себя. Каждой команде не нужно поднимать свой шлюз в Slack, свою систему секретов и свой планировщик. Экономия здесь не в строках кода, а в том, что решения по идентичности и памяти принимаются один раз и одинаково для всех агентов.
Граница знания: в описании нет ни цен Managed Deep Agents, ни ограничений беты, ни деталей реализации. Как устроен открытый харнесс и что на нём строят, видно по другим проектам: например, Deep Life Sci для фармы и лабораторной науки собран на Deep Agents с песочницей LangSmith.
Рамка для собственного решения простая. Для одного агента под одну задачу примитивы реально собрать самому. Когда агентов несколько и они работают с чувствительными сервисами, стоимость владения этими примитивами растёт, и готовый слой начинает окупаться. Что выгоднее в вашем случае, зависит от требований к аудиту, изоляции и числа команд.
Что из этого кейса стоит перенести в свою компанию
Порядок действий, который следует из примитивов LangChain:
- Выберите среду, где люди уже работают. Slack или его аналог даёт нулевой порог входа, но заранее заложите breakout, иначе агент начнёт мешать в каналах.
- По каждому сервису решите, OBO или сервисный аккаунт. Начинайте с самых чувствительных: почта, публичные каналы, продакшен-инфраструктура. Для внутренней CRM сервисный аккаунт часто достаточен, для публикации в соцсети нужен узкий список допущенных.
- Разграничьте глобальную и пользовательскую память до запуска. Правила компании и стиль живут в общем слое, личный контекст сотрудника в пользовательском, и между ними должна быть граница.
- Вынесите исполнение кода в песочницу, а доступ к сервисам пустите через прокси секретов. Ключи не должны попадать в код агента и в контекст модели.
- Определите, какие прогоны будут по расписанию и событиям, и заранее придумайте идентичность для них. Фоновый агент без собственных прав не запустится, а с чужими правами создаст проблемы в аудите.
- Решите, где нужен кастомный UI. Пакетные операции с подтверждениями вроде разбора бэклога писем в чате неудобны, и это выясняется быстро.
Ограничения кейса стоит держать в голове. Это опыт одной компании, метрик эффективности и цен в описании нет. Выбор идентичности всегда компромисс между точной атрибуцией и удобством поддержки, а двухуровневая память требует собственной проработки защиты от смешения слоёв. Если хочется сравнить подход с самописной архитектурой, начните с разбора оркестрации, памяти и инструментов агента с кодом на Python.