Jeff Champagne, Field CTO na Cribl – Série de Entrevistas

Jeff Champagne, Field CTO na Cribl, traz experiência profunda em observabilidade, dados empresariais, estratégia de produto e arquitetura técnica. Antes de se juntar à Cribl, ele atuou como Diretor de Gerenciamento de Produto na Databricks e passou mais de sete anos na Splunk em funções de produto, arquitetura e engenharia de sistemas globais. Seu histórico também inclui liderança em arquitetura de sistemas na BNY ConvergEx, trabalho de engenharia sênior na Premier Technology Solutions e liderança de engenharia inicial na Assist-2-Sell, o que lhe dá uma perspectiva ampla sobre como as empresas coletam, gerenciam, analisam e agem em dados operacionais em escala.

Cribl é uma empresa de telemetria empresarial que se concentra em ajudar equipes de TI, segurança, SRE e DevOps a coletar, processar, encaminhar, armazenar e analisar dados de observabilidade e segurança sem ficar presas a um único fornecedor. A empresa se posiciona como a “Plataforma de IA para Telemetria”, com produtos como Cribl Stream para coleta de telemetria em tempo real, redução, enriquecimento e encaminhamento; Cribl Edge para coleta de telemetria de endpoint neutra em termos de fornecedor; Cribl Search para busca de dados no local; e Cribl Lake para armazenamento. Sua missão mais ampla é dar às empresas mais controle, flexibilidade e eficiência à medida que os volumes de telemetria crescem e as operações impulsionadas por IA exigem dados mais limpos e acessíveis.

Você trabalhou em Splunk, Databricks e agora Cribl, o que lhe dá uma visão rara sobre dados empresariais, observabilidade e infraestrutura ao longo de múltiplos ciclos tecnológicos. Nessa perspectiva, o que parece genuinamente diferente sobre o desafio de observabilidade criado pela IA agente?

Na observabilidade de aplicativos, sempre lidamos com caminhos de execução complexos e ramificados, rastreando solicitações por meio de microsserviços e correlacionando logs em sistemas distribuídos. Nas operações de segurança, lidamos com fontes de dados de alto volume e disparatadas para detectar ameaças em sistemas que, embora complexos, ainda se comportam de maneira previsível. A IA agente não reinventa nenhum desses problemas; ela os explode simultaneamente.

Os agentes encadeiam decisões, invocam ferramentas externas e criam subagentes dinamicamente de maneiras que não são pré-determinadas no momento da escrita. O gráfico de execução não é apenas complexo, mas pode ser drasticamente diferente a cada vez, e o volume de telemetria necessário para reconstruir o que realmente aconteceu cresce exponencialmente a cada salto. Coletar toda a telemetria necessária para tornar os sistemas agentes observáveis deve ser fácil de instrumentar e economicamente viável para operar em escala. Caso contrário, as empresas farão a mesma troca que sempre fizeram e reduzirão a visibilidade para controlar os custos — exatamente o momento errado para ficar cego.

À medida que as empresas incorporam agentes autônomos em fluxos de trabalho, onde estão as maiores lacunas de visibilidade entre o que um agente de IA é solicitado a fazer e o que realmente acontece nos sistemas subjacentes?

Os agentes completam fluxos de trabalho que parecem bem-sucedidos na superfície enquanto silenciosamente fazem chamadas de ferramentas ruins, alucinam parâmetros ou se desviam do objetivo original. As consequências frequentemente surgem horas depois em outro sistema.

A desconexão geralmente começa na interpretação: uma leve ambiguidade na instrução original é resolvida de maneira diferente dependendo do que o agente recupera da memória, quais ferramentas estão disponíveis naquele momento ou como um passo anterior na cadeia moldou seu contexto. Você também precisa instrumentar os sistemas downstream que o agente depende, porque um agente pode fazer uma chamada de banco de dados perfeitamente bem-formada e ainda retornar uma resposta errada se a tabela subjacente nunca foi atualizada porque um trabalho de ETL falhou silenciosamente upstream.

O agente fez exatamente o que foi solicitado; os dados em que confiava simplesmente estavam desatualizados.

Por que as ferramentas de observabilidade tradicionais são frequentemente insuficientes para monitorar sistemas de IA agente?

Primeiro, elas foram construídas em torno de esquemas rígidos e proprietários e formas de dados previsíveis. As trilhas agentes não se conformam a essas expectativas — elas são volumosas, altamente variáveis em estrutura e incluem tipos de dados como texto de prompt completo, cadeias de raciocínio de modelo e payloads de chamadas de ferramentas que as ferramentas legadas não foram projetadas para ingerir sem trabalho de transformação significativo. Padrões abertos como as convenções semânticas de GenAI do OpenTelemetry estão surgindo para abordar isso, mas muitas plataformas legadas não foram projetadas para tirar proveito deles.

