O log de um microsserviço tradicional registra o que aconteceu. O log de um agente em produção registra o que o modelo disse que fez, o que nem sempre corresponde ao que de fato ocorreu. Pra mim, a diferença parece sutil até o momento em que um agente retorna uma resposta plausível, factualmente errada, ou invoca uma ferramenta com parâmetros derivados de uma alucinação intermediária que nunca apareceu no output. O logging convencional captura a requisição e a resposta, e entre esses dois pontos existe um processo de raciocínio multi-step que permanece opaco a menos que a instrumentação tenha sido desenhada pra capturá-lo.
Na minha análise, a observabilidade em sistemas agênticos opera sobre um objeto diferente da observabilidade em sistemas determinísticos. Em um serviço convencional, o trace reconstitui uma sequência de chamadas entre componentes com entrada, saída, latência e status. Em um agente, o trace precisa reconstituir uma sequência de decisões, em que cada passo envolve a interpretação de contexto pelo modelo, a escolha de uma ação possível e a incorporação do resultado dessa ação ao contexto pra o passo seguinte. O que torna o debugging difícil é que a lógica de decisão em cada passo não está codificada em nenhum lugar, ela emerge da interação entre o prompt, o estado do contexto naquele momento e o comportamento estocástico do modelo. Instrumentar apenas entradas e saídas de cada chamada ao LLM captura a superfície do processo, mas não o mecanismo que produziu cada decisão.
A unidade mínima de observabilidade pra um agente em produção é o span de raciocínio completo: o prompt enviado ao modelo (com system prompt e histórico de contexto), a resposta do modelo com eventuais tool calls e seus argumentos, o resultado da execução, e a decisão sobre o próximo passo. O OpenTelemetry publicou convenções semânticas experimentais pra agentes GenAI que formalizam essa estrutura, com operações como invoke_agent e atributos pra gen_ai.agent.name, gen_ai.request.model e tokens consumidos por span. A padronização importa porque permite que ferramentas diferentes interpretem traces agênticos de forma consistente, mas só tem valor se a instrumentação capturar o que precisa ser capturado, e a maioria das implementações em produção ainda registra menos do que o necessário pra reconstituir uma falha.
O que precisa ser capturado vai além do que plataformas como Langfuse e LangSmith oferecem por padrão. Ambas capturam traces estruturados com prompts e respostas associados a tool calls, com latência e custo por token, e fazem isso bem. Pra mim, o problema está no que fica de fora: o estado do contexto acumulado no momento de cada decisão. Um agente que falha no passo quatro de um chain de seis passos frequentemente falha por causa de algo que aconteceu no passo dois, uma extração parcial ou um resultado de ferramenta interpretado de forma diferente da esperada. O trace que mostra apenas o prompt e a resposta de cada passo permite identificar onde a saída divergiu, mas não por que divergiu. A instrumentação que resolve esse problema registra o contexto completo enviado ao modelo em cada chamada, com custo de armazenamento não trivial e decisões explícitas sobre retenção e amostragem.
A amostragem é onde a observabilidade agêntica encontra seu primeiro trade-off sério. Registrar o trace completo de cada invocação em produção gera volume que escala linearmente com throughput e tamanho de contexto: um agente com 10 mil requisições diárias e contextos de 8 mil tokens, em chains de 4 passos, produz cerca de 320 milhões de tokens de observabilidade por dia. Na minha avaliação, a decisão prática é amostrar, registrando traces completos pra uma fração das requisições e apenas metadados pra o restante. Como a falha pode não estar na fração amostrada, a mitigação mais eficaz é a amostragem condicional: trace completo sempre que a saída falhar na validação estrutural ou a latência exceder um limiar, e amostragem aleatória pra o resto.
O segundo trade-off está na fronteira entre observabilidade e privacidade. Registrar prompts e respostas completas de agentes que processam dados de usuários significa armazenar esses dados num sistema de observabilidade com políticas de acesso e retenção que podem divergir do principal. Em contextos regulados pela LGPD ou pelo GDPR, o trace pode conter dados pessoais que exigem tratamento específico, e a decisão sobre o que registrar deixa de ser puramente técnica. A solução que equilibra os dois lados é registrar o trace estruturado com metadados completos junto de hash do conteúdo sensível pra correlação, deixando o conteúdo completo apenas em modo de diagnóstico sob demanda, com TTL curto e acesso restrito.
O que a observabilidade agêntica revela quando implementada com profundidade é um padrão específico desse tipo de sistema: a degradação de raciocínio sob pressão de contexto. À medida que o contexto cresce ao longo de um chain multi-step, a qualidade das decisões do modelo tende a se degradar de forma não linear, com saltos abruptos de precisão quando o contexto ultrapassa limiares que variam por modelo e por tipo de tarefa. Essa degradação não se manifesta como erro explícito, ela se manifesta como mudança sutil na saída, detectável apenas por avaliação contínua operando sobre os traces. Pra mim, o sistema de observabilidade que funciona em produção agêntica é o que trata a qualidade da saída como um espectro contínuo, mas não como um boolean, permitindo correlacionar variações nesse espectro com variáveis operacionais como tamanho do contexto acumulado, modelo utilizado e posição da chamada no chain.