AI Gateway поднимается на уровень выше: от маршрутизации моделей к маршрутизации agent-сессий

Раньше ключевое решение в вашем AI gateway было простым: какую модель вызвать, через какого provider, с какой политикой fallback. Теперь это решение усложняется. Инженерные команды развёртывают agent-ы на нескольких runtime-платформах — Claude Managed Agents, Bedrock AgentCore, Vertex Agents и собственной инфраструктуре — и обнаруживают, что ни одна платформа не покрывает все рабочие нагрузки.

Команда LiteLLM Engineering опубликовала на прошлой неделе архитектурный анализ, в котором явно сформулировала это следствие: AI gateway поднимается на уровень выше. Примитив маршрутизации — уже не вызов модели, а agent-сессия.

Что говорит пост об архитектуре LiteLLM

Ключевое наблюдение: компании не будут консолидироваться на одном agent runtime. Coding agent-ы работают на Bedrock AgentCore или Claude Managed Agents. Data agent-ы — внутри Databricks или Snowflake. Внутренние workflow agent-ы — на кастомной инфраструктуре. Когда agent runtime-ы фрагментируются, командам нужен слой, способный регистрировать, вызывать, наблюдать и управлять agent-ами независимо от того, где они были построены.

LiteLLM отображает это напрямую на привычный стек моделей:

• Модели → Agent harness-ы. Вызываемый примитив меняется с модели на harness (Claude Code, Codex, DeepAgents).
• Inference providers → Agent runtime-ы. Вы маршрутизируете работу agent-а в Claude Managed Agents, Bedrock AgentCore, Vertex Agents или self-hosted среду.
• Model gateway → Agent control plane. Gateway должен управлять agent-сессиями, расписаниями, памятью и мульти-runtime вызовами — не только перенаправлять API-запросы.
• Открытые ниши. Надёжного слоя высокоскоростного обслуживания harness-ов пока нет; доминирующего agent control plane — тоже.

Три роутинговых следствия для инженерных команд

1. Состояние сессии становится первоклассным объектом маршрутизации. Вызовы моделей безсостоянийны: отправить запрос, получить токены. Agent-сессии имеют состояние: контексты инструментов, память, промежуточные результаты и делегирование sub-agent-ам. Ваш routing-слой должен понимать, нужно ли возобновить существующую сессию или создать новую — и на каком runtime. Fallback с одного runtime на другой — уже не простая замена заголовка; это может потребовать миграции сессии или холодного старта.

2. Атрибуция затрат должна отслеживать работу на уровне сессии, а не только расход токенов. Когда один пользовательский запрос разветвляется на coding harness, вызов извлечения памяти и три вызова инструментов, billing-атрибуция не может ограничиться подсчётом input/output токенов. Командам нужен учёт на уровне сессии, агрегирующий стоимость моделей, вычислений, памяти и вызовов инструментов по всем runtime-ам.

3. Риск зависимости от provider умножается. Политики fallback на уровне моделей (переключить Claude Fable 5 на Kimi K2.7 Code при таймауте) уже хорошо проработаны. Fallback на уровне agent-а — нет: если Claude Managed Agents деградирует, сможет ли ваша команда перенаправить ту же agent-сессию на Bedrock AgentCore? Ответ зависит от совместимости API и переносимости сессий — ни то, ни другое пока не стандартизировано.

Угол router/operator

LiteLLM определяет gateway как естественный объединяющий слой, поскольку он уже управляет учётными данными моделей, rate limit-ами, fallback-ами и отслеживанием расходов. Расширение на agent-сессии — это наращивание возможностей, а не смена продукта.

Практические вопросы для routing-команд:

• С какими runtime-ами ваш gateway должен уметь работать? Claude Managed Agents (api.anthropic.com/v1/agents/), Bedrock AgentCore (AWS SigV4), Vertex Agents (GCP Auth) и self-hosted harness-ы — у каждого свой интерфейс вызова. Ваш gateway должен поддерживать их все или использовать слои-адаптеры.
• Где хранится состояние сессии? Если gateway — это control plane, он должен либо владеть хранилищем сессий, либо чисто проксировать ссылки на сессии в каждый runtime. Утечка session ID между runtime-ами — это нарушение границы данных.
• Каков ваш SLA на уровне agent-а? У большинства команд сегодня есть SLA на уровне модели (задержка p99, бюджет fallback). SLA на уровне agent-а требует договорённости о том, что значит «сбой» для долговременной сессии — таймаут, частота ошибок или потолок затрат — и сопоставления каждого варианта с действием на уровне runtime.

Что стоит наблюдать и попробовать пользователям TheRouter

Переход от маршрутизации моделей к маршрутизации agent-сессий не требует немедленного переосмысления вашего gateway. Но он требует обновления архитектурного плана:

1. Проведите аудит используемых agent runtime-ов — даже неформально. Команды нередко обнаруживают, что одновременно работают на Claude Managed Agents через enterprise-подписку Claude Code и на Bedrock AgentCore через AWS-стек.
2. Добавьте теги уровня сессии в текущую наблюдаемость. Даже если ваш gateway сегодня маршрутизирует только вызовы моделей, проставление меток с agent session ID и типом harness подготовит ваш logging-пайплайн к переходу на control plane.
3. Следите за Anthropic и AWS. Claude Managed Agents и Bedrock AgentCore — наиболее вероятные стартовые точки для мульти-runtime agent-работы у большинства инженерных команд. Любые изменения их API вызова — сигнал для пересмотра политики маршрутизации.

Для команд, уже использующих TheRouter для маршрутизации provider-ов и fallback, естественным развитием будет оценка: должны ли ваши правила маршрутизации учитывать тип harness, а не только model ID. Запрос, помеченный как Claude Code-сессия, может требовать совершенно других политик таймаута, повтора и потолка затрат по сравнению с одиночным inference-вызовом.

Архитектурный сдвиг, который описывает LiteLLM, пока носит направленный, а не операционный характер. Но команды, которые уже сейчас обновят свои абстракции маршрутизации — разделив политику модели и политику сессии, — избегут дорогостоящего рефакторинга, когда agent control plane станет стандартной инфраструктурой.