20 июля 2026 года AWS выпустила платформу Loom AWS — open-source референсную платформу для развёртывания и контроля AI-агентов в корпоративной среде. История не про «ещё один фреймворк», а про более приземлённую боль: как не превратить десятки агентов в серый зоопарк с чужими правами доступа, неучтёнными интеграциями и непонятной ответственностью. Для русскоязычных команд это важный сигнал: большие облака уже спорят не о том, нужны ли агентные системы, а о том, как их держать в рамках безопасности и эксплуатации.
Как пишет InfoQ, Loom опубликована в AWS Labs и сразу подаётся без маркетинговой маскировки: это не managed service, а «показательный» образец того, как компания может собрать собственную платформу для AI-агентов на AWS. Внутри — агенты на Strands Agents SDK, исполнение на Amazon Bedrock AgentCore Runtime, единый интерфейс управления, backend API, интеграция с identity provider, авторизация по scope и жизненный цикл для самих агентов, памяти, MCP-серверов и agent-to-agent-интеграций. Иначе говоря, AWS продаёт не готовый волшебный комбайн, а схему сборки с уже проставленными ограничителями.
Ключевая идея Loom — вынести управление агентами из уровня «каждая команда пишет как умеет» в платформенный слой. Проект вырос из прототипа, который в июне описал на Medium Хики Парк, principal solutions architect в AWS. Тогда он разбирал семь задач, которые всплывают почти у любой платформенной команды при масштабировании агентных систем: обязательное тегирование ресурсов, role-based и attribute-based access control, шаблоны развёртывания, проверка ПО перед релизом, передача идентичности через цепочку делегирования, борьба с расползанием числа агентов и обязательное участие человека перед чувствительными действиями. Набор выглядит не слишком романтично, зато до боли знакомо всем, кто хоть раз пытался превратить пилот в корпоративный сервис.
Самая интересная часть — передача идентичности по цепочке вызовов. Когда агент действует от имени пользователя, затем обращается к MCP-серверу, а тот идёт дальше в REST API, на каждом шаге нужно не просто «какой-то токен», а токен, который сохраняет исходного пользователя и его права. В Loom для пользовательских сценариев используется полный authorization code flow, а для передачи полномочий дальше — обмен токенами по RFC 8693, который поддерживает AgentCore Identity. В результате вниз по цепочке уходит не обезличенный сервисный доступ, а связка из пользователя и агента с сохранением контекста делегирования. AWS отдельно визуализирует каждый переход — от агента к MCP-серверу и дальше к Amazon API Gateway — где на каждом уровне формируется собственный on-behalf-of token. Практический смысл тут простой: downstream-системы должны видеть только те данные, которые реально доступны исходному сотруднику, а не всё, что «случайно смог» промежуточный сервис.
Не менее показателен и способ развёртывания. Платформа Loom AWS принципиально не делает runtime code generation. Вместо этого она берёт заранее написанного Python-агента на Strands Agents и подставляет на этапе деплоя поведенческие инструкции, memory resources, конфигурации MCP или A2A. Код между развёртываниями не меняется, меняется только конфиг. Для enterprise-среды это куда важнее, чем кажется на первом чтении: платформенная команда может один раз прогнать код через проверки, добавить корпоративные требования вроде логирования, аудита или ограничений по вызовам и затем многократно переиспользовать тот же артефакт. Если кастомизация не нужна, AWS предлагает идти в no-code-сценарий через managed harness в AgentCore. Секреты и учётные данные Loom у себя не хранит вообще: они лежат в AWS Secrets Manager и подтягиваются по необходимости, а входящая и исходящая аутентификация отдаётся AgentCore Identity.
Контроль вместо магии
Управление в Loom строится на двух механиках, которые в корпоративной разработке часто обсуждают меньше, чем модели и prompt engineering, хотя именно они потом определяют стоимость владения. Первая — обязательные теги. Для каждого развёрнутого ресурса Loom требует как минимум три: loom:application, loom:group и loom:owner. Можно добавлять и свои, например cost center. На бумаге это выглядит скучно, но любой FinOps- или security-команде не нужно объяснять, зачем потом искать безымянный агент, который месяцами ел бюджет и ходил в прод под сервисной учёткой «на время теста».
Вторая механика — разделение доступа по двум измерениям. Тип роли определяет, что пользователь вообще может делать и какой интерфейс видит, а групповые теги — какие ресурсы ему доступны. Администратор попадает на каталог и панель управления, обычный пользователь — фактически в чат, где видит только агентов своей группы и собственную историю взаимодействий. Для discovery Loom интегрируется с AWS Agent Registry, который сейчас находится в public preview, и работает с A2A agent card specification и схемой MCP tools. Перед публикацией в production агент должен пройти review. У этой части уже заметны шероховатости: в более раннем описании интеграции Парк указывал, что ARN реестра содержит лишь случайную буквенно-цифровую строку, а не имя registry, поэтому для некоторых IAM-политик приходится использовать wildcard по ресурсу. Для демо это терпимо, для строгих enterprise-политик — не лучший подарок.
Human-in-the-loop в Loom тоже сделан не для галочки. AWS описывает три варианта ручного подтверждения чувствительных действий — через hook framework в Strands Agents и нативные MCP elicitations. То есть опасный вызов можно поставить на паузу до одобрения человеком, а не надеяться, что агент «сам поймёт», когда ему не стоит трогать интеграцию с внутренним API, CRM или финансовой системой. На фоне разговоров о fully autonomous agents это выглядит почти старомодно, но для бизнеса старомодность здесь ближе к слову «вменяемость».
Что это меняет для рынка
Реакция сообщества пока осторожная. InfoQ приводит обсуждение на Reddit: спустя два дня после появления Loom никто в треде не поделился реальным production-опытом. Самая содержательная реплика свелась к тому, что решение выглядит продуманным и «правильно директивным», но при желании похожую платформу можно собрать и самостоятельно примерно за неделю. В этом, пожалуй, и проходит главная граница продукта. Loom бесплатна как open-source проект, но платить всё равно придётся за лежащие под ней managed-сервисы AWS. То есть вопрос не в цене лицензии, а в том, готовы ли вы принять архитектурные допущения AWS ради ускорения сборки собственной платформы.
Для рынка это ещё один признак того, что слой управления AI-агентами быстро оформляется в отдельную категорию. Недавно в том же контексте обсуждали Claude apps gateway от Anthropic как контрольную плоскость для AI-инструментов разработки. Loom заходит с другой стороны: не как поддерживаемый конечный продукт, а как платформенный шаблон для greenfield-сценариев с упором на identity, deployment governance, registry и approval workflows. Для разработчиков и платформенных команд здесь полезно даже не само решение целиком, а набор инженерных приоритетов AWS. Компания явно говорит: сначала идентичность, права, теги, секреты и review, а уже потом красивые демо про автономных помощников.
Главный вопрос теперь не в том, будут ли компании запускать агентные платформы внутри. Они уже запускают. Вопрос в другом: станет ли платформа Loom AWS удобным чертежом для enterprise-команд или останется добротным reference implementation, который все уважительно читают, но в прод уносят только отдельные идеи. Проверить исходную заметку можно в : как минимум ради того, чтобы посмотреть, в какую сторону AWS сама предлагает строить контроль над AI-агентами, пока рынок ещё не успел превратить это в набор несовместимых полуфабрикатов.