Agentes de IA já iniciam workflows do Step Functions. O agente escolhe o momento; o workflow mantém os passos

A coisa mais arriscada que um agente enterprise pode fazer é improvisar um processo que já existe. Um reembolso tem uma checagem de elegibilidade, uma aprovação do gestor e um crédito lançado em uma ordem específica. Quando recebe as APIs individuais e precisa descobrir a ordem, o agente geralmente acerta. O problema é o geralmente.

O anúncio da AWS em 29 de outubro oferece um arranjo diferente. Workflows existentes do AWS Step Functions, Standard e Express, agora podem ser expostos como ferramentas para agentes de IA pelo Amazon Bedrock AgentCore Gateway, que fala MCP. O agente decide quando rodar um workflow e qual input passar. O Step Functions executa cada passo exatamente como foi definido.

A linha que ele traça

Quem decide o quê quando um agente chama um workflow

O agente

• Entende o pedido
• Escolhe o workflow
• Fornece o input
• Lê o status da execução

Probabilístico

O workflow

• Checagem de elegibilidade
• Etapa de aprovação humana
• Retentativas e caminhos de erro
• Chamadas para 220+ serviços da AWS

Definido e testado com antecedência

Os sistemas de registro

• O crédito lançado
• O histórico de execução

O que os auditores leem

O exemplo da AWS é um agente de suporte que dispara um workflow de reembolso que executa etapas de elegibilidade, aprovação do gestor e lançamento do crédito. O agente nunca toca a API de crédito diretamente. Também não consegue pular a aprovação, porque a aprovação é um estado no workflow, não uma instrução no prompt.

A segunda capacidade é mais discreta e útil na operação: agentes podem consultar execuções de workflow. Um agente consegue responder “quais execuções de pedido falharam durante a noite, e em qual etapa” a partir do histórico de execução, em vez de reconstruí-lo a partir dos logs.

A disponibilidade segue as regiões do AgentCore Gateway, e o preço é a tarifa padrão dos dois serviços.

Por que este é o formato certo

Já defendemos que um agente bem operado torna partes de si mesmo desnecessárias: quando um caminho de raciocínio se repete, ele deve virar software comum e sair do modelo. O Step Functions como ferramenta é a outra metade dessa ideia. A organização não precisa converter nada; ela já tem workflows que codificam seus procedimentos, testados e versionados, muitas vezes com etapas de aprovação que o compliance aprovou anos atrás. O agente se torna uma nova forma de iniciá-los, não um substituto para eles.

É também a fronteira que descrevemos em a disputa pela camada que autoriza a transação. O raciocínio está se tornando portátil entre fornecedores; a autoridade para efetivar uma transação deve ficar com o sistema que a detém. Uma máquina de estados com seu próprio papel IAM e histórico de execução é um lugar razoável para essa autoridade morar.

O que isso não resolve

Quem pode iniciar o workflow. Expor um workflow como ferramenta o torna chamável por qualquer agente que o gateway permitir. A pergunta muda de “o agente consegue fazer as etapas” para “este agente, agindo por este usuário, deveria poder iniciar este workflow”. Isso exige uma política no gateway, ligada a a identidade por trás de cada chamada de ferramenta, não apenas ao papel do próprio workflow.

Validação de input. O agente fornece o input. Um workflow que confiava nos antigos chamadores, porque eram sistemas internos com schemas fixos, agora recebe valores escolhidos por um modelo. Valide no primeiro estado como se o chamador não fosse confiável, porque em parte ele não é.

Execuções duplicadas. Agentes tentam de novo. Uma ordem de execução definida não garante que os efeitos aconteçam exatamente uma vez em sistemas externos. Reembolsos, pagamentos e notificações precisam de chaves de idempotência para que a segunda chamada retorne o primeiro resultado em vez de pagar duas vezes.

Workflows escritos para pessoas. Alguns workflows assumem que um operador humano vai notar um resultado estranho entre etapas. Um agente não vai. Revise quais workflows são seguros para expor antes de expô-los, começando pelos somente leitura e reversíveis.

Nada disso é um argumento contra o recurso. É um argumento para tratar o catálogo de workflows como uma superfície de autorização: uma lista explícita de quais procedimentos agentes podem iniciar, para quem, com quais inputs. Times que já rodam seus processos críticos em máquinas de estado saem na frente. Times que não rodam agora têm mais um motivo para começar.