Por que agentes de IA funcionam na demonstração e falham em produção

Uma demonstração prova que um caminho pode funcionar. Um serviço em produção também precisa lidar com dados incompletos, dependências lentas, permissões que mudam, novas tentativas e usuários que fecham o navegador no meio da tarefa.

A diferença costuma estar no software e na operação ao redor do modelo. Melhorar as instruções não torna uma integração pouco confiável transacional nem renova uma credencial expirada.

A demonstração esconde premissas

Imagine um agente que atualiza um cliente no CRM após analisar uma conversa de suporte. Na demonstração, ele tem um cliente conhecido, uma transcrição clara, credenciais válidas e um desenvolvedor acompanhando cada etapa.

Em produção, dois clientes podem ter o mesmo nome. A transcrição pode conter um identificador errado. O CRM pode aceitar a alteração e não devolver uma resposta. Outra pessoa pode modificar o registro enquanto o agente raciocina.

Antes do lançamento, transforme cada premissa em uma condição verificável ou em uma falha que o sistema consiga tratar.

Cinco falhas que vale a pena testar

Falha	Consequência	Resposta de implementação
Identidade ambígua	Outro registro é alterado	Exigir identificador verificado ou pedir esclarecimento
Resultado incerto de uma ferramenta	Uma ação concluída é repetida	Identificar operações e consultar seu status
Perda de estado	A tarefa recomeça	Persistir o progresso e definir como retomar
Permissões excessivas	Outra conta é acessada	Aplicar o escopo na ferramenta ou serviço
Investigação sem fim	O orçamento é consumido sem conclusão	Limitar a execução e retornar um status incompleto

Essas respostas exigem comportamento da aplicação, não apenas instruções para o agente tomar cuidado.

Quando uma atualização não responde

Se update_customer exceder o tempo de espera, a solicitação pode não ter chegado, ter falhado ou ter sido concluída sem que a resposta retornasse.

Tentar novamente sem verificar trata os três casos como se fossem iguais. Associe a tarefa a um identificador persistente de operação. Se o sistema oferece idempotência, reutilize-o. Caso contrário, desenhe uma verificação ou conciliação e não afirme que a ação terminou até confirmar seu estado.

Considere também alterações simultâneas. Uma atualização baseada em um registro antigo pode sobrescrever informações recentes. Dependendo do sistema, serão necessários controles de versão ou escritas condicionais. O agente deve receber um conflito compreensível e saber o que pode fazer depois.

Avalie o trabalho concluído

Uma resposta dizendo “atualizado com sucesso” não basta. Verifique o estado real da aplicação e se o registro correto mudou. Em tarefas de leitura, confira se a resposta é sustentada pelas evidências recuperadas.

Crie testes com dados que você tenha permissão para usar. Inclua solicitações normais, registros ausentes, instruções conflitantes, acesso revogado, indisponibilidade de serviço, uma solicitação repetida e uma tarefa que deve ser recusada.

Repita alguns casos porque o comportamento pode variar. Meça separadamente sucesso, efeitos incorretos, encaminhamento, duração e custo. Uma média alta não compensa uma violação de permissões.

O guia de avaliação de agentes da Anthropic distingue execução e resultados. O registro explica o caminho; o estado final mostra o que aconteceu.

Use o piloto para ensaiar a operação

Cada tarefa com falha precisa de um responsável. Alguém deve revisar exceções, decidir o que é aceitável e aprovar mudanças. Sem essas responsabilidades, o projeto pode ficar parado mesmo que o modelo funcione.

Comece com poucas ferramentas e usuários. Quando útil, opere primeiro em modo de recomendação. Registre versões do modelo e das ferramentas para investigar regressões. Preserve apenas os registros necessários, com controles adequados de acesso e retenção.

Serviços gerenciados como o Amazon Bedrock AgentCore podem fornecer infraestrutura, mas sua equipe continua definindo tarefa, permissões e critérios de aceitação.

Defina critérios próprios de lançamento

Não copie uma meta arbitrária de “95% de precisão”. Defina o que constitui um erro, quanto custa e quais falhas são inaceitáveis. Um rascunho de resumo e uma alteração de conta exigem decisões diferentes.

Antes de ampliar o acesso, demonstre recuperação das falhas testadas, rastreabilidade das ações, limites de execução e encaminhamento de tarefas não resolvidas. Inclua o custo da revisão no orçamento.

Confira se um fluxo fixo atende ao processo e use nosso modelo de custos. A Timewise Labs pode ajudar a levar o caso de uso à produção.

Adaptado do artigo da Dream Hatch Labs.