Validar decisões multiagente com Step Functions e Bedrock AgentCore

Por Ben Freiberg, Arquiteto de Soluções Sênior e Nithin Chandran Rajashankar, Technical Account Manager na Amazon Web Services.

Para uma equipe de operações de uma companhia aérea, um único cancelamento de voo desencadeia uma reação em cadeia. Centenas de passageiros precisam de novos itinerários em minutos, e nenhum caso é igual ao outro. Eles têm diferentes níveis de fidelidade, estão sujeitos a diferentes regras tarifárias e têm conexões seguintes que podem não esperar. Os passageiros têm preferências variadas de cabine e assento e podem se enquadrar em diferentes direitos regulatórios, dependendo de onde fizeram a reserva e para onde estão voando.

A maioria das companhias aéreas lida com isso por meio de um sistema em camadas: a automação baseada em regras cobre as reacomodações simples, de um único trecho, e todo o restante segue para uma fila manual atendida por agentes de serviço. Isso funciona quando as interrupções são isoladas. Quando não são, a fila fica sobrecarregada, os tempos de espera aumentam e os passageiros acabam escolhendo alternativas por conta própria, o que gera novas interrupções em cascata.

É exatamente aí que os agentes de IA se tornam interessantes. Um agente pode raciocinar sobre disponibilidade de assentos, regras tarifárias, direitos de fidelidade e prazos de conexão da mesma forma que um agente de balcão experiente faria, mas na velocidade de uma máquina e em paralelo para centenas de casos. A colaboração multiagente normalmente permite que um agente supervisor direcione o trabalho para subagentes colaboradores, com o próprio modelo decidindo qual subagente é executado e em que ordem. Mas um agente sem restrições pode otimizar para a preferência do passageiro ignorando uma restrição de codeshare, reacomodar em um voo que atende ao tempo mínimo de conexão no papel, mas não naquele aeroporto específico, ou calcular a compensação sob o regime regulatório errado por ter interpretado incorretamente o ponto de venda do bilhete.

Orquestrar agentes especializados do Amazon Bedrock AgentCore com o AWS Step Functions oferece o poder de raciocínio da IA generativa com as barreiras de proteção da validação determinística. O Step Functions adiciona expansão nativa (fan-out) para milhares de passageiros, um padrão de callback que pausa um caso para revisão humana sem custo de computação, e um histórico de execução durável que serve como sua trilha de auditoria. O princípio é que os agentes propõem, e o código determinístico valida. O padrão é demonstrado aqui para reacomodação de companhias aéreas, mas se aplica a qualquer lugar em que decisões automatizadas possam ter consequências financeiras ou regulatórias reais.

Visão geral da solução

O design é uma máquina de estados do Step Functions em que etapas determinísticas, mapeadas para os processos de negócio, envolvem o comportamento não determinístico de cada agente. O diagrama a seguir mostra o fluxo de ponta a ponta. Em um nível alto, o workflow passa pelas seguintes etapas:

1. O workflow começa quando um evento de cancelamento de voo chega, por exemplo, por meio de uma integração com o Amazon EventBridge.
2. Uma etapa de enriquecimento busca dados adicionais, como a lista de passageiros, reservas atuais, status de fidelidade e preferências armazenadas.
3. O workflow se expande (fan-out) para executar agentes em paralelo para cada passageiro afetado.
4. Dois agentes são então executados para cada passageiro: um agente de busca de alternativas propõe as três principais opções de reacomodação, e um agente de compensação determina o direito com base na rota, duração do atraso e causa.
5. Uma etapa de validação determinística é executada após cada agente, confirmando que os voos são realmente reserváveis e que as regras de direito são seguidas antes que qualquer resultado seja usado.
6. O workflow verifica se o caso pode ser confirmado automaticamente ou precisa de revisão humana.
7. As reservas são confirmadas, as compensações são emitidas e as confirmações são enviadas. Os casos não resolvidos vão para agentes humanos.

O princípio fundamental: nenhum estado de Tarefa (Task) do agente grava no sistema de reservas ou emite um pagamento. Somente estados de Tarefa determinísticos fazem isso, e apenas depois que uma etapa de validação determinística for aprovada.

