Workshop avançado: dominando a observabilidade de IA — Doug Guthrie, Braintrust

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Advanced Workshop: Mastering AI Observability — Doug Guthrie, Braintrust · Canal: AI Engineer · 1:51:34 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings

Resumo

Doug Guthrie apresenta práticas de observabilidade de IA com Braintrust e mostra como combinar tracing, scores e análise de tópicos para identificar problemas e padrões nos dados de agentes. Ele propõe um ciclo de melhoria contínua em que dados de produção alimentam o desenvolvimento, os evals e as mudanças no agente. No workshop, configura um agente de suporte, automatiza a avaliação de traces e demonstra como usar tópicos e consultas SQL para encontrar casos relevantes. Por fim, mostra como um coding agent pode usar esses dados para atualizar conjuntos de dados, executar evals e apoiar a criação de pull requests.

Pontos-chave

• Tracing é a base da observabilidade: sem registrar as etapas, entradas e saídas do agente, problemas de qualidade ficam difíceis de localizar.
• Evals e observabilidade se complementam: juntos, ajudam a medir a qualidade e a orientar melhorias no agente.
• Dados de produção devem alimentar um ciclo de desenvolvimento que inclui análise, mudanças, evals e deploy.
• Scores podem ser baseados em código, em LLM judge ou em revisão humana; é importante calibrá-los conforme o agente evolui.
• Topics ajuda a descobrir padrões, problemas e intenções de usuários que os scores existentes talvez não capturem.
• Facets e preprocessors personalizados permitem adaptar a análise de tópicos às necessidades de cada agente.
• Adicionar exemplos reais de produção aos conjuntos de dados ajuda a ampliar os evals e a evitar regressões.
• O Braintrust CLI, SQL e skills permitem que coding agents consultem traces e automatizem etapas do ciclo de melhoria.
• A amostragem de scores online pode ser ajustada conforme a maturidade do agente e o custo de execução.
• O Braintrust oferece opções de hospedagem SaaS, BYOC e híbrida, com configurações de plano e gerenciamento distintas.

Capítulos

Início	Capítulo	Resumo
00:13	Apresentação e objetivos do workshop	Doug Guthrie apresenta o workshop, o repositório de exercícios e o objetivo de usar observabilidade para criar agentes melhores.
06:32	Integrações e ciclo de melhoria	O apresentador descreve a flexibilidade de integração da Braintrust e o ciclo que conecta produção, desenvolvimento e evals.
13:47	Scores online e Topics	Guthrie diferencia scores offline e online e introduz Topics como forma de descobrir padrões além dos problemas já conhecidos.
21:07	Perguntas sobre escala e concorrentes	A conversa aborda a geração de insights em escala, as diferenças em relação a outras plataformas e o uso de dados próprios.
30:01	Hospedagem e preparação do workshop	O apresentador explica as opções de hospedagem e inicia a configuração do projeto e da organização na Braintrust.
38:07	Provedores de IA, API key e ambiente local	Guthrie configura provedores e credenciais, clona o repo e prepara o ambiente Python e o Braintrust CLI.
46:14	Inicialização do CLI e primeiros traces	O workshop inicializa o CLI, verifica a configuração e envia um trace do agente de suporte para a Braintrust.
53:28	Configuração de scores e automações	O apresentador configura scores de avaliação e automações para executá-los quando novos traces chegam.
1:00:10	Facets personalizados e importação de traces	Guthrie cria uma facet personalizada, configura Topics e importa traces para começar a gerar sinais de produção.
1:07:28	Exploração de tópicos e análise de traces	O apresentador examina padrões de uso e problemas identificados, mostrando como combinar Topics e scores para investigar traces.
1:15:44	Automação do ciclo com coding agents	Guthrie demonstra uma skill que permite a um coding agent consultar dados, inspecionar traces, alterar o agente e executar evals.
1:24:06	Implantação híbrida e modelos	A sessão responde a perguntas sobre deployments, modelos usados e as opções disponíveis para o pipeline de Topics.
1:32:46	Organização de projetos e maturidade dos evals	O apresentador discute como organizar dados por projeto, como os evals evoluem e quando executar scores em código ou na plataforma.
1:40:01	CLI, remote eval e melhorias com agentes	Guthrie destaca o CLI e o remote eval e mostra como um coding agent pode usar insights para atualizar agentes e conjuntos de dados.
1:47:13	Remote eval e próximos usos	A sessão demonstra parâmetros de remote eval no playground e termina discutindo a avaliação de coding agents e skills.

Citações

Sem tracing, não conseguimos entender o que está acontecendo nem onde a qualidade está se deteriorando. — 05:29

A produção deve informar o desenvolvimento. — 08:05

Se você consegue 100% em todos os evals, provavelmente seus casos de teste não são fortes o suficiente. — 12:46

Adicionar o exemplo certo ao conjunto de dados depende do sinal gerado nos logs. — 1:13:40

Conceitos e entidades

• Braintrust (empresa): Plataforma de evals e observabilidade apresentada no workshop para ajudar equipes a medir e melhorar agentes.
• Doug Guthrie (pessoa): Solutions engineer da Braintrust que conduz a apresentação e o workshop.
• BrainStore (ferramenta): Backend próprio da Braintrust, desenvolvido para armazenar e consultar dados de agentes em escala.
• Topics (conceito): Recurso que identifica e agrupa padrões nos dados, como tarefas, sentimento e problemas.
• tracing (conceito): Registro das etapas, ferramentas, entradas e saídas executadas por um agente.
• LLM judge (conceito): Método que usa um LLM para avaliar saídas ou conversas com base em critérios definidos.
• OpenAI Agents SDK (ferramenta): SDK usado no exemplo do workshop para implementar o agente de suporte.
• Braintrust CLI (ferramenta): Interface de linha de comando usada para consultar dados, executar evals e gerenciar conjuntos de dados.
• Codex (ferramenta): Coding agent usado na demonstração para consultar traces e automatizar tarefas do ciclo de melhoria.
• Cloudflare (empresa): Empresa citada por Guthrie como uma das organizações cujos engenheiros ele consulta sobre o uso da plataforma.
• Dropbox (empresa): Empresa citada como cliente que explora o uso de Topics para analisar traces em escala.
• Lightstep (ferramenta): Plataforma mencionada por um participante ao perguntar sobre diferenças em relação à Braintrust.

Tradução completa (pt-BR)

00:13 Olá, pessoal. Meu nome é Doug Guthrie. Sou engenheiro de soluções na Braintrust. Tenho alguns colegas, alguns colegas na sala, que podem ajudar se vocês ficarem travados em algum momento durante o workshop de hoje. Além disso, sou interrompido o dia todo durante as chamadas, então, se quiserem me interromper a qualquer momento e fazer uma pergunta, fiquem à vontade. Espero que vocês já tenham conseguido pegar o QR code. Ele leva diretamente a este repo. É isso que vamos usar hoje como parte do workshop e

00:44 vamos entender como fazer observabilidade com a Braintrust e usar os diferentes recursos disponíveis para criar agents melhores. É por isso que estamos todos aqui. Como podemos realmente criar agents de boa qualidade? Vou deixar isso na tela por mais uns 10 segundos.

01:21 Vou mostrar isso de novo mais adiante na apresentação, quando começarmos o workshop de fato. Então, se não conseguirem pegar, também podem pesquisar no Google por dpguthrie no GitHub e procurar esse repo no GitHub para encontrá-lo. Beleza. Estamos todos aqui para dominar a observabilidade de IA, e vou mostrar como isso funciona no contexto do uso da Braintrust. Uma breve agenda. Tenho alguns slides para estabelecer as bases da observabilidade, e acho que

01:52 vou falar sobre o que aprendemos a respeito de como fazê-la muito bem. Vou estabelecer as bases e dar uma ideia de como gerar sinais em meio a esse enorme volume de ruído. Provavelmente todos vocês já viram um trace ou conseguem entender que os agents que estão criando geram uma quantidade enorme de dados. Conseguir analisar tudo isso e realmente extrair algum tipo de sinal ou insight é um desafio. É aí que está a dificuldade. Uma coisa é conseguir rastrear e ter uma plataforma que permita fazer observabilidade. Outra coisa

02:23 é saber como realmente fazer algo com isso e extrair algum tipo de insight. Vou mostrar como isso funciona na Braintrust e depois vamos percorrer no workshop tudo o que descrevi ou mostrei nestes slides. Como eu disse, se tiverem alguma pergunta, podem fazer a qualquer momento. Não me incomodo. Vou tentar reservar um tempo no final para perguntas e respostas também. Então, fiquem à vontade para deixar suas perguntas para o fim. Uma breve introdução à Braintrust, caso não a conheçam.

02:53 Somos uma plataforma de IA, evals e observabilidade. Nosso único objetivo é ajudar nossos clientes a criar agents melhores. Ajudamos nossos clientes a entender como é a qualidade e, então, como melhorá-la de uma forma real e mensurável. Uma das partes mais divertidas do meu trabalho é poder conversar com alguns dos clientes que vocês veem ali no canto superior direito. Posso entender como eles estão criando seus agents. E muitos desses aprendizados acabam

03:24 chegando ao nosso produto. Também aparecem nos meus outros trabalhos com clientes. Então, posso conversar com os engenheiros da Cloudflare e da Dropbox e entender o que estão fazendo, que tipos de scores estão criando, como pensam sobre os tópicos dos nossos novos recursos e que tipos de automações estão desenvolvendo com base nisso. Espero dar uma ideia disso hoje. Como mencionei, somos uma plataforma de evals e observabilidade. Quando pensamos em evals e observabilidade, acho que são dois lados diferentes da mesma moeda.

03:55 Juntas, elas realmente permitem criar agents de melhor qualidade. Se vocês ficarem por aqui — e quero dizer, se não forem clientes da Braintrust, se ainda não estiverem usando a Braintrust —, recomendo muito que voltem e deem uma olhada na Braintrust no próximo mês ou nos próximos dois meses. Acho que o setor, de modo geral, está hoje numa abordagem mais passiva de observação de dados. É mais ou menos o que mencionei sobre conseguir extrair insights. A Braintrust está caminhando para algo um pouco mais

04:26 próximo do que chamamos de observabilidade ativa. Na verdade, ela oferece os elementos básicos, os fundamentos, para fornecer os insights certos, sem que vocês precisem extrair dados da plataforma e entender o que eles significam no contexto do agent e o que precisam fazer para melhorá-lo. Então, a observabilidade ativa é a maneira de começar a trazer esses insights até vocês, para que possam criar agents de melhor qualidade. Essa foi uma breve introdução à Braintrust. Vou mencionar isso de novo no final, mas temos um estande na expo. Acho que abre por volta das 5h. Apareçam por lá. Estarei lá hoje à noite. Venham falar comigo e fazer mais perguntas.

04:58 Também estaremos aqui a semana toda. A base de tudo isso, a base da observabilidade em geral, como imagino que a maioria de vocês já saiba, é o tracing. É preciso entender todas as diferentes etapas que o agent executa, certo? O que ele faz para chegar à resposta final? E não só isso: quais são as entradas dessas ferramentas? Quais são as saídas? E, quando começamos a pensar em todas as diferentes etapas que o agent pode

05:29 executar, isso pode crescer muito rapidamente. Conseguir analisar tudo isso é o desafio que estamos tentando resolver. Mas, sem esse tracing, não conseguimos entender o que está acontecendo nem onde a qualidade está se deteriorando. Então, conseguir rastrear todos esses dados e depois extrair algum tipo de insight é algo em que a Braintrust pode agregar valor. Mas, de modo geral, se vocês estão pensando em observabilidade e não têm alguma parte da stack

06:00 representada em um trace como este, então ela é uma caixa-preta. Vai ser muito difícil identificar esses problemas de qualidade ou, sabe, orientar o Codex, o Claude Code ou qualquer outra ferramenta que estejam usando a entender o que está acontecendo. Se esses dados não estiverem disponíveis, vocês não conseguem identificar os pontos em que o agent está falhando e onde poderia ser melhorado. Portanto, o tracing é a base. Acho que, se olharem para o lado dos evals e, claro, para a observabilidade que estamos discutindo hoje, tudo gira em torno da nossa capacidade de capturar tudo o que o agent está fazendo.

06:32 Só mais um comentário rápido sobre a Braintrust. Temos muitas maneiras diferentes de fazer isso. Vou avançar um pouco. O workshop que faremos usa um agent de suporte fictício. O agent em si não é o mais importante, mas foi desenvolvido com o OpenAI agents SDK. Temos muitas integrações com diferentes frameworks de agents. Temos integrações com todos os provedores de IA e oferecemos suporte a diferentes linguagens de programação. Então,

07:02 dependendo de como vocês estão criando o agent — o exemplo de hoje é em Python, mas poderia ser em TypeScript, Java, Ruby ou Go —, somos bastante flexíveis. Permitimos que vocês usem o que já estão fazendo, seja em termos de linguagem de programação ou da maneira como estão criando o agent: com um framework, usando OpenTelemetry, desenvolvendo a própria orquestração ou qualquer outra abordagem. A Braintrust tem uma forma de se integrar a isso com bastante facilidade. E acho que, ao observar o mercado, se vocês estão tentando entender como

07:34 Como faço para rastrear este agent? Em geral, você vai precisar ter a capacidade de percorrer muitas coisas diferentes. E você pode ver aqui que há muitas maneiras diferentes de integrar sua stack ao Braintrust. Então, de novo, hoje estou usando um agent de demonstração com o OpenAI Agents SDK, mas certamente não estamos limitados a isso. Isso é algo que, bem, eu digo a palavra “ciclo virtuoso” umas 100 vezes por dia, parece.

08:05 A ideia toda, e onde acho que recebemos bastante feedback dos nossos clientes, é que a maneira como eles estão criando agents melhores hoje é criando algo assim, certo? E o que quero dizer com isso é que a produção deve orientar o desenvolvimento. Você deve ter um ciclo virtuoso realmente simples e fácil de criar, que permita desenvolver algum tipo de mudança, corrigir algo no seu agent e testar se essa mudança causou alguma regressão no agent ou o melhorou. Você

08:36 deve poder ter confiança para colocar esse agent em produção. Quando você faz o deploy, certo? Precisamos conseguir observá-lo. Mas, além dessa observação, precisamos acrescentar algo a ela que talvez não esteja explicitamente indicado neste ciclo virtuoso: você precisa conseguir extrair algum tipo de insight em escala. A maioria dos clientes, especialmente os que mostrei no slide anterior, opera em uma escala enorme, e conseguir extrair insights — ou ter uma pessoa analisando esses dados — seria incrivelmente desafiador. Então, precisamos adicionar uma camada de inteligência a isso, e

09:06 essa é uma das coisas que o Braintrust oferece. Mas acho que, se você está pensando no processo de criar um agent melhor em geral, precisa de um ciclo virtuoso como este. Você precisa criar algo em que a produção, de alguma forma, informe como você vai modificar seu agent. Então, é isso que vou mostrar um pouco hoje, durante o workshop: como podemos extrair automaticamente alguns desses insights do nosso agent de suporte, levar esses insights de volta ao processo de desenvolvimento, fazer algum tipo de mudança e executar um eval, certo? Esse

09:38 esse tipo de ciclo se torna incrivelmente importante. E espero que se torne algo muito simples, que a maioria das empresas e dos desenvolvedores consiga integrar com facilidade. Então, quando digo “sinal”, nesse contexto, quero dizer duas coisas diferentes que também vamos conectar durante o workshop. Quero dizer pontuações. Isso pode ser, sabe, avaliadores. É uma maneira de medir a saída do seu agent

10:10 de alguma forma. Você tem algum modo de falha específico, algo que está tentando entender sobre o agent quando ele recebeu uma entrada. Podemos criar muitos tipos diferentes de pontuações. Uma delas, que você vê bem à esquerda, é uma pontuação baseada em código. Em geral, elas são muito rápidas, muito baratas e muito fáceis de executar. Imagine que estou tentando validar um esquema. Estou tentando entender se a ferramenta A foi chamada antes da ferramenta B. Ela foi chamada na ordem correta? Coisas

10:40 que podem ser produzidas muito, muito rapidamente e sem precisar recorrer a um LLM. A opção mais subjetiva, porém, é o LLM as a judge. Queremos trazer algum tipo de compreensão humana para essa trilha, certo? Para essa interação que acabou de acontecer com aquele caso de eval, ou até mesmo online. Assim, você pode dar ao LLM alguns critérios sobre como quer avaliar a saída ou a conversa, e ele deve produzir uma pontuação. E então há provavelmente

11:11 na verdade, uma quarta opção aqui, mas a terceira que você vê à direita é um LLM as a judge alinhado à revisão humana. Como você pode imaginar, também é importante que, se tenho um LLM as a judge produzindo resultados e estamos tomando decisões com base neles, entendamos se esses resultados são bons ou não. Portanto, deve haver algum tipo de revisão humana. Acho que isso é especialmente importante se você estiver usando esses judges online, certo? Se estiver pontuando interações reais dos usuários com seu agent, deve ser possível

11:42 oferecer algum tipo de interface para que os usuários façam essa revisão e calibrem esses judges, certo? Não é algo que você configura e esquece. Seu agent vai evoluir, e suas pontuações também. A quarta opção, da qual tenho um exemplo no workshop, é uma pontuação baseada em código, mas que invoca um LLM nos bastidores. Imagine que há lógica condicional ou coisas mais avançadas ou complexas que você precisa fazer com base em algum tipo de lógica que queira codificar na sua pontuação baseada em código. Você também pode fazer

12:14 isso. Essas são algumas das coisas que acho que ouvi em diferentes conversas com nossos clientes. De novo, acho que você deve considerar isso com certa cautela. Nem sempre vai se encaixar em 100% dos cenários, todas as vezes. São coisas em que vi bastante sucesso entre nossos clientes. Só conseguir entender o raciocínio que o LLM apresentou para produzir uma pontuação é incrivelmente útil, especialmente na revisão humana, quando você pensa: “Ah, entendo por que ele produziu esse resultado.” Isso vai me ajudar a decidir como posso alterar minhas pontuações.

12:46 Acho que, especialmente no início, quando temos um agent que estamos colocando em produção, a pontuação binária é melhor do que usar A, B, C, D e assim por diante. E você deve ser muito rigoroso. Deve criar exemplos realmente difíceis. Se você tirar 100% em todos os seus evals — e provavelmente vamos tirar hoje, porque é um caso de uso de demonstração —, mas, se você tirar 100% nos seus evals, bem, primeiro, provavelmente você não tem

13:16 casos de teste suficientemente fortes no seu conjunto de dados. Suas pontuações provavelmente não são rigorosas o bastante. Então, você deve observar isso e calibrar de acordo. Outra coisa que tenho observado — e, de novo, considere com cautela — é que incluir alguns exemplos nos seus prompts tende a ajudar. E talvez usar um modelo mais forte para pontuar do que para gerar, certo? Vamos aproximar isso o máximo possível da subjetividade humana. Obviamente, isso pode mudar dependendo do tipo de tráfego, certo? Se

13:47 começarmos a falar de pontuação online e coisas assim, mas, nesse ponto, há obviamente dois tipos diferentes de pontuação, pelo menos da maneira como vemos isso aqui na Braintrust. Há a offline, certo? É o que fazemos com nossos evals. Tentamos extrair algum sinal para saber se devemos colocar isso em produção. Isso vai nos indicar se houve melhora ou regressão. Isso pode ser, imagine, conectar isso a… Desculpem. É minha filha.

14:25 É, então você pode imaginar conectar isso, certo? Ao CI. Pode imaginar conectar isso a algum tipo de pipeline automatizado. De novo, em que você executa isso offline. E, por outro lado, a ideia toda — ou o que estamos discutindo aqui — é como extrair sinal das coisas que estão realmente acontecendo em produção. Uma das coisas que você pode fazer é usar essas pontuações online e pontuar o tráfego à medida que ele chega ao Braintrust. E, de novo, a ideia é associar algum tipo de sinal que permita a você, como usuário, acessar isso e

14:57 tipo: “Nossa, minha pontuação de precisão do roteamento é zero nestes exemplos. Existe algum padrão que eu deveria levar em conta com base nesse feedback, certo? Então, preciso transformar essa quantidade enorme de dados em algo muito menor e mais fácil de consumir.” O segundo sinal é um recurso que temos no Braintrust chamado tópicos. A ideia aqui é que você queira entender padrões nos seus dados. Você quer ir um pouco além das incógnitas conhecidas, certo? Ou seja, suas pontuações que já criou

15:28 nas suas evals offline são modos de falha que talvez você já tenha reconhecido. São coisas para as quais você já está fazendo testes, mas esse certamente não é o escopo em que seu agent pode operar, nem os modos de falha que ele pode encontrar. Portanto, precisamos entender além disso, e Tópicos é um dos recursos que ajudam a tornar isso possível. Devemos conseguir entender falhas silenciosas. Então, você pode ver aí pontuações bem tradicionais, como factualidade e moderação. Elas vão detectar um conjunto muito pequeno de erros, e provavelmente você tem pontuações um pouco mais específicas que está usando. E, nesse sentido, as evals que você executa também usam esse subconjunto de pontuações para identificar melhorias ou regressões, mas há uma ampla gama de casos de uso que seus cenários de teste não capturam, mas que seus usuários estão de fato explorando com seu agent e tentando obter algum tipo de resultado — talvez não o resultado certo. Então, queremos capturar esses casos extremos. Queremos capturar a cauda e, então, estruturar o ciclo de melhoria contínua,

15:59 um pouco mais de scores personalizados que você está usando. E, nesse sentido, os evals que você está executando, mais uma vez, usam esse subconjunto de scores para entender a melhoria ou a regressão, mas há uma grande variedade de casos de uso que seus cenários de teste não estão cobrindo, que seus usuários estão de fato explorando com seu agent e tentando obter algum tipo de resultado — e talvez não seja o resultado certo. Então, queremos capturar esses casos extremos. Queremos capturar a cauda da distribuição e estruturar, então, o flywheel,

