SLA для агентных сервисов: почему аптайм больше ничего не решает

В 2024–2025 годах провайдеры вроде OpenAI, Anthropic и облачные платформы начали продавать не просто обработку запросов моделью по API, а агентные сервисы: продукты, которые сами планируют шаги, вызывают инструменты и выполняют многоходовые задачи. И тут выяснилось, что привычный SaaS-контракт под них не заточен. Обещание «99,9% доступности» покрывает то, что сервер ответит. Оно не покрывает то, что агент¹ сделает нужное, а не удалит не ту строку в базе.

Разница не косметическая. Обычный SLA меряет один вопрос: работает сервис или лежит. Агентный сервис добавляет второй вопрос, на который старые метрики не отвечают: а результат-то верный? Между этими двумя вопросами — вся цена перехода на автономных агентов в проде.

Что обещает классический SaaS SLA

Стандартный SLA облачного сервиса строится вокруг нескольких измеримых величин:

• Доступность (uptime) — процент времени, когда сервис принимает запросы. Типичные значения: 99,9% (около 43 минут простоя в месяц) или 99,95%.
• Латентность — время ответа, часто как перцентиль: p95, p99.
• Компенсация — сервис-кредиты (проценты от счёта), если провайдер не дотянул до обещанного.

Всё это про инфраструктуру. Сервис либо отвечает вовремя, либо нет — факт бинарный и легко измеряемый логами. Провайдеру удобно: он контролирует свои серверы и отвечает ровно за них.

Почему агентам этого мало

Агентный сервис отвечает быстро и стабильно — и при этом может провалить задачу. Модель доступна на 99,95%, но в 8% случаев неправильно интерпретировала запрос, вызвала не тот инструмент или зациклилась. Uptime зелёный, бизнес-результат красный.

Для обычного API вопрос «работает ли сервис» и «выполнил ли он мою задачу» — это один и тот же вопрос. Для агента это два разных вопроса, и второй провайдеры пока почти не берут в контракт.

Появляются метрики, которых в SaaS-договорах раньше не было:

• Task success rate — доля задач, доведённых до корректного результата. Меряется не логами сервера, а проверкой самого результата, что уже сложнее и субъективнее.
• Стоимость на задачу — агент может «думать» больше или меньше шагов. Один и тот же запрос иногда стоит центы, иногда — доллары, если модель ушла в длинную цепочку рассуждений и расширила контекстное окно².
• Обратимость действий — что делает сервис, если агент совершил вредное действие: есть ли откат, подтверждение перед необратимыми операциями, журнал шагов.
• Полная латентность задачи, а не одного вызова: агент из десяти шагов ждёт десять ответов подряд, и суммарное время предсказать труднее.

Чем агентный SLA отличается от обычного

Ключевой разрыв — в последней строке. Провайдеры готовы платить кредиты за простой, потому что простой они могут измерить и он их вина. За «агент выполнил задачу неправильно» почти никто в контракте не отвечает: слишком трудно отделить ошибку модели от кривого запроса пользователя или плохо описанного инструмента.

Что уже есть на рынке

На практике SLA на уровень доступности API у крупных провайдеров существуют — обычно на корпоративных и enterprise-тарифах, не на базовых. Но эти SLA по-прежнему про доступность и латентность API, а не про качество агентного результата. Гарантий на task success rate публично почти никто не даёт: слишком много переменных вне контроля провайдера.

Актуальные условия, тарифы и наличие SLA у конкретного провайдера меняются часто — их стоит смотреть на официальной странице сервиса и в тексте enterprise-соглашения, а не полагаться на цифры из обзоров.

Кому это пригодится, а кому нет

Стоит закладывать агентный SLA в требования, если:

• Агент выполняет необратимые действия — платежи, рассылки, изменения в проде. Здесь обратимость и подтверждения важнее аптайма.
• У вас регулируемая отрасль и нужен полный аудит: журнал каждого шага, кто и что решил.
• Стоимость задачи критична для юнит-экономики — тогда нужна оговорка о потолке расходов на задачу, а не только цена за токен.

Хватит обычного SaaS-подхода, если:

• Агент работает как ассистент-черновик, а человек проверяет каждый результат перед применением. Тогда цена ошибки низкая, и task success rate можно не гарантировать контрактом.
• Вы делаете прототип или внутренний инструмент, где простой на час не стоит денег.
• Задачи однотипные и короткие — тогда разброс стоимости и цепочек невелик.

Что спросить у провайдера перед подключением

1. Есть ли SLA на доступность API и на каком тарифе он начинает действовать.
2. Как считается компенсация и за что именно — только за простой или за что-то ещё.
3. Есть ли лимиты и потолок расходов на одну задачу, чтобы агент не ушёл в дорогую цепочку.
4. Ведётся ли полный журнал шагов агента и как долго он хранится.
5. Есть ли режим подтверждения перед необратимыми действиями.
6. Что происходит при сбое посреди задачи — откат, повтор, частичное выполнение.

Пока рынок агентных сервисов молодой, договор придётся дочитывать до конца самому. Строчка «99,9% uptime» выглядит солидно, но отвечает не на тот вопрос, который вас разорит.

¹ Агент — программа на базе языковой модели, которая не просто отвечает на запрос, а сама планирует последовательность шагов и вызывает внешние инструменты (поиск, код, API), чтобы выполнить задачу.

² Контекстное окно — объём текста (в токенах), который модель удерживает одновременно. Чем длиннее цепочка рассуждений агента, тем больше окно и тем дороже обходится задача.