Construindo workflows de IA multi-agente tolerantes a falhas com AWS Lambda durable functions

Por Satish Kamat, Ben Freiberg e Reetesh Surjani.

Workflows de IA agêntica coordenam múltiplos agentes que raciocinam, planejam e agem através de processos de múltiplas etapas. Cada etapa é cara, não determinística e imprevisível em latência. Gates de revisão humana podem pausar a execução por dias. Falhas transitórias são esperadas, e reiniciar um workflow pela metade desperdiça tempo e dinheiro. Ações duplicadas, como cobrar um pagamento duas vezes ou enviar a mesma solicitação novamente, criam riscos financeiros e de conformidade. Até agora, resolver esses problemas significava construir infraestrutura personalizada, como máquinas de estado, filas, armazenamentos de checkpoint antes de escrever uma única linha de lógica de negócios.

A autorização prévia é uma das etapas mais demoradas na prestação de serviços de saúde. Um provedor deve obter aprovação de uma seguradora antes que certos tratamentos ou medicamentos sejam cobertos. A seguradora avalia se o cuidado é medicamente necessário, seguro e econômico.

A IA agêntica está transformando esse processo. O que anteriormente levava dias — extrair dados clínicos, avaliar necessidade médica, verificar critérios específicos do pagador e obter aprovação do médico — agora pode ser tratado por agentes de IA que extraem registros, aplicam diretrizes e redigem cartas de justificativa automaticamente.

Este post mostra como as AWS Lambda durable functions podem orquestrar um workflow agêntico de autorização prévia em saúde. O pipeline coordena múltiplos agentes de IA, um gate de revisão humana e uma submissão externa ao pagador em uma única função tolerante a falhas. Usando dois padrões principais — callbacks para aprovações human-in-the-loop e invocações assíncronas de agentes, e polling para tarefas externas de longa duração — as Lambda durable functions permitem que você se concentre no workflow clínico em vez de construir máquinas de estado personalizadas, lógica de retry e infraestrutura de checkpoint.

Visão geral das AWS Lambda durable functions

As Lambda durable functions estendem o modelo de programação padrão do Lambda com um mecanismo de checkpoint e replay. Você envolve seu handler com o durable execution SDK, que aprimora o contexto do Lambda com durable operations como context.step(), context.waitForCallback() e context.waitForCondition(). Essas operações criam checkpoints de progresso, lidam com falhas e suspendem a execução durante períodos de espera. Se ocorrer uma falha ou a função for retomada após ser suspensa, o Lambda invoca sua função novamente. Ele restaura o estado anterior reproduzindo o event handler desde o início e pulando durable operations concluídas anteriormente. As Lambda durable functions oferecem padrões adicionais como execução paralela, durable invocations e compensações no estilo saga. Consulte o Guia do Desenvolvedor do AWS Durable Execution SDK para o conjunto completo de capacidades.

Workflows de IA agêntica são naturalmente adequados para durable functions porque cada invocação de agente é tipicamente cara, lenta e propensa a falhas transitórias, que são exatamente as propriedades que se beneficiam de checkpoint automático e replay. Além de orquestrar etapas de agentes, durable functions podem pausar a execução do workflow para entrada externa. Você pode suspender a execução até que uma aprovação humana chegue, ou fazer polling de um sistema externo para conclusão com backoff configurável. Para funções on-demand, você não incorre em cobranças de computação enquanto a execução está suspensa (consulte preços do Lambda para detalhes).

O pipeline de autorização prévia em saúde

O orquestrador de workflow de autorização prévia coordena quatro agentes de IA, um gate de revisão humana e uma submissão ao pagador.

