Eu comecei a tratar observabilidade para agentes como um problema diferente no dia em que vi um sistema “saudável” falhar feio.
A latência estava dentro do esperado, não havia erro 5xx, as integrações principais tinham respondido, e a chamada ao modelo tinha terminado sem timeout. Mesmo assim, o agente entregou uma resposta ruim. Ele não “quebrou” no sentido clássico. Ele apenas escolheu a ferramenta errada, consultou uma fonte desatualizada e chegou a uma conclusão plausível, porém incorreta. Foi ali que eu percebi que meus dashboards ainda estavam muito bons para observar infraestrutura, mas já não bastavam para observar um sistema que decide em múltiplos passos. Essa sensação não é isolada: no relatório State of Agent Engineering, 57% dos respondentes disseram já ter agentes em produção, 32% apontaram qualidade como principal barreira, 20% citaram latência e 89% afirmaram já ter implementado observabilidade para agentes. Em outras palavras, esse problema já saiu da fase de experimentação e entrou na rotina operacional.
A partir daí, minha leitura mudou. Em aplicações tradicionais, eu continuo querendo saber se a requisição respondeu, quanto tempo levou, que dependência falhou e quanto recurso consumiu. Em agentes, tudo isso ainda importa, mas não é suficiente. O que começa a importar também é a trajetória da tarefa: quais ferramentas foram chamadas, em que ordem, com que resultados, com quanto contexto, e se essa sequência produziu uma saída realmente útil. A LangChain resume esse problema dizendo que a observabilidade de agentes precisa dar visibilidade passo a passo sobre execução, uso de ferramentas, dados recuperados e pontos onde o comportamento se desviou do caminho esperado, justamente porque agentes são não determinísticos e a mesma entrada pode levar a sequências diferentes de ações.
O ponto em que a observabilidade clássica fica curta
Em um sistema web tradicional, o caminho entre entrada e saída costuma ser relativamente estável. Mesmo quando a arquitetura é distribuída, existe uma ideia razoável de fluxo: gateway, serviço, banco, fila, cache, dependência externa. O trace, nesse contexto, me ajuda a reconstruir a execução. Se algo ficou lento, eu vejo onde. Se algo falhou, eu vejo onde. Se alguma dependência saturou, os sinais costumam apontar nessa direção.
Com agentes, esse mesmo trace ainda é útil, mas ele passa a contar apenas metade da história. A outra metade é a decisão. Um agente pode responder em oito segundos, sem timeout, com custo aceitável, e ainda assim ter seguido um caminho ruim: recuperar o documento errado, insistir em uma tool desnecessária, ignorar um trecho relevante do contexto ou se perder numa sequência de passos redundantes. Foi por isso que comecei a separar duas perguntas que antes eu misturava: “o sistema executou bem?” e “o sistema decidiu bem?”. Em software tradicional, essas duas perguntas se sobrepõem com mais frequência. Em agentes, elas se separam com facilidade. A LangChain chama atenção justamente para isso ao argumentar que, em agentes, observabilidade e avaliação precisam caminhar juntas, porque comportamento ruim pode emergir ao longo de múltiplos turnos mesmo quando cada chamada isolada parece normal.
Um cenário simulado que mostra o problema
Imagine um agente interno de suporte ao desenvolvedor. Ele responde perguntas sobre deploy, rollback, pipelines, RFCs e procedimentos operacionais. Um engenheiro pergunta: “Como faço rollback do serviço de pagamentos em produção?”
O painel tradicional mostra algo muito tranquilizador. A requisição terminou com sucesso. A latência foi de 6,8 segundos. A CPU do serviço está normal. Não houve erro na ferramenta de busca. A chamada ao modelo voltou com status saudável. Se eu parar aqui, tudo parece ok.
Agora vamos abrir o que aconteceu de verdade. O agente interpretou corretamente a intenção, escolheu a ferramenta de busca adequada e recuperou três documentos. Até aí, nada errado. O problema foi o peso que ele deu ao material recuperado. Em vez de priorizar a RFC mais recente, ele sintetizou a resposta a partir de um runbook antigo que ainda aparecia bem ranqueado. O resultado final foi uma instrução parcialmente desatualizada. A execução foi tecnicamente bem-sucedida, mas a decisão foi ruim.
Esse cenário me interessa porque ele desmonta uma ilusão comum: a de que observabilidade tradicional falha apenas quando o sistema “fica lento” ou “retorna erro”. Em agentes, um sistema pode parecer saudável do ponto de vista de execução e continuar errado do ponto de vista de decisão. É esse espaço entre uma coisa e outra que eu preciso tornar observável.
O que eu passei a querer enxergar
Depois de alguns casos como esse, eu parei de olhar para o agente como “uma chamada de LLM com ferramentas” e passei a tratá-lo como um sistema de decisão instrumentável. Isso me levou a querer ver cinco camadas de sinal, ainda que elas nem sempre apareçam organizadas dessa forma em uma mesma ferramenta.
A primeira continua sendo a mais tradicional: latência, taxa de erro, saturação, uso de tokens, custo por tarefa e disponibilidade das dependências. Sem isso, eu sequer sei se o sistema está de pé.
A segunda camada é a trajetória da tarefa. Eu quero entender quantos passos houve, em que ordem, onde a execução se alongou, onde ela repetiu comportamento e se ela convergiu de forma razoável ou ficou circulando em torno do problema.
A terceira camada é o uso de ferramentas. Aqui o detalhe importa: não basta saber que uma tool foi chamada. Eu quero saber se ela foi necessária, se foi a escolha correta, se apareceu cedo ou tarde demais no fluxo e se alterou de fato a resposta final.
A quarta camada é o contexto. Quanto contexto ativo a tarefa carregou? Quais fontes foram recuperadas? O agente precisou resumir ou comprimir a sessão? Ele começou a perder foco porque a janela cresceu demais? A Anthropic descreve contexto como um recurso finito com retornos decrescentes e fala explicitamente em “attention budget”: cada novo token compete por uma parcela dessa capacidade limitada, o que torna a curadoria do contexto parte central da performance do agente.
A quinta camada é qualidade. Essa é a mais desconfortável porque não se deixa reduzir apenas a métricas técnicas. Aqui entram sinais como aderência à política, correção da resposta, necessidade de retrabalho humano, escalonamento manual, reabertura de tickets e até feedback explícito do usuário. A LangChain argumenta que observabilidade por si só não basta e que ela precisa alimentar avaliação, justamente porque ver a trajetória não é o mesmo que julgar se a trajetória foi boa.
O dado que mostra por que tools mudam o jogo
Se existe um número que me convence rapidamente de que observabilidade para agentes não pode ser apenas APM com outro nome, é o crescimento do uso de tools. No State of AI 2024 da LangChain, a média de traces com tool calls subiu de 0,5% em 2023 para 21,9% em 2024. Esse salto é importante porque mostra uma mudança de natureza: os modelos deixaram de ser observados apenas como geradores de texto e passaram a se comportar muito mais como coordenadores de ações e consultas externas. Quando isso acontece, olhar apenas para a inferência final é parecido com observar um sistema distribuído olhando só para o gateway.
Esse problema fica ainda mais concreto quando eu penso em um agente corporativo cercado de integrações. Não é difícil imaginar um ambiente em que ele precise conversar com tickets, documentação, repositório, observabilidade, banco de leitura e APIs internas. A tentação inicial costuma ser “deixar tudo disponível” o tempo inteiro. Só que esse desenho cobra um preço. A Anthropic publicou um caso em que apenas carregar as definições de mais de 50 ferramentas via MCP consumia cerca de 72 mil tokens upfront, chegando a algo em torno de 77 mil tokens antes de qualquer trabalho começar. Com descoberta de ferramentas sob demanda, o contexto inicial caiu para cerca de 8,7 mil tokens, preservando 95% da janela. Esses números são valiosos porque mostram que escolha de ferramenta e escolha de contexto já não são só detalhes de implementação; são decisões de arquitetura com impacto direto em custo, latência e foco.
Outro cenário simulado: agente de investigação de incidentes
Agora imagine um agente de investigação de incidentes. O objetivo dele é simples: receber um alerta, consultar logs, métricas, traces, tickets recentes e runbooks, e devolver uma hipótese inicial com um plano de ação.
Na primeira versão da arquitetura, eu instrumentei apenas o básico: tempo total da execução, latência das integrações, custo da chamada ao modelo e taxa de erro. Em um incidente real, o agente respondeu que a causa mais provável era degradação no serviço de autenticação. A execução parecia saudável, mas a hipótese estava errada. O problema real estava em uma fila de eventos do checkout.
Na segunda versão, eu passei a observar também o raciocínio operacional do fluxo. Não no sentido de “ler pensamento”, mas no sentido bem pragmático de rastrear que evidências o agente consultou, em que ordem ele consultou, quais hipóteses descartou, quanto contexto consumiu para chegar à hipótese final e se a hipótese coincidiu, depois, com a causa-raiz confirmada. Essa instrumentação mudou completamente a minha capacidade de diagnosticar o erro. Descobri que o agente tinha dado peso excessivo a um padrão antigo de log, ignorado a métrica correta do pipeline de eventos e produzido uma conclusão coerente com a evidência errada. O trace técnico me dizia que o sistema executou; essa segunda camada me dizia por que a decisão tinha sido ruim.
É por isso que eu gosto da direção que o OpenTelemetry vem tomando. Em 2025, o projeto publicou um texto explicando a evolução das convenções semânticas para observabilidade de sistemas agentic, com entidades como tasks, actions, agents, artifacts e memory. Ao mesmo tempo, as convenções de GenAI para spans, métricas e eventos já estruturam elementos como chamadas de inferência, tool requests, tokens e metadados do modelo. O ecossistema inteiro está, aos poucos, aceitando que agentes exigem um vocabulário observável mais rico do que o de chamadas HTTP e spans de banco.
Onde avaliação entra de verdade
Durante algum tempo eu tratei avaliação como um tópico separado de observabilidade. Hoje, eu acho essa separação artificial. Um trace perfeito pode descrever com precisão uma execução ruim. E uma execução ruim pode ser exatamente o tipo de coisa que só aparece quando eu confronto telemetria com algum sinal externo de qualidade.
Se um agente respondeu dentro do SLA, mas foi corrigido manualmente em metade dos casos, isso é um problema operacional. Se um agente consultou sempre as mesmas tools, mas produziu respostas que geraram reabertura de tickets, isso é um problema operacional. Se uma mudança de prompt ou de retrieval reduziu latência, mas piorou aderência à política, isso é um problema operacional. Por isso eu gosto da formulação da LangChain: observabilidade me ajuda a entender o que aconteceu; avaliação me ajuda a dizer se o que aconteceu foi bom. Em agentes, eu preciso das duas.
O que eu colocaria num dashboard de agente em produção
Se eu estivesse montando hoje um dashboard mínimo para um agente importante, eu não abriria mão da visão tradicional de latência, erro, tokens e custo. Mas isso seria apenas a fundação. Por cima dela, eu colocaria uma camada de trajetória, para enxergar como as tarefas se desenrolam ao longo dos passos; uma camada de ferramentas, para entender o padrão de tool calls e seus custos; uma camada de contexto, para observar crescimento de sessão, necessidade de compaction e saturação de janela; e uma camada de qualidade, para ligar o comportamento interno do agente aos efeitos externos percebidos pelo usuário.
O ponto não é estético. É epistemológico. Sem essas camadas, eu consigo dizer que o sistema executou. Não consigo dizer com a mesma segurança se ele executou bem.
O que eu realmente quero defender
Se eu tivesse que condensar tudo em uma frase, eu diria isto: em aplicações tradicionais, eu observo o que o software executou; em agentes, eu também preciso observar como ele decidiu.
Essa diferença parece pequena, mas muda o tipo de telemetria que vale a pena coletar, o tipo de ferramenta que faz sentido usar e até a forma como eu defino “saúde” em produção. Logs, métricas e traces tradicionais continuam indispensáveis. Mas, sozinhos, eles descrevem apenas a metade técnica do problema. A outra metade — trajetória, contexto, ferramentas, custo de decisão e qualidade da saída — é a parte que transforma um agente de demo em um sistema realmente operável.