16:30 certo? Queremos trazer esses exemplos de volta para nossos conjuntos de dados. Queremos executar evals. Talvez queiramos criar novas pontuações com base nesse feedback. Então, o que são Tópicos? Em geral, ou em alto nível, Tópicos é uma maneira de entender padrões nos seus dados. Podemos criar agrupamentos desses padrões e dar uma ideia da frequência com que eles ocorrem. Também é importante destacar que há facetas integradas e personalizadas. O que quero dizer com isso é que, ao acessar sua conta do Braintrust, você pode habilitar um recurso chamado

17:02 Tópicos e, pronto para uso, ver tarefas, problemas e sentimento. Assim, posso entender: “Qual é a intenção mais comum dos usuários? Como os usuários se sentem ao interagir com meu agent? E quais são os problemas mais comuns do agent?” E essa taxonomia não precisa ser fornecida previamente por mim. O LLM a cria para mim como parte desse pipeline. Mas também posso trazer minhas próprias facetas personalizadas. Posso criar meu próprio prompt e meu próprio pipeline para gerar esses

17:32 padrões nos meus dados, certo? Em relação às coisas que me interessam. Voltemos a isso. Isto é apenas um exemplo de ilustração do que você pode ver com os tópicos gerados. Mas por que usar isso? Acho que já toquei um pouco nesse ponto, mas você quer evitar pontos cegos. Quer entender todas as diferentes maneiras como seus usuários interagem com seus agents e deixar que isso oriente o que você fará como desenvolvedor, certo? Isso não precisa necessariamente ser um problema ou

18:04 um modo de falha. Pode ser, por exemplo, uma solicitação de recurso ou algo novo que seu agent poderia fazer, com base na maneira como os usuários realmente interagem com ele. Acho que uma das formas como vi muitos dos nossos usuários começarem a usar isso é justamente para criar, ou entender o que está acontecendo e orientar como deve ser o roadmap do agent, certo? Isso começa a revelar coisas que talvez não soubéssemos sobre esses agents em produção. Nos bastidores, há um pipeline realmente complexo

18:34 você vê ali à esquerda um pré-processador. Pense no meu primeiro slide, com aquele trace, que é muito, muito pequeno em comparação com o que vi nossos clientes gerarem. Precisamos pré-processar esses dados e transformá-los em algo significativo para fornecer ao LLM. Então, oferecemos o que chamamos de pré-processador padrão. Basicamente, pegamos o que você verá na visualização de conversa, que mostrarei daqui a pouco: a troca de mensagens, certo? O usuário, o assistant e as

19:04 chamadas de ferramentas. Pré-processamos aquele trace enorme e o transformamos em algo significativo e muito menor. Depois, passamos isso para uma faceta, certo? A faceta é aquilo que acabei de descrever: problemas, tarefas, sentimento ou suas próprias facetas personalizadas. O que faremos aqui é passar esses dados pré-processados para essa faceta. Em seguida, vamos resumi-los. Então, criamos um embedding vetorial desse resumo no nosso backend. Depois disso, quando temos esse embedding vetorial, podemos criar o que

19:35 chamamos de mapa de tópicos. É mais ou menos o que vocês viram no slide anterior, o gráfico de dispersão. Isso nos permite rotular e classificar nossos traces. E, quando tenho esses rótulos e classificadores, fica extremamente simples para mim como usuário — e também para mim como usuário de um agente de programação sobre o Braintrust — começar a filtrar todo esse ruído usando todos esses dados tão ricos. Um ponto importante: o pipeline que vocês estão vendo, as

20:05 facetas e a etapa de embedding usam um modelo hospedado que temos. Fizemos muito trabalho nos bastidores para criar algo que não seja apenas um recurso para mostrar numa demonstração. É claro que vamos ver algumas coisas aqui hoje, mas isso precisa funcionar em escala. Você deve conseguir executá-lo em 100% dos seus traces. Esse é o objetivo do nosso pipeline de tópicos. Só para dar um pouco mais de detalhe do que talvez devesse: custa 6 centavos por milhão de tokens no lado da entrada e 40 centavos no

20:36 lado da saída. Compare isso com outros modelos que talvez você esteja usando como LLM como juiz para gerar o mesmo tipo de sinal. Dá para criar um caso de uso bastante convincente, principalmente se você começar a perceber o valor dos tópicos, rótulos e classificadores que geramos como resultado. Também toquei um pouco no motivo de termos criado isso. Temos clientes que geram quantidades enormes de dados. E uma

21:07 das coisas que acho que resolvemos bem cedo foi conseguir ingerir esses dados e permitir que nossos clientes consultassem esses dados em velocidades inferiores a um segundo. O que ainda não conseguíamos fazer no início era agir sobre esses dados, certo? É aí que entra a observabilidade ativa. Como é que agora extraímos insights de todos esses dados, especialmente de dados em escala? É aí que surge o desafio. Então, se você tem esse pipeline realmente complexo, projetado para operar em escala —

21:38 quero dizer, tanto do ponto de vista técnico quanto do custo, como mencionei antes —, podemos oferecer um recurso básico e uma fundação realmente interessantes, sobre os quais nossos clientes podem construir para alimentar esse ciclo de melhoria contínua. No fim das contas, o que estamos tentando fazer é permitir que nossos clientes criem esse ciclo e o façam de uma maneira que realmente melhore a qualidade dos agents, e que consigam fazer isso muito, muito rapidamente.

22:09 Certo. Espero não ter perdido ninguém na apresentação e que vocês estejam prontos para o workshop. Um rápido show de mãos: alguém ainda precisa do código QR ou da URL do repo no GitHub? Sim. Sim, vou deixar isso aqui por uns 30 segundos.

22:54 >> Minha equipe usa Lightstep. Acho que o Lightstep é meio ruim. Você pode me dar uma lista de coisas que minha equipe diz, tipo: “Bem, por que deveríamos usar BrainTrust no lugar?” Algo que eu possa levar para eles e dizer: “Estas são as coisas que BrainTrust oferece para vocês, como as soluções mais conhecidas.” >> Nossa, você foi direto para a concorrência, hein? Uau. Não estava preparado para isso. Não sou exatamente a pessoa certa para isso. Não vou ficar aqui falando mal de ninguém. Acho, sim, que temos uma oferta mais forte e que

23:26 acho que temos uma oferta mais forte em vários aspectos. Sem nenhuma ordem específica, um deles é a flexibilidade que mostrei no outro slide. Há a possibilidade de trabalhar com várias linguagens e várias linguagens de programação — desculpe, vários frameworks. É uma forma muito agnóstica de criar seu agent. Acho que o LangSmith também tem um pouco disso, mas com certeza é voltado para LangGraph, LangChain, deep agents e esse tipo de coisa. E acho que eles têm recursos que são meio que só para

23:56 isso. Outra coisa que acho — na verdade, se voltarmos, eu costumava ter um slide sobre isso — é que a BrainTrust criou seu próprio banco de dados no fim de 2024. O motivo para termos criado esse banco de dados foi que Ankur, nosso CEO, percebeu muito cedo a trajetória que estávamos seguindo em relação a agents. Na época, usávamos ClickHouse nos bastidores, e ele percebeu muito rapidamente, quando começamos a integrar clientes como aqueles que vocês viram, Netflix, Microsoft e Dropbox, que o ClickHouse não dava conta em escala. E tivemos que fazer algo diferente. Foi aí que a equipe de engenharia e Ankur criaram o BrainStore. Esse é nosso próprio backend, desenvolvido para esse fim. Acho que, na época, as pessoas acharam que éramos loucos. Pensaram: “Olha, existem todas essas alternativas open source. Tem o ClickHouse. Existem essas soluções que, na verdade, nos permitem fazer isso e fazer bem.” O que vocês veem agora, especialmente talvez no caso do LangSmith, é que eles acabaram de criar o próprio banco de dados. A Arize também acabou de criar o seu próprio

24:27 banco de dados, há uns seis meses. Acho que as pessoas estão começando a perceber que esse é um problema que as soluções prontas não resolvem e que é preciso algo personalizado. Nesse aspecto, acho que estamos uns anos à frente de alguns desses concorrentes. E isso aparece nos tópicos, na capacidade de gerar insights reais a partir de dados em escala. Provavelmente há outras coisas também. Se quiserem, venham falar comigo depois e podemos entrar em detalhes, mas eu diria que esse

24:58 último ponto — termos nosso próprio backend e as coisas que conseguimos criar em cima dele — foi realmente o que nos permitiu, acho eu, nos diferenciar dos outros participantes desse setor. Sim. Sim, você. Sim.

25:28 >> [fungada]

26:13 >> Sim, quer dizer, durante o workshop — desculpem se alguém não conseguiu ouvir — a pergunta era sobre exemplos de tópicos e um pouco mais de informação sobre o processo e se realmente estamos gerando algo significativamente diferente, já que os traces são relativamente parecidos. Eles vão ser semanticamente semelhantes. Acho que vocês vão ver isso no workshop, espero. Acho que os clientes que usam isso em produção provavelmente discordariam de você. É por isso que usam: porque estão vendo essas diferenças

26:51 e vendo essas diferenças aparecerem como classificadores distintos, como coisas que ainda não conheciam antes de executar esse pipeline. Acho que parte disso é simplesmente colocar a mão na massa e usar seus próprios traces. Tenho dados de demonstração fictícios, nos quais usei um script para, espero, criar algumas diferenças para gerarmos isso. Acho que você naturalmente vê ainda mais disso quando usuários reais interagem com o agent. Os traces provavelmente parecem um tanto semelhantes, certo? Estamos

27:24 invocando as mesmas ferramentas. Passa pelo mesmo workflow. Mas acho que, dependendo do que seu agent está fazendo e do que seus usuários fazem com ele — e talvez, para contextualizar um pouco, acho que muitos de nós estamos criando agents cada vez mais complexos ou sistemas cada vez mais complexos —, isso gera algumas diferenças que vão aparecer na tela. Mas vocês vão ver que, quando criarem uma conta, terão uma conta gratuita. Podem enviar

27:54 dados até certo limite. Também podem ativar os tópicos para ver se eles estão gerando algumas dessas coisas. Então, mesmo depois deste workshop, incentivamos vocês a experimentar. E vejam se isso gera tópicos interessantes para vocês. Sim, pode falar. >> Tragam seus próprios traces, já que vocês não estão mostrando aos seus clientes usando os próprios dados. >> Sim.

28:25 Sim, a pergunta é: podemos usar tópicos, talvez, nas nossas próprias sessões com Cloud Code, Codex e assim por diante? Com certeza. Uma das coisas que vocês vão ver na nossa página de integrações é uma integração com Cloud Code, uma integração com Codex, Cursor e Open Code. Então, estou trabalhando agora com vários clientes que estão tentando fazer exatamente isso e adicionar tópicos por cima. Não sei exatamente de onde vem a pergunta, mas acho que o que tenho ouvido é que a maioria dos

28:55 engenheiros hoje, a maioria das equipes de engenharia, está usando essas ferramentas, e agora é preciso ter visibilidade sobre a eficácia delas, sobre o quanto realmente estão melhorando o workflow e coisas desse tipo. Acho que provavelmente ainda é preciso implementar alguns mecanismos, mas, se vocês só querem entender o que as pessoas estão fazendo nessas diferentes ferramentas, os tópicos são uma ótima forma de começar a entender isso. Sim.

29:27 Temos algumas opções de hospedagem diferentes. Uma é o SaaS completo; é essa que todos vocês vão usar hoje. Também temos os modelos BYOC e híbrido. Talvez seja melhor explicar ainda mais o contexto: a BrainTrust foi projetada, desde o primeiro dia, para oferecer suporte a um deploy híbrido. Com isso, quero dizer que o control plane, o aplicativo web e os metadados que armazenamos sempre serão hospedados por nós. O data plane — ou seja, seus traces, conjuntos de dados e experimentos — pode ser hospedado na sua VPC, dentro da sua infraestrutura. Fazemos deploy em todos os principais provedores de nuvem. Mas, sim, temos aqueles clientes que vocês viram ali; eu apostaria que 90% deles são hospedados por conta própria. Sim. Sim, desculpe. Você, de camisa verde.

30:01 Sim, a pergunta é: como vocês lidam com conversas longas usando tópicos? Posso mostrar uma parte disso durante o workshop, mas há configurações diferentes que vocês podem definir. Elas podem operar em traces diferentes ou só ser acionadas depois de um certo período. De modo geral, acho que há uma noção de quanto tempo as conversas costumam durar, e isso tende a orientar as configurações que vocês definem. Mas há… não sei.

30:31 hospedado na sua VPC, dentro da sua infraestrutura. Fazemos deploy em todos os principais provedores de nuvem. Mas, sim, na verdade, temos aqueles clientes que vocês viram ali; eu diria que 90% deles são auto-hospedados. Sim. Sim, desculpe. Camisa verde.

31:04 Sim, então a pergunta é: como vocês lidam com conversas longas sobre determinados tópicos? Parte da resposta é que posso mostrar isso durante o workshop, mas há diferentes configurações que você pode ajustar e que operam em — elas podem operar em diferentes traces, ou podem ser acionadas somente depois de um certo período. Então, dependendo… de modo geral, acho que existe uma compreensão de quanto tempo as conversas costumam durar, e isso tende a orientar as configurações que você cria. Mas há… não sei

31:34 Entrar no workshop provavelmente responde um pouco melhor a isso. Mas acho que podemos responder a essa pergunta. Beleza. Que tal mais uma e depois começamos? Sim, esse pré-processador: oferecemos um padrão. Você pode trazer seu próprio pré-processador personalizado. Você tem dados que existem fora do que conseguimos analisar a partir da entrada e da saída, ou do que vai para o LLM e volta dele. Você tem coisas nos metadados. Tem coisas em algum outro span que talvez não estejamos…

32:04 …fazendo algum tipo de pré-processamento como parte desse pré-processador padrão. Você certamente pode criar o seu próprio. A outra coisa, de novo, como acho que mencionei, são as facetas. Você pode trazer sua própria faceta. Pode criar sua própria coisa que está tentando entender ou os padrões que está tentando derivar no BrainTrust. Mas sim, acho que uma das outras coisas muito legais desse pipeline é que ele é totalmente modificável, no melhor sentido da palavra. Beleza. Estou vendo um cronômetro de 30 minutos. Acho que temos até as 11h, não é?

32:35 Beleza. Certo, vou presumir que todo mundo tem o workshop ou o código QR aqui, ou pelo menos acesso ao repo. Podemos aumentar um pouco o zoom? Certo,

33:05 isso pode ser um pouco diferente dependendo de você ter ou não uma organização no BrainTrust. Como eu disse, o Noah está aqui atrás e pode ajudar se você tiver algum problema. E, se quiser, pode simplesmente gritar comigo por um tempo; tudo bem também. Então, obviamente, a primeira coisa de que vamos precisar é de uma organização no BrainTrust. Vou percorrer este guia com vocês e vamos começar a entender exatamente o que acabei de descrever. Queremos criar esse ciclo virtuoso e acho que vamos nos concentrar um pouco mais no lado online, mas

33:36 saibam que também existe o outro lado, que são os evals, e eu tenho um eval como parte disso sobre o qual também podemos conversar. Certo, uma pequena prévia: não era para ter feito isso, mas vamos criar uma nova organização. Se esta for sua primeira organização…

34:06 …que você criou, vá até esse link. Talvez haja algumas etapas diferentes no início. Pode ser que peçam para você informar alguns provedores de IA e gerar uma API key. Por favor, siga essas etapas. Também tenho instruções para elas. Você verá um fluxo um pouco diferente porque já tenho organizações criadas aqui no BrainTrust. Se estiver vendo uma tela como a minha agora, levantem a mão rapidinho. A maioria das pessoas está só…

34:37 …criando uma organização no BrainTrust pela primeira vez? Certo, legal. Ótimo, fico feliz em ver isso. Criamos a organização. O próximo passo é criar um projeto? Desculpa? Ah. Problemas de internet. Adoro. Certo, então ninguém consegue participar. Que pena. Não sei se alguém estava aqui no ano passado. Tivemos exatamente o mesmo…

35:08 …exatamente o mesmo problema. Bem, vamos passar por isso mesmo assim, e vou tentar não ir rápido demais, sabendo que ninguém mais está fazendo isso aqui. Então, vocês verão que criamos uma organização. Também verão que criamos automaticamente um projeto chamado “my project”. Vocês podem excluí-lo, se quiserem. Vamos criar nosso próprio projeto para este workshop. Eu o chamaria de AIE-workshop.

35:38 Todo o código no repo pressupõe que vocês fizeram isso. É claro que poderiam não fazer e depois alterar outras coisas no repo, mas eu queria chamar a atenção para isso caso estejam acompanhando. Saibam que precisam garantir que o projeto definido aqui também corresponda ao que está no repo. Então, as outras duas coisas de que precisamos para concluir isso são: primeiro, vamos precisar gerar ou criar um provedor de IA. Se vocês forem ao BrainTrust e…

36:10 …acessarem as configurações, verão um lugar onde podem configurar seus provedores de IA. Vou clicar neste aqui em cima. Deve haver várias opções para adicionar algum tipo de API key, ou a federação de identidade de carga de trabalho, que lançamos recentemente para alguns dos principais provedores de IA. Mas as organizações também costumam fazer, ou eu as vejo fazendo, algo como criar seu próprio gateway. E querem conectar esse gateway ao…

36:42 …BrainTrust. Podem fazer isso usando um provedor personalizado. Vocês fornecem a especificação subjacente à qual esse gateway está em conformidade, indicando como fazemos a autenticação com ele, além de algum outro tipo de URL e autenticação. De modo geral, dá para se conectar a muitos provedores de IA diferentes de várias maneiras. Nunca vi alguém não conseguir se conectar a alguma coisa pelo BrainTrust. Outra coisa, caso estejam acompanhando e usando um gateway que talvez tenha firewalls…

37:13 …provavelmente verão alguns erros deste lado. Saibam que há maneiras de permitir certos endereços IP nesses diferentes lugares que talvez aceitem apenas determinados endereços IP, como um gateway. Vou parar de compartilhar por um instante para vocês não verem minha API key.

38:07 Certo, mais uma coisa: também vou gerar uma API key. Certo. >> Certo. Para recapitular o que acabei de fazer aqui,

38:38 acessei os provedores de IA. Adicionei OpenAI e Anthropic usando API keys. Vocês precisarão disso se configurarem a pontuação online e usarem avaliadores como parte dela: será necessário escolher algum tipo de modelo. Outra observação: quando vocês realmente executam essas pontuações, usam seus próprios modelos para isso. A única exceção é o pipeline Topics, que usa os modelos integrados do BrainTrust para esse pipeline complexo.

39:13 Certo. Então, basicamente, acabamos de fazer a etapa zero. Criamos uma nova organização. Temos um projeto chamado AI e-workshop. Temos um provedor de IA e uma API key. Se ainda não fizeram isso, certo? Agora podemos clonar este repo.

39:55 Parece que não atualizei alguma coisa no código. Certo. Mais uma vez.

40:27 >> Certo, alguém pode sinalizar com positivo ou negativo: está tudo bem ou preciso aumentar o zoom? Beleza. Certo, vamos começar a passar por isso. Obviamente, vamos usar algumas ferramentas diferentes para viabilizar isso. Estou usando UV como gerenciador de pacotes para instalar todas as minhas dependências de Python. Então, se ainda não tiverem UV instalado, usem este comando. Eu já tenho, então vou executar UV sync e adicionar também algumas dependências de desenvolvimento…

40:57 …isso deve criar um ambiente virtual no seu diretório e instalar tudo o que é necessário para executar este workshop. A próxima coisa que faremos é criar nosso arquivo .env, e já temos um arquivo de exemplo. Então, vocês podem copiá-lo. Neste arquivo, só precisam adicionar uma API key gerada no BrainTrust e definir um modelo padrão. Isso só é necessário se quiserem iniciar a interface de chat ou executar evals, acho. Mas essas são as duas coisas que vocês criariam ou modificariam no arquivo .env que acabaram de copiar para viabilizar e executar este workshop.

41:27 Há outras coisas ali; o arquivo .env tem instruções sobre o que mais vocês podem alterar. Por exemplo, se quiserem seguir as práticas recomendadas de que falamos antes, talvez criando ou usando um modelo avaliador melhor, mais poderoso, também podem fazer isso. Só que, se vocês não…

41:58 ciente do que isso deveria ser, aqui está o arquivo .env que acabamos de copiar. Novamente, estou apenas modificando ou adicionando minha chave de API do Braintrust e, em seguida, adicionei um modelo padrão. Obviamente, esse modelo padrão será algo acessível pelos provedores que configurei no Braintrust. Então, se eu usar OpenAI, vou usar um modelo GPT; Anthropic, Sonnet, e assim por diante. Portanto, certifique-se de que essas duas coisas correspondam.

42:29 A outra coisa que será muito importante para este workshop é instalar o Braintrust CLI. Isso permitirá que vocês executem SQL arbitrário, executem evals, visualizem os logs e criem conjuntos de dados. Pensem naquele ciclo virtuoso que acabei de descrever: muitas dessas coisas fazem parte dele, e podemos conectá-las ao nosso agent para que ele mesmo comece a executá-las, como vocês verão no final do workshop.

42:59 Como vocês podem ver aqui, já tenho o Braintrust CLI instalado. Também vou executar bt setup skills e usar o Codex. Talvez vocês estejam usando Cloud Code, Open Code, Cursor, Quen ou Gemini. Isso também é compatível, mas a ideia aqui é dar ao nosso agent de programação acesso a algumas skills para entender como criar um conjunto de dados, executar evals, escrever SQL e assim por diante.

43:33 É. Mudar para o quê? Ah, sim. É uma ótima ideia. Eu não acho que já tenha feito isso aqui. >> [risos] >> Alguma ideia?

