Архитектура AI-систем постепенно смещается от модели stateless request → response к системам, где состояние, память и контекст становятся самостоятельными архитектурными сущностями.
Это не означает, что microservices или stateless API исчезают. Скорее происходит другое: поверх существующей инфраструктуры появляется новый слой — agentic runtime, которому нужны persistent memory, orchestration, identity, sandboxing и управление жизненным циклом состояния.
За последние месяцы сразу несколько крупных инженерных команд независимо друг от друга начали решать похожие задачи. LinkedIn развивает Cognitive Memory Agent, Cloudflare — Agent Memory, Google — инфраструктуру для агентных приложений, а Kubernetes-ориентированные проекты исследуют специализированные runtime-механизмы для stateful agent workloads.
По отдельности это разные продукты. Вместе они начинают складываться в один архитектурный паттерн.
От stateless services к stateful agents
Классическая распределённая система хорошо работает, когда запрос относительно независим от предыдущего:
request → service → response
Состояние хранится отдельно — в базе данных, кеше или внешнем хранилище, а сам сервис старается оставаться stateless. Для обычных web-приложений это чрезвычайно эффективная модель. Она упрощает горизонтальное масштабирование, deployment и отказоустойчивость. Но агентная система работает иначе. Агент может:
- выполнять задачу в течение длительного времени;
- обращаться к нескольким инструментам;
- взаимодействовать с другими агентами;
- сохранять результаты предыдущих действий;
- продолжать работу после паузы;
- действовать от имени конкретного пользователя;
- использовать контекст из нескольких предыдущих взаимодействий.
Поэтому одного context window уже недостаточно. Возникает новая архитектурная проблема:
как управлять состоянием агента, а не просто передавать ему очередной prompt?
Именно здесь появляется memory-centric architecture.
Память становится отдельным архитектурным слоем
В современных agentic systems память постепенно перестаёт быть просто технической деталью реализации. Она начинает выполнять роль самостоятельного домена:
- хранить долговременный контекст;
- извлекать релевантную информацию;
- разделять episodic, semantic и procedural memory;
- управлять актуальностью данных;
- определять, что нужно сохранить, а что забыть;
- контролировать доступ к памяти.
Cloudflare, например, рассматривает persistent memory как отдельный компонент для агентов, а LinkedIn развивает собственную memory infrastructure для stateful и context-aware AI applications. Это важный сдвиг в архитектурном мышлении. Раньше мы говорили:
Cache → ускоряет доступ к данным.
Теперь всё чаще приходится говорить:
Memory → управляет состоянием и контекстом агента.
Это не одно и то же. Кеш можно удалить и восстановить из источника истины. Потеря же определённого состояния агента может изменить его дальнейшее поведение. Поэтому memory требует собственных политик жизненного цикла, качества, актуальности и безопасности.
Новый архитектурный стек
Если объединить наблюдаемые сегодня решения, начинает проявляться следующая структура:
Это важное отличие от классической microservice architecture. Вместо того чтобы рассматривать агента как ещё один сервис, система начинает выделять вокруг него специальные механизмы для memory, orchestration и controlled execution.
Почему одного context window недостаточно
Увеличение context window решает только часть проблемы. Чем больше информации попадает в контекст, тем сложнее становится определить:
- какая информация действительно важна;
- что является актуальным;
- что устарело;
- какие факты относятся к текущей задаче;
- какие данные принадлежат конкретному пользователю;
- какие предыдущие действия должны влиять на текущее решение.
Иными словами, проблема постепенно превращается из:
«Как дать модели больше контекста?»
в:
«Как управлять контекстом?»
Это принципиально разные задачи. Именно поэтому появляются отдельные memory layers, retrieval mechanisms и context-management systems.
От orchestration к agent runtime
Вторая часть изменений касается orchestration. В классической архитектуре orchestration часто ограничивается управлением workflow:
event → service A → service B → service C
У agentic systems цепочка становится динамической. Агент может самостоятельно решить:
- какой tool вызвать;
- какой сервис использовать;
- передать задачу другому агенту;
- повторить операцию;
- запросить дополнительный контекст;
- остановить выполнение.
Поэтому появляется новый слой:
Здесь orchestration уже отвечает не только за порядок выполнения. Он становится ответственным за routing, coordination, validation, identity и lifecycle. Именно это отличает простой workflow engine от полноценного agent runtime.
Identity становится частью архитектуры
У обычного backend-сервиса есть относительно понятная модель:
User → API → Service
У multi-agent system цепочка может выглядеть иначе:
User → Agent A → Agent B → Tool → External Service
И здесь возникает принципиальный вопрос:
От чьего имени выполняется действие?
Если Agent A вызывает Agent B, должен ли Agent B получить все права Agent A? Очевидно, нет. Поэтому для agentic systems становятся особенно важны:
- identity propagation;
- scoped permissions;
- short-lived credentials;
- delegation;
- auditability;
- isolation между агентами.
Без этого многоагентная архитектура быстро превращается в систему, где трудно определить, кто именно выполнил действие и почему у него были соответствующие права. Таким образом, identity перестаёт быть исключительно authentication-проблемой. Она становится частью orchestration layer.
Sandbox становится базовой инфраструктурой
Есть ещё одна особенность агентов: они не только читают данные. Они могут выполнять действия. А значит, появляется новый уровень риска. Agent может:
- запускать код;
- работать с файлами;
- обращаться к API;
- устанавливать зависимости;
- изменять данные;
- выполнять команды.
Поэтому sandboxing постепенно превращается из дополнительной функции в базовый механизм agent infrastructure. Архитектура начинает выглядеть так:
Это особенно важно для автономных и long-running agents. Чем больше полномочий получает агент, тем важнее становится изоляция среды выполнения.
Kubernetes: не замена контейнеров, а новый слой поверх них
Здесь особенно важно не делать слишком сильный вывод. Kubernetes не превращается в «runtime для агентов вместо runtime для контейнеров». Скорее поверх Kubernetes появляются специализированные механизмы для stateful и agentic workloads. Получается примерно такая модель:
Это важное архитектурное развитие. Kubernetes продолжает решать инфраструктурные задачи, но поверх него появляется специализация под новые типы workload’ов.
Stateless API никуда не исчезает
Одна из самых опасных ошибок при анализе этого тренда — объявить конец stateless architecture. Этого не происходит. Stateless API по-прежнему отлично подходит для:
- CRUD;
- transactional systems;
- web services;
- ingestion;
- integrations;
- deterministic workloads;
- большинства обычных microservices.
Изменяется не фундамент всей distributed architecture, а её верхний слой. В результате возникает гибридная модель:
И это выглядит значительно реалистичнее, чем идея о полном переходе от stateless к stateful системам.
Что объединяет эти изменения?
Если посмотреть на все сигналы вместе, можно выделить пять взаимосвязанных архитектурных направлений:
1. Memory
Система должна помнить и управлять состоянием.
2. Orchestration
Система должна координировать динамические действия агентов.
3. Identity
Каждое действие должно иметь понятный security context.
4. Execution
Агенту нужна контролируемая среда выполнения.
5. Observability
Нужно наблюдать не только запросы, но и изменение состояния системы.
Получается новый цикл:
Это уже не просто request/response pipeline.
Это state evolution loop.
Почему меняется observability
В традиционной системе мы в первую очередь измеряем:
- latency;
- throughput;
- error rate;
- CPU;
- memory;
- request volume.
Для agentic systems этого становится недостаточно. Нужно понимать ещё и:
- как изменилось состояние агента;
- какой контекст был использован;
- какие tools были вызваны;
- сколько шагов потребовалось;
- какие решения были приняты;
- какие данные попали в memory;
- какие permissions использовались;
- почему агент повторил действие.
Поэтому observability постепенно смещается:
request observability → workflow observability → state observability.
Это один из наиболее важных, но пока недооценённых архитектурных сдвигов.
Что будет происходить дальше
На горизонте 6–12 месяцев наиболее вероятны не революционная замена существующей архитектуры, а постепенная специализация.
Высокая вероятность
Memory и context management станут стандартными компонентами production agent systems.
Высокая вероятность
Orchestration будет всё чаще выделяться как самостоятельный архитектурный слой.
Высокая вероятность
Sandboxing и scoped identity станут обязательными для production-grade autonomous agents.
Средняя вероятность
Kubernetes и другие infrastructure platforms будут получать всё больше agent-specific abstractions.
Средняя вероятность
Появится больше стандартов для передачи context, identity и capabilities между агентами.
Низкая, но интересная гипотеза
Stateful agent sessions начнут вытеснять часть традиционных request-driven workflows там, где требуется длительное взаимодействие и сохранение контекста.
При этом stateless services продолжат существовать как фундаментальный слой.
Что архитекторам стоит делать уже сейчас
Главный вывод не в том, что нужно срочно переписать существующие microservices. Наоборот. Лучше разделить архитектурные ответственности.
1. Выделить memory как отдельный домен
Не смешивать persistent agent state с обычным cache. Определить:
- lifecycle;
- retention;
- freshness;
- validation;
- ownership;
- access control.
2. Отделить orchestration от capabilities
Агент должен координировать действия, но бизнес-сервисы не должны превращаться в набор agent-specific решений. Архитектурное разделение остаётся важным:
Orchestration → Capabilities
3. Проектировать identity заранее
Не откладывать authorization до момента, когда в системе появится второй агент. Для multi-agent systems identity и delegation должны быть частью дизайна с самого начала.
4. Использовать sandboxing по умолчанию
Чем больше возможностей получает агент, тем меньше должна быть зона его потенциального воздействия.
5. Пересмотреть observability
Метрики должны описывать не только запросы. Они должны позволять ответить на вопрос:
Как изменилась система в результате действий агента?
Главный вывод
Мы не наблюдаем смерть microservices или stateless architecture. Мы наблюдаем появление нового архитектурного слоя поверх них. AI-агенты создают workload, в котором недостаточно просто обработать запрос и вернуть ответ. Система должна:
помнить → планировать → координировать → действовать → сохранять состояние → продолжать работу.
Именно поэтому memory, orchestration, identity, sandboxing и state observability начинают объединяться в новую архитектурную модель.
Условно её можно представить так:
Поэтому следующий этап развития distributed systems, вероятно, будет определяться не отказом от stateless architecture, а сочетанием stateless infrastructure с управляемым stateful agent layer.
Именно здесь сегодня формируется один из наиболее интересных архитектурных фронтов: не просто как запустить AI-модель, а как построить вокруг неё надёжную, наблюдаемую, безопасную и масштабируемую систему.