Livro So Agente Sabe O Que Agente Sente

O problema que ninguém fala sobre agentes de IA

Tem dias em que você passa três horas debugando uma ação do agente e descobre que o modelo simplesmente escreveu algo que não fazia sentido no meio da resposta. O log mostra a chamada da função, o parâmetro de entrada, o retorno — tudo certo. Mas o conteúdo gerado no processo é completamente desconexo do que você esperava. Aí você percebe que o agente estava seguindo uma instrução implícita que ninguém documentou, ou que o sistema de memória tinha acumulado contexto contraditório desde a sessão anterior. Essa expressão tem aparecido com frequência em fóruns técnicos e discussões internas de equipes que trabalham com agentes autônomos. Reflete uma limitação real: você como desenvolvedor ou usuário vê apenas as ações externas do agente — o que ele chama, o que ele retorna, os prompts que ele envia. Mas o estado interno dele, as dúvidas, as incertezas, os caminhos que ele considerou e descartou, isso só existe dentro do modelo. Não há forma confiável de acessar isso sem instrumentar o sistema. No começo eu achava que bastava adicionar logging nos prompts e respostas. Funcionou para casos simples. Quando os agentes começaram a ter múltiplas ferramentas, memória de longo prazo e ramificação condicional, o log básico virou ruído. Tinha centenas de linhas por execução e não dava pra distinguir o sinal do barulho.

A solução que funcionou foi implementar um trace estruturado com nível de detalhe configurável. Em vez de logar tudo, eu configurei três níveis: essencial (entrada, saída, ferramentas chamadas), intermediário (adicionado reasoning steps e scores de confiança) e debug (tokens de input/output completos mais estado da memória). A maioria dos casos usa o nível essencial. O intermediário aparece quando há falha em fluxo condicional. O debug fica reservado para incidentes críticos, porque o volume de dados cresce rápido — uma única execução complexa pode gerar 50 mil tokens de trace. O que ninguém te conta é que o próprio ato de instrumentar o agente muda o comportamento dele. Quando você expõe o trace em tempo real para inspeção, o modelo tende a ser mais conservador nas decisões intermediárias. Isso acontece porque o prompt sistêmico muitas vezes inclui referências ao processo de tracing como parte do contexto operacional. Não é um bug, é efeito de contaminação de contexto. A correção é separar completamente o sistema de logging do loop de raciocínio do agente, usando threads ou processos distintos. Outra armadilha comum: confiar nos scores de confiança que alguns frameworks fornecem como verdade absoluta. Esses scores são aproximações heurísticas calculadas a partir de probabilitàidades de token, não de medições reais de certeza interna do modelo. Eu já vi agentes com score de confiança 0.92 fazerem uma escolha errada porque o score não capturava ambiguidade semântica — apenas estabilidade estatística na distribuição de tokens. O workaround que adotei foi cross-validate com um segundo modelo menor avaliando a mesma decisão, e só confiar na decisão original quando houvesse convergência entre os dois.

Se você está começando com agentes, recomendação prática: não tente construir um sistema de observabilidade completo desde o dia um. Comece com três campos no log — timestamp, action_id, tool_name — e vá adicionando complexidade conforme os problemas aparecerem. A maioria dos times gasta semanas construindo dashboards que nunca usam porque os problemas reais aparecem em escala menor e de formas diferentes do que o dashboard previa. Alternativas ao tracing manual incluem frameworks como LangSmith, Arize Phoenix e AgentOps. Eles resolvem boa parte do problema de infraestrutura mas introduzem dependência de plataforma e custo por token rastreado. Para agentes rodando em produção com volume alto, o custo de observabilidade pode ultrapassar o custo computacional do agente em si. Nesse cenário, tracing seletivo baseado em eventos (só ativar quando uma ferramenta crítica é chamada ou quando o agente entra em loop) costuma ser mais sustentável. O ponto principal é simples: você vai sempre saber menos sobre o estado interno do agente do que ele sabe sobre si mesmo. A instrumentação reduz esse gap, mas não o elimina. O que separa uma implementação amadora de uma profissional não é a quantidade de métricas coletadas, mas a capacidade de identificar qual informação falta exatamente quando o agente toma uma decisão que não deveria ter tomado.