Segundo, a equação de escala e custo se quebra rapidamente. Um único agente que lida com cargas de trabalho de produção pode gerar mais telemetria em uma hora do que uma pilha de aplicativos inteira produziu em um dia, e a maioria das plataformas tradicionais cobra por volume ingerido e armazenado. Isso cria uma troca impossível — ou você instrumenta tudo e enfrenta custos desenfreados, ou reduz a visibilidade nos sistemas onde você mais precisa.

Quando um agente de IA falha, como as organizações podem determinar se a causa raiz foi o modelo, a camada de recuperação, uma dependência de API, um problema de permissão ou um problema de infraestrutura downstream?

Isolar a causa raiz em uma falha agente é um processo de eliminação por camadas. Isso só funciona se sua telemetria abranger todos eles consistentemente. Sinais de latência e erro nas trilhas do modelo apontam para o próprio LLM. Trilhas de recuperação dizem se o contexto retornado foi relevante ou desatualizado. Trilhas de chamadas de ferramentas expõem dependências de API falhas ou erros de permissão.

Como mencionado, você também precisa de telemetria dos sistemas downstream que o agente depende, porque um agente pode fazer uma chamada perfeitamente bem-formada e ainda produzir uma resposta errada se os dados em que confiava nunca foram atualizados. Nenhum sinal único conta a história toda, o que é por que correlacionar todos esses níveis em um lugar é o que separa as equipes que podem depurar falhas agentes rapidamente daquelas que ainda estão chutando.

Quais tipos de dados de telemetria se tornam mais importantes quando as empresas estão tentando entender o comportamento do agente em escala?

A base ainda é MELT — métricas, eventos, logs e trilhas — mas o peso muda consideravelmente quando você se move para sistemas agentes. Métricas dizem que algo está errado e logs dão o registro bruto do que aconteceu, mas nenhum deles pode reconstruir a cadeia de raciocínio que um agente seguiu para chegar a uma resposta errada. É aí que as trilhas se tornam o sinal mais crítico.

Em um sistema distribuído tradicional, uma trilha mostra como uma solicitação se moveu por meio dos serviços. Em um sistema agente, ela mostra como um modelo raciocinou por meio de um problema, quais ferramentas ele chamou, qual contexto ele recuperou, onde ele se ramificou e o que ele decidiu a cada etapa. Sem essa trilha, você está olhando para uma saída sem forma de explicar como você chegou lá.

Os outros sinais MELT não desaparecem; métricas sobre uso de token e latência importam para custo e desempenho, e logs de sistemas downstream permanecem essenciais. Mas as trilhas são o que tornam o comportamento do agente legível em escala.

Muitas discussões de IA ainda se concentram fortemente em alucinações. As empresas estão subestimando falhas operacionais, como recuperações ruins, integrações quebradas, picos de latência ou contexto ausente?

A maioria das alucinações em produção não são falhas de modelo; elas são falhas operacionais disfarçadas. Recuperações ruins retornam contexto desatualizado ou incompleto, e o modelo preenche a lacuna com algo que soa plausível. Uma integração quebrada significa que o agente nunca obteve os dados de que precisava para raciocinar corretamente em primeiro lugar. Contexto ausente de um trabalho de ETL falho parece uma alucinação, mas é realmente um problema de infraestrutura.

Quando as equipes não podem ver a diferença, elas recorrem ao que podem controlar, que geralmente é o modelo em si. Elas iteram sobre prompts do sistema, adicionam guardrails e refinam estruturas de avaliação, e embora essas técnicas tenham valor real, elas estão tratando um sintoma em vez da causa. Em minha experiência, o investimento de maior valor é quase sempre a qualidade e a frescura dos dados na camada de recuperação. Um agente bem fundamentado com dados limpos e atuais superará um agente fortemente projetado para prompts trabalhando com contexto desatualizado ou incompleto a qualquer momento.

À medida que os agentes se tornam mais autônomos, o que as equipes de empresa devem registrar, rastrear ou monitorar para manter a responsabilidade sem se sobrecarregar com ruído?

A base ainda é MELT, mas a responsabilidade para sistemas agentes exige camada de estrutura de avaliação sobre telemetria tradicional. Métricas, eventos e logs superfície falhas de infraestrutura e integrações quebradas que podem corromper o comportamento do agente antes que o modelo responda; trilhas dão a você a cadeia de raciocínio para entender por que ele chegou a uma resposta particular. Mas nenhum deles diz se a resposta foi realmente correta, e é aí que a avaliação LLM-as-juiz preenche a lacuna. As mesmas capacidades de IA que alimentam os agentes podem ser usadas para avaliá-los, pontuando saídas para precisão, fundamentação e conclusão de tarefa em uma escala que nenhum processo de revisão humano pode igualar.

Pré-produção, atua como um portão de qualidade, capturando regressões antes que elas atinjam os usuários. Em produção, torna-se um monitor contínuo, amostrando tráfego ao vivo e sinalizando respostas que caem fora de limites aceitáveis. A chave para evitar ruído é reconhecer que nem todos os fluxos de trabalho do agente carregam o mesmo risco, o que significa mudar de monitoramento uniforme para algo que a indústria está começando a chamar de governança humano-no-loop. Você define linhas de base comportamentais e limites de confiança antecipadamente, deixa os agentes operarem e reserva intervenção humana para exceções.

