Como agentes de IA planejam tarefas em várias etapas e onde falham

Como agentes de IA planejam tarefas? Eles transformam um pedido em uma lista curta de passos pretendidos, escolhem cada ação dentro de um ciclo e revisam a lista conforme os resultados das ferramentas voltam. Na prática, o plano costuma ser uma nota de trabalho que o modelo reescreve ao longo do caminho, e não um documento fixo combinado de antemão, e é por isso que ele pode desviar. Tornar o plano visível, verificável e limitado é o que permite a uma pessoa supervisioná-lo em vez de simplesmente confiar nele.

Principais pontos

• O plano de um agente é um roteiro vivo que muda a cada resultado de ferramenta, não um contrato assinado no início.
• Os planos falham de poucas maneiras repetíveis: desvio de objetivo, premissas não verificadas, etapas puladas, roteiro desatualizado, perda de contexto e conclusão falsa.
• As falhas passam despercebidas porque a mensagem final soa fluente mesmo quando o meio do trabalho deu errado.
• A solução é estrutural: plano salvo, status por etapa, premissas registradas, pontos de aprovação e um relatório final que liga cada etapa a uma evidência.
• Quanto mais liberdade o agente tem para reescrever o próprio plano, mais inspeção ele exige.

O que significa um agente de IA planejar?

Um agente não planeja como um gerente de projetos, com um documento aprovado antes de o trabalho começar. O modelo de linguagem lê o pedido, as instruções que recebeu e o contexto fornecido pelo sistema ao redor, e então produz o próximo movimento. Muitas vezes isso inclui um pequeno roteiro com os passos pretendidos. Quando uma ferramenta devolve algo, o modelo lê a nova situação e decide de novo. Esse ciclo é explicado com mais profundidade em Como funciona o loop de um agente de IA: como ele decide o próximo passo.

Na prática, o plano assume uma de três formas:

• Implícito: o plano existe apenas no raciocínio do modelo para o movimento atual, e ninguém consegue inspecioná-lo depois.
• Nota escrita: o agente mantém um roteiro no contexto de trabalho ou em um arquivo e o atualiza conforme avança.
• Estruturado: uma lista de passos com um status para cada um, guardada e verificada pelo sistema ao redor do modelo, não apenas pelo próprio modelo.

Quanto mais abaixo nessa lista, mais fácil é supervisionar o trabalho. A orientação da Anthropic sobre como construir agentes eficazes separa fluxos de trabalho, em que o código define o caminho, de agentes, em que o modelo conduz o próprio processo. O risco de planejamento cresce com o segundo tipo, porque o caminho em si é uma decisão que o modelo continua tomando.

Como um agente divide um pedido em etapas?

A sequência abaixo é o que um agente bem comportado faz diante de um pedido que exige mais de uma ação. Nem todo agente cumpre todas as etapas de forma explícita, e é nessa diferença que os problemas começam.

• Passo um, reformular o objetivo: o agente descreve com as próprias palavras o que entende do pedido e como seria um resultado concluído.
• Passo dois, descobrir o que falta: ele identifica os fatos de que precisa, como um cadastro de cliente, um intervalo de datas ou uma política, e decide onde buscá-los.
• Passo três, decompor: ele divide o objetivo em ações menores e anota quais dependem de outras.
• Passo quatro, associar ferramentas às etapas: para cada ação ele escolhe uma ferramenta, como uma busca, uma leitura de banco de dados ou um rascunho em um sistema de e-mail. O que é tool calling em IA? Explicação simples para empresas mostra como essa escolha funciona.
• Passo cinco, agir e ler: ele executa a primeira ação e lê o resultado com atenção, inclusive os erros.
• Passo seis, revisar: ele adiciona, remove ou reordena etapas com base no que aprendeu.
• Passo sete, conferir a linha de chegada: ele compara o resultado com o objetivo do passo um e então para ou continua.

Os passos um e sete são os que mais aparecem comprimidos ou pulados. Sem um objetivo declarado e uma linha de chegada declarada, o agente não tem com o que comparar o próprio trabalho, e a pessoa que revisa também não.