1. Agente de extração clínica (step). Extrai dados clínicos relevantes (códigos de diagnóstico, histórico de procedimentos, resultados de laboratório) dos registros médicos do paciente.
2. Agente de necessidade médica (step). Avalia se o procedimento atende às diretrizes clínicas com base nos dados extraídos.
3. Agente de critérios do pagador (step). Verifica os requisitos de autorização específicos do pagador e identifica qualquer documentação ausente.
4. Agente de geração de justificativa (step). Produz a carta de justificativa de autorização prévia usando as saídas dos três agentes anteriores.
5. Revisão do médico (callback). O orquestrador suspende e aguarda que um médico revise e aprove a justificativa gerada. Como isso usa waitForCallback(), a função não incorre em cobranças de computação enquanto o médico leva minutos, horas ou dias para responder.
6. Submissão ao pagador e adjudicação (polling). Uma vez aprovado, o orquestrador submete a solicitação de autorização ao sistema do pagador usando uma etapa idempotente com um clientRequestToken (mostrado no código abaixo) para ajudar a prevenir submissões duplicadas. Em seguida, faz polling do status de adjudicação do pagador usando waitForCondition() com backoff exponencial, suspendendo entre cada verificação.

Figura 2. O pipeline de autorização prévia de seis estágios, orquestrado por uma única Lambda durable function.

Juntando tudo em código

O pipeline inteiro, desde etapas de agentes até revisão humana até submissão ao pagador e polling, vive em uma única função que se lê de cima para baixo:

@durable_execution
def handler(event: dict, context: DurableContext) -> dict:
    # 1-4: Sequential agent steps (each checkpointed)
    clinical_data = context.step(extract_clinical_agent(event["patient_id"]))
    necessity = context.step(medical_necessity_agent(clinical_data))
    criteria = context.step(payer_criteria_agent(event["payer_id"], necessity))
    justification = context.step(justification_agent(clinical_data, necessity, criteria))

    # 5: Suspend until physician approves (minutes to days, zero compute cost)
    def submit_for_review(cb_id, ctx):
        send_to_review_system(cb_id, justification)

    approval = context.wait_for_callback(
        submitter=submit_for_review,
        config=WaitForCallbackConfig(timeout=Duration.from_days(7)),
        name="physician_review",
    )

    if not approval.get("approved"):
        return {"status": "REJECTED", "reason": approval.get("reason")}

    @durable_step
    def make_idempotency_key(ctx: StepContext) -> str:
        return str(uuid.uuid4())

    # 6: Submit to payer and poll for decision
    idempotency_key = context.step(make_idempotency_key(), name="idempotency-key")
    submission = context.step(submit_authorization(justification, idempotency_key))

    def check_payer_status(state, ctx):
        return {**state, "status": get_payer_status(state["submission_id"])}

    decision = context.wait_for_condition(
        check=check_payer_status,
        config=WaitForConditionConfig(
            initial_state={"submission_id": submission["id"], "status": "PENDING"},
            wait_strategy=payer_adjudication_strategy,
        ),
        name="payer_adjudication",
    )

    return {"status": decision["status"], "authorization_id": submission["id"]}

Como o orquestrador lida com falhas

O orquestrador é projetado para lidar com os modos de falha que surgem em workflows reais:

• Uma etapa de agente falha. Se o agente de necessidade médica falhar após o agente de extração clínica ter sido concluído, a Lambda durable function reproduz o handler, pula a etapa de extração que já teve checkpoint criado e tenta novamente apenas a etapa que falhou. Isso ajuda a evitar incorrer novamente no tempo, custo e gasto de tokens de etapas concluídas.
• O médico rejeita a justificativa. O callback retorna approved: false, o orquestrador retorna um status REJECTED e nenhuma submissão ao pagador ocorre.
• A adjudicação do pagador excede o máximo de tentativas. waitForCondition() gera um erro de timeout após o limite de tentativas configurado, que você pode capturar e encaminhar para uma fila de revisão manual ou ação compensatória.
• A etapa de submissão tenta novamente após uma falha transitória. Como a submissão carrega um clientRequestToken derivado do ID de execução, novas tentativas contra o pagador são idempotentes no nível da API do pagador, o que ajuda a prevenir solicitações de autorização duplicadas.

O padrão de callback