Qual papel as pipelines de telemetria podem desempenhar para ajudar equipes de segurança, SRE, dados e IA a trabalhar a partir de uma visão compartilhada do comportamento do agente?

Equipes de segurança, SREs, engenheiros de dados e equipes de IA estão todas olhando para fatias diferentes do mesmo problema por meio de ferramentas diferentes, e nenhuma delas tem a visão completa por conta própria. O motivo pelo qual as pipelines de telemetria se tornaram uma parte padrão da arquitetura de dados empresarial moderna é que elas resolvem exatamente esse problema: uma pipeline única e bem governada upstream de todas as suas ferramentas garante que cada equipe trabalhe a partir dos mesmos dados normalizados e enriquecidos sem agentes e coletores personalizados implantados para cada equipe.

Essa flexibilidade importa em dois níveis. O primeiro é o nível de dados. Uma pipeline de telemetria bem projetada permite que você ajuste os dados à estratégia de armazenamento e análise certa, para que você não pague preços de análise para dados dos quais você só precisa para retenção de conformidade de longo prazo. O segundo é a opção à medida que o paisagem de ferramentas de IA continua a evoluir rapidamente. Empresas que constroem sua estratégia de observabilidade em torno do ecossistema de um único fornecedor enfrentarão projetos de migração caros a cada vez que uma ferramenta melhor emerge.

Quais erros as empresas estão cometendo quando tentam adaptar práticas de monitoramento existentes para implantações de IA agente?

O erro mais comum que vejo é alcançar plataformas de observabilidade premium existentes para coletar trilhas de agente sem pensar nas implicações de custo primeiro. Trilhas agentes são grandes, variáveis e volumosas de maneiras que a telemetria de aplicativos tradicional não é, e a maioria das plataformas premium cobra por ingestão e armazenamento. A conta pode se tornar um problema sério antes que as equipes sequer percebam o que está acontecendo, e a resposta típica é reduzir o que elas coletam. O resultado é o pior dos dois mundos: alto custo e visibilidade incompleta.

O segundo erro é aplicar o modelo mental errado ao que o monitoramento é suposto responder. O monitoramento de infraestrutura tradicional pergunta “o sistema está funcionando?” e gera alertas quando não está. Essa pergunta é necessária, mas está longe de ser suficiente para sistemas agentes, onde a infraestrutura pode estar perfeitamente saudável enquanto o agente está silenciosamente tomando más decisões, recuperando dados desatualizados ou se desviando de seu objetivo original. Equipes que adaptam dashboards e limiares de alerta existentes para fluxos de trabalho de agente frequentemente se convencem de que têm cobertura quando, na verdade, estão apenas observando a tubulação.

O terceiro erro é tratar a instrumentação como uma afterthought. Empresas que pilotam agentes rapidamente e se mudam para produção sem pensar sobre a observabilidade acabam em ciclos de remediação caros, reconstruindo a arquitetura de coleta de dados após a primeira falha de produção significativa. As equipes que escalonam implantações de agente com mais sucesso instrumentam cedo, estabelecem linhas de base enquanto o tráfego é baixo e o comportamento é previsível, e constroem sua estrutura de avaliação antes de precisar, em vez de depois que algo dá errado.

Olhando para o futuro, a visibilidade da infraestrutura se tornará um pré-requisito para a adoção de IA empresarial da mesma forma que a observabilidade em nuvem se tornou essencial para a migração em nuvem em grande escala?

O paralelo com a nuvem é extremamente semelhante. A coisa mais importante que eu digo aos clientes quando eles movem a infraestrutura para a nuvem é que eles não estão apenas levantando e transferindo. Eles estão implantando uma arquitetura completamente nova com novas capacidades. Tudo isso precisa ser instrumentado e monitorado de maneiras que as ferramentas anteriores provavelmente não estavam configuradas para. As empresas que pularam essa etapa encontraram falhas em cascata que não podiam diagnosticar, custos em espiral que não podiam explicar e interrupções que não podiam prevenir. A observabilidade se tornou a base da confiança que tornou a escala em nuvem possível, e o mesmo padrão está se desenrolando agora com a IA agente, movendo-se mais rápido e com apostas mais altas.

A principal razão pela qual os agentes precisarão desse tipo de supervisão indefinidamente é que eles são não determinísticos por design, seu comportamento emerge em tempo de execução e sua capacidade eficaz cresce a cada vez que você conecta uma nova ferramenta. A certificação estática pré-implantação não pode cobrir um sistema cuja superfície de ação muda com cada integração. Os agentes operarão dentro de limites de confiança definidos, e esses limites se expandirão ao longo do tempo à medida que a infraestrutura de observabilidade, política e avaliação amadurece. Os limites em si nunca desaparecerão, e isso não é um estado de falha. É assim que todos os sistemas autônomos consequenciais do mundo já funcionam.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Cribl.