44:17 >> O que é? Control B?

44:50 Vamos fazer isso.

45:43 Desculpe? Command Shift B? Digitar o quê? >> Certo. >> [risos]

46:14 >> Imagino que todos vocês estivessem esperando me ver navegando pelo terminal sem fazer ideia do que estou fazendo. Então, está tudo certo. Assim é melhor para todo mundo. Ótimo. Desculpem por isso. Certo, beleza. A próxima coisa que faremos é inicializar o CLI. Vou fazer algo um pouco diferente porque já inicializei uma sessão e fiz OAuth no Braintrust para acessar uma organização diferente. Então, vou executar…

46:44 uma organização diferente. Então, vou executar… Opa. Novamente, se vocês já têm o Braintrust CLI e criaram uma nova organização, vão passar por esse processo e depois selecionar a organização que acabaram de criar. No meu caso, era ABC DPG. Legal.

47:15 Depois vou executar bt init e procurar ABC. Isso vai criar um arquivo config.json no diretório para que, quando o BT for executado, saiba a qual organização e projeto acessar. Dá para imaginar esse arquivo sendo incluído no repo de vocês. Assim, todos os engenheiros terão acesso a ele, e o BT terá uma forma mais fácil de entender de qual organização e projeto deve executar um eval e consultar dados. Legal. Vamos…

47:45 Agora vamos configurar algumas das coisas diferentes de que precisaremos para o workshop. Vou apenas preencher um banco de dados. Vou pular este comando de smoke test, mas vou executar make ready. Se vocês não tiverem make ou acesso a ele, os comandos propriamente ditos estão logo abaixo e também podem ser executados. O que isso está fazendo agora é verificar: “Certo, configuramos tudo corretamente? Temos o Braintrust CLI? Temos uma chave de API do Braintrust? Temos um modelo padrão? Esse tipo de coisa.” Então, acho que podemos seguir em frente.

48:16 Agora, só para dar uma ideia do caso de uso, pelo menos neste exemplo, que estamos viabilizando: é um chatbot muito simples, mas o que quero entender é se ele está conectado da maneira correta. Estamos vendo os logs chegarem ao Braintrust? Acabei de clicar no botão do nosso chat. Agora devemos ver um log aparecer no Braintrust com a pergunta que acabamos de fazer. Aqui está um exemplo de trace que acabou de ser criado…

48:48 com base, vocês sabem, na integração que temos com o OpenAI Agents SDK. Acho que, seguindo essa ideia, vou mostrar como é uma integração no Braintrust. Este é, obviamente, um único exemplo. Mas tudo o que estamos fazendo é isto. É isso que estamos importando do Braintrust SDK, e estamos definindo o processador de trace como um processador de tracing do Braintrust.

49:20 Há também uma forma mais fácil de fazer isso. Existe um instrumento automático que exige uma única alteração de linha. O motivo de eu ter feito assim é que também estou usando o gateway da Braintrust nos bastidores. Talvez eu não tenha explicado isso muito bem. A Braintrust também tem um gateway. Assim, podemos acessar todos os provedores de IA configurados no Braintrust por meio de uma única interface, que é o que estamos fazendo aqui, mas configuramos o tracing pelo nosso SDK,

49:51 diretamente para os agents da OpenAI. Estamos definindo esse processador de trace como um processador de tracing do Braintrust. E, novamente, isso significa que todos os traces e spans emitidos vão agora para o Braintrust. Talvez possamos fazer isso… Na verdade, não vamos fazer daqui, porque esse não é o modo claro. Certo. Também tenho um script aqui — ou código aqui — para executar evals. E, obviamente, esse não é necessariamente o objetivo do workshop,

50:22 certo? Estamos falando um pouco sobre observabilidade. Mas acho que, no contexto da observabilidade, é preciso pensar no ciclo virtuoso. E parte desse ciclo são os evals. O que conseguimos entender e deduzir sobre o que aconteceu em produção deve voltar para os nossos evals. No repo de vocês também há um conjunto de dados fictício, com alguns casos de teste que queremos agora executar no nosso eval. Então, o que acabamos de fazer foi usar novamente o Braintrust CLI. Criamos um conjunto de dados

50:52 e carregamos uma série de linhas por meio dele. Agora vou executar o eval. Mais uma vez, ele vai percorrer esse conjunto de dados, passar por cada linha e invocar o nosso agent. Depois, vamos armazenar todo esse tipo de telemetria e os resultados do eval diretamente no Braintrust. Mas também dá para imaginar como isso será extremamente informativo quando executarmos esse ciclo virtuoso, quando começarmos a entender e fizermos uma alteração. Em geral, queremos compará-la

51:23 com alguma coisa. Queremos conseguir entender se melhoramos ou regredimos em relação à última vez que executamos esse eval. Então, vou abrir o Braintrust. Agora devemos ver, na página de experimentos, o eval que executamos. Vocês veem a série de pontuações que definimos para este caso de uso específico. Também dá para ver — e talvez eu mostre isso daqui a pouco — que temos pontuações diferentes. Como descrevi antes, algumas são mais baseadas em código. Por exemplo, “ferramentas obrigatórias chamadas”: “Certo, tenho esta pergunta. É isto que espero.” Depois, temos algo um pouco mais próximo de um LLM judge, como a resolução do suporte e a qualidade do uso das ferramentas.

51:53 Então, temos uma série, ou uma combinação, de pontuações que podem fornecer o sinal certo para entender o que está acontecendo com o nosso agent. Certo, vamos ao ponto principal. A ideia aqui é que agora podemos criar algum tipo de sinal nos nossos logs. Obviamente, temos apenas um log no momento, e vamos precisar…

52:25 gerar alguns dados e colocá-los no Braintrust. Mas, antes de fazermos isso, vamos usar essa série de scores e enviá-los ao Braintrust para podermos configurar uma automação que seja executada quando os logs chegarem ao Braintrust. Então, de novo, vou usar este comando make push scores. Ele vai procurar a série de scores que criamos e enviá-los ao Braintrust. Há uma maneira de defini-los na interface. Você também pode, como veem aqui, definir seus

52:56 scores no código e enviá-los ao Braintrust. A ideia é executá-los como parte de uma automação online ou, talvez, também temos um playground, e você pode compartilhá-los com outro usuário do playground. Assim, ele pode usar o mesmo score, mas com controle de versão no seu repo. De novo, aqui está a série de ferramentas que acabamos de… Desculpem, a série de scores que acabamos de carregar no Braintrust. Agora, se forem à aba de scores, devem ver os diferentes scores que criamos. Então, tenho, vamos dizer,

53:28 a resolução do suporte como exemplo, certo? Este será um avaliador LLM. E o que vocês estão fazendo aqui, de novo, é definir os critérios com base nos quais querem avaliar algo, considerando a interação do usuário com esse agent. Uma coisa que eu destacaria é que há diferentes tipos de variáveis que vocês podem acessar e passar para um avaliador LLM. Essa thread é mais ou menos o que descrevi antes. É o que vocês veriam se fossem à nossa página de logs e clicassem na

54:00 thread, que é este ícone aqui, mas, na verdade, ela só mostra a troca de mensagens desse agent, certo? Isso é muito útil, especialmente se vocês tiverem uma conversa com várias interações e quiserem passar a conversa inteira ao LLM. Podem usar uma variável chamada thread. Há outras que também podem usar, como mensagens do usuário ou mensagens do assistente, ou simplesmente a entrada e a saída de um span específico, porque querem criar um score que entenda e avalie, por exemplo, a consulta à política.

54:30 Mas há algumas maneiras diferentes de começar a pensar em como avaliar a qualidade do meu agent em várias dimensões. Agora que carregamos nossos scores no Braintrust, o que precisamos fazer é conectá-los para que sejam executados quando os traces chegarem ao Braintrust. No Braintrust, isso é feito por meio de uma automação. Se olharem na página de logs, verão Automations aqui no canto superior direito. É aqui que vocês podem começar

55:02 a criar regras que acionem seus scores. Se olharem para o escopo aqui, isso é muito importante, especialmente quando começamos a pensar nos diferentes casos de uso. Vocês podem pensar: “Tenho uma conversa com várias interações, mas minhas interações estão distribuídas por diferentes traces. Não as vejo aninhadas umas nas outras; não vejo cada interação aninhada em um único trace.” Nesse caso, talvez eu queira selecionar este escopo de grupo e então

55:33 fornecer algum tipo de ID, alguma forma de entender como as coisas estão relacionadas. No meu caso, é um ID de conversa. Outra coisa que talvez queiram fazer é criar um score acionado para um span específico. De novo, vocês querem avaliar algum tipo de saída intermediária ou etapa intermediária e definir como alvo um span específico. Quando fazem isso e clicam em span, o padrão será root. Vocês também podem adicionar qualquer tipo de filtro, por exemplo, para reconhecer minha consulta à política,

56:03 e, neste caso, quero dizer algo assim. Quero entender se isso é root ou se o nome do atributo do span é lookup policy. Há também, de novo, a opção trace, que é o que vamos usar nesta demonstração. Isso nos permitirá acessar todos os diferentes spans dentro desse trace para gerar um score. Então, neste caso, vou selecionar a qualidade da comunicação, a resolução do suporte e a qualidade do uso de ferramentas.

56:34 Esses são todos avaliadores LLM. Se estiverem acompanhando, saibam que, dependendo da taxa de amostragem definida aqui, haverá custo de computação de modelo quando carregarem dados no Braintrust por meio desses avaliadores. Só queria destacar isso. De novo, se estiverem acompanhando e talvez queiram reduzir um pouco essa taxa… Vou definir como 100% para que vocês tenham um sinal bem claro, ou uma boa ideia de como isso pode ficar.

57:04 Então, o que acabei de fazer foi dizer: “Ei, quero executar esses scores em quaisquer novos logs que chegarem ao Braintrust e quero executá-los no trace.” Certo. Vamos passar aos tópicos agora. Há um lado do nosso sinal que podemos criar. Esta é a maneira mais específica de entender um modo de falha, certo? Talvez seja algo para o qual estamos, obviamente, fazendo evals. Identificamos que precisamos entender se estamos causando alguma regressão ao mudar algo no nosso agent. Os tópicos, por outro lado, são mais voltados às incógnitas desconhecidas. São áreas para as quais ainda não estamos fazendo testes ou das quais ainda não temos conhecimento.

57:36 Vocês também vão notar, logo ao lado de Automations, a opção Enable topics. E, na verdade, deixa eu voltar. Acho que a primeira coisa que vamos fazer aqui é ativar os tópicos. Vocês verão uma tela como esta. E verão os recursos integrados: tarefa, sentimento e

58:06 problemas. Ou seja, o que eu descrevi: o que as pessoas ou os usuários estão fazendo com meu agent, qual é o sentimento deles — estão felizes, estão tristes? — e quais são os diferentes tipos de problemas que estão enfrentando na interação com esse agent. Vou ativar isso. Isso será aplicado aos traces existentes. Obviamente, ainda não há muitos dados aqui, então, com o tempo, veremos alguns dados aparecerem. O que também permite que vocês tragam sua própria maneira de identificar padrões nos dados é a possibilidade de criar sua

58:37 própria faceta. Vocês também vão notar que é aqui que podem definir seu próprio pré-processador. Hoje, vamos usar o padrão, thread, mas saibam que, se quiserem trazer sua própria função para o Braintrust para analisar algo nesse trace, podem fazer isso. Se olharem, há também um arquivo nesse repo chamado support workflow issue facet. É um arquivo Markdown. Esse é o prompt que usaremos para nossa faceta personalizada.

59:08 Então, de volta ao Braintrust, vou copiar o nome support workflow issue. Essa será nossa faceta personalizada. Depois, quero copiar o prompt daqui. Outra coisa que provavelmente vão querer fazer é excluir determinadas saídas de facetas. Como podem ver, instruí o LLM a retornar none quando

59:39 os critérios a seguir forem atendidos. O que não quero necessariamente ver são facetas geradas que digam algo como: “Ei, não há nenhum problema aqui.” Estou realmente interessado apenas nas coisas que estão dando errado. Então, vou copiar também esta regex que está no início e colá-la aqui. Vocês também podem optar por aplicar isso aos traces existentes. Neste caso, isso não é muito importante, porque não temos muitos. Então, quanto aos tópicos, é isso.

1:00:10 Na verdade, tudo o que você precisa fazer para começar a entender se consegue identificar alguns padrões nos seus dados. Se você voltar ao nosso repo e procurar talvez uma maneira diferente… Não vou passar por isso, mas queria destacar novamente a possibilidade de usar a CLI do Braintrust para fazer várias coisas interessantes. Então, aquele workflow que acabei de mostrar na interface também pode ser feito aqui no BT. Eu

1:00:40 posso configurar esses tópicos para serem executados. Posso configurar essas definições de automação. Aqui, defini os problemas de sentimento das tarefas e os problemas do workflow de suporte. Outra coisa que fiz — vocês também podem ver algumas configurações diferentes ali embaixo — é que há várias maneiras de configurar as definições, certo? Então, dá para controlar como o pipeline que roda em tempo real é executado ou em quais dados ele é executado. Com isso, quero dizer que talvez você queira adicionar um filtro. Talvez queira dizer: “Só quero executar meu pipeline de tópicos nos traces que

1:01:12 atendam a estes critérios.” Talvez você também queira aplicar algum tipo de taxa de amostragem com base em alguma métrica conhecida sobre o tráfego e o custo que isso pode gerar, e assim por diante. Você também vai querer entender a janela dos tópicos. Por exemplo, quando eu gerar meu mapa de tópicos, qual intervalo de traces devo usar com base em uma janela? Este… Acho que talvez seja a pergunta que você fez antes, alguém de camisa verde: como configuro isso quando tenho conversas de longa duração?

1:01:44 Parte disso é o agrupamento por escopo, que permite incluir talvez outros traces, outras interações que existam em traces diferentes. Esta é outra configuração que você pode ajustar. Talvez queira definir um dia, talvez dois dias. Vocês sabem que as conversas que os agents têm com os usuários, ou que os usuários têm com os agents, podem se estender por um período bem longo. Assim, você pode configurar quando o pipeline de tópicos será acionado. Vou escolher aqui um período bem curto. Mas, de novo, você pode

1:02:16 configurar isso com base no que entende sobre a interação dos usuários com seus dados. Desculpem, a interação dos usuários com o seu agent. Mais uma vez, há o mesmo tipo de escopo que destaquei para as pontuações. Você pode executar isso em cada trace individual. Ou, se tiver aquela conversa com várias interações distribuída por vários traces, pode usar este agrupamento e então usar aquele identificador comum, certo? No meu caso, tenho um ID de conversa que está sendo registrado como metadado. Então, vou clicar em salvar.

1:02:51 Agora temos os tópicos configurados. Ativamos os que vêm prontos para uso e também criamos nossa própria faceta personalizada. Em seguida, configuramos as definições de automação para serem executadas quando os dados chegarem ao Braintrust. Além disso, agora podemos começar a ver como isso fica na prática. Há um comando aqui para executar… Tenho alguns dados de traces armazenados em um bucket do S3. Vamos importá-los.

1:03:21 Mais uma vez, por baixo dos panos, o que vocês vão ver é o BT sync. Assim, podemos pegar esses dados e enviá-los para o Braintrust. Talvez isso responda à sua pergunta, alguém de camisa azul, sobre o LangSmith. Já ajudei muitos clientes a importar traces de outros provedores porque queriam manter ou continuar tendo acesso a parte desses dados. Mas queria destacar que esta é uma ótima maneira de fazer isso em escala. Então, vocês podem ver aqui que acabamos de

1:03:51 carregar 968 traces. 1.052 spans — esse é o valor… desculpem, são 5.260 spans. Então, é uma maneira bem rápida de colocar dados no Braintrust. Mas, novamente, a ideia toda aqui é começar a gerar alguns sinais e entender onde podemos fazer melhorias no nosso agent. Vocês vão começar a ver alguns exemplos de traces. Também vão notar que há duas

1:04:21 coisas aqui. Cada interação é representada como um trace próprio. Então, esta é a pergunta mais recente do usuário, e aqui está a resposta para essa pergunta. Vocês também podem notar que há 11 mensagens anteriores. Assim, talvez eu queira trazer o ID da conversa. Com isso, posso começar a buscar outros traces que tenham os mesmos metadados. Mas os agents da OpenAI oferecem uma espécie de atalho, pois anexam todas aquelas mensagens anteriores. Então, não precisamos necessariamente passar por essa etapa, mas queria destacar outro recurso do Braintrust, que permite agrupar traces por alguns metadados arbitrários que você definiu e que são compartilhados entre esses traces. Você pode trazer todos os traces relevantes para esta árvore. Bem rapidinho, certo? A visualização em thread é uma ótima maneira de entender a interação de ida e volta do seu agent. Também há a visualização de linha do tempo, que é uma ótima maneira

1:04:52 de entender onde talvez existam gargalos. Você também pode ver informações muito interessantes sobre cache hit nas diferentes chamadas de LLM. Acho que essas informações podem ser úteis em vários tipos diferentes de workflow. Outro recurso que eu destacaria, e ainda não falei sobre ele, é este pequeno ícone azul no canto inferior direito: nosso agent loop. Todo mundo tem um agent, certo? Então, você pode usar o loop para fazer várias coisas diferentes na plataforma. Na verdade, pode usar o loop para criar sua própria interface sobre esses dados de traces.

1:05:23 E acho que esta é uma ótima maneira de fazer aquilo que mencionei sobre o outro método de pontuação: permitir que pessoas revisem as respostas do agent ou dos próprios LLM judges e forneçam calibração. Você pode pedir isso ao loop, e ele vai criar uma interface usando vibe coding sobre os dados de traces. É uma maneira diferente de incluir talvez outra persona para contribuir com esse flywheel. Vocês também vão notar que algumas automações estão começando a ser acionadas. Então,

1:05:56 temos minha automação de judge: qualidade da comunicação, resolução do suporte e assim por diante. E vocês também devem começar a ver alguns tópicos sendo gerados. Neste caso, temos um usuário que quer verificar o status do reembolso de um item devolvido, e assim por diante. Temos um sentimento negativo. O usuário expressou frustração e insatisfação com o status de uma transação pendente. Aqui está meu workflow de suporte, minha faceta personalizada. Houve uma falha na recuperação do registro do pedido. Tanto as buscas por IDs de pedido específicos quanto as buscas mais amplas por clientes

1:06:26 não conseguiram localizar o pedido. Então, só queria destacar duas coisas diferentes aqui, certo? Carregamos traces no Braintrust e, com base nas automações e nos tópicos que configuramos, estamos começando a receber esses sinais em tempo real. Aquele pipeline complexo que identifica padrões nos seus dados aparece imediatamente, certo? Ele aparece com base na forma como você configurou o pipeline, obviamente. Esse é o sinal que vamos poder usar. Enquanto isso começa a ser preenchido, vou abrir

1:06:57 outro projeto em que já executei isso. Mostrei algumas ilustrações antes do que isso pode começar a parecer no Braintrust. No topo desta página, vocês veem um retrato dos tópicos em determinado momento e a frequência com que os traces foram agrupados, conforme identificamos padrões neles. Vou expandir o primeiro exemplo.

1:07:28 Então, o que vocês começam a ver no topo desta página é um retrato dos tópicos em determinado momento e da frequência com que os traces nos quais identificamos padrões estão sendo agrupados. Vou expandir o primeiro exemplo.

1:07:58 Consigo entender o que os usuários estão tentando fazer com meu agent, certo? Posso ver no topo que a resolução de danos e problemas de trânsito parece ser, mais uma vez, a coisa mais frequente para a qual os usuários usam meu agent. E acho que isso remete ao que eu estava descrevendo antes, quando estava passando pelos slides: posso usar algumas dessas informações para entender onde meu agent poderia avançar ou o que ainda não construí nele, mas que os usuários estão tentando fazer. Tudo isso, em conjunto, será usado para, de certa forma,

1:08:31 informar esse ciclo virtuoso. Um pouco mais abaixo, tenho meu tópico de sentimento. Meus problemas não foram gerados. O motivo é que procuramos pelo menos 100 correspondências ou 100 facetas geradas como parte desse pipeline. E esse agent que criei e o prompt pronto para uso que temos para problemas não combinam exatamente, e, por isso, não geramos facetas. Mas acho que isso é algo bom. Quer dizer,

1:09:01 não queremos simplesmente gerar dados ruins. Não queremos simplesmente gerar um sinal com o qual você não possa realmente fazer nada. E foi por isso que criei meus problemas de workflow de suporte. Neste caso, estou começando a entender: ei, há uma falha na busca de registros. Há algo acontecendo com meu agent que, mais uma vez, não identificamos com nossos evals, mas estamos entendendo que ocorre uma falha na busca durante o processo do agent. Certo, esse é o tipo de informação que, considerada em conjunto, com o contexto das nossas pontuações online, realmente me permite fazer algo e

1:09:33 melhorar meu agent de alguma forma. Alguma pergunta? Legal. Certo. Quero mostrar um workflow que, acho, certamente segui quando comecei na BrainTrust, e que acredito que muitas pessoas também seguiram, certo?

1:10:03 Geramos esse sinal. Ótimo. Agora preciso conseguir fazer algo com ele. Acho que, obviamente, na interface da BrainTrust, há muitas coisas diferentes que posso usar para começar a entender ou, mais uma vez, filtrar esse ruído. Talvez eu queira olhar os diferentes classificadores ou os diferentes rótulos aplicados a esses rastros, certo? Eles correspondem àqueles tópicos que vocês viram na outra ilustração. Posso usar isso para filtrar os resultados.

1:10:35 Provavelmente aumentar isso. Não. Em teoria, posso usar isso para filtrar os resultados de alguma forma, certo? Com base no feedback que estamos recebendo, e entender o que posso fazer a partir daí, certo? Então, filtrei o conjunto de resultados. Estou examinando um rastro e identificando o que deu errado ao analisar o rastro e os intervalos nele. Talvez eu esteja usando novamente minhas pontuações online para filtrar ainda mais esse conjunto de resultados,

