Агент не живёт в промпте: как построить общий lifecycle для разных AI-runtime в Kubernetes

«Мы подключили AI-агента» - звучит просто: подняли под, вернули URL. Ровно до появления второго типа агента, первого перезапуска и первого пользователя, который хочет, чтобы агент помнил вчерашний разговор.

В демо AI-агент - это чат и tool call. В production до первого ответа нужно найти или поднять StatefulSet, подключить пользовательский диск, доставить конфиг и skills, выдать токен, дождаться настоящей готовности, а потом уметь уснуть, проснуться по cron, пережить обновление и не потерять память. Мы в MWS строим control plane для персональных AI-агентов на Kubernetes (StatefulSet, operator/CRD, PVC/CSI, Kafka, Redis): первый runtime - OpenClaw, сейчас проверяем подключение второго (Hermes) через общий манифест, а не форк control plane. Доклад - для тех, кто выводит AI-агентов из демо в сервис на многих пользователях, и для тех, кто проектирует агентные платформы.

Покажем реальный lifecycle create → ready → provision → sleep → wake → sync → backup → delete и то, как AI-система превращается в highload-задачу: burst создания подов, CSI и scheduler в critical path, at-least-once команды, гонки реплик, владение памятью. С цифрами: cold start сейчас ~37 s (p50), первый warm-slot замер ~6 s; расскажем, что это даёт и чего не решает. Слушатель унесёт ownership matrix, lifecycle state machine и критерий, что выносить в общий контракт, а что оставлять runtime-specific - применимо и без OpenClaw.