AWS, Microsoft, Google и Anthropic за последние месяцы почти синхронно пришли к одной архитектурной идее: ИИ-сессии становятся новой единицей вычислений для агентных систем. Для разработчиков и платформенных команд это не академический спор о терминах, а вполне приземлённый вопрос о том, где теперь проходит граница между процессом, контейнером и рабочим контекстом агента.
Об этом сообщает The New Stack: крупнейшие игроки рынка ИИ-инфраструктуры фактически пересобирают один и тот же слой runtime для агентов, но расходятся в главном, как именно изолировать такую сессию. Иначе говоря, консенсус по поводу формы нагрузки уже появился, а консенсуса по поводу её безопасного исполнения пока нет.
Суть сдвига довольно проста. Классическое облако долго жило в логике виртуальных машин, потом контейнеров, потом бессерверных функций. У каждой модели был свой базовый объект управления: VM, pod, invocation. Агентные системы ломают эту схему, потому что полезная работа здесь редко укладывается в один короткий вызов. У агента есть память в рамках диалога, цепочка инструментов, обращения к внешним API, промежуточные решения, иногда несколько параллельных веток исполнения. Всё это логичнее упаковывать не в отдельный запрос, а в сессию, которая живёт дольше одной функции и богаче одного промпта.
На этом месте начинается самое интересное. Если сессия становится базовой единицей работы, её нужно не просто хранить, а исполнять, ограничивать и защищать. У такой сессии есть состояние, доступ к инструментам и, в ряде случаев, полномочия действовать от имени пользователя или сервиса. Это уже не просто контекст для LLM, а почти маленькая операционная среда с собственными правами, временем жизни и поверхностью атаки. Поэтому спор между AWS, Microsoft и Google идёт не о красивой терминологии, а о том, какой именно runtime нужен агенту и насколько жёсткой должна быть изоляция между такими средами.
То, что в этом разговоре рядом с гиперскейлерами фигурирует Anthropic, тоже показательно. Рынок больше не делится на «облачников» и «модельные компании» так аккуратно, как ещё год назад. Разработчик хочет не абстрактную модель и не абстрактную инфраструктуру по отдельности, а рабочую среду, где агент может рассуждать, вызывать инструменты, хранить контекст и не проливать чужие данные между сессиями. На практике это означает, что слой orchestration, слой безопасности и слой исполнения всё плотнее срастаются в один продуктовый пакет.
Для инженерных команд здесь сразу несколько последствий. Во-первых, меняется способ проектирования приложений. Если раньше архитектура вокруг LLM часто строилась как набор stateless-вызовов плюс внешняя база для памяти, то теперь в игру входит runtime, который сам понимает длительную работу агента как первичную сущность. Во-вторых, по-новому встаёт вопрос наблюдаемости. Отлаживать придётся уже не только отдельный запрос к модели, но и всю траекторию ИИ-сессии: какие инструменты вызывались, где агент получил доступ к данным, на каком шаге изменил состояние и почему ушёл в лишний цикл.
Для бизнеса это ещё чувствительнее, чем для разработчиков. Как только агент начинает жить в сессии, а не в одноразовом вызове, резко возрастает цена ошибки в изоляции. Если такой runtime неправильно отделяет один контекст от другого, проблема выходит далеко за рамки «модель ответила странно». Речь уже о разграничении корпоративных данных, политик доступа, журналирования действий и соответствии внутренним требованиям безопасности. Проще говоря, CFO может не знать, что такое session-aware runtime, но точно поймёт риск, если агент одной команды внезапно получит хвосты контекста другой.
Отсюда и расхождение подходов у крупных игроков. Все согласны, что агенту нужен более долгоживущий и более богатый вычислительный контур. Но дальше начинаются разные инженерные философии: насколько такую среду надо приближать к контейнеру, насколько к песочнице, насколько к управляемому сервисному процессу. Это принципиально, потому что от модели изоляции зависит всё остальное: холодный старт, стоимость, плотность размещения, доступ к файловой системе и сети, удобство локальной разработки, а главное, предсказуемость поведения под нагрузкой и при сбоях.
Для русскоязычной IT-аудитории в этой истории важен не сам факт очередного спора между big tech-компаниями, а сигнал о смене базовой абстракции. Если раньше команды спорили, где держать промпты и как прикрутить retrieval, то теперь фокус смещается к тому, где живут ИИ-сессии и кто контролирует их жизненный цикл. Это особенно важно для продуктовых команд, которые строят внутренних агентов, copilot-сценарии, автоматизацию поддержки или аналитических ассистентов. Во всех этих кейсах состояние, инструменты и права доступа уже важнее самого красивого демо с моделью.
Есть и ещё один неприятный, но полезный вывод. Рынок агентов постепенно уходит от иллюзии, что всё можно решить на уровне фреймворка. Фреймворк помогает собрать workflow, но не заменяет среду исполнения. Как только агент получает долговременный контекст и возможность действовать, вопрос runtime становится инфраструктурным, а не библиотечным. И это означает, что следующая волна конкуренции в AI stack пойдёт не только между моделями, но и между платформами, которые предложат более надёжный, дешёвый и безопасный способ обслуживать ИИ-сессии.
Главный вопрос теперь не в том, станет ли сессия новой единицей вычислений для агентных систем: крупнейшие компании уже ведут себя так, будто ответ получен. Вопрос в другом: какая из моделей изоляции окажется достаточно строгой для enterprise и достаточно дешёвой для массового запуска агентов, не превратив каждый полезный workflow в слишком дорогой эксперимент.