1:11:06 talvez até mais. Mas acho que o workflow que vocês podem seguir é usar essa interface e começar a entender todas as coisas diferentes, tudo o que está dando errado. Vou pegar minha tarefa X e combiná-la com esse sentimento; quero ver que tipo de insight consigo extrair disso. Gerar o sinal é ótimo. Agora temos muitos dados com os quais podemos tomar algumas dessas decisões informadas, mas acho que vocês também conseguem reconhecer o problema dessa abordagem. É que estou sempre reagindo. A responsabilidade fica

1:11:37 comigo, como usuário da BrainTrust: preciso percorrer a interface, clicar em botões, filtrar e depois analisar esses rastros. Tem que haver um jeito melhor. Talvez eu queira usar o Loop. O Loop é, mais uma vez, o agent integrado à plataforma, que pode fazer coisas diferentes. Neste caso, pedi: “Ajude-me a entender o que devo melhorar no meu agent de suporte com base nos logs recentes.” Uma das coisas que vocês vão começar a perceber, e que acho realmente interessante do ponto de vista do ciclo virtuoso, é como podemos começar a incorporar

1:12:09 dados relevantes para informar esse ciclo virtuoso. Outra coisa que acho interessante na BrainTrust, especificamente no Brain Store, o backend que a alimenta, é que você pode executar SQL diretamente nele. É possível acessar todos esses dados de rastreamento e todos esses intervalos escrevendo SQL. Talvez você não queira escrever esse SQL, mas seu coding agent consegue escrevê-lo com muita facilidade. E o que vocês estão vendo acontecer aqui é o Loop. Mais uma vez, o Loop é nosso agent na plataforma. Fiz uma pergunta, e o que

1:12:39 o Loop fez foi começar a executar várias consultas SQL. Ele está incorporando o contexto relevante para a pergunta que fiz. O que provavelmente não dá para fazer — e, mais uma vez, pensando em escala, você não vai buscar cada rastro para procurar sinais usando seus agents, seus coding agents. Você precisa que esse sinal esteja associado aos seus rastros de alguma forma, e precisa que esse sinal seja real. Depois, precisa de uma maneira muito flexível de consultar todos esses dados, para poder buscar apenas aquela parte relevante da informação.

1:13:10 A última coisa que não aparece neste exemplo, mas que vocês verão um pouco mais adiante, é que, depois de encontrar exemplos interessantes com base no sinal gerado, quero ir até eles. Quero investigar aquele rastro. Quero clicar naquele intervalo. Quero ver a entrada. Quero ver a saída. Certo, esse é o tipo de análise que eu provavelmente faria, mas não consigo fazer em escala. Mas, se eu puder delegar parte disso ao Loop para orientar o que talvez eu mude, corrija ou acrescente, ou se puder delegar ao meu coding agent, esse

1:13:40 é o tipo de coisa que, na minha opinião, realmente melhora a qualidade do agent de forma muito eficiente. Vou passar por algumas partes, mas o que descrevi aqui foi usar tópicos e pontuações para entender e analisar esses dados com base no sinal. O que vocês também podem fazer agora é usar esse conjunto filtrado de dados. Vocês encontraram um exemplo interessante e querem

1:14:12 adicioná-lo a um conjunto de dados, certo? Isso é o que nos permite melhorar o agent. Quero levar esse exemplo de volta aos meus evals offline. Posso fazer isso aqui pela interface. Vou adicioná-lo ao meu conjunto de dados. Agora tenho esse caso extremo, algo que preciso melhorar, ou um novo recurso que preciso adicionar com base no que vi na interação desse usuário com meu agent. Posso adicioná-lo de volta ao meu conjunto de dados. Mas, mais uma vez, o importante aqui é adicionar ao conjunto de dados o item certo, com base no sinal criado

1:14:42 nos nossos logs. E, claro, vocês não querem me ver programar e tentar descobrir se consigo melhorar o agent. Mas, depois que eu fizesse isso, executaria meus evals de novo. Compararia com a última vez que executei os evals. Houve melhora? Houve regressão? Aquele novo exemplo que adicionei ficou melhor? Será que realmente melhorei as pontuações que obtive em uma avaliação online? Outra coisa que talvez vocês queiram fazer é: ao reconhecer esses novos casos extremos, provavelmente vão querer criar um

1:15:13 pontuação. Certo? Tenho uma falha na consulta de registros. Esse pareceu ser o problema que encontrei com mais frequência. Provavelmente quero criar uma pontuação que me permita capturar isso antes de levar meu agent para produção. Então, há todas essas etapas, certo? Essas coisas que você provavelmente vai querer fazer para criar esse flywheel. E acho que isso fica realmente poderoso quando você consegue executar tudo de forma automatizada. Quando posso conectar uma skill ou algum tipo de workflow usando todos os recursos básicos que acabei de

1:15:44 descrever para automatizar tudo isso. Então, se você olhar aqui o nosso arquivo Markdown do workshop, há um repo no GitHub com skills que disponibilizamos. Na verdade, no momento há apenas uma skill. A ideia é dar aos seus agents de programação a capacidade de executar esse flywheel automatizado. Certo? Queremos passar exatamente pelo mesmo processo. Quero que o Codex, o Cloud Code ou qualquer outra ferramenta escreva SQL. Quero que ele visualize traces. Quero que visualize spans. Quero que crie novas pontuações e execute

1:16:16 evals e modifique algo no meu agent, e quero fazer isso acompanhando a tela. Sim, pode ir. Sim, então, se você olhar para a minha eval que criei

1:16:53 Então, é mais ou menos assim que uma eval aparece no Braintrust. Seu conjunto de dados aqui, na verdade, faz parte dos comandos que executamos no início para carregar nossos dados de exemplo, como a série de casos de teste, no Braintrust. Mas também dá para imaginar que, no início, esta é minha visão mais delimitada do mundo em que meu agent opera, certo? Estes são os casos de teste que quero fornecer a ele para entender: “Ei, devo levar isso para produção?” Mas a operação da

1:17:24 coisa que estou descrevendo é que você começa a melhorar mais a qualidade quando consegue selecionar traces e exemplos da produção e trazê-los de volta para o seu conjunto de dados. Então, isto aqui, esse workflow bem simples, é o que eu estava descrevendo. Este registro fixado, esta linha, este trace, talvez indique algum modo de falha. E quero trazê-lo de volta para um

1:17:54 conjunto de dados existente ou para um novo conjunto de dados contra o qual quero executar uma eval. Certo. Então, acho que o resultado de tudo isso é como podemos usar todos aqueles recursos básicos que descrevi antes. Acho que o pipeline de tópicos executado em segundo plano é meio que

1:18:24 a estrela do show. A importância de adicionar itens ao conjunto de dados, porém, é que suas evals devem evoluir junto com seu agent. Quando penso em evals, penso em um conjunto de dados. Penso no meu agent, certo? É como uma função que invoca meu agent. E depois penso na série de pontuações que me permite entender se o resultado é bom ou ruim em relação aos casos de teste enviados ao meu agent. Mas, quando crio meu conjunto de evals,

1:18:55 é uma forma de estabelecer uma linha de base. Certamente, ele não representa por completo tudo o que os usuários podem fazer com meu agent. Então, ao adicionar novos registros a esse conjunto de dados, consigo capturar diferentes modos de falha ao longo do tempo e fazer alterações no meu agent para que, certo, não continuemos tendo esses problemas no futuro. Mas trata-se mais da evolução do seu agent e de garantir

1:19:26 que todas essas coisas relacionadas às suas evals evoluam junto com ele. Assim, você pode, primeiro, capturar coisas novas, mas também, à medida que altera seu código, evita regressões no seu agent com base nas interações anteriores que selecionou para incluir no conjunto de dados. Há algumas maneiras diferentes de instalar isso. Vou escolher a primeira opção. >> [limpa a garganta] >> Se você tiver o GitHub CLI instalado, pode usá-lo. Também há o NPX.

1:19:58 E também dá para clonar o repo localmente e seguir as instruções de instalação específicas dos agents que você está usando. Certo. Temos o arquivo da skill. Instalamos. Então, agora talvez eu queira executar esse flywheel. Quero vê-lo em ação. Vou fazer duas coisas diferentes aqui.

1:20:28 Vou executar isto. Depois, vou mostrar um exemplo anterior para que vocês não fiquem só aqui assistindo ao Codex rodar. Então, vamos fazer isso. Vamos deixar rodando. Vou abrir outro repo. Certo. O mesmo prompt. E, na verdade, deixa eu… Acho que acabei

1:20:58 pulando uma coisa que provavelmente é importante destacar. Certo, os logs gerados aqui, ou os tópicos gerados. Então, agora temos todos esses sinais, certo? Esta é a coisa contra a qual acabei de executar o Codex neste projeto. Agora ele deve conseguir recuperar todos esses itens diferentes, certo? Essas tarefas, esses sentimentos, essa questão do workflow de suporte. Tudo isso, e essas pontuações estão associadas a esses traces e agora fazem parte deste workflow.

1:21:29 Então, vamos deixar isso rodando neste terminal aqui. Certo, vamos voltar a este enquanto ele executa. Assim como vocês viram na sessão do Loop, o que vão começar a ver aqui é o Codex escrevendo comandos SQL. Então, BT SQL, e vamos recuperar todas essas informações, ou as informações relevantes, para a sessão. Assim, agora podemos consultar este projeto e estes traces com flexibilidade, e também devemos conseguir reconhecer

1:22:01 e entender — ou o Codex deve conseguir reconhecer e entender — esses tópicos e essas pontuações que foram calculadas. Então, veja, temos 968 traces de suporte, exatamente o que carregamos. Há falhas pontuadas e um agrupamento visível de erros de ferramentas ao escalar para um humano. Vou inspecionar os resultados do classificador e os traces de falha representativos e transformar isso em um resumo concreto. Então, novamente, a capacidade de fazer consultas flexíveis com essa ferramenta SQL é bastante impressionante. Parece

1:22:33 que conseguiu reconhecer algo nas nossas pontuações. E continua fazendo consultas. E isso é o que descrevi antes: poder investigar um trace individual. Encontrou algo. Encontrou um exemplo que nos permitiria melhorar nosso agent de alguma forma mensurável. Queremos visualizar esse trace, escrever mais SQL, mas é isso que nos permite ser bem abrangentes e realmente trazer todos esses dados tão ricos, selecionando apenas os itens que de fato vão impulsionar alguma mudança que possamos fazer no nosso agent.

1:23:05 Certo, vamos ver o que mais fizemos aqui. Parece que estamos vendo como executar evals. Estamos visualizando conjuntos de dados existentes. Acabamos de criar um novo conjunto de dados. Na verdade, estamos no comando de ajuda. Mas espero que vocês consigam ver isto. É isso que estamos tentando criar. Estes são os… os

1:23:36 recursos básicos do Braintrust. Nossos tópicos, nosso Braintrust CLI, o backend que permite escrever SQL, uma plataforma que oferece tanto evals quanto observabilidade. Todas essas coisas, em conjunto, permitem criar esse flywheel e fazê-lo de uma forma realmente significativa. Fico feliz em responder a algumas perguntas agora. Só estamos esperando um pouco o Codex terminar de processar, mas

1:24:06 Fico curioso para saber se alguém… Sim, pode falar. Sim, temos uma implantação híbrida. Isso significa que o plano de dados, onde todos os dados ficam — seus traces, seus experimentos, seus conjuntos de dados — permanece na sua infraestrutura, mas o plano de controle, como o aplicativo web que você está vendo, fica conosco.

1:24:37 A implantação híbrida só está disponível no plano Enterprise. Sim. Para complementar esse ponto, caso tenham curiosidade, existem duas modalidades diferentes. Há a opção BYOC, em que, novamente, o plano de dados é implantado na sua infraestrutura, mas nós o gerenciamos para você. E há uma opção mais híbrida, implantada no seu plano de dados e gerenciada pela sua equipe. Temos um provider do Terraform ou Helm charts, dependendo da nuvem que vocês usam. Alguém no fundo da sala? Não precisa gritar.

1:25:26 Acho que, na maior parte dos casos — e acho que isso está mudando um pouco — as pessoas estão usando mais os modelos dos grandes provedores de modelos. Em geral, é isso que tenho visto. Acho que isso está começando a mudar um pouco. Sei que, no começo, o uso era muito concentrado nos grandes provedores de modelos. Não sei dizer especificamente; não cheguei a ver modelos pequenos, necessariamente, mas vi pessoas começarem a fazer fine-tune de seus próprios modelos e

1:25:58 e ver se isso consegue impulsionar — a ideia toda, por trás disso, são os evals, por exemplo — a capacidade de entender se posso alternar entre modelos sem introduzir regressões ou piorar a qualidade do agent. Mas, sim, eu diria que, em grande parte, são os grandes provedores de modelos, embora isso talvez esteja mudando um pouco.

1:26:35 Desculpe, isso é para um LLM como juiz? Ah. Sim, então, um ponto importante: provavelmente dá para ver isso naquela tela, quando você acessa as configurações de automação de tópicos e a seção avançada. A única opção que você tem para

1:27:06 tanto a etapa de sumarização quanto a etapa de embedding vetorial são modelos hospedados pela Braintrust. Há alguns motivos para isso. Um é que treinamos esses modelos especificamente para essa finalidade. E, em segundo lugar, a complexidade do pipeline faz com que não seja possível simplesmente conectar qualquer modelo e esperar obter resultados semelhantes. No começo, permitíamos conectar modelos diferentes nessa etapa, mas o pipeline de tópicos, ou os tópicos que

1:27:38 eram gerados como resultado, simplesmente não eram bons. Por isso, restringimos essa etapa a modelos hospedados pela Braintrust. Sim, é possível. Posso acessar…

1:28:09 Como todos esses dados existem essencialmente como metadados associados ao trace, você pode extraí-los para diferentes visualizações. Acho que, neste caso, tenho uma visualização salva. Aqui estão algumas coisas da Braintrust. Se quiser criar seu próprio dashboard ou sua própria visualização, é assim que você faz. Você pode salvar todas essas visualizações e criar seus próprios gráficos personalizados. Mas, aqui em cima, dá para ver

1:28:40 sentimento ao longo do tempo, tarefas ao longo do tempo, principais sentimentos, principais tarefas — os itens personalizados que você criou podem ser exibidos aqui. Neste caso, dá para ver que estou buscando classifications.sentiment não nulo e agrupando por esse rótulo. Então, é bem simples configurar isso. Sim, acho que sim. Mas considerem isso com cautela. Em geral, o que tenho visto é que agents mais novos, ou coisas que acabaram de entrar em produção, têm uma taxa de amostragem maior. E, com o tempo,

1:29:11 essas incógnitas conhecidas, ou os itens que suas pontuações tendem a revelar, vão diminuindo, e o sinal que você extrai disso também diminui. Então, você começa a reduzir essa taxa de amostragem. Acho que, se você estiver usando um LLM como juiz para algo mais voltado à classificação ou à taxonomia, também pode considerar alterar isso ou substituir essa abordagem por tópicos. O Dropbox é um cliente com quem trabalho, e eles têm uma série muito

1:29:42 complexa de pontuações de classificação que executam para entender uma taxonomia relacionada aos traces. Eles experimentaram usar tópicos para isso. Um dos motivos — na verdade, o mais importante — é que essa é uma maneira muito mais econômica de processar a maioria, ou até 100%, dos traces deles, algo que o LLM como juiz simplesmente não conseguia fazer em escala. Assim, é possível gerar tanto sinal quanto necessário. Então, resumindo, acho que existe um nível de maturidade

1:30:12 que, na minha opinião, determina como deve ser a taxa de amostragem. Ela tende a diminuir à medida que o agent amadurece. Além disso, há os tipos de resultados que seu LLM como juiz pode produzir. Se forem mais voltados à classificação ou à taxonomia, você pode considerar substituí-los por tópicos. Sim, isso não é possível diretamente na interface, mas você poderia criar uma pontuação no código. Certo? Imagine que eu chamo a pontuação um. Com base no resultado da pontuação um, faço algo e chamo a pontuação dois. O

1:30:42 retorno dessa função é um array de pontuações. Certo? É um array de objetos de pontuação. Mas, sim, é certamente possível; você define isso no código. Não há nada na Braintrust que permita dizer: “Quero executar a pontuação A e, com base no resultado, conectá-la à pontuação B ou C”. Mas é certamente possível criar isso no código. Ah, sim. Você também poderia simplesmente

1:31:14 fazer com que seu filtro procure especificamente a presença desse score span e só seja acionado quando ele estiver presente. Sim. Esqueci qual era o cliente, mas isso surgiu outro dia e era

1:31:44 mais relacionado às tarefas. Não me lembro exatamente do que se tratava, mas era algo que eles não sabiam que os usuários estavam fazendo com o agent deles. Então, era mais um caso de uso como solicitação de recurso ou, sabe, incógnitas desconhecidas, mas em relação ao que os usuários faziam com o agent, não necessariamente um modo de falha. Acho que o mais surpreendente para mim talvez seja as pessoas estarem usando isso para descobrir esse tipo de coisa. Quando comecei a

1:32:14 experimentar o recurso e conversar com clientes, a maior parte, pelo menos para mim, era voltada aos tipos de problemas que seria possível descobrir. Mas acho que agora há uma variedade enorme de padrões que você consegue associar aos traces e, depois, usar em conjunto para entender algo sobre o mundo que você não sabia a respeito do seu agent. Então, sim, não tenho o exemplo exato do que os tópicos revelaram, mas era muito mais

1:32:46 algo como: “Nossa, eu não sabia que esses usuários estavam usando nossos agents, ou tentando usar meu agent, para isso.” No momento, eu diria que eles são orientados a casos de uso, ou você poderia até imaginá-los como específicos de um agent. No meu caso, tenho um agent de suporte e, no meu projeto, registro os logs dele no projeto do agent de suporte. Também armazeno os conjuntos de dados

1:33:17 que uso para executar os evals do meu agent de suporte. Também armazeno as pontuações desse agent nesse projeto. Então, em geral, eles funcionam como um contêiner para recursos relevantes a um caso de uso ou a um agent. Em breve, vamos introduzir no projeto um objeto de agent de primeira classe. Assim, você poderia imaginar um sistema multi-agent em que todos os logs dos agents ficam no mesmo projeto, mas ainda há uma distinção entre os agents A, B e C.

1:33:49 Ah, então você também poderia imaginar fazer isso. >> É, então, a página de monitoramento que mostrei antes tem escopo de projeto. Se você quisesse criar uma visualização com escopo mais organizacional, teria que criar consultas e extrair dados do BrainTrust. Isso vai mudar no futuro. É…

1:34:21 …mais uma questão de como permitir que nossos clientes façam isso em escala. Você poderia imaginar que tentar consultar vários projetos diferentes e reunir esses dados em um dashboard se torna um pouco desafiador. Então, sim, no momento temos escopo de projeto, mas dá para imaginar que isso vai começar a mudar com o tempo. Quer dizer, acho que isso é justo. Acho que talvez o que você veria é seus evals mudando…

1:34:53 …com a mesma frequência com que você muda o agent. E talvez nem seja tão frequente, mas acho que há a possibilidade de eles mudarem de alguma forma com base no que você consegue inferir das interações dos usuários com esse agent, certo? Isso poderia ser um prompt. Poderia ser uma ferramenta. Poderia ser uma ferramenta nova. Poderia ser algo no runtime ou na arquitetura que precisasse mudar. E, para mim, o que tenho visto com mais frequência é que seus evals geralmente mudam como resultado de algo que você está mudando. Quer dizer…

1:35:24 obviamente, se for uma mudança simples no prompt, provavelmente você não vai mudar muita coisa nos seus evals, além de talvez selecionar alguns exemplos novos para esse conjunto de dados. Mas acho que o que tenho visto é que os agents tendem a evoluir com certa frequência, e, se você estiver se orientando por interações reais com usuários, talvez eles estejam mudando um pouco mais do que você esperaria. Mas, sim, acho que é um comentário justo: se o agent…

1:35:54 …não for muito complexo, não tiver — ou, sabe, não exigir — muitas mudanças, considerando o escopo do que está fazendo, então os evals talvez não mudem muito por causa disso. Ainda acho que há valor em conseguir gerar esse sinal em produção sobre o que está acontecendo. Especialmente se você puder fazer isso de forma econômica, aí, sim, essa parte ainda tem valor, na minha opinião. Sim, tenho clientes que fazem…

1:36:25 …as duas coisas. Acho que uma parte é preferência. Às vezes, parte disso é simplesmente não entender o que o Braintrust pode fazer. Por exemplo, os codebase scores são um ótimo exemplo disso: você pode ter um codebase score muito complexo que usa diferentes dependências de Python ou TypeScript e precisa executá-lo — ou acha que precisa executá-lo — na sua própria infraestrutura, porque ele usa todas essas dependências complexas. O que você pode fazer no Braintrust, quando…

1:36:56 …você envia um score, inclusive um codebase score, é incluir dependências nesse envio. Assim, o score ainda pode usar aquilo de que depende. E conheço alguns clientes com quem trabalhei que simplesmente não sabiam que podiam fazer isso. Para mim, o valor está em não ter parte desse código assíncrono na sua própria codebase, que procura esses acionadores ou fica verificando: “Ei, este trace foi gerado e…

1:37:26 …preciso esperar 60 segundos desde o último evento para então ser acionado”. Para mim, o valor está em transferir parte dessa complexidade para o Braintrust. Mas você ainda pode fazer isso. Uma das coisas que considero únicas no modelo de dados do Braintrust é que você pode atualizar spans. Então, se esse span já existir no BrainTrust, ele é mutável. Você pode adicionar, sabe, alterar os metadados, anexar scores, anexar métricas diferentes. E, se quisesse fazer isso em…

