За последние девять месяцев Amazon, Microsoft и Google фактически пришли к одной и той же схеме, по которой должны работать корпоративные агентные платформы. Для российских команд, которые уже смотрят на AI-агентов не как на демо, а как на часть продакшена, это важный сигнал: рынок быстро стандартизует не интерфейсы, а набор обязательных слоев вокруг агента, и именно там начинает расти новая зависимость от конкретного облака.
Об этом сообщает The New Stack. По наблюдению издания, три гиперскейлера, каждый со своим брендингом и привычкой переименовывать продукты в самый неподходящий момент, в итоге собирают почти одинаковую конструкцию: runtime для запуска агента, память, шлюз к инструментам и данным, слой identity, observability и governance. У Amazon это Bedrock AgentCore, у Microsoft — Foundry, у Google — Gemini Enterprise Agent Platform. Названия разные, инженерный замысел один: превратить агентную сборку из набора SDK и сервисов в отдельный платформенный слой для enterprise.
Сама по себе эта унификация не выглядит сюрпризом. Когда компания пытается вывести агента в продакшен, ей мало выбрать модель. Нужно решить, где хранить session state и долгосрочную память, как подключать тикетные системы и внутренние API, от чьего имени агент вообще действует, где изолировать сгенерированный код и как отслеживать регрессии качества до того, как их заметят пользователи. Каждое такое решение по отдельности кажется частной настройкой. Вместе они определяют, в каком облаке живет вся система и насколько больно будет переезд через год.
Автор статьи сравнивает нынешний этап с эпохой PaaS. В 2011–2016 годах разработчики так же собирали приложения из виртуальных машин, балансировщиков, очередей, секрет-хранилищ и мониторинга, а потом Cloud Foundry и Heroku упаковали этот зоопарк в более понятный контракт вокруг приложения. Важным был не сам продукт, а то, что приложение можно было описать как единицу развертывания. Buildpacks появились в Heroku в 2011 году, затем эволюционировали в Cloud Native Buildpacks: проект запустили Pivotal и Heroku в январе 2018-го, а в октябре того же года его принял CNCF. Мысль здесь простая: сама платформа могла проиграть рынок, но удачная абстракция выживала. С агентами такой общей абстракции пока нет.
Если смотреть на детали, сходство между платформами уже трудно списать на совпадение. Amazon вывела AgentCore в общую доступность в октябре 2025 года и собрала вокруг него семь сервисов: runtime, gateway, memory, browser, code interpreter, identity и observability. Microsoft с 1 января 2026 года переименовала Azure AI Foundry в Microsoft Foundry; Foundry Agent Service закрывает тот же набор задач, включая session-isolated runtime, управляемую память и трассировку на базе OpenTelemetry. Google на Cloud Next 2026 убрала бренд Vertex AI для этой части стека и переложила агентные сервисы под вывеску Gemini Enterprise Agent Platform: там рядом оказались Deployments, Memory Bank, Sessions, Agent Registry, Policies и Gateways. Иначе говоря, три вендора независимо пришли к мысли, что агент в enterprise — это не просто prompt плюс модель, а целый контрольный контур вокруг него.
Проблема в том, что унификация архитектуры не означает переносимость. Как раз наоборот. Если память агента лежит в managed-store одного провайдера, трассы уходят в его же telemetry-сервис, а identity завязана на его каталог пользователей, то миграция превращается в пересборку всей системы. Именно здесь статья подводит к своей главной мысли: рынку не хватает контракта переносимости для agent platform, аналога того, что PaaS когда-то дала обычным приложениям. Пока есть разрозненные протоколы, но нет единого жизненного цикла артефакта. Условно говоря, инструменты уже умеют разговаривать друг с другом, но никто еще не договорился, что именно считается «пакетом агента», как его версионировать, как продвигать между средами и как откатывать после проваленной оценки.
Автор предлагает понятную рамку. У PaaS были исходники приложения, buildpack, backing services, service binding, router, логи и метрики, release promotion и platform policy. В мире агентов этому соответствуют код и инструкции агента вместе с evaluation suite, механизм упаковки под конкретный framework, модель и memory provider, подключение инструментов и данных, endpoint или MCP/A2A-интерфейс, трассы и quality scores, поэтапный rollout и слой разрешений. И почти на каждом из этих уровней переносимость пока ломается: у SDK нет общего формата пакета, провайдеры вшиваются в логику агента, креды выдаются облаком-хозяином, а оценка качества часто завязана на вендорский harness.
При этом часть строительных блоков уже существует. MCP описывает доступ агента к инструментам и данным. A2A закрывает сценарии общения между агентами. OpenTelemetry формирует конвенции для agent spans, tool calls и token usage, хотя значительная часть атрибутов там еще помечена как in development. OCI-образы остаются запасным вариантом упаковки. Даже сами вендоры, по сути, признают необходимость нейтрального слоя: в декабре 2025 года Linux Foundation объявила о запуске Agentic AI Foundation, а среди founding projects были MCP от Anthropic, goose от Block и AGENTS.md от OpenAI. В AWS, Google и Microsoft тоже зашли туда как platinum members. Но протоколы — это еще не платформа. Они не отвечают на вопросы о versioning, promotion между окружениями и экспортируемом состоянии памяти.
Для разработчиков и платформенных команд вывод довольно приземленный. Если агентные платформы становятся новым уровнем enterprise-инфраструктуры, выбирать их придется не только по модели или цене токенов. Важнее посмотреть, можно ли забрать артефакт агента без переписывания, вынести память за пределы облака и не потерять observability при переезде. Для бизнеса это уже не академический спор про open standards, а обычный вопрос переговорной позиции перед поставщиком. Чем быстрее платформы становятся похожи внешне, тем внимательнее придется смотреть на скрытые точки привязки под капотом.
Следующий большой передел, похоже, пройдет не вокруг того, кто первым прикрутил очередного «умного агента» к корпоративному порталу, а вокруг того, кто задаст базовый контракт для его упаковки, запуска и переноса. Если такой слой не появится в open source, рынок получит знакомую картину: красивые агентные платформы сверху и старый добрый vendor lock-in снизу, только теперь с памятью, правами доступа и трассами, которые тоже не хочется перевозить вручную.