Integrando o harness do AgentCore com o Step Functions

O harness do AgentCore é um loop de agente gerenciado. Você especifica um modelo, um prompt de sistema e ferramentas, e o harness executa o ciclo de raciocínio (chamadas de modelo, execução de ferramentas, gerenciamento de memória e geração de resposta) de ponta a ponta em uma única chamada de API. Ele lida com a orquestração intra-agente para que o Step Functions possa se concentrar na orquestração entre agentes: fan-out, sequenciamento, portas de validação e roteamento de exceções. O Step Functions oferece uma integração otimizada nativa para o harness do AgentCore, que chama InvokeHarness em um HarnessArn de destino. A integração otimizada oferece um tempo limite estendido por Tarefa de 15 minutos (900 segundos), para que os agentes tenham tempo suficiente para raciocinar sobre propostas complexas. O trade-off é que a chamada do agente é apenas do tipo requisição-resposta. Não há .sync nem .waitForTaskToken na etapa do agente, e apenas a mensagem final do assistente é retornada para a máquina de estados.

O trecho a seguir, em Amazon States Language, mostra a invocação otimizada do harness dentro de um Distributed Map. Para a definição completa, veja o exemplo no Serverless Land.

{
  "Comment": "Illustrative - per-passenger rebooking fan-out",
  "StartAt": "RebookPassengers",
  "States": {
    "RebookPassengers": {
      "Type": "Map",
      "ItemProcessor": {
        "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" },
        "StartAt": "FindAlternatives",
        "States": {
          "FindAlternatives": {
            "Type": "Task",
            "Resource": "arn:aws:states:::bedrockagentcore:invokeHarness",
            "Parameters": {
              "HarnessArn": "<HARNESS_ARN>",
              "RuntimeSessionId.$": "$.passenger.sessionId",
              "Messages": [{ "Role": "user", "Content": [{ "Text.$": "States.JsonToString($.passenger)" }] }]
            },
            "TimeoutSeconds": 900,
            "ResultPath": "$.proposal",
            "Next": "ValidateRebooking"
          },
          "ValidateRebooking": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "End": true }
        }
      },
      "MaxConcurrency": 1000,
      "End": true
    }
  }
}

Observação: o nome do serviço é escrito como bedrockagentcore (sem hífen) na string de recurso do Step Functions, mas bedrock-agentcore (com hífen) no ARN do AgentCore.

MaxConcurrency é definido como 1000 para limitar o fan-out e proteger os sistemas de reserva e inventário downstream. Se você omiti-lo ou defini-lo como 0, obtém o comportamento padrão, que executa até 10.000 execuções filhas em paralelo. A Tarefa do agente flui diretamente para uma Tarefa de validação determinística.

Em que difere da colaboração multiagente gerenciada

A colaboração multiagente normalmente significa que um agente supervisor decide qual subagente é executado e quais ferramentas ele chama. O Step Functions remove essas decisões completamente da camada de agentes.

Esse design coloca a orquestração, o fan-out, a validação, o roteamento, as novas tentativas e a trilha de auditoria no Step Functions. O roteamento é um estado determinístico que você define e pode testar isoladamente, e não uma classificação de modelo que você espera que seja consistente. Você obtém um histórico de execução por estado (cada transição registrada com entrada e saída), enquanto os rastreamentos na camada de agentes exigem adesão explícita (opt-in) e fornecem a justificativa do raciocínio, em vez de um log de eventos durável e sempre ativo.

Análise detalhada do design da aplicação de referência

A imagem a seguir mostra a máquina de estados do Step Functions implementada pela aplicação de exemplo.

Etapa 1, Gatilho. Uma regra do Amazon EventBridge inicia o workflow em um evento de cancelamento de voo.

Etapa 2, Enriquecimento. Uma Tarefa determinística busca a lista de passageiros, reservas, status de fidelidade e preferências para o estado de execução.