1:37:57 …código, você já teria toda a estrutura necessária do seu lado. Aí seria bem simples dizer: “Ei, tenho este ID de span. Quero anexar a ele estes scores e métricas diferentes”. Então, acho que parte disso é apenas preferência. Algumas pessoas simplesmente querem ter um pouco mais de controle, o que é perfeitamente válido. Você certamente pode fazer isso. Para mim, é uma questão de controle de acesso baseado em funções, provavelmente. Você ainda quer conseguir gravar parte desses dados de trace e depois restringir quem…

1:38:28 …pode vê-los. Acho que o workflow que acabei de descrever — esse flywheel automatizado — é, na verdade, uma ótima maneira de fazer isso, porque posso apresentar insights às pessoas. Posso gerar um PR com base em todos esses insights, mas não dou acesso aos traces subjacentes. Dou acesso à análise desses traces. Aqui estão as consultas SQL que executei. Aqui estão os dados agregados que obtive. Se você simplesmente não tiver engenheiros capazes de ver esses dados, grave-os em um projeto ao qual ninguém…

1:38:58 …tenha acesso e restrinja o acesso dessa forma, mas depois crie uma conta de serviço que possa executar esse tipo de flywheel sobre esses dados, para que você não perca acesso a todos esses insights. Isso. Recursos mais subestimados. Meu palpite é que o BrainTrust CLI é avaliado de forma bem justa. Acho que eu…

1:39:30 …faço propaganda dele sempre que posso, ou recomendo a qualquer engenheiro. Digo isso porque acho que lançamos no fim de fevereiro. Tivemos uma conferência de usuários. E ainda hoje vou conversar com clientes e perguntar: “Vocês estão usando o Braintrust CLI? Estão usando?”. E alguns ainda não estão. Mas, para mim, apostaria que 100% de vocês estão usando algum agent de programação, certo? É assim que vocês programam hoje. Ter o CLI como parte disso… Eu…

1:40:01 …espero que vocês tenham conseguido ver alguns dos tipos de workflows que podem criar. Para mim, isso se torna incrivelmente atraente. Você já está em um terminal, já está no seu IDE, seja lá qual for. Use o CLI, conecte-o ou dê ao seu agent de programação as skills para entender como usá-lo. E use isso para ampliar seu workflow. A outra coisa que pode ser atraente, dependendo um pouco da sua organização…

1:40:32 …e das diferentes pessoas que contribuem para esse flywheel, é um recurso que chamamos de remote eval. É uma forma de disponibilizar esse eval em um playground. E isso serve mais para situações em que talvez haja especialistas no assunto, gerentes de produto ou pessoas contribuindo de alguma forma para esse flywheel. Elas podem modificar prompts ou fazer parte desse processo de otimização iterativa. E criamos todos esses recursos — essas aplicações — para que elas possam…

1:41:03 …usar de uma forma com pouco ou nenhum código. O remote eval permite disponibilizar no playground o eval que mostrei antes — aquele eval com uma tarefa e um conjunto de dados — com parâmetros, para que quem usa o playground possa começar a alterar o system prompt, a descrição de uma ferramenta ou algo assim. Isso pode ser interessante para um engenheiro de IA porque você não precisa necessariamente ser o gargalo na criação de aplicações ou na produção de algo para um produto.

1:41:33 gerente para se conectar e permitir que modifiquem um prompt ou contribuam para esse ciclo de melhoria. Então, talvez não seja tão impactante quanto a CLI, mas pode ser, dependendo da estrutura da sua organização. Acho que cobri a maior parte. Me diga onde estou enganado. Acho que o que comecei a fazer aqui é exatamente isso. O Braintrust em si, pelo menos no momento, não tem acesso ao seu código, certo? Ele não entende o que você escreveu e, com base nas informações que tem, não consegue necessariamente recomendar uma alteração em funções específicas ou na arquitetura do agent. Mas

1:42:05 quando você integra a CLI do Braintrust ao seu agent de programação e o conecta — obviamente estou no meu repo aqui —, agora consigo analisar. Vamos ver se conseguimos encontrar algo aqui. Na minha sessão, com base no que consegui entender, estamos criando novas pontuações. Então, houve uma alteração na pontuação. Podemos pular os testes.

1:42:37 Parece que há ferramentas novas que conseguimos adicionar ao nosso agent, mais uma vez com base em alguns desses insights. Então, acho que a resposta à sua pergunta é: isso é totalmente possível. O que acabei de demonstrar é esse ciclo de melhoria: “Ei, descubra o que está acontecendo em produção; use minhas pontuações ou meus tópicos, porque associei informações sobre problemas, sentimento ou

1:43:09 o que quer que seja; isso se torna extremamente convincente ou interessante para o agent incorporar e, então, modificar seu agent de alguma forma.” Acho que, mais adiante, veja, agora temos novos exemplos no nosso conjunto de dados. Parece que criamos um novo conjunto de dados com esses exemplos. Agora vamos executar nossa avaliação, provavelmente um pouco mais abaixo. Você também pode ver que estamos consultando diretamente o experimento que foi executado.

1:43:39 Então, todo esse ciclo de melhoria está registrado aqui, nesta skill de aprimoramento de agent. Espero ter respondido à sua pergunta, pelo menos em parte. Legal. Para mim, essa é uma das partes mais convincentes do Braintrust no momento. Todos estamos desenvolvendo nossos agents, em certa medida, com a ajuda de um agent de programação. Se eu conseguir trazer o contexto certo e tiver acesso às primitivas certas para associar os dados certos aos meus traces, esse ciclo de melhoria — esse ciclo de melhoria automatizado — se torna bem interessante.

1:44:30 Então, acho mesmo que é viável. Posso mostrar um exemplo. Na verdade, se eu voltar aqui… No momento, não há um botão na plataforma que você aperta e que diz: “Ei, execute o ciclo de melhoria”. Mas o que mostrei foi que você pode se integrar a isso com muita facilidade usando todas as ferramentas que já tem. O que mais você pode fazer com isso, certo? Dá para imaginar, por exemplo, integrar isso a uma ação do GitHub que é executada em determinada

1:45:01 frequência, acionada por alguma coisa, e abrir um PR. Também dá para imaginar que isso seja acionado por uma mensagem no Slack, certo? Acho que há muitas maneiras diferentes de acionar isso. Nos bastidores, tudo está disponível para você optar por usar. Um exemplo: aqui está uma ação do GitHub que criei. Se você olhar, há um arquivo YAML que executa o Claude Code. Ele incorpora a

1:45:31 CLI do Braintrust. Incorpora a skill. Mas o que ainda precisamos entender nesse caso é o que mudou. Este é meu exemplo bem, bem simples de um agent supervisor. O que mudou? Por que essas coisas mudaram? Por que, neste caso, o Claude Code recomendou essas alterações? Aqui está o impacto real, certo? Com base nas evals que executei. Aqui estão alguns links para o Braintrust, onde você pode inspecioná-las. Aqui estão as regressões de arrependimento que incorporei com base nessa análise. E aqui está o seu PR. Você é o revisor. Descubra se isso é algo significativo que devemos produzir. Então, acho mesmo que isso é algo que você pode escolher usar hoje. Temos clientes que já fazem isso. Um deles — aquele que estava no primeiro slide que mostrei — usa isso para gerar de cinco a dez PRs a mais por dia do que antes. Se você tiver, mais uma vez, todas essas informações, se tiver aquele Codex ou Claude Code realmente inteligente consultando seus dados de produção com bastante flexibilidade e trazendo os elementos interessantes, acho que isso se torna bem convincente para muitos casos de uso.

1:46:02 incluído com base nessa análise. E então aqui está seu PR. Você é o revisor. Descubra se isso é algo significativo que deveríamos produzir. Então, acredito absolutamente que isso é algo que você pode habilitar hoje. Temos clientes que já estão fazendo isso. Um deles, que estava no primeiro slide que mostrei, está usando isso para gerar de cinco a dez PRs a mais por dia do que antes. Se você tiver, mais uma vez, todas essas informações, se tiver aquele Codex Claude realmente inteligente

1:46:33 Sim. Sim, esse repo de skills do Braintrust é open source. Sim. Há também um arquivo YAML aqui que passou pelo processo real do GitHub — ele foi executado dentro de uma ação do GitHub. Também é open source. Sim.

1:47:13 Sim. Sim, o que acontece é o seguinte: mostrei antes como escrevemos evals — uma das maneiras de escrever evals com o Braintrust é usando esse código de avaliação. Então,

1:47:43 aqui está minha avaliação para outro projeto, que estou mostrando fora do projeto anterior. Uma coisa que destaco aqui, e que é diferente do que você viu no código anterior, são os parâmetros. Nos bastidores, expus parâmetros diferentes que afetam meu sistema de agents. Neste caso, é algo relativamente simples: o agent supervisor. Mas, se você olhar no playground, venha até aqui. Você pode incorporar coisas diferentes ao Braintrust, certo? Acho que não muita gente o usa para prompts hoje em dia, exceto para coisas bem básicas, mas

1:48:14 essa avaliação remota permite iniciar um servidor de desenvolvimento. Assim, posso estar trabalhando localmente e executar eval my file name --dev. Isso inicia um servidor e procura automaticamente em localhost:8300. Você também pode expor esse servidor dentro da sua própria infraestrutura. Você criou e expôs essa avaliação e também expôs parâmetros diferentes. Neste caso,

1:48:45 expus um system prompt e o modelo desse system prompt. Se eu rolar um pouco mais para baixo, também há um prompt e um modelo para o agent de matemática, além de um prompt e um modelo para o agent de pesquisa. Mas posso interagir com toda essa complexidade e com todas as ferramentas de cada um desses agents diretamente no playground. Basta clicar em executar; ele processa tudo, a execução do código permanece no servidor e os resultados dessa avaliação são transmitidos de volta ao playground.

1:49:27 >> Sim, o Brain Trust inicia uma solicitação POST para um endpoint de avaliação que você expôs nesse servidor. Há um jeito bem simples de fazer isso; posso mostrar outro exemplo. Você pode usar uma função do tipo create_app ou remover as partes de que precisa para iniciar o servidor. No momento, esse servidor de avaliação remota está hospedado no Modal. Estou usando essa

1:49:57 função create_app. Ela expõe todas as evals, pelo menos da forma como configurei, no meu diretório de evals. Agora elas ficam disponíveis no playground para os usuários experimentarem. Uma das coisas que estamos fazendo internamente neste momento é — e isso é muito motivado pelas interações que temos com nossos clientes — pensar bastante em quão bom é, de fato, o agent de programação deles e em quão eficientes são ao usar esses agents de programação.

1:50:29 E parte disso é, na verdade, executar evals nas skills que eles estão usando. É entender as sessões que eles têm com Claude Code e Codex, e assim por diante. Acho que eles ainda estão — digo isso porque estamos nos dedicando bastante, nos bastidores, a criar algumas das diferentes primitivas e mecanismos que nossos clientes podem conectar ou usar para começar a entender esses tipos de coisa. Sim, só porque você vê dois commits e uma estrela, isso não

1:51:00 é indicativo do que consideramos um problema muito, muito importante para os engenheiros de hoje. É. Legal. Ótimo. Obrigado a todos. Agradeço por terem vindo.

1:51:34 [música]

Transcrição original

[00:13] Hey everybody. My name is Doug Guthrie. I’m a solutions engineer at Braintrust. Um I have a few colleagues, uh a couple colleagues in the room that uh can help if you get stuck anywhere uh within the workshop today. Also, um I get interrupted all day long during calls, so if you want to stop me at any point and ask a question, I’m up for that as well. Uh hopefully you’ve had a chance to grab the QR code by now. It just takes you out to this repo. This is what we’re going to be us- using today uh as part of the workshop and

[00:44] going through understanding how you can do observability within Braintrust and sort of using all of the different features within there to build better agents. That’s really why we’re all here. Like, how do we actually create good quality agents? Um I’ll leave this up for uh 10 more seconds or so.

[01:21] I’m going to have this again later in the the presentation when we actually get into the workshop. So, if you if you don’t get it, um you can also Google um dpguthrie on GitHub and search that re- uh repository on on GitHub and you’ll be able to find it. Cool. So, um we’re all here to master AI observability, uh and I’m going to give you what that looks like in the context of using Braintrust. Uh quick agenda. Uh I do have some slides that I want to sort of set the foundation for doing observability, and I think um

[01:52] what we’ve learned of how to how to do it really well. So, I’ll sort of set the foundation for what that looks like. Uh give you a sense for how do we generate signal in this massive amount of noise? Um you all have probably seen a trace or you can understand that the agents that you’re building are generating a massive amount of data. And being able to parse through all of that and actually derive some type of signal or insight is challenging. That’s where the challenge resides. It’s there’s one side of actually being able to trace and then have a sort of platform that allows for observability. Then there’s the other

[02:23] side of how do we actually do something with it and derive some type of insight. So I’ll show you what that looks like within Braintrust and then we’ll sort of walk through all of what what I what I described or what I’ve shown on on these slides in the workshop. Um as I said, uh if you have a question, feel free to jump in. I do not mind. Uh I have sort of at least I’ll try to save some time at the end for some Q&A as well. So feel free to save your question to the end. So just a quick Braintrust intro if you’re not uh familiar.

[02:53] Uh we are an AI and we are an Evals and observability uh platform. Our sole goal is to help our customers build better agents. Uh we we sort of uh help enable our customers understand what quality looks like and then how to improve it in a real measurable way. Um one of like the the more fun parts about my job is that I actually get to go speak to some of these customers that you see up there in the top right. I get to understand how they are building their agents. And a lot of those learnings actually make make their way

[03:24] into our product. Make their way into my other engagements with customers. So I get to go actually talk to the engineers of Cloudflare and I get to talk to the engineers of Dropbox and I get to understand what they’re doing, the the types of scores they’re creating, how they think about our new feature topics, what that sort of creates, the the types of automations they’re building on top of it. Uh I hope to give you some sense of that today. Uh mentioned some of this, right? We are an Evals and observability platform. Um you think about like evals and observability, I think they’re like two

[03:55] diff two sides of the same coin. Uh taken together, it’s really what’s going to allow you to create better quality agents. Uh if you if you hang around and I mean like if you if you aren’t a Braintrust customer, if you’re not using Braintrust today, would highly recommend coming back and looking at Braintrust in the next month, 2 months. Uh where I think we see the the industry at large today is is a more like very passive way of observing data. Uh sort of what I alluded to of like being able to derive insight. Uh Braintrust is moving, I think, a little bit more

[04:26] towards what we call active observability. It’s It’s actually giving you the primitives, uh the foundations, to give you the right insights where you don’t actually have to pull from your platform and understand what that means in the context of your agent and and what you need to go do to go and improve it. Uh so, uh active observability is the is the way in which we can start to bring those insights to you so that you can build better quality agents. So, quick quick Braintrust stuff there. Um I’ll plug this again at the end, but we are We do have a booth at the expo. Uh I

[04:58] think it opens around 5:00. Come and find. I’ll be there tonight. Come and find me, ask some more questions. Uh we’ll be here all week as well. So, the the foundation to all of this, uh the foundation to observability in general, like I’m guessing most of you already know here, is tracing. You have to be able to understand all of the different steps that your agent takes, right? What are the the the things that it’s doing to get to its final output. And not only not only that, but what are the inputs to those tools? What are the outputs of those? And if you if you start to think about like all of the different steps that your agent can

[05:29] take, this can balloon um pretty quickly. And being able to sort of parse through this, this is the challenge that we are trying to solve. But without that tracing, right? We’re not actually able to understand what’s going on, where quality is actually deteriorating. Uh and so, being able to uh one, trace all of this data and then derive some type of insight again is where where Branch is going to provide some value, but it just in in general, if you’re thinking about observability, if you don’t have some part of your stack

[06:00] in in a trace that looks like this, then it’s it’s a black box. It’s going to be very challenging for you to actually surface those quality issues or, you know, point Codex or cloud code or whatever you’re using out there to like understand what’s going on. If that’s that that data is not there, you can’t actually surface those those places where the agent is falling down, where it could be improved. So, tracing is the foundation. I think if you look at the eval side and of course talking today the observability, it all sort of centers around us being able to capture all of the different

[06:32] things that our agent is doing. So, just another quick call out on the Branch Trust side. We we have a lot of different ways. So, I’ll skip ahead just a little bit. The workshop that we’re doing is built on it’s a you know, dummy sort of support agent. The the sort of agent isn’t the thing that’s important, but it’s built with the Open AI agents SDK. We have lots of dinner different integrations with all of the different agent frameworks. We have integrations with all of the AI providers. We have different programming languages. So,

[07:02] depending on how you are building your agent, whether it’s the example today is in Python but it could be TypeScript, it could be Java, Ruby, Go. So, we are pretty flexible in that we allow you to sort of bring whatever it is you’re doing today from a programming language perspective or how you are building your agent, whether it’s with a framework, whether you’re using Open Telemetry, whether you’re sort of hand rolling your own orchestration, whatever it is, Branch Trust has a way to hook into that pretty seamlessly. And I think if you’re looking out across the market, right, if you’re trying to understand how do I

[07:34] how do I trace this this agent, you’re going to have to have the ability to go across a lot of different things generally. And you can see over here there’s a lot of different ways in which you can integrate your stack into Braintrust. So again, I just have the dummy agent today is using the open AI open AI agents SDK, but that’s certainly not what we’re confined to. This is something that I sort of I say the word flywheel like, I don’t know, 100 times a day it seems like. Um

[08:05] The whole idea and where I think we’ve gotten a lot of feedback from our customers is the the way in which that the way in which they are building better agents today is they are creating something like this, right? And what what I mean by that is that production should inform development. You should have a really simple and easy to create flywheel that allows you to develop some type of change, fix something within your agent, test whether or not that change regress the agent in some way or improved it. You

[08:36] should be able to have the confidence to go and deploy that agent to production. When you deploy, right? We need to be able to observe it. That observation though, we need to like tack something on top of that which maybe you don’t see necessarily called out specifically within this flywheel, but you need to be able to derive some type of insight at scale. Most of the customers, especially on the slide that I showed earlier, they have a massive amount of scale and being able to derive inside or having a human comb through that data would just be incredibly challenging. And so we need to layer intelligence on top of that and

[09:06] that’s one of the things that that Braintrust will offer, but I think just if you’re thinking about the the process of building a better agent in general, you need a flywheel like this. You need to create something where production in some way informs how you go and change your agent. And so this is what I’ll show you a little bit today when we go through the workshop is how we can actually surface some of those insights in an automated way from our support agent, bring those insights back to our development process, make some type of change, run an eval, right? That

[09:38] that sort of loop uh becomes sort of uh it’s just incredibly important. And and hopefully it becomes a very trivial thing that most companies and most developers can just very easily plug into. So, when I say signal, uh I just in this context I mean two different things that we will sort of wire up also during the workshop. Uh I mean uh scores. So, this could be uh you know, evaluators. This is just a way to measure the output of your agent

[10:10] in some way. Uh you have some particular failure mode, you have something that you’re trying to understand about the agent when it um when it received some input. Uh we we can create a lot of different types of scores. Uh one of them you see over on the far left is a code-based score. These are generally uh very fast, very cheap, uh and very easy to run. Uh you can imagine like I’m trying to validate a schema. I am trying to understand was tool A called before tool B? Was it called in the right order? Uh things

[10:40] that can be produced very very quickly uh and without sort of having to go into an LLM. Uh the more subjective, though, is that LLM judge. We want to bring some sort of like human uh understanding to that that that trace, right? to that interaction that just happened with that eval case or even uh online as well. And so, you could actually, you know, give the LLM some criteria of how you want to assess the output or assess that conversation, and it should produce some score. Um And then there’s there’s a probably

[11:11] actually a fourth one here, but the third one that you see over on the right is an LLM LLM judge aligned with human review. What’s also important, you could probably imagine, is if I have an LLM judge and it’s producing results and we are sort of making uh decisions based on the those results, we should probably understand whether or not those results are good or not. And so, there should be some element of human review. I think especially if you are using these judges in an online sense, right? You are scoring actual interactions of users with your agent, you should be able to

[11:42] provide some type of interface to users to provide that review to calibrate those those judges, right? This isn’t a set it and forget it type thing. Uh your agent will evolve, so too will your scores. The the fourth one that I actually have an example of in the uh the work the workshop is a sort of code-based score, but it invokes an LLM under the hood. Uh you can imagine like there is branching logic or there’s just uh more advanced or complex things that you need to do uh based on some type of logic that you want to encode in your code-based score. Uh so, you could do

[12:14] that as well. Uh these are some of the things that I think I’ve heard in in different conversations with with our customers. Uh I think again, it’s like take it with a grain of salt to some degree. Like it’s not always going to fit 100% of the scenarios every single time. It’s It’s where I’ve seen a lot of success across our customer base. Um just being able to like understand the reasoning that the LLM gave for producing a score, incredibly helpful especially on that human review side where it’s like, “Hey, I can understand why it produced that.” That will then inform how I can go change my scores in some way.

[12:46] Um binary scoring, I think uh especially at the outset when we have sort of an agent that we are putting out into production, binary scoring I think is is better than, you know, A B C D or or so on. And you should be incredibly harsh. Uh you should produce really hard examples. You should You should if you get 100% on every single one of your evals and and we probably will today because it’s uh sort of dummy use case, but if you get 100% of your uh 100% on your evals, yeah, one, you probably don’t have uh

[13:16] strong enough test cases in your data set. Your scores probably aren’t harsh enough. Uh so, you should sort of look at that and and and sort of calibrate accordingly. Um another one that I’ve seen, you know, again, grain of salt including some examples in in your prompts tends to tends to help and then perhaps using a stronger model for scoring than for generation, right? Let’s bring a little bit closer to human subjectivity as possible to this. Obviously, this can change based on the the the type of traffic, right? If