Onde os planos de várias etapas desviam?

O desvio é gradual. Nenhum movimento isolado parece errado, mas a soma termina em um lugar para o qual o pedido não apontava. Estes são os pontos em que isso mais acontece.

• Desvio de objetivo: o agente reinterpreta um pedido difícil como um vizinho mais fácil e conclui bem o mais fácil.
• Desvio de premissa: um palpite feito cedo, como qual cliente ou qual período era o pretendido, passa a ser tratado como fato nas etapas seguintes.
• Escopo que cresce: o agente acrescenta extras úteis que ninguém pediu, como avisar um terceiro ou atualizar um segundo registro.
• Etapas puladas: um passo é descartado porque parecia redundante, ou porque uma ferramenta falhou e o agente contornou o problema sem avisar.
• Plano desatualizado: chega um resultado inesperado, mas o agente continua seguindo o roteiro escrito antes da surpresa.
• Perda de contexto: em execuções longas, decisões e restrições iniciais saem do que o modelo consegue enxergar. Como compactar contexto sem perder decisões importantes mostra como reduzir esse risco.
• Conclusão falsa: o agente declara o trabalho pronto com evidência parcial, como um rascunho salvo e nunca enviado, ou um registro alterado e nunca confirmado.

Nenhum desses problemas exige um modelo fraco. Eles decorrem de um sistema que toma decisões em sequência, com informação incompleta e sem uma checagem externa.

Por que as falhas de plano passam despercebidas?

O principal motivo é que a linguagem fluente esconde o processo. Uma mensagem final como “Revisei os registros e atualizei o cronograma” soa igual quando todas as etapas rodaram e quando metade foi pulada. Quem vê apenas o fim do trabalho não consegue notar a diferença.

Três outros fatores pioram a situação. Erros de ferramenta às vezes são absorvidos: o agente tenta de novo, recebe outro resultado e segue em frente sem registrar que algo deu errado. Novas tentativas podem repetir efeitos colaterais, então uma etapa que parecia ter falhado pode ter acontecido em parte. E, quanto mais longa a execução, menos gente lê o meio dela.

É o mesmo problema que a observabilidade resolve em software comum. O guia introdutório de observabilidade do OpenTelemetry descreve os traces como o caminho registrado de uma requisição por um sistema. Uma execução de agente precisa do equivalente: um registro de qual etapa foi tentada, com qual ferramenta e o que voltou, para que uma pessoa possa seguir o caminho depois.

Como tornar o plano de um agente visível?

Visibilidade é uma decisão de projeto do harness, o sistema ao redor do modelo, e não um favor que o modelo faz por você. Para uma visão geral dessa camada, veja O que é harness de IA? Um guia prático para negócios. A lista abaixo funciona para a maioria dos agentes de negócio.

• Salve o plano antes da primeira ação, em um lugar estável fora da memória de trabalho do modelo.
• Dê a cada etapa um status: não iniciada, em andamento, concluída, bloqueada ou pulada, com um motivo para as duas últimas.
• Mantenha as premissas em uma lista própria, identificadas como premissas, para que não passem por fatos.
• Vincule cada chamada de ferramenta à etapa que ela atende, para que uma linha de log possa ser rastreada até o plano.
• Registre cada mudança no plano com um motivo curto, como “cadastro do fornecedor ausente, etapa de consulta adicionada”.
• Coloque pontos de aprovação antes das etapas que enviam mensagens, gastam dinheiro, apagam dados ou envolvem terceiros.
• Grave um checkpoint depois de cada etapa relevante, para que um trabalho interrompido possa ser retomado. Veja Checkpoints de agentes de IA: como retomar o trabalho.
• Exija que o relatório final liste cada etapa planejada com a evidência de que ela aconteceu, e não apenas um resumo.

O último item se conecta à ideia de linha de chegada. Definição de pronto para agentes de IA: exija evidência defende que o agente comprove a conclusão com artefatos que uma pessoa possa conferir, e o plano é a estrutura natural para apresentar essa prova.