Etapa 3, Fan-out do Map. Um Distributed Map itera pelos passageiros afetados em paralelo. A escolha do tipo de Map é importante em escala. Um Map inline executa até 40 iterações simultâneas, que é o limite documentado para optar pelo modo Distributed. Um Distributed Map executa até 10.000 execuções filhas em paralelo por padrão, sendo a ferramenta certa quando um evento em um hub afeta milhares de passageiros.

Etapa 4, Agente 1 busca alternativas. Uma Tarefa do AgentCore propõe as três principais opções, raciocinando sobre as preferências e restrições do passageiro.

Etapa 5, Validação determinística da proposta de reacomodação. Uma Tarefa do AWS Lambda confirma que cada voo proposto é reservável, verificando a disponibilidade em tempo real, as regras tarifárias e a validade da rota, e rejeita opções alucinadas. Um agente pode propor com confiança um voo que não existe. Esta etapa é onde essa proposta é interceptada antes que possa se tornar um bilhete.

Etapa 6a, Agente 2 elabora a compensação. Uma segunda Tarefa do AgentCore elabora apenas o texto de notificação personalizado voltado ao cliente. Ela não calcula o direito nem movimenta dinheiro.

Etapa 6b, Verificação determinística de direito. Uma Tarefa Lambda calcula e valida o direito em relação às tabelas de regras antes que qualquer compensação seja emitida. Estruturas de proteção ao consumidor, como o Regulamento da UE 261/2004 (EU261) e as regras de reembolso do Departamento de Transporte dos EUA, são referenciadas aqui de forma ilustrativa, para mostrar por que o cálculo determinístico e auditável é importante. As faixas específicas, gatilhos e valores são configurações que você mesmo deve possuir e validar em relação à orientação legal vigente, e não algo que um agente deva inferir.

Etapa 7, Roteamento de escolha e humano no processo. Um estado Choice confirma automaticamente as reacomodações para alguns passageiros e direciona o restante para um humano. Para os casos que precisam de revisão, o workflow aguarda em uma Tarefa .waitForTaskToken separada, apoiada por Lambda, Amazon Simple Notification Service (Amazon SNS) ou Amazon Simple Queue Service (Amazon SQS), com um tempo limite de 4 horas. A espera ocorre nessa Tarefa de callback separada, nunca na etapa do agente.

{
  "Comment": "Illustrative - route and wait on a human, not on the agent",
  "RouteDecision": {
    "Type": "Choice",
    "Choices": [
      {
        "Variable": "$.passenger.autoConfirmEligible",
        "BooleanEquals": true,
        "Next": "ExecuteBooking"
      }
    ],
    "Default": "AwaitHumanApproval"
  },
  "AwaitHumanApproval": {
    "Type": "Task",
    "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
    "Parameters": {
      "QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/approvals",
      "MessageBody": {
        "taskToken.$": "$$.Task.Token",
        "passengerId.$": "$.passenger.id",
        "options.$": "$.proposal.validatedOptions"
      }
    },
    "TimeoutSeconds": 14400,
    "Next": "ExecuteBooking"
  }
}

Etapa 8, Execução. Estados de Tarefa determinísticos confirmam a reserva, emitem a compensação e enviam a confirmação. Cada Tarefa de execução deriva um token de idempotência a partir do ID do passageiro combinado com o ID da decisão (o nome da execução filha, ou um hash do conjunto de opções validadas) e o transmite para as APIs de reserva e pagamento, de forma que uma nova tentativa ou redrive resulte em nenhuma operação, em vez de uma reserva duplicada ou um segundo pagamento.

Etapa 9, Agregação e roteamento de exceções. O workflow resume os resultados e direciona quaisquer casos não resolvidos para agentes humanos.

A etapa de validação em si é um código determinístico comum. Um validador de reacomodação simplificado em Python é semelhante ao seguinte.

# Illustrative - reject any option the agent proposed that is not bookable
def handler(event, context):
    passenger = event["passenger"]
    proposed = event["proposal"]["options"]

    validated = []
    for option in proposed:
        flight = lookup_flight(option["flightId"])
        if flight is None:
            continue  # hallucinated or stale flight, reject
        if flight["seatsAvailable"] < 1:
            continue  # no inventory, reject
        if not fare_rules_allow(passenger["fareClass"], flight):
            continue  # fare rule violation, reject
        if not route_is_valid(passenger["origin"], passenger["destination"], flight):
            continue  # invalid route, reject
        validated.append(option)

    return {
        "passengerId": passenger["id"],
        "validatedOptions": validated,
        "autoConfirmEligible": passenger["loyaltyTier"] == "top" and len(validated) > 0,
    }