[13:47] we start to talk about online scoring and things like that, but um to that point, there are obviously two different types of scores, at least the way that we see that here at BrainTrust. There is the offline, right? This is our with our e-vals. We are sort of trying to derive some signal of whether or not we should push this thing to production. This is going to give us indication of did it improve or did it regress? Um this is going to be uh you can imagine wiring this up to Excuse me. It’s my daughter.

[14:25] Um yeah, so you can imagine like wiring this up, right? To CI. You can imagine wiring it up to some sort of automated pipeline. Again, where you’re running it offline and then on the flip side, the the whole idea or like the thing that we’re talking about here is how do we how do we derive signal from things that’s actually happening in production? And one of those things that you can do is use those online scores and and score that traffic as it’s incoming into BrainTrust. And again, the idea is to attach some type of signal where then you as a user can actually go in and be

[14:57] like, “Hey, my routing accuracy score is zero in these examples. Is there some sort of pattern that I should be aware of based on this feedback, right? So I need to go from like this massive amount of data into something that is much smaller and easier for me to consume.” The second signal is a is a feature that we have in BrainTrust called topics. The idea here is that you want to like understand patterns within your data. You want to go a little bit further beyond the uh the known unknowns, right? So, like your scores that you’ve already created

[15:28] uh in your offline evals, they are failure modes that perhaps you’ve already recognized. There are things that you already are testing for, but that’s certainly not the the scope in which your agent can operate or the failure modes that it can encounter. And so, we need to understand beyond that, and Topics is one of those things that will help enable that. We should be able to um understand silent failures. So, you can see there like these very sort of traditional scores like factuality and and moderation. They’re They’re going to catch a very small subset of errors, and and probably you have a

[15:59] little bit more uh bespoke scores that that you’re using. And then to that point, like the evals that you’re running again are using those those subset of scores to understand improvement or regression, but there is a sort of wide swath of use cases that your test scenarios are not capturing, that your users are actually uh probing your agent with and trying to like get some type of output, and perhaps maybe it’s not the right one. Um so, we want to capture these edge cases. We want to capture the tail end, and we want to structure uh then the flywheel,

[16:30] right? We want to bring these examples back to our data sets. We want to run evals. We want to perhaps create new scores based on that feedback. So, so what is what is Topics? Uh Topics uh in general or at a high level is a way for us to understand patterns within your data. Um we can create clusters of those patterns and give you a sense of frequency with which those things are occurring. Uh also important to call out here is that there are both built-in and custom facets. And And what what I mean by that is when you go into your BrainTrust account, you can enable a feature called

[17:02] Topics, and out of the box you can see task, issues, and sentiment. So, I can understand, “Hey, what are What is the common user intent? How are users feeling when they interact with my agent?” And what are the common agent issues? So, I can and that that sort of taxonomy, where I’m not necessarily providing that taxonomy up uh up front. The LLM uh creates that uh for me as part of this pipeline. But, I can also bring my own custom facets. I can I can sort of build my own prompt, and I can build my own pipeline to create these

[17:32] patterns within my data, right? With respect to the things that I care about. Uh go go back to this. Um this is you know, just an example of of of an illustration that you might see with the topics that were generated. Uh but, why why would you use it? I think I sort of alluded to this a little bit, but you want to be able to not have blind spots. Uh you want to be able to understand all of the different ways in which your users are interacting with your agents, and then allow that to inform what you go do as a developer, right? This this doesn’t even necessarily have to be an issue or

[18:04] failure mode. This could be like potentially um feature requests, new things that your agent could do based on the way users are actually interacting with your agent. Um so, this is like I think one of the ways in which I’ve seen a lot of our users start to use this uh is actually create this or or sort of understand what’s going on and inform what a road map should look like for the agent, right? It It starts to uncover things that were not necessarily aware of with respect to these agents running in production. Behind the scenes it is a really complex

[18:34] pipeline. Um you see over there on the left a preprocessor. So, if you think back to my my first slide with the that trace, and that’s like a very very small trace uh relative to what I’ve seen our customers generate. What we need to do is preprocess that data into something that is meaningful to give to the LLM. Um so, we give you a what we call a default preprocessor. We essentially take what what you’ll see in our thread view, and you’ll see that in just a little bit, but it’s the back and forth, right? It’s the user, it’s the assistant, it’s the

[19:04] tool calls. We preprocess that massive trace into something that is meaningful is much smaller. Uh we then pass that to a facet, right? The facet is the thing that that I just described, issues, tasks, sentiment, your own built-in facets. What we’re going to do here that that pre-process data is going to be passed to that facet. We are going to then summarize it. That summary, we then create a vector embedding of that summary within our back end. Uh, on top of that, once we have that vector embedding, we can now go create what we

[19:35] call a topic map. This is sort of what you saw on the previous slide of the the scatter plot. Uh, this is what now allows us to label our traces and classify them. And if I have those labels and those classifiers, it becomes incredibly trivial for me as a user, and also incredibly trivial for me as a user um, using a coding agent on top of Braintrust to now start to filter through that noise using all of that really rich data. Uh, important callout, the pipeline that you’re seeing, the

[20:05] facets and that embedding step is actually using a a hosted model that we have. So, we have just done a lot of work behind the scenes to create um, not not like a feature that you would just like show in a demo. Obviously, like we’ll we’ll see some stuff here today, but this should work at scale. You should be able to run this on 100% of your traces. That’s that’s the sort of goal of our topics pipeline. It is uh, just to get like maybe more detailed than I should, 6 cents per um, million tokens on the input side and 40 cents on

[20:36] the output side. Uh, compare that to like other models that are that you might be using uh, on the LLM judge to create that same type of signal. You can create a pretty compelling use case, um, especially if you start to see value in the the sort of topics and the labels and classifiers that we generate as a result of it. Um, I also alluded to this a little bit, like why did we build this? Uh, we’ve met we have customers that that generate uh, massive amounts of data. And one of

[21:07] the things that I think we solved for very early on was being able to ingest that data and then being able to allowing our customers to query over that data in in sort of sub-second speeds. What we need What we didn’t necessarily have at the outset was the ability to go do something with it, right? And this is where that active observability comes into play. Like >> [snorts] >> how do we now go derive insight from all of this data, especially this data at scale? This is where that the challenge comes into play. And so if you have this really complex pipeline that has been architected to both run at scale, um and

[21:38] I mean that from a technical perspective as well as a cost one, uh like I alluded to earlier, then we can actually provide a I think a really interesting primitive and foundation that our customers can build on to inform that flywheel. Um at the end of the day, the the the thing that we’re trying to do is enable our customers to build that flywheel and to build it in a way that actually um improves their agent quality and they can do it very, very quickly.

[22:09] All right. Hopefully I I didn’t lose anybody there in the in the presentation and you all are ready for workshop. Um quick show of hands, anybody still need the QR code or the URL for the the GitHub repo? Yeah. Yeah, I’ll keep it up here for 30 seconds or so.

[22:54] >> Uh my team uses Lightstep. I think Lightstep kind of sucks. Can you give me a list of things that my team says, “Well, why should we use BrainTrust instead?” That I can go to them and say, “These are the things that BrainTrust gives you in the likes of the town. >> Oh, man, you’re going like straight competitor here, huh? Wow. Was not prepared for for that. Uh I am I’m certainly not the guy. Like I will not be up here bashing anybody. Um I I do think that we we have a a stronger offering and I

[23:26] think we have a stronger offering in a in a lot of different regards. Um certainly not in any particular order. One of them is the the flexibility that I showed to you on the other slide. There is the ability to go across multiple languages, multiple programming, excuse me, multiple programming languages, frameworks. Um It’s a very agnostic way to build your agent. Uh LangSmith, I think, has some of that as well, but they are definitely geared towards LangGraph and uh LangChain and deep agents and and those types of things. And I think they have features that are only sort of for

[23:56] that. Um the other thing that I think if you go back, actually I used to have a slide on this, but BrainTrust built their own database in late 2024. And and the reason that we built this database is is Ankur, our CEO, recognized very early on the trajectory that we were going in from a agent perspective. And so he we were using ClickHouse behind the scenes at the time and recognized very quickly when we onboarded the likes of, you know, the the customers that you

[24:27] saw on there, Netflix and Microsoft and Dropbox, that they ClickHouse just very quickly fell down at scale. And we had to go do something different. And so this is where the engineering team and Ankur built BrainStore. This is our own purpose-built back end. I think at the time people thought we were crazy. They thought like, “Hey, there are all of these like open-source alternatives. There’s ClickHouse. Like there are these things that actually, um you know, allow us to do this and do this well.” What you now see, and especially like you probably see see on the LangSmith side, they’ve just built their own database. Um Arise, they just built their own

[24:58] database like 6 months ago. I think people are starting to recognize uh that this is actually a problem that’s not solved for with out-of-the-box solutions, and you need something custom. And so, in that regard, I think we’re like a year uh ahead of some of these these competitors. And where that shows up is is in topics, is in being able to generate real insights on data at scale. Um there there’s probably some other other ones. If you want to, you know, come find me afterwards, we can we can get into it, but um I’d say that that

[25:28] last one, like the having our own back end, and the things that we were able to build on top of that, has really what is really enabled us, I think, to separate ourselves from other players in the space. Yeah. Yeah, you. Yeah.

[26:13] >> [snorts]

[26:51] >> Yeah, I mean, like during the workshop sorry if if anybody couldn’t hear that the question was just like examples of topics and a little bit more insight into how into perhaps the the process and are we actually generating anything that is meaningfully different because the traces are relatively the same. They are going to be semantically similar. Um I think you’ll see this in the workshop, hopefully. Uh I think the the customers that are using this in production would would probably disagree with you. That’s why they are using it is because they are they are seeing those those differences

[27:24] and they are seeing those show up as different classifiers, as things that they they weren’t yet aware of before actually running that pipeline. Um I I think part of it is just like is getting your hands dirty a little bit and actually putting in your actual traces. Like I have dummy demo data where I’ve, you know, used a script to hopefully create some differences that we create this. I think you naturally see even more of that when you have actual users interact with the agent. Um the traces look probably somewhat similar, right? We’re

[27:54] invoking the same tools. It’s going through the same uh workflow. But I think, you know, depending on what your agent is doing and what your users are doing with your agent and I think maybe to back up a little bit, I think a lot of us are building agents that are increasing in complexity or they’re building systems that are increasing in complexity. And it creates, I think, some some differences that that will show up on on screen. But you you’ll see when you create an account, you actually have you have a free account. You can send

[28:25] data up to a certain point. You can even toggle on topics to see if it is actually generating some of these things. So, we’d just encourage you even after this workshop to go play with it. Um and and see if it does generate some interesting uh topics for you. Yeah, go for it. >> bring your own traces as you are not showing to your customer using your own data. >> Yeah.

[28:55] Yeah, the the question is like uh can we can we use topics perhaps on like uh our own sessions with Cloud Code and Codex and and so on? Absolutely. One of the things that you’ll see if you go to our integrations page is an integration with Cloud Code, integration with Codex, uh Cursor, Open Code. And so you can I’m actually working with um multiple customers right now where they are trying to do exactly that and layer topics on top of that. I I think a lot of I don’t know exactly where the question’s coming from, but I think what I’ve heard is that most

[29:27] engineers today, most teams of engineers are using those tools and there there needs to now be I think insight into the efficacy or how well these things are actually improving the workflow and and and those types of things. And I and I think there’s there’s probably some machinery that still needs to be put in place, but if you’re just looking to hey, understand what people are doing in those those different tools, I think topics is a really good way to start to understand that. Yeah.

[30:01] So we have uh we have a few different hosting options. One is just full SaaS, that’s what you’re all going to be using today. Uh we have both a BYOC and a hybrid model. Um and so maybe to like back up even further than this or than the question is like BrainTrust was actually architected from day one to support a hybrid uh deployment. And so by that I mean uh the control plane, the web app, right, the the metadata that we store is always going to be hosted by us. The data plane, so your traces, your data sets, your experiments can actually be

[30:31] hosted within your VPC, within your infrastructure. Uh we deploy across all of the major cloud providers. Um but yeah, you actually we have, you know, those customers that you saw up there, I would wager that 90% of them are uh self-hosted ones. Yeah. Yeah, sorry. Green shirt.

[31:04] Yeah, so the the question is like how do you handle long-running conversations with topics? Uh some of it is I can I’ll be show you this during the workshop, but there are different settings that you can configure that operate on uh they can operate on different traces, that can operate or can only be invoked after a certain time period. Uh so depending on like generally speaking, I think there’s an understanding of how long conversations tend to last that tends to inform the settings that you create. But there’s I don’t know

[31:34] getting into the workshop probably answers that a little bit better. Uh but I think we can answer that one. Cool. How about one more and then we’ll jump in. Yeah, this this the preprocessor, we give you a default one. You can bring your own custom preprocessor. Uh you have data that exists outside of uh what we can parse uh from input and output or what what’s going to and from the LLM. You have stuff that’s in metadata. You have stuff that’s within some other span that maybe we’re not

[32:04] sort of pre processing as part of that default preprocessor, you can absolutely create your own. Uh the other one again like I think I mentioned was the facets. You can bring your own facet. You can build your own uh thing that you’re trying to understand or to derive patterns of within BrainTrust. But yeah, this I think one of the the other really cool things about this pipeline is it’s completely hackable uh in the best sense of the word. Cool. I see a 30-minute timer. I think we we have till we have till 11:00 though.

[32:35] Cool. All right, so I’m going to assume everybody has the the workshop or the the QR code here or at least the the access to the repo. Is that we zoom in a little bit? Okay,

[33:05] this could be a little bit different based on you having a BrainTrust org or not. Like I said, Noah is back here and can help if you if you run into anything. Also, you know, if you want to like just yell at me for a little bit that’s that’s fine, too. So obviously the first thing that will need here is a is a BrainTrust organization and it’s all I’ll sort of walk walk through this this guide with you all and and we’ll start to understand exactly what I just described there. We want to create that flywheel and I think we’ll we’ll focus a little bit more on the online side, but

[33:36] just know that there is the the flip side which is the e-vals and I do have an e-val as part of this that we can also chat about. All right, so a little bit of a a teaser there that was not meant to do that, but we will create a new organization. Um if it if it’s your first organization

[34:06] that you’ve created, uh you’re going to navigate to that that link. You may have some different steps at the outset. It may actually uh ask you to provide some AI providers and a uh generate an API key. Please go through that. I also have steps for those as well. Uh you just see a slightly different uh flow because I already have organizations created here on the BrainTrust side. If you see if you see a screen like I do now? Quick raise Raise your hands. Do most people Are most people just

[34:37] creating a new Braintrust org for the very first time? Okay, cool. Awesome. I love to see that. Um we created the org. Is the next step to create a project? Sorry? Oh. Internet issues. Love that. Okay, so nobody can participate. Okay, bummer. I don’t know if anybody was here last year. We had the exact same

[35:08] exact same problem. Um well, we’ll just go through this though, and I will try not to go too fast knowing that nobody else is is doing this here, but So, you’ll see that you we we created an organization. Uh you’ll also see where we automatically created a my project. Uh you can you can delete this if if you’d like. Uh we’re going to create our own project for uh this workshop. Uh I would label it this, AIE-workshop.

[35:38] All of the sort of code in the repo uh assumes that you have done this. Now, you could certainly uh not do this and then change some other things in the repo, but I just wanted to call that out if you are following along. Uh just know that you’ll need to uh make sure that the project that you’ve defined here is also matching what you have within the repo. So, the the other two things that we’ll need to sort of complete this is uh one, we will need to generate or create an AI provider. Uh so, if you go over to Braintrust and

[36:10] into your settings, you’ll see a uh a place where you can actually configure your AI providers. Uh I’ll click this one up here. There there should be a lot of different uh places for you to add some type of API key or uh what we just released very recently is workload identity federation for some of our major AI providers. But you can also our organizations tend to also do or where I see them also build is like they’ll have their own gateway. And they want to connect their their gateway to

[36:42] BrainTrust. They could do that using a custom provider. You sort of give the underlying spec that that gateway sort of conforms to how we are authenticating to that and some other sort of URL authentication type. So generally speaking you can connect to a lot of different AI providers in a lot of ways. I haven’t seen anybody not be able to connect to anything from from BrainTrust. The the other thing maybe just to if if you are sort of following along and you are using a gateway but that gateway has perhaps some firewalls

[37:13] you’d probably see some some errors on this side. Just know that you know there are ways in which you can sort of allow certain IP addresses to those different places that perhaps only allow certain IP addresses like a gateway. Um I’m going to stop sharing just for a second so you don’t see my API key.

[38:07] All right, one more I’m going to generate an API key also. Okay. >> All right. So, just to recap what I just did here,

[38:38] I went over to AI providers. I added both OpenAI and Anthropic as API keys. Uh the reason that you’ll need this is if you do configure online scoring and you’re using judges as part of that, uh you will need to choose some type of model. So, another call out here is that when you actually invoke those those scores, you are using your own models to do so. The only caveat to do that is that Topics pipeline, which uses our BrainTrust built-in models um for that complex pipeline.

[39:13] All right. So, we essentially just did uh sort of step zero here. We uh created a new org. We have a project called AI e-workshop. We have an AI provider, and then we have an API key. Uh if you haven’t done this, right? So, we can now clone this repo.

[39:55] Looks like I did not update something in the code. All right. One more time.

[40:27] >> All right, anybody thumbs up, thumbs down, is this okay from a you need to zoom in? Cool. Okay, so let’s let’s start going through this. Um obviously we’re going to be using some some different tooling here to uh to power this. I am using UV as the the sort of package manager to install all of my uh Python dependencies. So, if you don’t have UV already installed, you would use this command. Uh I already do, so I’m just going to run uh UV sync and then add some dev

[40:57] dependencies as well. Uh so, that should create a virtual environment within your directory and then should install all of the different uh things that are required to run this workshop. The next thing that we will do is uh create our .env file and we already have one as a example. So, you can copy that one over. And all you’re doing in this one is you are adding an API key that you generated on the Braintrust side and then you are adding a default model. Um this is really only needed if you wanted to spin

[41:27] up the the sort of chat UI uh or then run I think evals as well. But these are the the two things that you would sort of create or modify within that .env that you just copied over uh to to power and run this workshop. There there’s some other ones that you know, there’s some instructions in that .env file of what you could also uh change like if you wanted to follow maybe those best practices that we talked about earlier of maybe creating or having a better or higher uh more powerful judge model, you could do that as well. Just if you’re if you’re not

[41:58] aware what this should be there is the the um this is the the .env that we just copied over. Again, I’m just modifying or added my Braintrust API key and then I added a a default model and this default model obviously is going to be something that is accessible via the providers that I that I configured on the Braintrust side. So, if I did open AI, I’m going to do a GPT model, Anthropic uh Sonnet, and so on. So, just make sure that these those

[42:29] two things uh mirror one another. The The other thing that’s going to be really important uh for this workshop is to install the Braintrust CLI. Uh this is going to allow you to run arbitrary SQL, to run evals, to view your logs, to create data sets. You think about that flywheel that I just described, a lot of those things are are part of that flywheel and it’s something that we can plug into our agent to actually start to do itself, which you’ll see at the end of the uh at the end of the workshop.

[42:59] So, you’ll see over here, I already have the uh the Braintrust CLI installed. Uh I’m also going to do a BT setup skills and I’m going to use Codex. Uh you might be using Cloud Code or Open Code or Cursor or Quen or Gemini. That’s supported also, but the idea here is that we are going to give our coding agent access to some skills to understand how to create a data set, how to run evals, um how to write SQL, and so on.

[43:33] Yeah. Switch to what? Oh, yeah. That’s a really good idea. Where I don’t I don’t think I’ve ever actually done that in here. >> [laughter] >> Any idea?

[44:17] >> What is it? Control B?

[44:50] Let’s do this.

[45:43] Sorry? Command shift B? Type in what? >> All right. >> [laughter]

[46:14] >> I’m guessing you all all were hoping to see me navigate around a terminal and not have any idea what I’m doing. So we’re we’re all good. This is better for everybody. Awesome. Sorry about that. Okay, cool. The The next thing that we will do is we will initialize uh the the CLI. Um I’m going to do something slightly different because I have uh already initialized uh an ending to OAuth into Brain Trust to access a

[46:44] different organization. So I’m going to do Oop. So if again, if you already have the Brain Trust CLI and you created a new org, uh you’ll go through that, and then you’ll just uh select that org that you just created. So for me it was ABC DPG. Cool.

[47:15] And then I will run that BT init, and I’ll look for ABC. And so this is just going to create a uh config.json file in the directory that when BT runs, it knows what org and project to to access. So you can imagine uh checking this into your your repo. All of your engineers now sort of like have access to um you know, BT has an easier way to understand what org and project that should uh run an eval and query data from. Cool. Let’s

[47:45] uh now go through uh actually setting up some of the different things that will need as part of uh the workshop. Uh I’m just going to seed a database. Uh I’m going to skip over this smoke command, but I’m going to run make ready. Um, if you don’t have uh, make or access to to make, there are the actual commands right below it that you can also run. Uh, what this is doing right now is just just trying to understand, “Hey, did we set up everything correctly? Do we have the the Braintrust CLI? Do we have a Braintrust API key? Uh, do we have a

[48:16] default model? Those types of things.” So, uh, I think we’re all good to go forward now. Uh, then just to kind of give you a sense for maybe the at least in this case the the trivial use case that we are that we are powering. Uh, very uh, simple chatbot, but really what I want to understand is is it sort of wired up in the right way? Are we seeing logs flow into Braintrust? And so, I just clicked the button in our chat. We should now see a log show up over on the Braintrust side with the uh, the question that we just asked. So, here is an example trace that was just created

[48:48] uh, based on the, you know, the the integration that we have with OpenAI Agents SDK. Um, I think maybe to that to that point, uh, just to show you like what sort of integration looks like uh, within Braintrust. This is obviously a a single example. Um, but all we’re all we’re really doing is is uh, is this. This is what we’re pulling in from the the Braintrust SDK and we are setting a trace processor to a Braintrust tracing

