Um agente altera vários arquivos, chama ferramentas, conversa com o modelo e entrega uma mudança. Se o resultado surpreende, por onde começar a investigação? Muitas equipes conseguem ver o resultado final e o consumo agregado, mas têm menos visibilidade sobre o caminho percorrido em cada sessão.

O anúncio do GitHub, publicado em 22 de setembro, adiciona suporte a OpenTelemetry no aplicativo GitHub Copilot. Administradores podem configurar a exportação em managed-settings.json e enviar os dados a ferramentas de observabilidade compatíveis. É uma mudança menos vistosa que um novo modelo no seletor, mas potencialmente mais útil para quem opera agentes em escala.

O que passa a ser visível

A documentação técnica do GitHub descreve três classes de dados: traces, métricas e eventos. Um trace conecta os passos de uma sessão, como uma chamada ao modelo, a leitura de um arquivo e uma nova chamada ao modelo. As métricas incluem tokens de entrada e saída. Eventos podem registrar se uma edição sugerida foi aceita ou rejeitada.

Isso ajuda a responder perguntas concretas: um agente gastou tempo demais procurando contexto? Repetiu chamadas à mesma ferramenta? Uma tarefa curta consumiu tokens desproporcionais? O anúncio não promete um painel que responda tudo automaticamente. Ele oferece a matéria-prima para investigar, cruzar dados e criar indicadores próprios.

Há um limite importante no escopo anunciado: a configuração é para o aplicativo Copilot por meio de ajustes gerenciados pela empresa. Não convém assumir, sem conferir a documentação de cada cliente, que todo ambiente onde o Copilot aparece emitirá exatamente os mesmos dados.

Observabilidade não é avaliação de qualidade

Um trace mostra o percurso, não prova que o código entregue está correto. Uma sessão com poucas chamadas pode ser eficiente ou apenas ter pulado uma verificação necessária. Da mesma forma, mais tokens podem indicar desperdício ou uma tarefa legitimamente difícil.

A leitura mais útil combina telemetria com resultados: tempo até uma mudança revisável, testes executados, retrabalho após revisão e falhas em produção. Para equipes com muitos agentes, essa correlação pode revelar onde o custo cresce sem melhorar a entrega. É uma hipótese operacional a testar, não uma promessa de ROI contida no anúncio.

Também há uma decisão de privacidade. O GitHub diz que prompts, respostas e argumentos de ferramentas ficam fora da exportação por padrão. A captura desse conteúdo pode ser habilitada, mas pode incluir código e dados sensíveis. Antes de ligar uma coleta mais ampla, vale definir quem recebe os rastros, por quanto tempo são retidos e qual problema a coleta precisa resolver.

A novidade coloca a observabilidade de agentes mais perto das práticas já familiares de operação de software. O próximo passo não é medir tudo. É escolher duas ou três perguntas que hoje ninguém consegue responder com confiança e verificar se esses rastros realmente ajudam.