Práticas recomendadas e barreiras de proteção

Rejeite alucinações por meio de validações. Nenhuma proposta de agente é aplicada sem que uma etapa de validação determinística seja aprovada primeiro. Isso minimiza o impacto de alucinações, injeções de prompt ou bugs no seu workflow.

Mantenha uma trilha de auditoria completa. O histórico de execução do Step Functions registra cada transição de estado, entrada e saída, e combinar isso com persistência durável oferece um registro por decisão. Você pode mostrar exatamente qual proposta foi feita, qual validação passou ou falhou, e quem aprovou a exceção.

Exponha aos humanos apenas as exceções verdadeiras. Os humanos tratam apenas o que a validação ou o agente não conseguem resolver. A confirmação automática lida com os casos claros, e as pessoas dedicam sua atenção aos casos genuinamente ambíguos.

Mantenha execuções abertas com baixo custo. O callback .waitForTaskToken mantém a execução aberta sem cobranças de computação enquanto a execução está pausada. Por exemplo, você pode manter milhares de aprovações pendentes durante a noite de forma econômica. Consulte a página de preços do AWS Step Functions para detalhes atuais.

Torne a execução idempotente. Proteja a execução da reserva e a emissão da compensação contra novas tentativas e envios duplicados, como mostrado na Etapa 8. Derive o token de idempotência a partir do ID do passageiro e do ID da decisão, e transmita-o para suas APIs de reserva e pagamento, de forma que uma repetição resulte em nenhuma operação.

Respeite o custo e os tempos limite. Mantenha o tempo limite de cada Tarefa por agente dentro da cota de 15 minutos, limite a concorrência do seu Map para proteger os sistemas downstream, e monitore o uso de tokens retornado na resposta do agente para poder atribuir e prever custos.

Trate erros deliberadamente. Aplique Retry e Catch nas Tarefas do agente para condições como BedrockAgentCore.ThrottlingException e BedrockAgentCore.ResourceNotFoundException, e nas Tarefas de validação do Lambda para seus próprios modos de falha. Um Catch em uma Tarefa do agente pode direcionar um passageiro travado diretamente para a fila humana, em vez de falhar toda a execução filha.

Confirme a disponibilidade e o suporte por Região. Verifique o status de disponibilidade atual e as Regiões da AWS com suporte para o AgentCore e a integração com o Step Functions em AWS Capabilities by Region no Builder Center.

Conclusão

Um evento de cancelamento de voo é um teste desafiador para a tomada de decisão automatizada, porque o resultado pode ter impacto financeiro imediato. A forma de usar agentes de IA com segurança nesse cenário é deixá-los fazer o que sabem fazer bem, propor opções e elaborar textos, sem nunca permitir que uma proposta se torne uma ação até que um código determinístico a tenha aprovado. Neste design, a orquestração, o fan-out, a validação, o roteamento e as novas tentativas são implementados no Step Functions, e não dentro do raciocínio de um agente. Os agentes não fazem alterações diretamente, e sua saída só é aplicada após a validação determinística. Você obtém um registro por decisão para revisão, e mantém as exceções abertas em um callback que não adiciona custo de computação ou armazenamento enquanto aguarda.

Para começar, implemente o padrão de referência do Serverless Land e adapte a camada de validação ao seu próprio workflow.

Este conteúdo foi traduzido a partir da publicação original do blog, que pode ser encontrada aqui.

Biografia do Autores

	Ben Freiberg é Arquiteto de Soluções Sênior na Amazon Web Services.
	Nithin Chandran Rajashankar é Technical Account Manager na Amazon Web Services.

Biografia do tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua área de interesse são tecnologias serverless. https://www.linkedin.com/in/nicolastarzia