A maior parte do que as pessoas chamam de agente é uma sequência fixa de passos com uma ou duas chamadas de modelo no meio. O control flow é conhecido de antemão, mas os times o entregam ao modelo mesmo assim, e depois passam semanas fazendo um loop não determinístico se comportar. Quando a forma do trabalho é conhecida, o orquestrador deveria ser determinístico, e o AWS Step Functions se encaixa melhor nesse papel do que um loop de agente feito à mão. Ele já resolve retries, timeouts, tratamento de erros, paralelismo e aprovação humana, exatamente as coisas que um framework de agentes te pede para reimplementar.

O reenquadramento que vale a pena internalizar: deixe o modelo tomar decisões, não a encanação. Use o modelo para os passos que genuinamente precisam de julgamento, extrair, classificar, rascunhar, e deixe uma máquina de estados decidir o que roda, em que ordem, e o que acontece quando um passo falha. Você não precisa de um LLM para saber que o passo três vem depois do passo dois.

Orquestração determinística é uma feature, não uma limitação

Um loop de agente feito à mão coloca o modelo no comando do control flow: ele decide qual ferramenta chamar, lê o resultado, decide a próxima ferramenta, e assim por diante até achar que terminou. Esse é o design certo quando o caminho é genuinamente desconhecido no momento de autoria. É o design errado quando o caminho é um fluxo de trabalho que você poderia desenhar num quadro branco, porque agora cada execução pode tomar uma rota diferente, os retries são ad hoc, e uma falha na metade do caminho deixa um estado que você tem que reconstruir.

O Step Functions inverte isso. Você declara os estados e as transições. Cada estado que precisa de julgamento invoca o Bedrock (diretamente ou via Lambda); cada estado que não precisa é lógica simples. A execução é reproduzível, toda transição fica registrada, e o histórico de execução é uma trilha de auditoria embutida. Para um fluxo de trabalho de forma conhecida, determinismo é exatamente o que você quer.

Retries e tratamento de erros que você não escreve

A maioria pouco glamorosa do trabalho de confiabilidade de agentes é política de retry. Uma chamada de modelo sofre throttling, uma ferramenta dá timeout, uma API downstream retorna um 500 transitório. Em um loop feito à mão você escreve backoff, jitter e tratamento por tipo de erro na mão, e geralmente acerta de forma sutilmente errada.

O Step Functions torna isso declarativo. Cada estado carrega seu próprio comportamento de retry e catch:

"InvokeModel": {
  "Type": "Task",
  "Resource": "arn:aws:states:::bedrock:invokeModel",
  "Retry": [{
    "ErrorEquals": ["Bedrock.ThrottlingException"],
    "IntervalSeconds": 2,
    "BackoffRate": 2.0,
    "MaxAttempts": 5
  }],
  "Catch": [{
    "ErrorEquals": ["States.ALL"],
    "Next": "HandleFailure"
  }]
}

Throttling recebe backoff exponencial, qualquer outra coisa é roteada para um estado de falha que você controla. Nenhum código de retry, nenhuma exceção perdida, e o comportamento fica visível na definição em vez de enterrado num loop.

Human-in-the-loop é um estado de primeira classe

O lugar onde agentes feitos à mão mais sofrem é pausar para um humano. Um agente que pode gastar dinheiro, enviar email ou mudar produção deveria parar e esperar aprovação, e fazer isso em um processo de longa duração significa segurar estado em algum lugar enquanto uma pessoa leva horas ou dias para responder.

O Step Functions já tem isso embutido através do padrão de callback. Uma tarefa iniciada com .waitForTaskToken pausa a execução, emite um token, e não faz nada até que algo chame SendTaskSuccess ou SendTaskFailure com esse token. O fluxo pode ficar pausado pelo tempo que a aprovação levar sem nenhum processo rodando, e depois retomar exatamente de onde parou. Você ganha um gate humano durável e auditável sem construir uma fila, um armazenamento de estado e um mecanismo de retomada por conta própria.

Quando você ainda quer um loop de agente de verdade

Isso não é um argumento contra loops de agente, é um argumento a favor de usá-los onde eles se justificam. Recorra a um loop guiado por modelo quando o caminho é genuinamente aberto: o modelo tem que decidir, em tempo de execução, qual entre muitas ferramentas usar e em que ordem, e nenhum grafo fixo captura isso. Pesquisa aberta, debugging livre e tarefas em que o próximo passo depende do que o último retornou de formas que você não consegue enumerar são o lar de verdade do loop de agente.

A armadilha é usar esse padrão para um pipeline de cinco passos com um branch. Se você consegue desenhar o fluxograma, codifique o fluxograma. Reserve o loop não determinístico para o trabalho que é de fato não determinístico.

A conclusão

Uma grande parte do trabalho de agentes em produção é orquestração determinística fantasiada de agente. Para esse trabalho, o Step Functions te dá retries, roteamento de erros, paralelismo e um estado de aprovação humana durável que você teria que construir e manter na mão, além de um histórico de execução que também serve como log de auditoria. Deixe o modelo fazer as chamadas que precisam de julgamento, e deixe uma máquina de estados ser dona do control flow. O agente mais confiável costuma ser aquele em que o modelo decide o mínimo possível.

Leia isso a seguir

Para a leitura de infraestrutura e plataforma do mesmo padrão, incluindo gates de aprovação em operações de alto risco, as notas de campo de cloud estão em ercan.cloud, e o hub fica em ercanermis.com.