A maioria dos projetos de "agente de IA" que chegam à Sparsum não são agentes multi-step. São automações de uma etapa com um LLM no meio — o que é útil, mas é uma categoria de risco completamente diferente da que o termo "agente" sugere. Um agente que executa uma ação e recebe o resultado é previsível: você sabe exatamente o que vai acontecer, e a governança se resume a validar a entrada e a saída. Um agente que decide uma sequência de ações — e ajusta essa sequência com base no que descobre no caminho — é outra arquitetura, com outro perfil de risco e outra exigência de governança.
Confundir as duas coisas é onde a maioria dos projetos perde controle.
A diferença entre executar e decidir
Automação de uma etapa segue um roteiro fixo: recebe uma entrada, aplica uma transformação ou chama uma API, devolve uma saída. O LLM participa de uma decisão pontual — classificar, extrair, resumir — mas o fluxo em volta dele é determinístico.
Um agente multi-step é diferente porque o próximo passo depende do resultado do passo anterior, e essa decisão é tomada pelo próprio agente, não codificada de antemão. Na prática: o agente consulta um sistema, avalia o que encontrou, decide se precisa de mais informação, consulta outro sistema, e só então decide a ação final. Cada etapa intermediária é uma bifurcação real — não uma condicional pré-programada com todos os caminhos já mapeados.
Isso muda a pergunta central de governança. Automação de uma etapa responde "essa saída está correta?". Agente multi-step precisa responder "essa sequência de decisões, incluindo as intermediárias que nunca aparecem no resultado final, foi razoável?".
O que muda na arquitetura: do script fixo ao loop de decisão
Tecnicamente, o salto de uma etapa para multi-step introduz três componentes que automação simples não tem:
- Planejamento — o agente decide a ordem das ações antes ou durante a execução, em vez de seguir uma sequência fixa escrita por um desenvolvedor.
- Uso de ferramentas condicionado a contexto — a mesma tarefa pode acionar ferramentas diferentes dependendo do que foi descoberto nas etapas anteriores, não de uma regra estática.
- Estado entre etapas — o agente precisa manter e atualizar contexto ao longo de múltiplas chamadas, e esse estado influencia decisões futuras na mesma execução.
Cada um desses três componentes é também uma superfície de falha nova. Planejamento errado gasta chamadas de API em caminhos que não levam a lugar nenhum. Uso de ferramenta mal condicionado aciona a ação errada com contexto real, não hipotético. Estado corrompido entre etapas propaga um erro do passo 2 para o resultado do passo 5 — e quando alguém audita o resultado final, a causa raiz já está três etapas atrás.
Onde multi-step agrega valor real
Multi-step não é melhor que automação de uma etapa — é necessário apenas quando o processo genuinamente exige decisão intermediária baseada em informação que só aparece durante a execução. Casos típicos:
- Due diligence documental — o agente lê um contrato, identifica uma cláusula ambígua, decide se precisa consultar um documento relacionado antes de classificar o risco, e só então produz o parecer.
- Triagem de incidente técnico — o agente consulta logs, identifica um padrão, decide se o padrão justifica consultar histórico de incidentes similares, e só então recomenda ação.
- Precificação com múltiplas variáveis dependentes — o agente verifica disponibilidade, decide se o cenário exige consultar exceção contratual, e só então calcula o preço final.
Em todos os três, a etapa 2 não poderia ser escrita como regra fixa antes da etapa 1 rodar — porque o que é relevante na etapa 2 depende do que a etapa 1 encontrou.
O risco que ninguém fala: falha em cascata
O problema mais recorrente em produção não é o agente errar uma decisão isolada. É uma decisão errada na etapa 2 virar a premissa silenciosa da etapa 4, sem que nada sinalize a inconsistência ao longo do caminho.
Automação de uma etapa falha de forma visível: a saída está errada, alguém percebe, corrige. Agente multi-step pode falhar de forma invisível: cada etapa individual parece razoável, mas a cadeia inteira converge para uma conclusão que nenhuma etapa isolada teria produzido sozinha. Isso exige um tipo de governança que a maioria dos projetos não implementa: log de cada decisão intermediária, não apenas do resultado final — porque é o único jeito de auditar onde a cadeia divergiu do esperado.
Sem esse log, depurar um agente multi-step que errou é como investigar um acidente sem caixa-preta: só existe o resultado, não o caminho que levou até ele.
Quando multi-step é over-engineering
A maioria dos casos que chegam pedindo "agente de IA" não precisa de multi-step — precisa de automação de uma etapa bem escopada, e adicionar planejamento autônomo só introduz risco sem benefício. Sinais de que o caso não justifica multi-step:
- O processo tem no máximo duas variáveis de decisão, ambas conhecidas de antemão — nesse caso, uma condicional determinística resolve com muito menos risco.
- As exceções são raras e catalogáveis — se é possível listar os casos de exceção com antecedência, a automação de uma etapa com escalonamento para humano nos casos listados é mais barata e mais auditável.
- Ninguém vai revisar o log de decisões intermediárias — se a operação não tem processo para auditar o caminho, não só o resultado, multi-step está adicionando complexidade que ninguém vai efetivamente governar.
Nesses casos, o RPA ou a automação de uma etapa continuam sendo a escolha certa — multi-step existe para resolver um problema específico, não para parecer mais sofisticado.
Framework de decisão
Antes de escopar um agente como multi-step, responda:
- A etapa 2 pode ser escrita como regra fixa antes da etapa 1 rodar? Se sim, não é multi-step — é uma condicional com um LLM no meio.
- Quantas etapas intermediárias existem, e cada uma será logada individualmente? Sem log por etapa, não há como auditar onde uma cadeia divergiu.
- Quem revisa a cadeia de decisão quando o resultado final é questionado? Se a resposta é "ninguém, só olhamos o resultado", a governança ainda não está pronta para multi-step.
- O custo de uma decisão errada na etapa 2 é recuperável na etapa 4? Se um erro cedo é catastrófico e não há checkpoint de revisão no meio do caminho, o design precisa de um ponto de validação humana antes da etapa final.
Se as respostas apontam para necessidade real de decisão condicionada a contexto emergente — não apenas para "parecer mais avançado" — multi-step é a arquitetura certa. Caso contrário, a automação mais simples entrega o mesmo resultado com muito menos superfície de falha.
Sparsum na prática
Em um projeto de triagem de contratos para uma operação de serviços, o desenho inicial pedido pelo cliente era um agente multi-step completo, com cinco etapas de decisão. Depois de mapear o processo real, ficou claro que três das cinco etapas tinham exatamente duas saídas possíveis, sempre as mesmas — não precisavam de decisão emergente, precisavam de uma condicional. O desenho final usou multi-step genuíno em apenas duas etapas — exatamente onde o próximo passo dependia de uma cláusula que só era identificada durante a leitura do contrato — e automação determinística no restante. O resultado processava mais rápido, custava menos por execução e era auditável em cada etapa, porque as etapas fixas nunca precisaram de log de decisão: o comportamento já era conhecido.
Em outro caso, uma operação industrial usava RPA para conciliar dados de manutenção entre três sistemas que não conversavam nativamente. O RPA quebrava toda vez que um dos sistemas mudava um layout de tela. O agente que substituiu esse fluxo precisava genuinamente de multi-step: cada conciliação exigia decidir, com base no que os três sistemas retornavam, qual era a fonte de verdade para aquele registro específico — uma decisão que mudava caso a caso e não podia ser pré-codificada.
Em ambos os casos, o critério que decidiu a arquitetura não foi "quão sofisticado o agente deveria parecer" — foi onde a decisão emergente genuinamente existia, e onde era apenas uma condicional disfarçada.