O padrão de callback permite que o orquestrador suspenda a execução e aguarde um sinal externo antes de retomar. Quando a durable function atinge um context.waitForCallback(), ela envia um callbackId único para um sistema externo e então suspende. Quando o sistema externo completa seu trabalho, ele chama a API do Lambda com SendDurableExecutionCallbackSuccess (ou SendDurableExecutionCallbackFailure) para retomar o orquestrador de onde parou.

No pipeline de autorização prévia, é assim que a etapa de revisão do médico funciona. Após o agente de geração de justificativa produzir uma carta, o orquestrador emite um ID de callback para o sistema de revisão clínica e suspende. O médico recebe o rascunho em sua fila de revisão, lê e aprova ou rejeita através da interface de revisão. A interface chama a API de callback do Lambda com o resultado, e o orquestrador retoma com a decisão de aprovação.

Como a função está totalmente suspensa, ela não incorre em cobranças de computação durante a janela de revisão, seja de 10 minutos ou 3 dias.

Figura 3. O fluxo de callback para a etapa de revisão do médico. O orquestrador emite um ID de callback para o sistema de revisão clínica e suspende. Quando o médico aprova ou rejeita, o sistema de revisão chama SendDurableExecutionCallbackSuccess para retomar o orquestrador com a decisão.

O padrão de callback é apropriado quando:

• Um humano precisa revisar e aprovar um resultado (horas a dias).
• Um agente externo é invocado de forma assíncrona e o orquestrador deve retomar quando ele terminar.
• Um webhook ou sistema de terceiros sinaliza conclusão.

O padrão de polling

Quando um sistema externo não pode enviar um callback, por exemplo uma API de pagador que não oferece suporte a webhook, o padrão de polling fornece uma alternativa. O orquestrador monitora a tarefa de longa duração verificando periodicamente seu status usando context.waitForCondition().

# Poll the payer's adjudication API with exponential backoff
decision = context.wait_for_condition(
    check=lambda state, ctx: {**state, "status": get_payer_status(state["submission_id"])},
    config=WaitForConditionConfig(
        initial_state={"submission_id": "auth-789", "status": "PENDING"},
        wait_strategy=create_wait_strategy(WaitStrategyConfig(
            should_continue_polling=lambda state: state["status"] == "PENDING",
            max_attempts=48,
            initial_delay=Duration.from_seconds(30),
            max_delay=Duration.from_seconds(300),
            backoff_rate=2.0,
        ))
    ),
    name="payer_adjudication",
)

Ele executa uma função de verificação periodicamente conforme configurado por uma estratégia de espera e avalia o resultado. Se a tarefa não estiver completa, suspende por um atraso configurável antes de verificar novamente. A função não incorre em cobranças de computação durante cada intervalo de espera. Cada resultado de polling tem checkpoint criado automaticamente, então no replay o orquestrador pula verificações concluídas anteriormente.

No pipeline de autorização prévia, é assim que a etapa de adjudicação do pagador funciona. A maioria das APIs de pagadores aceita uma submissão e retorna um ID de rastreamento, mas não envia um sinal de conclusão de volta. O orquestrador chama waitForCondition() com a API de status do pagador, uma estratégia de backoff exponencial (30 segundos a 5 minutos) e uma contagem máxima de tentativas que cobre a janela típica de adjudicação do pagador.

As Lambda durable functions fornecem waitForCondition() com suporte integrado para estratégias de backoff configuráveis, limites máximos de tentativas e timeouts, o que pode ajudar a reduzir a necessidade de infraestrutura de polling separada, como regras agendadas, máquinas de estado ou lógica de retry personalizada.

Figura 4. O fluxo de polling para a etapa de adjudicação do pagador

Polling é apropriado quando:

• Um trabalho assíncrono não suporta callbacks.
• Uma API ou sistema externo expõe apenas um endpoint de status ou Describe.
• O orquestrador aguarda que um recurso fique disponível.

Preocupações de custo e operacionais

Aqui estão algumas implicações ao usar orquestração de workflows agênticos com Lambda durable functions:

• Novas tentativas não executam novamente agentes concluídos. Se o quarto agente falhar, os três primeiros não são reinvocados, então a organização não paga custos de tokens duas vezes pelo mesmo trabalho.
• Tokens de idempotência ajudam a prevenir submissões duplicadas ao pagador. Uma nova tentativa que cruza a etapa de submissão reutiliza o clientRequestToken, o que ajuda o pagador a deduplicar do seu lado. Esta é uma propriedade importante quando solicitações de autorização duplicadas podem desencadear problemas de conformidade.
• Logger replay-aware simplifica o registro de logs. O logger do SDK (context.logger) tem replay-aware, o que significa que ele suprime automaticamente linhas de log duplicadas durante o replay.
• A visibilidade operacional é consolidada. Em vez de juntar logs de uma máquina de estado, uma fila, uma tabela de checkpoint e um poller, o workflow inteiro é uma função com um histórico de execução. O Lambda publica métricas específicas de durable execution no Amazon CloudWatch, incluindo ApproximateRunningDurableExecutions, DurableExecutionDuration e DurableExecutionFailed, para que você possa rastrear workflows em execução, detectar falhas e definir alarmes no nível de execução. O Lambda também publica eventos de mudança de status de durable execution para o Amazon EventBridge (RUNNING, SUCCEEDED, FAILED, TIMED_OUT) para acionar notificações ou workflows downstream, e você pode habilitar o AWS X-Ray para rastreamento distribuído em toda a execução. Para mais detalhes, consulte Monitoramento de durable functions no guia do desenvolvedor do Lambda.

Usando coding agents para construir e testar durable functions

Para acelerar a construção de orquestração de workflow agêntico com Lambda durable functions, você pode usar o Kiro power para Lambda durable functions ou o Agent Plugin para AWS Serverless, que está disponível em qualquer ferramenta de AI coding assistant que suporte agent plugins, como Claude Code e Cursor. Você também pode instalar agent skills do plugin individualmente em qualquer ferramenta de AI coding assistant que suporte agent skills. Isso ajuda seus coding agents como Kiro a:

• Fazer o scaffold de uma função orquestradora a partir de uma descrição em prosa do workflow, conectando chamadas de context.step(), wait_for_callback() e wait_for_condition() com base nos estágios descritos.
• Gerar testes unitários que exercitam o comportamento de replay, incluindo testes que injetam falhas em etapas específicas para confirmar que checkpoints concluídos são pulados na nova tentativa.
• Gerar testes de integração que simulam entrega de callback e respostas de polling para que você possa validar o comportamento de ponta a ponta sem um sistema externo completo.

Conclusão

Workflows de IA agêntica podem ser não determinísticos, de longa duração e propensos a falhas. As Lambda durable functions podem ajudar a enfrentar esses desafios adicionando checkpoint, replay e suspensão ao modelo de programação do Lambda, para que o trabalho concluído seja pulado na nova tentativa e as falhas sejam retomadas exatamente onde ocorreram.

Neste post, percorremos um pipeline de autorização prévia em saúde para ilustrar dois padrões: Callbacks para aprovações human-in-the-loop e invocações assíncronas de agentes, e polling para monitorar tarefas externas de longa duração.

Além desses dois padrões, as Lambda durable functions oferecem capacidades adicionais para construir workflows resilientes, como execução paralela, child contexts para contexto de execução isolado para agrupamento de operações e compensações no estilo saga. Consulte o Guia do Desenvolvedor de Lambda durable functions para o conjunto completo de capacidades. Para preços de funções on-demand e de concorrência provisionada, consulte a página de preços do Lambda.

Comece com Lambda durable functions com exemplos do Serverlessland e instale o Agent Plugin para AWS Serverless.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

	Satish Kamat é Sr. Delivery Consultant na Amazon Web Services.
	Ben Freiberg é Senior Solutions Architect na Amazon Web Services.
	Reetesh Surjani é Delivery Consultant na Amazon Web Services.

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