[49:20] processor. Uh, there is also an easier way to do this. There is an auto instrument that is a single um, line change. The the the reason that I did this is because I’m also using our gateway under the hood. Um, maybe I buried that a little bit. Braintrust also has a gateway. So, all of those AI providers that you have configured within Braintrust, we can now access uh, from a single interface, uh, which is what we’re doing here, but we have our sort of uh, tracing set up from our SDK,

[49:51] right directly for OpenAI agents. We are setting that trace processor uh to a Braintrust tracing processor. And again, this means that all of those traces that are emitted, all those spans that are emitted, are now uh going to Braintrust. Uh maybe we’ll just do it Actually, no, we won’t do it from here because that’s not light mode. Okay. So, I also have uh a script in here or I have uh code in here to run evals. And obviously, this isn’t like the the necessarily the point of the the

[50:22] workshop, right? We’re talking a little bit about observability. But but I think uh in the context of observability, you need to think about the flywheel. And and part of that flywheel is evals. Um the things that we are able to understand and derive about what happened in production should make their way back to our evals. Uh and so, there’s also within the uh the repo that you have a uh sort of dummy data set, right? It has a few uh test cases that we want to now run through our eval. So, what we’ve just done again is used our Braintrust CLI. We’ve created a data

[50:52] set, and we’ve actually loaded in a series of rows via that. Um I’ll now run the eval. Again, this will go uh run through that that data set. It’ll sort of pass each row within that data set and invoke our agent. And now, we will store all of that sort of um uh all that telemetry and the the sort of results of that of that eval uh directly within Braintrust. But you could also imagine this is going to be incredibly informative when we do go run that flywheel, when we do go start to under- stand uh and we go make a change. Generally, you want to compare it

[51:23] against something. You want to be able to understand did I improve or regress from the last time that I actually ran that eval. Uh so, we have Actually, I’ll just come out to Braintrust. Uh so, we should now see over here in our experiments page our eval that we have run. You see the the series of scores that we’ve defined for this particular use case. Uh you could also see and and maybe I’ll come out to this in just a a bit, but uh we have different scores, right? Just like I described earlier, there are there are scores that are um more more code-based. So, required tools called, “Hey, I I

[51:53] have this question. This is what I expect.” Uh then I have maybe a little bit more of that LLM judge. So, support resolution and the tool use quality. So, sort of a series or a um mix of scores that can provide the right signal for understanding what’s going on with our agent. Okay, let’s let’s get sort of to the the meat of this, though. The The idea here is that we can now uh create some type of signal within our uh within our logs. So, obviously, we have a single log right now, uh and we will need to to

[52:25] generate some data and put it into Braintrust. But, before we do that, let’s um use those series of scores and push those into Braintrust so that we can now configure an automation so that they can run when logs come into Braintrust. So, again, I’m going to use this uh make push scores command. This is actually going to look for uh the series of scores that we’ve created and push them into Braintrust. Uh so, there is a way in which you can define these in the UI. You could also, like you you you see here, define your

[52:56] scores in code and push them into Braintrust. Uh with the idea being that you’d want to run them as part of an online automation, uh or perhaps uh we also have a playground and you could give that to another user of the playground and they can use that same score, but have it version controlled within your repo. Um again, here are the series of tools that we just uh Excuse me, the series of scores that we just loaded into Braintrust. Uh you should now see, if you go over to your scores tab, the different scores that we created. So, I have, let’s, you know,

[53:28] support resolution as an example, right? This is going to be an LLM judge. Uh and and what you’re doing here, again, is defining that criteria in which you want to judge something with the with with with respect to the um the the the user’s interaction with that agent. Uh one thing I’d call out here is that there are different sort of variables you can access and pass to an LLM judge. Uh this thread is is sort of what I described earlier. Um it’s it’s what you would see if you come over to our logs page and you click on the

[54:00] thread, which is this icon here, but it’s it’s really just going to be that back and forth of that agent, right? This is really helpful, especially if you have a multi- turn conversation and you want to sort of pass the entirety of that conversation to the LLM, you can use a variable called thread. There there there’s some other ones uh that that you could also use like user messages or assistant messages or simply input and output from a particular span because you want to create a score that understands and scores look up policy as

[54:30] an example. But, there’s a few different ways in which you can start to think about how do I start to assess the quality of my agent across a lot of different dimensions. So, now that we have our scores loaded into Braintrust, the the thing that we need to do now is actually wire them up to run when traces come into Braintrust. Uh what what that looks like on the Braintrust side is an automation. Uh if you look in your logs page, you’ll see up here in the top right uh automations. This is where you can start

[55:02] to create rules that your scores can be invoked on. Um there are if you if you look at here at the scope, I think this is is really important, especially you start to think about like the different use cases that you have. Um you could think I have a multi-turn conversation, but my uh turns are actually across different traces. I don’t see them nested under each um I don’t see each turn nested under a single trace. So, what I might want to do in that case is select this group scope and then

[55:33] provide some type of ID, some type of way to understand how things are related. In my case, it’s a conversation ID. Um the other thing that you might want to do is create a score that is invoked for a particular span. Again, you want to assess some type of intermediate output or intermediate step, and you want to target a particular span. When you do this, when you click span, it’ll default to the root. Um you could also add any type of filter for I want to recognize, let’s say, my lookup policy,

[56:03] and I want to say in this case something like that. So, I want to understand if this is is root or the span attribute name is in lookup policy. Uh there’s also, again, like the trace, which is what we will use for this demo. Uh this is going to allow us to uh essentially access all of the different spans within that trace to produce some score. Uh so, in this case, I’m going to pull out my uh communication quality, and my support resolution and tool use

[56:34] quality. These are all LLM judges. So, if you’re following along, um just know that depending on the sampling rate that you uh that you put here, you’re going to incur actual model compute uh when you go and and load data into Braintrust via these judges. So, just wanted to highlight that. Again, if you’re following along and and perhaps maybe you want to uh lower this a little bit. Uh I’m just going to go to 100% just so you kind of get a a really good signal or a really good idea of what this could start to look like.

[57:04] So, what what this what what I’ve just done now is I’ve said, “Hey, any new any new logs that have come into Braintrust, I want to uh run those scores against those, and I want to run against the out the the trace.” Okay. Let’s uh let’s let’s jump into topics now. So, there’s there’s one side of our signal that we that we can create. This is the more scoped down way of understanding a failure mode, right? This is perhaps something that we have We’re obviously eval-ing for. We have recognized to be something that um you

[57:36] know, we need to understand if we are regressing anything as we go and change something within our agent. Uh topics again is is more for those unknown unknowns. Those those areas that we are not yet testing for or that we’re not yet aware of. Uh you’ll also notice right next to our automations is an enable topics. Uh and actually let me come back this. I think the the first thing that we’ll do here, enable topics. So, you’ll see you’ll see a screen that looks like this. Um and you’ll see those built-ins. So, task, sentiment, and

[58:06] issues. So, sort of what is what I described, what are people or users doing with my agent, what is their sentiment, are they happy, are they sad, and then what are sort of like a broad range of issues that they are experiencing uh with respect to that interaction of that agent. So, I’ll enable this. Um this will apply to existing traces. Obviously, not a lot of data here, so um we’ll eventually see some data show up here. The thing that I again allows you to bring your own way of understanding patterns within your data is where you can actually create your

[58:37] own facet. Um you’ll also notice here, this is where you can also define your own preprocessor. Uh we’re just going to use the default thread one here today, but just know that if you wanted to bring your own function to BrainTrust to parse something within that trace, uh you could certainly do that. So, if you look, there’s also a file within that repo called support workflow issue facet. It’s a markdown file. Uh this is the prompt that we will be using for our custom facet.

[59:08] And so, back in uh BrainTrust, I’m going to grab the uh support workflow issue name. That will be our custom facet. And then I want to grab the the prompt here. Um the other thing that you’ll most likely want to do is to exclude certain facet outputs. So, you can see here I’ve instructed the LLM to output none when

[59:39] the following criteria has been met. Uh what I don’t necessarily want to see is um facets that are that are generated where it’s like, “Hey, this there’s no problem here.” Uh I’m I’m really only interested in the things that are that are going wrong. So, I will grab um this regex also at the top. And I’ll paste it here. Uh you can also choose to apply to existing traces. Um not super important in this case because we have uh we don’t have very many. So, on on the topic side, that’s that’s

[1:00:10] really all you need to need to do to um start to understand whether or not you can see some patterns within your your data. Um if you come back over to our our repo here and you look for a perhaps a different way. Uh I’m not going to go through this, but I just wanted to highlight again the the ability to utilize the BrainTrust CLI to do a lot of um interesting things. So, that’s sort of workflow that I just went through in the UI, I can also do here within uh BT. I

[1:00:40] can actually configure these topics to to run. I can configure those those automation settings. Um so, here I’ve defined my task sentiment issues and my support workflow issues. Uh the other thing that I did, you can also see some different configurations down there. There is different ways to configure the settings, right? So, that pipeline that runs in real time, you can control how it runs or what it runs on. And so, by that I mean you might want to add a filter. You might want to say like, “I only want to run my topic pipeline on traces that

[1:01:12] meet this criteria.” Uh you may again want to apply some type of sampling rate based on uh some understood metric you have about traffic and uh cost this could potentially incur, so on. You also want to understand the the topic window. Like when I generate my topic map, what is the sort of range of traces that I should use based on some window? Uh this one I’m going to This is I think maybe the question you had earlier in the green shirt around like how do I how do I maybe configure this when I have long-running conversations?

[1:01:44] Um part of that is that group by scope is being able to pull in perhaps other traces that other turns that exist across other traces. Uh this also is another setting you can configure where you want to perhaps, you know, this could be a day, this could be 2 days. Like you all understand that the the conversations that your agents are having or users are having with your agents stretch a very um long time period. And so you can configure sort of when the topics pipeline gets gets invoked. Uh I’m going to do something really short here. Um but again, you can

[1:02:16] configure this based on your understanding of the users’ interaction with your uh with your data. Excuse me, users’ interaction with your agent. Uh then again, there’s the same sort of scope that that I highlighted with the scores. Uh you can have this run at the individual trace. Or again, if you have that multi-turn conversation that exists across multiple traces, you would use this group and then use that sort of common um identifier, right? In my case, uh I have a conversation ID that’s being logged out as metadata. So I’ll click save.

[1:02:51] So now we have sort of like the the topics configured. We’ve enabled our uh out-of-the-box ones, and we have also created our own custom facet, and then we have configured our automation settings to uh to be run when data comes into BrainCert. Uh on top of that, so now we can actually start to see what some of this looks like. There is a command here where you can run um essentially the I I have some trace data stored out in an S3 bucket. Uh we are going to just import it.

[1:03:21] Again, under the hood here, what you’re going to see is BT sync. So, we can actually take that data and push it into Braintrust. Um maybe to your to your question in the blue shirt about LangSmith earlier, I’ve actually helped a lot of customers import traces from other providers because they wanted to like maintain or still have some of that that data. But, just highlighting like this is a really great way to uh to do this at scale. So, you can see here we just we just

[1:03:51] loaded in uh 968 traces. Uh 1,052 spans, or that’s the the rate, excuse me. Uh 5,260 spans. So, pretty pretty quick way to get data into Braintrust. But, again, like the whole idea here is for us to start to generate some signal and start to understand where we can make some improvements within our agent. Uh so, you’ll start to see like here’s uh just some uh some examples of traces. Uh you’ll also see that this is the this is actually two

[1:04:21] things you’ll see here. Um each turn is actually represented uh as its own trace. So, this is the the newest user question and here is the the output for that question. Uh you can also notice that there are 11 previous messages. And so, I might want to do something where I I pull in my conversation ID. And so, now I can start to pull in other traces that are that have that sort of same metadata. But, the the sort of OpenAI agents gives you somewhat of a cheat code where it actually just

[1:04:52] attaches all of those previous messages. So, we don’t necessarily have to go through this step, but just wanted to highlight another feature within Braintrust that allows you to group traces by some arbitrary metadata that you’ve defined within those that they they they share across those traces, and you can pull all of those relevant traces into the tree here. Um really quick, right? The thread view, I think is a really great way to understand sort of like the back and forth uh of your agent. Uh there’s also um the timeline view, which is a great way

[1:05:23] to understand like perhaps where bottlenecks exist, or you could even see there’s really interesting information for, you know, cash hit uh across the different LLM calls. So, this information, I think, can be useful in a lot of different types of of workflows. The the other one I’d highlight, and I haven’t really talked about this yet, um this little blue icon in the bottom right is our agent loop. Um everybody has an agent, right? Uh so, you can actually use loop to do a lot of different things across the platform. Uh you can use loop, in fact, to create your own UI on top of that trace data.

[1:05:56] And so, this is, I think, a really great way when I was talking about the other scoring method of I want to uh allow humans to go and review output of whether it’s the agent or the LLM judges themselves and provide some calibration. This is actually something you can prompt loop with, and it’ll vibe code uh a UI on top of that trace data. So, just a different way to bring in perhaps another persona to sort of inform that flywheel. Um you you’ll also see as part of this, like we’re starting to see some some automation start to be triggered. Uh so,

[1:06:26] we have my uh judge automation, so communication quality, support resolution, and so on. And what you should also see is some topics starting to be generated as well. So, in this case, right? We have a user who wants to check the status of a returned item refund, and so on. Um we have a negative sentiment. This user expressed frustration and dissatisfaction with the status of a pending transaction. Here’s my support workflow, my custom facet here. There’s an order record retrieval failure. Both specific order ID lookups and broader customer searches

[1:06:57] failed to locate the order. So, just wanted to you know, two different things here, right? We loaded traces into Braintrust, and based on the sort of automations and topics we’ve configured, we are now starting to get that signal in real time. Right? So, that complex pipeline that generates patterns within your data it shows up immediately. Right? It shows up um based on how you’ve configured that pipeline, obviously. But, this is the now the signal that we’re going to be able to use. Um while this while this starts to uh populate, I’m going to go out to

[1:07:28] another project where I where I already ran this. Um so, I showed you some illustrations earlier of what this uh perhaps starts to look like um within Braintrust. So, at the top here uh in this page, what you start to see is a uh snapshot in time of your of your topics and the frequency with which uh the traces that we have recognized some pattern in patterns in, where they are being grouped. And so, in the first example, I’ll expand this.

[1:07:58] Uh I can understand what users are trying to do with my agent. Right? I can see at the top uh damage and transit resolution seems to be uh the most frequent thing that again users are uh using for my agent. And this is I think going back to what I was describing earlier when I was in the slides is I can actually use some of this information to understand like perhaps where my agent can actually go um further or the thing that I don’t yet have built within my agent that users are trying to do. Um all of this taken together will will be used to sort of

[1:08:31] inform that flywheel. Um a little bit further down, I have my sentiment topic. Uh my issues did not get generated. The The reason this didn’t get generated is because we we look for at least 100 matches or 100 facets that were generated as part of that pipeline. Um and this sort of agent that I built and the out-of-the-box prompt that we have for issues don’t exactly jive or match and we don’t really generate um we don’t we don’t really generate facets as a result of that, but I I that this is a sort of a good thing. Like, we

[1:09:01] don’t want to just generate bad data. We don’t want to just generate signal that you can’t actually go do something with. And so this is where I’ve created my support workflow issues. And in this case, I’m starting to understand, hey, there’s a record lookup failure. There’s something going on with my agent that we haven’t again recognized with our evals, but we are understanding that there is a lookup failure as part of that agent going through its process. Right, this is the kind of information sort of all taken together. This with the the context of our online scores that actually allow me to go do

[1:09:33] something with it and and improve my agent in some way. Any questions? Cool. Okay. I want to show you sort of like a a workflow that that I think, you know, I certainly did when I when I first started at BrainTrust and I think a lot of lot of folks um

[1:10:03] they did as well, right? We’ve generated that signal. This is great. Um now I need to be able to go do something with that. And so I think, you know, obviously within the the BrainTrust UI here, there’s a lot of different things that I can utilize to start to understand or again filter through that noise. Um I might want to look at, you know, the the different um classifiers or the different labels that were placed on top of these traces, right? That map to those topics that you saw in that other illustration. This I can use, right? To filter this down. Um

[1:10:35] probably increase this. No. Uh this I can use theoretically to filter this down in some way, right? Based on the the the feedback that we are getting uh and understand the thing that I can do from there, right? So like I filtered my result set down. I’m drilling into a trace and I’m recognizing by kind of parsing through the trace and the spans within there what went wrong. Um maybe I’m again using my online scores to filter this result set down

[1:11:06] again, perhaps even further. But I but I think like that the workflow that you might go through is you’d use this UI and you’d start to understand all the different things, like all what’s going wrong. I’m going to take my task X and combine it with this sentiment and I want to see what sort of insight I can derive from it. Um obviously generating the signal, really great. We have a lot of data now that we can actually go make some of these informed decisions, but I think you all can probably recognize the the problem with that approach as well. It’s like I am very reactive. The the onus is

[1:11:37] on me as a user of Brain Trust to like go through and click buttons and filter and then parse through these traces. Like there’s got to be a better way. Um I might want to use Loop. Loop is a right again, the agent that is embedded here within the platform that can do different things. Um I asked it in this case, help me understand what I should improve in my support agent based on recent logs. So one of the things that you’ll start to see that’s I think again, really interesting from a uh flywheel perspective, is how we can start to pull

[1:12:09] in relevant data to inform that flywheel. Um another thing that I think is again, really interesting about Brain Trust and specifically Brain Store, the back end that powers it, is that you can write SQL directly against it. All of that trace data, all of those spans can be accessed by writing SQL. Um you may not want to write that SQL, but your coding agent can very very easily write that SQL. And so what you’re seeing happen here is Loop. Again, Loop is our our agent in the platform. I asked it a question and what

[1:12:39] Loop did is it started firing off a bunch of SQL queries. It’s pulling in context that is relevant for the question that I asked it. What you’re probably not able to do and again, thinking at scale, you’re not going to pull in every single trace searching for signal, right, using your agents, your coding agents. You need that signal attached to your traces in some way, and you need that signal to be real. And then you need a very flexible way to start to query across all of that data, so you can only pull in that relevant bit of information.

[1:13:10] Um the the last thing that you you don’t see in this one, but you’ll see a little bit later, is once I find those interesting examples based on the signal that was generated, I now want to go to this. I want to investigate that trace. I want to click into that span. I want to look at the input. I want to look at the output. Right, this is the kind of analysis that I would probably do, but I’m not able to do at scale. But if I can offload some of that again to loop to inform what I might go change or might might go fix or might go add, or I could offload to my coding agent, this

[1:13:40] is the kind of thing that actually I think drives agent quality in a really efficient way. Um so, I’m going to skip through some of this, but sort of what I described here is using topics and scores to understand and and to like actually parse through that that data based on the signal. Um what you might also do now is you might actually use that that filtered set of data. You actually found an interesting example, and you want to go

[1:14:12] add that to a data set, right? The thing that allows us to now go improve that agent. I want to go bring that example back to my offline evals. Right, I could do that here from the UI. I’m going to add this to my data set. Now I have this sort of edge case, this thing that I need to go and sort of improve upon or a new feature I need to add based on what I’ve seen with this user’s interaction of my with my agent. I can go add that back to my data set. But again, like the thing that becomes important here is adding the right thing back to the data set based on the signal that was created

[1:14:42] within within our logs. And then of course, you’d go and you you guys don’t want me to see me code and and figure out if I can improve the agent. But once I once I did, I’d go run my eval again. I’d go compare that to the last time I ran the eval. Did I improve? Did I regress? That new example that I pulled in, did I make it better? Did I actually improve those scores that I ran in an online sense? The other thing that you might want to do is like you actually recognized these new edge cases, you probably want to go create a

[1:15:13] score. Right? I have a record lookup failure. That that seemed to be the the problem that I encountered the most. I probably want to go create a score that allows me to capture that before go before pushing my my agent to production. So, there are all of these steps, right? These things that you would probably want to do to create that flywheel. And what I think becomes really powerful here is when you can run this in an automated sense. When I can plug a skill or I can plug some type of workflow using all of the primitives that I just

[1:15:44] described to automate all of that. And so if you look here at at our workshop markdown file, there is a GitHub repo for skills that that we have out there. There’s actually a single skill at the moment. The idea is to give your coding agents the ability to run that automated flywheel. Right? We want to actually go through that exact same thing. I want I want Codex or Cloud Code or whatever to write SQL. I want it to view traces. I want it to view spans. I want it to create new scores and run

[1:16:16] evals and modify something within my agent and I want to do that, you know, watching my my screen. Yeah, go for it. Yeah, the the So, if you look at my If you look at my eval that I’ve created

[1:16:53] So, this is this is sort of what an eval looks like in in Braintrust. Um your data set here is actually part of like the the commands that we ran at the outset was to load our sample data, like our series of test cases into Braintrust. But but you could also imagine like this is at the outset, this is like my sort of scope down view of the world in which my agent operates, right? These are the test cases that I want to give to it to understand, “Hey, should I go push this thing to production?” But the the sort of like operation of

[1:17:24] the thing that I’m describing here is that the where you start to improve the quality the most is is when you can curate traces, curate examples from production, and bring those back to your your data set. So, this right here, like this sort of like very sim- simplistic workflow, is what I was describing. This pin this um this record here, this row, this trace, it perhaps is indicative of some failure mode. And I want to bring this back to either an

[1:17:54] existing data set or a new data set that I want to run an an eval against. Correct. Um so, I think like the sort of culmination of of all of this is uh how we can uh use all of those those sort of primitives that I described earlier. I think the topics pipeline uh running behind the scenes is is kind of

[1:18:24] the the star of the show. Um the the the importance of adding to the the data set though is your your evals should evolve with your agent. And when when I think about evals, I think about a data set. I think about my agent, right? So, it’s like function that invokes my agent. And then I think of the series of scores that allow me to understand good or bad with respect to those test cases being passed to my agent. But, when I create my eval set,

