Managed Deep Agents 0.8 - релиз платформы, которая упаковывает харнесс Deep Agents в управляемую инфраструктуру для продакшена. Обновление добавляет user-owned credentials, user-level memory, HTTP-каналы, передачу файлов в Slack и встроенный веб-поиск на базе Parallel. Платформа при этом остаётся в бете.
Смысл релиза в том, что он разводит двух «пользователей» агента: команду, которая его собирает, и человека, от имени которого агент выполняет действия. До 0.8 такое разделение строили вручную: хранили токены каждого сотрудника, следили, чтобы история одного клиента не попала в контекст другого, писали отдельные коннекторы под каждую внутреннюю систему. Теперь это части платформы.
Что такое Managed Deep Agents и зачем вышел релиз 0.8
Managed Deep Agents объединяет харнесс Deep Agents с инфраструктурой, которая нужна агенту в продакшене: каналы (например, Slack), идентичность и аутентификация, управление разрешениями для инструментов. Харнесс отвечает за примитивы для длительных задач, а платформа - за рантайм вокруг них. В анонсе 0.8 продукт описан как код-фёрст проект в вашем репозитории: все примитивы агента складываются в одну директорию, а не разносятся по внешним сервисам.
Сборка такой обвязки своими силами обычно растягивается на кварталы дорожной карты и потом требует постоянной поддержки. Отсюда и логика managed-подхода: команда описывает поведение агента, а роутинг запросов, секреты и интеграции берёт на себя платформа. Общий обзор класса решений и критерии выбора собраны в статье про managed-агентов как новый стандарт продакшн-разработки.
Релиз 0.8 адресует четыре задачи, с которыми команды сталкиваются при выводе агентов в продакшен: память агента, аутентификацию, каналы и управление инструментами. Вот что конкретно появилось.
Ключевые нововведения 0.8: краткий список
- User-owned credentials. Агент получает доступ к инструментам с правами конкретного пользователя, а не с общим сервисным ключом на всю команду.
- User-level memory. Персональный контекст вызывающего пользователя хранится отдельно от общей памяти агента.
- HTTP-каналы. Агента можно подключить к внутренним инструментам, клиентским порталам и системам поддержки, которые умеют отправлять вебхуки.
- Передача файлов в Slack. Slack-канал теперь умеет передавать файлы в дополнение к приёму сообщений.
- Встроенный веб-поиск на базе Parallel. Работает из коробки: достаточно указать MCP-сервер в конфигурации, отдельный аккаунт и API-ключ не нужны.
User-owned credentials и user-level memory: как агент действует от имени пользователя
Один агент обычно обслуживает много людей: сотрудников отдела продаж, клиентов, операторов поддержки. Если все они ходят через один сервисный аккаунт, агент видит их данные одинаково и действует с одинаковыми правами. Разделение идентичности и памяти убирает эту общую точку отказа.
В структуре проекта за это отвечают файлы identity.py или identity.ts: в них настраивают аутентификацию, скоупинг потоков (thread scoping) и скоупинг памяти (memory scoping). Логику самой памяти описывают отдельно, в memory.py или memory.ts.
Чем user-level memory отличается от общей памяти агента
Общая память принадлежит агенту как продукту: инструкции, знания о предметной области, накопленные выводы, полезные всем без исключения. User-level memory привязана к конкретному человеку: его роль, прошлые обращения, предпочтения, история задач.
Аналогия простая. Общая память - это корпоративная база знаний, к которой обращаются все. User-level memory - личный профиль сотрудника, куда не подмешивается чужая история. Приватность здесь главная причина разделения, но есть и вторая: смешение контекстов заметно ухудшает ответы, потому что модель приписывает одному пользователю факты из диалогов другого.
Как credentials пользователя влияют на доступ к инструментам
User-owned credentials меняют модель доступа: агент работает в границах прав человека, который его вызвал, а не от имени общего сервиса. Что этому пользователю недоступно, того агент не сделает. Для аудита это удобно: во внешних системах остаётся след реальной учётной записи, а не безликого бота, и по логам понятно, кто именно инициировал действие.
Управление разрешениями для инструментов входит в управляемую инфраструктуру платформы. Ошибки в конфигурации при этом никто не отменял: если выдать интеграцию слишком широко или привязать не тот грант, агент отработает ровно по этим правам. Проверять скоупы стоит так же внимательно, как доступы любого другого сервиса с доступом к внутренним данным.
Типичная нагрузка, ради которой всё это делается: агент отдела продаж ищет данные об аккаунтах, исследует компанию, готовит брифинги к встречам и follow-up письма. Ему нужны память, доступ к инструментам, веб-поиск, рассуждение и планирование. Память при этом должна быть своей у каждого менеджера, а доступ к CRM - ограничен его зоной ответственности, а не всей базой клиентов.
HTTP-каналы: как подключить агента к внутренним инструментам и клиентским порталам
HTTP-каналы принимают вебхуки. Это самый низкий порог интеграции из возможных: если система умеет отправлять HTTP-запрос на событие, её уже можно связать с агентом без отдельного коннектора под каждый сервис. В описании релиза к целевым поверхностям отнесены внутренние инструменты, клиентские порталы, системы поддержки и другие продуктовые интерфейсы, способные отправлять вебхуки.
Примеры интеграций: поддержка, порталы, внутренние инструменты
- Система поддержки. Создание тикета отправляет вебхук с текстом обращения и данными клиента. Агент поднимает историю по этому пользователю, подтягивает документацию и возвращает черновик ответа обратно в тикет.
- Клиентский портал. Форма в личном кабинете шлёт вебхук, когда клиент задаёт вопрос по заказу. Агент видит только данные этого клиента, потому что работает в его правах, и отвечает прямо в интерфейсе портала.
- Внутренняя админка. Кнопка «подготовить выгрузку» отправляет событие с параметрами. Агент собирает данные доступными инструментами и возвращает результат в административный интерфейс.
Лимиты по частоте запросов, форматы payload и схемы аутентификации вебхуков в анонсе не раскрыты. Их стоит уточнять в документации до того, как проектировать нагрузку.
Передача файлов в Slack: что изменилось
Каналы в Managed Deep Agents - это точки входа, через которые пользователи пишут агенту; Slack и GitHub указаны как примеры таких каналов. В 0.8 к сообщениям добавилась передача файлов. Практический эффект: агент может отправить в канал отчёт, документ или другой результат работы, а не ограничиваться текстовым описанием. Какие именно типы файлов поддерживаются и как проходит передача, источник не уточняет, поэтому для конкретных сценариев это стоит проверить на своей сборке.
Встроенный веб-поиск на базе Parallel: без отдельного аккаунта и API-ключа
Веб-поиск в Managed Deep Agents работает на базе Parallel и включён из коробки. Раньше доступ к поиску означал ещё одну регистрацию, ещё один ключ в хранилище секретов и ещё одну точку для ротации. Теперь достаточно указать MCP-сервер в конфигурации: отдельный аккаунт и API-ключ не требуются.
Для агентов, которые исследуют компании, проверяют факты или собирают контекст к встрече, поиск в вебе - обязательный инструмент. Когда он доступен без внешнего провайдера, старт проекта ускоряется: меньше ключей и меньше согласований с безопасностью. Лимиты выдачи, глубина индекса и точность результатов в анонсе не описаны, поэтому для задач, критичных к достоверности, выдачу нужно проверять на своих запросах.
Структура проекта Managed Deep Agent: где что лежит
Managed Deep Agent - код-фёрст проект в репозитории. Примитивы агента раскладываются по файлам и директориям, и это упрощает ревью: изменение в правах, памяти или инструментах видно в диффе, а не спрятано в настройках внешней панели.
| Файл или директория | Назначение |
|---|---|
identity.py / identity.ts | аутентификация, скоупинг потоков и памяти |
memory.py / memory.ts | определение памяти агента |
tools/ | кастомные инструменты |
channels/ | точки входа, например Slack и GitHub |
middleware/ | кастомный middleware |
schedules/ | управляемые cron-расписания |
connectors/ | управляемые коннекторы |
skills/ | навыки, синхронизируемые в Context Hub |
sandbox/ | конфигурация песочницы |
evals/ | оценка агента |
Рядом лежат файлы самого агента - agent.py и instructions.md: код и инструкции в одном месте. Такой layout удобен тем, что инфраструктурные настройки не разбросаны по десяткам сервисов, а живут рядом с логикой. Как харнесс сокращал контекст и отдавал разработчикам контроль над промптами, подробнее разобрано в материале про Deep Agents v0.7 и сокращение входных токенов на 65%.
Какие ограничения остаются у Managed Deep Agents 0.8
Платформа находится в бете, и это главное ограничение релиза. Конкретный список того, что пока работает с оговорками, в материалах 0.8 не опубликован: анонс лишь фиксирует сам статус беты. Планировать продакшен стоит с запасом по срокам, с планом отката и с готовностью к изменениям в API и конфигурации.
Второй момент - природа managed-подхода. Он снимает нагрузку на инфраструктуру, но не отменяет проверку сценариев на своих данных. Агент, который уверенно отвечает на демо-запросах, может ошибаться на реальных клиентских формулировках, поэтому набор оценочных задач в директории evals/ нужен не для галочки.
Третий момент - привязка к стеку. Харнесс Deep Agents, MCP-серверы, каналы и коннекторы задают архитектуру проекта, и переезд на другое решение потребует работы. Практика внедрения ИИ-агентов в реальные процессы показывает, что провал чаще случается не на уровне модели, а на уровне контекста и организации процесса вокруг неё: об этом есть отдельный разбор про побочный продукт ИИ-агента для аналитиков.
Кому подходит Managed Deep Agents 0.8 и что делать дальше
Платформа имеет смысл для команд, которые уже выводят агентов в продукты и устали поддерживать собственные прослойки: хранилище секретов, разделение памяти, интеграции с тикетницами и мессенджерами. Особенно если требуется, чтобы агент действовал от имени конкретного сотрудника или клиента, а не от общего сервисного аккаунта.
Подождать стоит тем, кто не готов работать с бетой, зависит от сервисов, которых нет в списке поддерживаемых каналов и коннекторов, или предъявляет жёсткие требования к контролю инфраструктуры и срокам. Для таких проектов самостоятельная сборка на харнессе Deep Agents остаётся рабочим вариантом, просто она потребует своих кварталов на обвязку.
Практический порядок действий для тех, кто решил пробовать:
- Разложить примитивы агента по структуре проекта:
agent.py,instructions.md,identity.py,memory.pyи остальные директории. - Настроить скоупинг потоков и памяти в identity, чтобы персональный контекст не пересекался между пользователями.
- Описать в memory то, что агент должен помнить о человеке, и отделить это от общей базы знаний.
- Подключить HTTP-канал или Slack как точку входа и проверить, какие данные приходят в вебхуке.
- Включить веб-поиск, указав MCP-сервер в конфигурации, и убедиться, что выдача подходит вашим задачам.
- Прогнать сценарии через
evals/на своих данных и только после этого расширять права инструментов.