Intuit поручила AI-агенту координацию аварийных переключений — но не само исполнение

От автоматизации действий — к автоматизации выбора

Intuit показала EWOK Agent — внутреннего AI-помощника для аварийного переключения сервисов между регионами AWS. Он построен поверх Ecosystem Wide Orchestrator Kit (EWOK), уже существовавшей платформы disaster recovery: владельцы сервисов описывают порядок восстановления в YAML, а система управляет вычислениями, базами данных, сетью, кэшами и асинхронными нагрузками. Для поддерживаемых сценариев базовый EWOK сократил восстановление с нескольких часов примерно до 20 минут.

Однако централизованный исполнитель не устранил самый человеческий участок процедуры. Дежурному всё ещё требовалось определить подходящий workflow, проверить готовность ресурса и помнить исключения вроде аварийного обхода change-freeze. EWOK Agent переносит эту операционную логику в версионируемые skills и принимает запросы из инженерного портала или IDE, например: «failover payments-gateway in production».

Четыре слоя и жёсткая граница полномочий

Архитектура разделена на четыре уровня. Consumer layer принимает запрос через портал или интеграцию по Model Context Protocol. Agent layer обращается к foundation model через Amazon Bedrock Converse API и применяет Amazon Bedrock Guardrails при каждом вызове. Skill layer хранит типизированные YAML-схемы и инструкции, которые компилируются в tool specifications. Наконец, execution layer вызывает EWOK API и выполняет проверки готовности, policy gates, создание change record и само переключение.

Ключевой принцип авторы формулируют предельно ясно: модель решает, что делать, а EWOK Agent детерминированно исполняет, как это сделать. Модель не получает учётных данных и не обращается к EWOK напрямую. Аутентификация добавляется в executor из контекста запроса, а каждое изменение выполняет обычный тестируемый код, возвращающий структурированный результат со статусом, execution ID и change ID.

Skills вместо инструкций в голове дежурного

Вместо свободного runbook каждая возможность оформлена как skill: YAML frontmatter задаёт типизированные входы и выходы, а текстовая часть содержит пошаговые правила принятия решений. Один шаг соответствует одному вызову executor; ошибка немедленно завершает сценарий, а повторные попытки и импровизация модели запрещены. Policy gate при этом считается отдельной управляемой веткой, а не неожиданным исключением.

Так, запрос во время change-freeze сначала блокируется. Агент может запросить номер инцидента или короткое аварийное обоснование и повторить вызов ровно один раз; если инженер отказывается, failover не запускается. За счёт единого Converse API конкретная модель остаётся конфигурационной деталью: Intuit может оценивать и менять foundation models, не переписывая skills, цикл и исполнители.

Почему цикл агента намеренно маленький

Сам agentic loop сводится к ограниченной последовательности: вызвать модель, проверить stop reason, исполнить выбранный skill и вернуть структурированный результат обратно. Guardrail intervention является штатным финальным исходом, а не поводом переформулировать запрос и пытаться обойти ограничение. Жёсткий MAX_ITERATIONS заставляет систему завершиться явной ошибкой, если она не смогла прийти к действию за допустимое число шагов.

Для этого сценария команда предпочла собственный цикл более высокоуровневому harness Amazon Bedrock AgentCore: аварийное восстановление требует своих ветвлений по stop reason и circuit breaker. Это не универсальный рецепт против управляемых платформ, а демонстрация того, что в критическом контуре видимый control flow может быть важнее удобной абстракции.

Безопасность как часть исполнения

Защита построена в несколько слоёв. Guardrails проверяют потенциально опасные данные из описаний тревог, runbook и метаданных сервисов; executor отдельно сверяет аргументы с известными сервисами и регионами. Очередь на сервис сериализует и дедуплицирует запросы, cooldown и circuit breaker мешают повторным переключениям, а destructive actions и обход change-freeze требуют явного решения человека.

Каждый вызов агента, tool call и решение о failover попадает в неизменяемый audit trail вокруг change record. Роль исполнения ограничена минимальными IAM-разрешениями, API имеет rate limits, а nonce и timestamp защищают от повторного воспроизведения запроса. По данным Intuit, команды используют EWOK Agent для failover уже восемь месяцев, но публикация описывает архитектурный шаблон и иллюстративные фрагменты кода, а не готовый репозиторий или CloudFormation stack.

Практический вывод

Самая полезная часть решения — не подключение LLM к production API, а сохранение узкой границы между вероятностным выбором и детерминированным изменением состояния. Модель интерпретирует намерение, выбирает типизированную возможность и координирует шаги; проверенный executor владеет доступом, политиками, идемпотентностью и аудитом. Такой рисунок применим далеко за пределами disaster recovery — везде, где агент должен действовать, но не имеет права самостоятельно определять правила безопасности.