É preciso manter um equilíbrio. Um plano rígido demais impede o agente de se adaptar quando a realidade difere do esperado, que é justamente o motivo de usar um agente. Um plano frouxo demais não deixa nada para inspecionar. Um meio-termo viável é ter objetivo fixo, linha de chegada fixa e pontos de aprovação fixos, com as etapas intermediárias livres para mudar, desde que cada mudança seja registrada.

Um cenário ilustrativo: o pedido atrasado de um fornecedor

Este cenário é ilustrativo e não descreve um projeto real.

Um gerente de operações pede a um agente: “Descubra por que o pedido do nosso fornecedor de embalagens está atrasado e avise o armazém sobre o que esperar.” O agente escreve este plano: consultar o pedido, ler as mensagens recentes do fornecedor, verificar o status da transportadora e redigir um aviso para o armazém.

A consulta devolve dois pedidos em aberto do mesmo fornecedor. O agente presume que se trata do maior e segue em frente. Isso é desvio de premissa. Em um sistema visível, essa suposição vai para a lista de premissas, e o relatório ao gerente diz: “Presumi que era o pedido maior; por favor, confirme.”

Em seguida, a consulta à transportadora falha por um erro temporário da ferramenta. O agente pula a etapa e escreve o aviso ao armazém usando apenas a mensagem do fornecedor. Em um sistema com status por etapa, a etapa da transportadora aparece como bloqueada, com o motivo, e o rascunho é marcado como incompleto. O aviso espera em um ponto de aprovação em vez de ser enviado.

O gerente revisa o plano, vê a premissa e a etapa bloqueada, corrige a escolha do pedido e pede uma nova tentativa. O agente retoma a partir do último checkpoint, conclui a etapa da transportadora e entrega um relatório final que lista cada etapa com sua evidência. O plano visível não tornou o agente mais inteligente. Ele fez dois erros silenciosos ficarem fáceis de ver antes de chegarem ao armazém.

Como a Be Human trata o planejamento em agentes gerenciados?

A Be Human projeta o harness para que o plano de um agente seja um objeto armazenado, e não um pensamento privado. Um primeiro projeto define um papel, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. Esse critério vira a linha de chegada contra a qual cada plano é conferido. Planos, status das etapas, premissas e chamadas de ferramenta são registrados, e os pontos de aprovação ficam antes das ações com efeito externo. Na operação gerenciada, a equipe revisa esses registros de forma recorrente, procura padrões de desvio, como etapas puladas com frequência, e propõe mudanças controladas em instruções, ferramentas ou permissões, em vez de alterar o comportamento de improviso.

Perguntas frequentes

Os agentes de IA planejam tudo antes de agir ou conforme avançam? A maioria faz as duas coisas. Eles costumam escrever um roteiro inicial e depois revisá-lo a cada resultado de ferramenta. Isso ajuda em trabalhos reais e bagunçados, mas significa que o primeiro plano é uma hipótese de partida, não um compromisso.

Posso obrigar um agente a seguir um plano fixo? Pode, movendo o caminho para o código, de modo que o modelo preencha apenas cada passo individual. Isso é um fluxo determinístico, e é a escolha certa quando as etapas nunca variam. Agente de IA ou fluxo determinístico? Como decidir ajuda a definir qual opção serve a cada tarefa.

Toda tarefa precisa de um plano escrito? Não necessariamente. Uma consulta de um único passo não precisa de registro de plano, e acrescentá-lo é só custo extra. Os planos se justificam quando a tarefa tem vários passos, usa mais de uma ferramenta, leva muito tempo ou termina em uma ação difícil de desfazer.

O que devo revisar primeiro quando o plano de um agente falha? Comece pela lista de premissas e pelos status das etapas, porque eles mostram onde o agente chutou ou pulou algo. Depois compare o relatório final com a linha de chegada definida no início. Se a falha veio de um objetivo errado ou de um limite ausente, mude as instruções ou os pontos de aprovação, e não apenas a redação do prompt.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.