[1:18:55] it’s a very sort of like it’s a way for me to establish a baseline. It is certainly not representative entirely of what users can do with my agent. And so, by me adding new records to that data set, it allows me to capture different perhaps failure modes over time and go make changes within my agent so that, right? We don’t we don’t continually experience those those issues in the future. But, it’s it’s more about like the the evolution of your agent and ensuring

[1:19:26] that all of those sort of like things that come along with your evals evolve with it. Um so, that you can one capture new things, but also like as you go change your code, you’re not regressing based you’re not regressing your agent based on previous interactions that you sort of curated into that data set. Um there’s there’s a few different ways to uh install this. Uh I’m going to choose just the top one. >> [clears throat] >> Uh so, if you have the the GitHub CLI installed, you can use that. Uh there’s also uh NPX.

[1:19:58] And there’s just cloning the the repo locally and and following the different install so, like with respect to the agents that you’re using. Okay. So, we we have the the skill file. We’ve installed that. Um so, now I might want to just like run this this flywheel. I want to see this in action. So, I’m going to I’m going to do two different things here.

[1:20:28] I’m going to run this. And then I’ll actually show you um a previous example so you’re not just sitting here watching Codex run. So, we’ll do that. We’ll let that run. I’m going to go out to another repo. Okay. So, same same prompt. Um, and actually let me, I think I sort of

[1:20:58] skipped over one thing here that I think is probably important to highlight. Right, the actual, uh, logs here that were generated or like the topics that were that were generated. So, we should now we have all this signal, right? This is the thing that I just, um, executed Codex against this project. It should now be able to pull back all of these different things, right? these tasks, these sentiments, uh, this support workflow issue. All of this and these scores are attached to those traces and are now part of this workflow.

[1:21:29] So, we’ll let this kind of go, uh, in in this in this terminal over here. All right, we’ll we’ll come to this one as it’s running. So, sort of like what you saw in in the loop session, uh, what you’ll start to see here is, uh, Codex writing SQL commands. So, BT SQL and we’re going to pull back all of that information or the relevant information into the session. And so, we can flexibly query across this project now and across these traces and we should be able to also recognize

[1:22:01] and understand or Codex should be able to recognize and understand those topics and those, uh, those scores that were run. Um, so we have, you know, you could see here we have 968 support traces, that’s exactly what we loaded in. There are scored failures, a visible cluster of escalate to human tool errors. Um, I’m going to inspect the classifier outputs and representative failed traces and turn that into a concrete summary. So again, the ability to flexibly query with that SQL tool uh becomes pretty impressive. Uh looks

[1:22:33] like it was able to recognize something with our scores. Uh and then is, you know, continually querying. And then this is what I described earlier of actually being able to drill into the individual trace. So, it found something. It found some example that would allow us to um improve our agent again in some measurable way. We want to view that trace, write some more SQL, um but this is really what allows us to be very comprehensive and and actually pulling in all of that really rich data, uh but only pulling in those things that are actually going to drive uh some some

[1:23:05] change that we can make within our agent. Okay, so let’s see what what else we just did here. Um looks like we’re looking at how to run evals. We are viewing existing data sets. Uh we just created a a new data set. Actually, we’re in the help command. Um but but hopefully what you’re able to see here is this. This is what we’re trying to create. This is what the This is what like the

[1:23:36] the primitives in uh in Braintrust. Our topics, our Braintrust CLI, the backend allowing you to write SQL, uh having a platform that does both evals and observability. Um all of these things sort of taken together allow you to again create that that flywheel and then do so in a in a really meaningful way. Um more than happy to take some questions right now. What’s it’s really just waiting a little bit on Codex to to cook, but

[1:24:06] curious if if anybody has Yeah, go for it. Yeah, we have a hybrid deployment. So, it means the data plane, so where all of the data resides, so your traces, your experiments, your data sets, they would remain in your infrastructure, but the control plane, right, just like the web app that you’re looking at, uh, would stay with us.

[1:24:37] The The hybrid deployment is only available for the enterprise plan. Yeah. Um, to that point, just if you’re curious, like there’s two different flavors of that. There is a BYOC one, where, again, data plane is deployed in your infrastructure, but we manage it for you. Then there is more hybrid, deployed in your data plane, your team manages it. We have sort of a a Terraform provider or Helm charts based on, uh, the the the cloud that you’re on. Back of the room? You don’t have to yell.

[1:25:26] Um, I I think for the for the most part, and I think this is changing a little bit, uh, folks are using more of the, uh, the models from the the big model providers. Uh, that’s generally what I see. Um, I I think that’s that’s starting to shift a little bit. Um, I know like at the outset, it it was very very heavily skewed towards the the major model providers. Um, I don’t know like specifically, I haven’t seen small models necessarily, but I have seen folks start to, um, perhaps fine-tune their own models and

[1:25:58] and see if it can’t drive, you know, the whole idea, again, like beyond behind it, like evals, as as one example, is to be able to understand if I can swap in and out models without sort of introducing regressions or, uh, deteriorating quality of the agent. But, yeah, I’d say largely it’s it’s the the major model providers, perhaps maybe shifting a little bit.

[1:26:35] Sorry, is this like for an LLM judge? Oh. Yeah, so uh important callout, um could actually see it probably back at at this screen when you’re looking at the uh topics automation settings and advanced. The The The only option you have for

[1:27:06] both the summarization and vector embedding step are Braintrust hosted models. Um the there’s a couple reasons for that. One is that we we’ve trained trained these models to do specifically this. And and two, like the the complexity of the pipeline sort of um makes it so that you can’t just necessarily plug in any model and and and hope to achieve similar results. Uh we started off by allowing different models to be plugged into that, but the the topics pipeline or the topics that

[1:27:38] were generated as a result of that just were not were not good. And so, we have enforced it so it’s only Braintrust hosted models for this step. Yes, you can. Um I can go out to

[1:28:09] Uh so, because all of that uh all of that data exists as metadata essentially on top of the trace. You can pull it out for different uh visualizations. So, I think in this case, I have a saved view. Um and just, you know, some some brain trust stuff here. Uh if you wanted to create your own sort of dashboard or your own view, uh this is how you would do that. Uh all of these views are like uh you can save it, you can create your own custom charts, but uh up here at the top, you can see

[1:28:40] sort of sentiment over time, tasks over time, top sentiments, top tasks, like the things that you’ve built custom uh can be pulled out in here. Uh you can see that like in this case, I’m looking for classifications.sentiment is not null, and I’m grouping by that label. So, these these become pretty simple to to set up. Yeah, I think so this again, grain of salt. Uh generally speaking, what I’ve seen though is like uh newer agents or newer things that are just being pushed to production have a higher sampling rate. And over time,

[1:29:11] those sort of like known unknowns or the things that your scores tend to surface become less and less, and the signal that you derive from it will will also become less. And so, you start to scale back that sampling rate. Uh I I think there’s also if you’re doing things with an LLM judge that is a little bit more on the classification side or on the taxonomy side, you can look to alter or you can look to swap that out with topics. Um Dropbox is a customer a customer that I work with, and they have this like very

[1:29:42] complex series of classification scores that they run to understand some taxonomy uh with respect to their traces. And they have experimented with uh using topics to do that. Um one because actually the most important reason for that is is it’s a much more cost-effective way to run across the majority or 100% of their traces, where the LLM judge just was not able to scale to that. You’re you’re able to generate as much signal. So, I think there is to maybe to summarize, there is a maturity

[1:30:12] that I think informs what the sampling rate should look like. It tends to scale back as the maturity of that agent increases. And then there is the types of things that the that your LLM judge might be producing. If it’s a little bit more on that classification or taxonomy side, you can look to swap that out with with topics. Yeah, so not directly within the UI, but you could create a code base score. Right? You could imagine like I invoke score one. Based on score one’s output, I go do something and I invoke score two. The

[1:30:42] return of that function is an array of scores. Right? It’s an array of score objects. But it’s yeah, it’s certainly possible, but you define it within code. There’s nothing within Braintrust that allows you to say, “Hey, I want to run score A based on the result of that, I want to wire it into score B or C.” But it is certainly possible just to create it within code. Oh, yeah. You could you could also just

[1:31:14] um your filter could look specifically for the presence of that score span and then only be invoked when when it when it’s there. Yeah. Um I forget the the customer, but this was surfaced the other day and it was

[1:31:44] more on the on the task side. Um I don’t remember specifically what it was, but it was actually something that they didn’t realize that users were doing with their agent. So, it was more of the use case of like uh feature request or um you know, unknown unknowns, but with respect to what users were doing with their agent, not necessarily a failure mode. And I think that’s been the perhaps the most surprising thing for me is that people are using it to uncover those types of things. I think when I was starting to

[1:32:14] like play around with the feature and talk to customers, it was you know, the the majority of it was was for me at least focused around the types of issues that you would be able to uncover, but I think there’s just like such a broad range of patterns that you’re now able to sort of uh attach to your traces and then use those sort of patterns together to inform something about like the the world that you didn’t know about your agent. Um so, yeah, it’s I don’t have the exact uh thing that the uh topics uncover, but it was much more

[1:32:46] around like, “Hey, I didn’t realize this uh these users were using our agents or trying to use my agent for this.” Um right now, I would say they’re they’re like use case driven or you could even imagine uh agent specific. So, in my case, I have this support agent and in my project, I am writing my logs for my support agent into my support agent project. I’m also storing the data sets

[1:33:17] that I’m running my evals for my support agent. I’m also storing the scores for that support agent in that project. So, they tend to be a uh a a container for relevant resources for a use case use case or an agent. Uh we are introducing very soon a a sort of uh first-class agent object into the project and so, you could imagine maybe there is a multi-agent system and you want all of the agents’ logs to go into the same project, but still have some delineation between agent A, B, and C.

[1:33:49] Uh so, you could imagine doing that as well. >> Um yeah, so the the sort of monitor page that I showed earlier is uh project scoped. Um if you wanted to create a more like organization scoped view, you’d have to uh create queries and pull data out of BrainTrust. Um that’ll eventually change. Uh it’s

[1:34:21] more How do we How do we allow our customers to do this? at scale. Um you could imagine trying to query across however many different projects and pulling that data into a dashboard uh becomes a little bit challenging. So, yeah, at the moment we are uh project scoped, but you could imagine that that that’s starting to change over time. I mean, I think that’s probably fair. Um I I think maybe what you’d potentially see is your your evals changing um

[1:34:53] as often as you are changing the agent. Like and it’s probably perhaps it isn’t even that frequent, um but I do think it does have the prospect to change in some way based on what you’re able to infer from users interacting with that agent, right? Like this could be This could be a prompt. This could be a tool. This could be a new tool. This could be um something within the runtime or the architecture that that needs to change. And to me, like what I’ve seen more frequently is that your evals will generally change as a result of something that you are change Like

[1:35:24] obviously if it’s a simple prompt change, like you’re probably not changing a lot within your evals outside of maybe curating some new examples into that data set. Um but but I do think what I’ve seen is that agents tend to evolve um somewhat frequently, and I think if you are being informed by actual interactions with uh with users in a real way, maybe they’re actually changing a little bit more than you’d expect. Um but yeah, I I do think it’s a fair, sort of, uh piece of feedback where uh

[1:35:54] the agent isn’t very complex. It doesn’t have, or it’s not, you know, it doesn’t necessitate a lot of changes based on the scope of of what the agent is doing. And so, the evals may not change too much as a result of it. Uh I do still think there is value in being able to generate that signal in production of of what’s going on. Um especially if you can do it in a cost-effective way, then then, yeah, it becomes like that part of it I still think there’s there’s value to. Yeah, like I I have customers that do

[1:36:25] both. Um I I I think some of it’s preference. Some of it um sometimes is just not understanding what Braintrust can do. Um allowing So, like the the codebase scores, I think, is a really good example of this, where you may have a really complex codebase score that uh uses different Python dependencies or TypeScript dependencies, and you need to run that, or you think you need to run that in your own infrastructure, because you have all of these, sort of, like, complex dependencies that are powering it. What you can do within Braintrust, when

[1:36:56] you when you go push a score, and even when you push a codebase score, you can bundle dependencies within that push. And so, the things that that score relies upon can still use those. And I know some customers that I’ve worked with just didn’t understand that they could they could do that. Uh to me, the value is, like, not having some of that, like, asynchronous code within your own codebase that um looks for those triggers, or is like it looks for, “Hey, this trace was generated, and

[1:37:26] I need to wait 60 seconds from the last event to go, sort of, be invoked.” And so, to me, the value is, like, offloading some of that complexity into Braintrust. Though, you still can do that. Um one of the, I think, unique things about, like, the Braintrust data model is that you can actually update spans in in So, if that span already exists within BrainTrust, it is mutable. And so, you could add you can you know, change the metadata, attach scores, attach different metrics. And so, if you wanted to do that in

[1:37:57] code, you had sort of like the um you know, the machinery in place on your side, it it becomes pretty trivial to go and like, “Hey, I have this span ID. I want to go attach these different scores and metrics to it.” So, I think some of it is just like it’s preference. Um some people just want to have a little bit more control, perfectly fine. Uh you can certainly do that. So, to me it’s a one it’s our back probably. Like you you still want to like be able to write some of that trace data and then lock down who

[1:38:28] can see it. I think that workflow that I just described is is a like that flywheel, that automated flywheel, is actually a great way to do that because I can surface insights to people. I can generate a PR based off of all of those insights, but I don’t give them access to the underlying traces. I give them access to the analysis of those traces. Here are the SQL queries that I ran. Here is the aggregate data that I pulled back. Um if you have just like no engine engineers are able to actually view that data, write it to a project that nobody

[1:38:58] has access to, um lock it down from that perspective, but then create sort of a service account that is actually able to like go run that sort of flywheel on top of it, so you don’t lose access to all of those insights. Yep. Most underrated features. Um My guess is the BrainTrust CLI is very properly rated. I I think I I

[1:39:30] I’d tout that uh any chance that I can get or I uh tell any engineer. The reason I say that is because I think we we released it in late February. We had a user conference. Um and I still think like I’m going out to customers today and I’m asking like are you using the Braintrust CLI CLI? Are you using it? And some of them still aren’t. Um, but to me, most like I’m I would wager 100% of you are using some coding agent, right? Like this is how you are coding today. Um, having the CLI as part of that, like I I

[1:40:01] hope you were able to see some of the like types of workflows that you were able to create. Um, to me it just is it becomes so incredibly compelling. You’re already in a terminal, you’re already in your IDE, whatever it is. Uh, use the CLI, attach that or or give your coding agent the skills to understand how to use that. And then use that to augment your workflow. Um, the other one that the other one that could be like somewhat compelling, it depends I think a little bit on your your organization

[1:40:32] and the different folks contributing to that flywheel. Uh, we have a feature called remote eval. It’s a way for you to expose that eval to a playground. And this is more like how can I perhaps uh, like in this scenario, there are perhaps subject matter experts, there are product managers, there are folks sort of like contributing to that flywheel in some way. Like they are modifying prompts or they are doing some of that hill climbing. And we sort of crafted like all of this um, you know, the these applications for them to go

[1:41:03] plug into in a low code low code type of way. The remote eval allows you to expose that eval that I showed to you earlier that like eval with a task and a data set, you can expose that to a playground with parameters so that the user of the playground can actually go and start changing the system prompt or a tool description or something like that. Like why that might be interesting for an AI engineer is that you don’t necessarily have to be sort of like the bottleneck in producing applications or uh, producing something for a product

[1:41:33] manager to go plug into and allow them to modify a prompt or contribute to that flywheel. So, maybe not as not as impactful as the CLI, but potentially given your organizational structure could be. I think I got most of that. Tell me where where I’m off. I I think like the the thing that I that I started doing here is exactly that. Uh like Braintrust itself, at least at the moment, doesn’t have access to your code base, right? It doesn’t understand like what you’ve written and based on the information it has, it

[1:42:05] can’t go recommend a change necessarily to specific functions or agent architecture. But when you bring the um Braintrust CLI into your sort of coding agent, and then attach that obviously like I’m I’m within my repo here, I’m able to now go through let’s see if we’ve been able to like get something here. So, in my session, uh based on what I’ve been able to sort of understand, we are creating new new scores. So, there’s a score change. Um there’s we can skip the tests.

[1:42:37] There is uh looks like newer tools that we were able to add to our agent again based on some of that insight. So, I I think like the the answer to your question is like this is absolutely possible. What what I’ve just sort of demonstrated here is that flywheel of like, “Hey, figure out what’s going on in production, use my scores or use my topics because I have sort of attached information of you know, issues or sentiment or

[1:43:09] whatever it is, this becomes incredibly compelling now or interesting for that agent to pull in, and then go modify your agent in some way. Um I think eventually as you get further down here, see now we have new examples to our data set. We have uh looks like we’ve created a new data set with those examples. We’re now going to go run our eval probably a little bit further down here. Uh you can also see like we are querying directly from that experiment that was run.

[1:43:39] So, that whole sort of flywheel is captured here within um within this agent improvement skill. And I think hopefully I answered your question to some degree. Cool. Um this to me is like one of the most compelling parts of Braintrust right now. Uh we’re all sort of developing our agents such to some degree with the help of a coding agent. If I can bring the right context, if I can have access to the right primitives that attach the right data to my traces, then this this flywheel, this like automated automated flywheel, becomes pretty interesting.

[1:44:30] So, I I I I absolutely think it’s feasible. Um if I could show you I’ll show you this example. Um actually, if I come back here So, within the platform right now, there isn’t like a button that you hit that says like, “Hey, go do the the flywheel.” But what I showed you is that you can very easily plug into this using all of the tools that you already have. The things that you’re now able to to do on top of this, right? You could imagine like maybe plugging this into a GitHub action that runs at some particular

[1:45:01] cadence that that gets triggered based on something and we open a PR. Uh you could also imagine it’s like triggered off of a Slack message, right? There are lots of different ways in which I think this could be triggered. Under the hood, all of the things are available for you to go sort of opt into this. Um one example Here’s a here’s an example of uh a GitHub action that that I that I created. So, under the if you look, there’s a a YAML file that actually runs through uh Claude code. It pulls in the

[1:45:31] Braintrust CLI. It pulls in the skill. But the the sort of again, like the thing that we we need still here is we need to understand in this case like what changed. And this is like my very very trivial supervisor agent uh example. What changed? Why these things changed? Why did Why did uh in this case Claude code recommend these changes? Here is the the actual impact, right? Based on the evals that that I ran. Here’s some links out to Braintrust where you can actually go inspect those. Here are these regret regressions that I

[1:46:02] pulled in based on that analysis. And then here is your PR. You You’re the reviewer. Go figure out if this is like a meaningful thing that we should go and and and produce. Um so, I absolutely think this is something that that you can opt into today. Like we have customers that are absolutely doing this. Um one of them that was on a that the first slide that I showed is using this to generate five to 10 more PRs per day than they were before. Um if you have again all of that information, if you have like the uh that really intelligent Codex Claude

[1:46:33] code or whatever querying very flexibly over your production data and pulling in the things that are that are interesting, I think it becomes pretty compelling from a lot of different use cases. Yeah. Yeah, that that Braintrust skills repo. This is open source. Yeah. There’s a There’s a YAML file in here as well that like that went through the actual um like GitHub like it did it within a GitHub action. Open source as well. Yeah.

[1:47:13] Yeah. Yeah, so what it looks like is Um, so I I I showed earlier how we write evals or one of the ways in which you can write evals with BrainTrust is by using that eval code. So,

[1:47:43] here’s my eval for a different project that I’m taking you outside of. The the one sort of thing that I call out here that’s different that you didn’t see in the previous code is the parameters. Um, under the hood here I am essentially uh I have exposed different parameters that that touch my sort of agentic system. And in this case it’s, you know, something somewhat trivial, right? It’s the supervisor agent, but if you look over at the playground itself, um, come over here. So, you have different things that you can pull into BrainTrust, right? The I

[1:48:14] think, you know, I don’t think a lot of people use it very much for prompts anymore outside of like the the very basic stuff, but that remote eval, I can spin up a dev server, so I can be local, I could write um eval my file name {dash} {dash} dev. It spins up a server and it um automatically looks for it on localhost 8300. Um, you could also expose this server within your own infrastructure. You have sort of um created that eval and you have exposed it and then you’ve also exposed different parameters. So, in this case

[1:48:45] I’ve exposed a system prompt and the model for that system prompt. And if I scroll down a little bit further, there’s also math agent prompt, model, research agent prompt, and model. But, I can sort of interact with all of that complexity, all of the tools that each one of those agents have directly from the playground. I can simply click run, it’ll go through, and all of the code execution remains on the server and then the results of that eval are streamed back into the playground.

[1:49:27] >> Yes, Brain Trust will initiate a post request to an eval’s endpoint that you have exposed on that server. So there’s there’s like very I can show you another example here. Um where you can there’s a sort of like create app function that you can use or you can sort of strip out the things that you would need to spin up the server. But that that remote eval server right now is is stood up on modal. I’m using this

[1:49:57] create app. It exposes all of the evals, at least in the way that I’ve configured it, in my evals directory. And now those are exposed to the playground for users to go and play with. One of the things that we are doing internally right now is we are and it’s really driven a lot by interactions that we have with our customers. I think I mentioned this at the outset like people are thinking very heavily right now about how well their their coding agent is actually how well how efficient they are with their coding agents.

[1:50:29] Um and part of that is actually it’s running evals on the skills that they’re using. It’s understanding the sessions that they have with cloud code and codex and so on. I think they’re still I say that with um I say that because we are putting a lot of effort behind the scenes into creating some of the different primitives and machinery that our customers can go like plug into or use to start to go understand those those types of things. Um yeah, just because you see like two commits and and one star there is not

[1:51:00] indicative of like where we uh like what we perceive to be as a very very important problem uh for engineers today. Yeah. Cool. Awesome. Thanks, everybody. Appreciate you coming out.

[1:51:34] >> [music]