AWS предложила новый паттерн для авиационного перебронирования: AI-агенты подбирают пассажиру новые рейсы, но детерминированная валидация решает, можно ли реально менять билет или платить компенсацию. Для разработчиков это полезный сигнал: агентам дают рассуждать, но не подпускают их напрямую к деньгам, бронированиям и другим дорогим кнопкам, сообщает The New Stack.
Паттерн опубликован 14 сентября в AWS Compute Blog. Авторы, Бен Фрайберг и Нитин Чандран Раджашанкар, описывают сценарий отмены рейса, когда авиакомпании нужно быстро обработать сотни пассажиров: учесть стыковки, тарифные правила, доступные места, статус в программе лояльности, предпочтения по салону и возможные компенсации. Ручная очередь в такой ситуации быстро превращается в операционный пожар. AWS предлагает вынести рутину в workflow на Step Functions, а рассуждения поручить специализированным агентам Amazon Bedrock AgentCore.
Ключевая идея проста и, что приятно, не пытается продать магию: агент предлагает, код проверяет. В примере workflow стартует от события отмены рейса, например через Amazon EventBridge. Затем детерминированный шаг подтягивает данные о пассажирах, бронированиях, лояльности и предпочтениях. После этого Step Functions запускает параллельную обработку пассажиров через Distributed Map. В демонстрации AWS ограничивает параллелизм параметром MaxConcurrency на уровне 1000, чтобы не положить downstream-системы бронирования и инвентаря. Если ограничение убрать или поставить 0, Distributed Map по умолчанию может запускать до 10 000 параллельных дочерних выполнений.
Для каждого пассажира работают два агентных шага. Первый агент ищет до трех альтернативных маршрутов. Второй готовит персонализированный текст уведомления или компенсационного сообщения. Но ни один из них не пишет в систему бронирования и не инициирует платеж. После предложения маршрута Lambda-проверка смотрит, существует ли рейс, есть ли места, разрешают ли тарифные правила такой обмен и валиден ли маршрут. После текста о компенсации отдельный детерминированный расчет сверяет право на выплату с таблицами правил. AWS приводит EU261 и правила возвратов Минтранса США как иллюстрацию, но подчеркивает: конкретные суммы, триггеры и диапазоны должны быть конфигурацией компании, а не догадкой модели.
Это важное отличие от классической multi-agent collaboration, где supervisor-agent сам решает, какого подагента вызвать, в каком порядке и с какими инструментами. AWS переносит оркестрацию, fan-out, retry, routing, validation и audit trail из слоя модели в Step Functions. Для инженера это менее эффектно на демо, зато куда ближе к продакшену: маршрутизацию можно тестировать отдельно, переходы состояний попадают в историю выполнения, а спорные кейсы уходят человеку, а не в еще один виток рассуждений модели.
Human-in-the-loop в паттерне тоже сделан без попытки держать агента в подвешенном состоянии. Если кейс нельзя подтвердить автоматически, Step Functions ставит отдельный callback-шаг с waitForTaskToken, например через Lambda, SNS или SQS. В примере указан таймаут 4 часа. Пока workflow ждет решения оператора, он не жжет compute. Это звучит буднично, но для авиакомпании, банка или страховой именно такие детали решают, будет ли архитектура жить после первого инцидента.
Еще одна практичная деталь — идемпотентность. Финальные шаги, которые подтверждают бронирование, выдают компенсацию и отправляют уведомление, должны получать идемпотентный токен на основе ID пассажира и ID решения. Тогда повторный запуск или retry не превратится в двойное бронирование, вторую выплату или серию одинаковых писем клиенту. В агентных архитектурах об этом часто вспоминают поздно, когда красивый proof of concept внезапно встречается с платежными API.
На том же направлении AWS продвигает AgentCore Code Interpreter: управляемую serverless-песочницу, где агент может выполнять код, считать, обрабатывать данные и проверять промежуточные выводы. В кейсе Abnormal AI AWS описывает это как вычислительный scratchpad для задач, где языкового рассуждения мало. Логика та же: LLM хорошо связывает контекст и формулирует варианты, но арифметика, проверки, структурирование данных и контроль побочных эффектов должны жить в проверяемой среде.
Для русскоязычных команд, которые уже экспериментируют с агентами в саппорте, финоперациях, закупках или внутренних approval-процессах, этот паттерн полезен не авиацией, а границей ответственности. Агент может ускорить поиск вариантов, написать черновик письма и собрать контекст. Но детерминированная валидация должна стоять между его предложением и любой операцией, которая меняет деньги, договор, билет, счет или запись в учетной системе. Иначе вместо автоматизации получится очень уверенный стажер с root-доступом.
Главный тренд здесь шире AWS: рынок постепенно отходит от идеи «пусть агент сам все сделает» к более скучной, но рабочей архитектуре, где вероятностная модель генерирует варианты, а детерминированная валидация, журналирование и человек на исключениях решают, что действительно попадет в продакшен. Чем дороже ошибка, тем меньше у агента должно быть прямых прав на действие.