A pilha open source de agentes que se aprimoram sozinhos — Marc Klingen, Langfuse

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: The Self-Improving OSS Agent Stack — Marc Klingen, Langfuse · Canal: AI Engineer · 16:36 · Assistir no YouTube

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

Resumo

Marc Klingen apresenta um fluxo de aprimoramento de agentes que combina traces de produção, conjuntos de dados, evals e mudanças propostas por agentes de IA. A automação pode assumir tarefas repetitivas, como identificar padrões de falha e sugerir melhorias, enquanto pessoas continuam definindo objetivos e revisando alterações importantes. Uma demonstração mostra um agente que redige documentação e changelogs, identifica problemas de clareza e jargão interno e propõe mudanças testadas contra uma versão de referência. O palestrante também destaca a necessidade de uma camada de dados escalável, econômica e capaz de reter traces por bastante tempo.

Pontos-chave

O aprimoramento de agentes combina monitoramento online de traces com experimentação offline em conjuntos de dados e evals.
O ciclo tradicional exige muito trabalho manual: analisar traces, atualizar dados de avaliação, criar evaluators e testar mudanças.
Agentes podem propor melhorias na implementação e também sugerir atualizações em conjuntos de dados e critérios de avaliação.
A revisão humana é importante para definir objetivos e evitar que o sistema otimize demais para casos irrelevantes ou produza resultados de baixa qualidade.
Sinais de produção, como feedback de usuários e alterações feitas por funcionários, podem alimentar continuamente o ciclo de aprimoramento.
Na demonstração, um agente de redação identifica jargão interno e falta de clareza e propõe mudanças avaliadas contra a implementação anterior.
Os agentes podem rodar periodicamente sobre dados acumulados, por exemplo, em um job diário ou semanal.
O uso de agentes para analisar grandes volumes de traces aumenta a demanda por uma camada de dados escalável, econômica e com retenção prolongada.

Capítulos

Início	Capítulo	Resumo
00:01	A evolução dos agentes e o ciclo de aprimoramento	Klingen descreve como o avanço dos modelos tornou possível automatizar ciclos que conectam uso em produção, dados de avaliação e novas versões dos agentes.
03:08	O que automatizar e onde manter a revisão humana	O palestrante explica os diferentes níveis do ciclo e defende que pessoas continuem definindo objetivos e revisando dados e critérios de avaliação.
07:51	Equilibrar automação, qualidade e supervisão	A meta é retirar as pessoas do trabalho repetitivo sem abrir mão da supervisão que orienta o sistema e evita otimizações inadequadas.
10:26	Demonstração de um agente para documentação	Um agente analisa mudanças de produto, recebe revisão humana e usa os sinais resultantes para melhorar a clareza e reduzir o jargão interno.
15:05	Aprendizados e infraestrutura de dados	Klingen resume o ciclo de coleta de sinais e avaliação e destaca a necessidade de armazenar traces em uma infraestrutura escalável e econômica.

Citações

Como podemos passar de conduzir esse ciclo manualmente para usar IA para conduzi-lo? — 03:08

Você define a direção e, então, a IA pode automatizar o trabalho com base nela. — 07:51

A IA consegue analisar muito mais casos de erro. — 09:24

Você quer ser dono da camada de dados. — 16:06

Conceitos e entidades

self-improving agents (conceito): Agentes que usam sinais de uso e resultados de avaliação para propor melhorias em outros agentes ou em sua própria implementação.
tracing and monitoring (conceito): Acompanhamento das execuções dos agentes em produção para entender como eles respondem e identificar problemas.
offline evaluation (conceito): Teste de mudanças em agentes com conjuntos de dados e critérios de avaliação antes de aplicá-las em produção.
Langfuse (empresa): Empresa cuja plataforma é apresentada como forma de conectar traces de produção a conjuntos de dados e avaliações offline.
Marc Klingen (pessoa): Cofundador da Langfuse e palestrante sobre ciclos de aprimoramento de agentes.
Loopcraft (conceito): Artigo mencionado como exemplo de visualização de ciclos de aprimoramento em diferentes níveis.
change log writer (conceito): Agente demonstrado que propõe atualizações para documentação e changelogs com base nas mudanças lançadas.
GitHub (ferramenta): Plataforma usada no exemplo para revisar e aprovar alterações de documentação por meio de pull requests.

Tradução completa (pt-BR)

00:01 [música] Pessoal, estou superanimado por estar aqui. Ah, certo. Meu laptop estava me avisando que isso começa agora. Oi, pessoal. Sou Mark, um dos fundadores da Langfuse. Estou superanimado para conversar sobre o que temos visto, sobre como as pessoas estão fazendo agentes se autoaperfeiçoarem e sobre que tipo de stack de referência open source está surgindo. Quer dizer, obviamente, minha visão

00:31 se baseia no trabalho com nossa comunidade de pessoas que usam a Langfuse para rastrear e avaliar seus agentes, mas acho que vou tentar manter a palestra focada principalmente em conclusões mais genéricas, que funcionem com qualquer stack que vocês estejam usando. Mas, sim, depois da palestra, ficarei feliz em conversar sobre os diferentes prós e contras. Em linhas gerais, acho que este é o ano em que as equipes falam sobre elevar o nível em que operam, porque modelos cada vez melhores simplesmente abstraem tudo que vem depois. Quer dizer, isso vem de alguém que diz: “Não escrevo prompts, tenho loops.” Peter

01:02 está escrevendo sobre isso, e a auto pesquisa está se tornando muito popular. Então acho que é mais ou menos para aí que as coisas estão caminhando, tanto no lado da produção de aplicações quanto em como realmente construir boas aplicações com agentes. Ao longo dos anos, os modelos ampliaram muito suas capacidades. Quando começamos a trabalhar na Langfuse, foi bem na época em que o Claude foi lançado, então até as aplicações mais simples não funcionavam direito. Por exemplo, construímos uma automação de issues do GitHub para pull requests, parecida com o que Devon ou Cursor estão desenvolvendo, mas, naquela época,

01:34 só conseguíamos manipular aplicações de página única, como um único arquivo HTML, porque editar vários arquivos era complicado demais. Desde então, todas essas coisas aceleraram muito, e isso realmente tornou os loops possíveis. Ao mesmo tempo, surgiu uma stack de referência mais clara para mostrar como construir ótimos agentes de IA, porque construir agentes é diferente de construir aplicações. É como uma sequência de rastreamento e monitoramento online de como os usuários realmente usam uma aplicação com agentes e, depois, um componente offline para criar conjuntos de dados, experimentar e

02:06 fazer alterações nesses agentes, avaliar offline se as coisas funcionam, implantar a nova versão em produção e, então, aprender novamente com o uso da aplicação por usuários reais. É uma espécie de loop. Tradicionalmente, você tem ferramentas de observabilidade e o Datadog no lado do rastreamento e monitoramento, e ferramentas de MLOps, como MLflow e Weights & Biases, mais no lado offline. Surgiu essa nova categoria, e esse também é o motivo pelo qual criamos a Langfuse: é preciso unir o online e o offline. Caso contrário, você acaba fazendo benchmark com dados imprecisos, com conjuntos de dados que não estão no loop nem sincronizados com

02:37 o que está acontecendo em produção, ou monitora os dados de produção, mas não faz benchmark offline. Então é preciso unir os dois. Mas isso envolve muito trabalho manual, porque você precisa analisar traces, atualizar esses conjuntos de dados, pensar em novos avaliadores e, depois, fazer essas alterações e criar novas hipóteses. É muito trabalho envolvido nesse processo. Desde que começamos a trabalhar na Langfuse, tentamos ensinar as equipes a conduzir bem esse processo, mas geralmente elas nos perguntam: “Ah, os modelos melhoraram. Como podemos sair do loop e automatizá-lo?”, porque é muito trabalhoso

03:08 fazer as coisas funcionarem. E é sobre isso que quero falar: como vemos as pessoas passando de conduzir esse loop manualmente para usar IA para conduzi-lo. Usamos a visualização de artigos como o artigo Loopcraft, ou de muitos outros artigos nessa área, que colocam diferentes loops uns sobre os outros. No nível mais baixo, você tem o loop de tokens: qual é o próximo token a ser produzido? E, no nível mais alto, está a forma mais abstrata de pensamento, em que você, como ser humano, ainda participa. Então, vamos ver como avançamos por eles, um por

03:41 um. Em linhas gerais, quero apenas destacar que tudo isso só é possível porque os modelos melhoram. Então, quando começamos a trabalhar na Langfuse, em 2023, tínhamos o GitHub Copilot; isso tornava possível o nível mais baixo, ou o nível dois. O nível três se tornou possível mais em 2024, e agora, em 2025 e 2026, estamos mais nos loops de nível superior, em que os próprios agentes raciocinam sobre o que corrigir, como propor novas correções e como verificar se elas realmente funcionam. O que ainda requer a participação de humanos é, primeiro, alinhar conjuntos de dados de exemplos de

04:13 perguntas que mostrem como os agentes são usados. É aí que os humanos precisam revisar o que é adicionado ao conjunto de dados e, depois, avaliar se os agentes realmente funcionam. Essas são as duas partes azuis no loop número três. Depois, ao propor correções, se o seu agente propõe como alterar um agente, você ainda quer ver o que foi alterado, porque há o risco de ajustar demais o agente ao conjunto de dados e à definição de falha. Normalmente, os agentes encontram todo tipo de padrão de falha diferente, mas

04:45 talvez alguns deles não sejam tão importantes assim, e você pense: “Hum, esse tipo de caso de uso do agente não importa tanto. Isso está fora do que o agente deveria realmente fazer.” Então não precisamos ajustar demais nossa aplicação a essa peculiaridade aleatória que encontramos em produção, mas queremos participar do loop para monitorá-la. Partindo desse padrão de loop, tentamos decompô-lo novamente em um workflow. O que vemos ser o uso mais comum de IA atualmente é a proposta de correções. Então, se temos traces de produção e critérios de evals e conjuntos de dados que reproduzem os problemas que encontramos em

05:16 produção, como subir o desempenho gradualmente com base nos conjuntos de dados? Essa é uma maneira muito legal de, por assim dizer, chegar ao sucesso por meio de loops com agentes, porque geralmente há umas dez coisas diferentes que você poderia fazer. Não sei: usar outro modelo, agregar o contexto de uma maneira nova e diferente. Tentar qualquer coisa que você encontre no X em uma determinada semana para ver se isso consegue melhorar o agente. Mas o importante é manter os limites do que você está otimizando. E usar IA principalmente para propor melhorias à implementação do agente.

05:46 No último mês, eu diria, vemos cada vez mais equipes usando IA nos seus loops para manter critérios de evals e conjuntos de dados. O que costuma entrar aqui é o alinhamento entre o formato de um conjunto de dados para um agente e o que os usuários realmente estão fazendo. Por exemplo, se temos uma aplicação de suporte ao cliente, como um agente de suporte, o conjunto de dados deve conter perguntas comuns de suporte. Mas os usuários fazem todo tipo de coisa com uma aplicação de suporte. Então, é preciso mantê-lo continuamente alinhado com

06:17 o que os usuários estão fazendo, e você pode usar agentes para isso. E também para evals: se você observar padrões de erro comuns, pode reproduzi-los e propor novos critérios de evals para esses conjuntos de dados offline. Por exemplo, não sei: quero ser conciso; quero responder no mesmo idioma que o usuário usou na pergunta da minha aplicação de suporte ao cliente. Então, você também pode propor novos avaliadores. Acho que isso ainda é relativamente novo, algo que surgiu nos últimos meses. E é aí que vemos a IA fazendo loops de forma mais automática. No entanto, normalmente, as equipes que

06:48 ainda estão envolvidos na revisão dessas mudanças, porque elas criam o novo limite em relação ao qual os outros agents tentam se aprimorar automaticamente. Se você deixar isso completamente sem controle, corre o risco de simplesmente criar mais conteúdo ruim. Usamos isso em uma publicação de blog nossa, na qual eu diria que o objetivo de uma aplicação de IA está sempre mudando, porque você não sabe muito bem. Normalmente, você começa com uma tarefa de alto nível. Vou continuar com o exemplo do suporte ao cliente. Você parte de alguém dizendo: “Ei, na nossa empresa, os clientes precisam esperar muito pelas respostas do suporte, e temos muitas pessoas empregadas para responder a

07:19 eles. A IA deveria conseguir fazer isso automaticamente, ou pelo menos ajudar no suporte ao cliente, mas é um objetivo muito vago, porque as pessoas nem sabem o que acontece no suporte ao cliente todos os dias. Então, é meio que: “Ah, queremos automatizar tudo isso”. No entanto, ao longo do processo, você descobre o que precisa fazer com base nos casos de erro. E é como esse mapa que você monta enquanto o avião está voando. E, quando olhamos para esse gráfico cíclico, você realmente quer estar envolvido na definição das metas e na maneira como faz mudanças nos conjuntos de dados e nos evaluators.

07:51 Você quer estar envolvido nesse ciclo, porque é você quem define a direção; então, a IA pode automatizar com base nela. Depois das mudanças recém-implementadas, você verá novas classes de erro e poderá mudar a causa, mais uma vez, no nível mais alto. Assim, você se livra de muito do trabalho mais manual e tedioso nos níveis inferiores. Essa é, então, a visão geral de como eu conceituaria os diferentes cenários em que você pode se encontrar. Eu diria que, se você implementar bem esse workflow de IA, com tracing

08:23 online de como seus agents estão trabalhando, implementando evals sobre o desempenho deles, mantendo conjuntos de dados com perguntas de exemplo e fazendo benchmarking com eles, você estará nessa categoria de investimento de tempo muito alto, porque precisa de uma equipe que trabalhe com esses dados toda semana. Mas a qualidade dos agents também é bastante alta. Quero dizer, é assim que as equipes vêm usando, por exemplo, a Langfuse nos últimos anos, e é assim que você pode, eu diria, alcançar o sucesso com sua aplicação de agent. Se você automatizar tudo completamente, eu diria que não precisa investir tempo nenhum, porque é só, não sei,

08:53 usar o modo de objetivo do Codex para chegar ao sucesso, ou adicionar ciclos de nível mais alto por cima disso. Mas você também corre o risco de que isso produza muitos tokens que não fazem muito sentido. Então, acho que você quer estar nessa espécie de terra prometida: não precisa investir muito tempo, mas participa das etapas mais importantes do ciclo, como definir a direção para onde quer ir, enquanto se livra de tudo que é tedioso. Assim, você investe muito menos tempo do que executando tudo manualmente. E a qualidade também pode ser ainda maior, porque, normalmente, se você precisa fazer tudo manualmente, fica limitado

09:24 pelo seu próprio tempo, pela sua própria perseverança, resistência ou paciência para analisar tantos dados, enquanto a IA consegue analisar muito mais casos de erro. Esse agent terá um desempenho melhor, e você precisará investir menos tempo. Acho que era isso que buscávamos. E a aparência disso é a seguinte: você participa no nível mais alto, mas também quer, idealmente, que sua aplicação forneça sinais interessantes. Por exemplo, quando falamos do caso de uso de uma aplicação de suporte ao cliente, os clientes podem xingar o agente de suporte.

09:55 Os clientes podem dizer: “Ah, não, você não entendeu” ou “isso não está correto”. Ou você pode sugerir mensagens a um agente interno, que pode aceitá-las ou alterá-las antes de enviá-las. Então, há muitos sinais implícitos que podem alimentar seu processo sem que você, como desenvolvedor do agent, precise fazer isso manualmente. Assim, você tem um fluxo contínuo de sinais sobre o qual seu ciclo pode atuar. Então, pode ser você, sua equipe ou algum sinal que chega, e os ciclos de nível inferior podem ser automatizados. Essa é, em linhas gerais, a nossa maneira de pensar sobre isso. E…

10:26 montamos uma aplicação de demonstração bem rápida que mostra isso. Por exemplo, nós, da equipe da Langfuse, temos um grande problema agora, porque nossa equipe de engenharia usa bastante IA e, por isso, lança muita coisa. De algum modo, precisamos atualizar nossos clientes e nossa base de usuários sobre o que há de novo toda semana, porque, nas últimas semanas, muita coisa foi lançada. Normalmente, precisamos atualizar a documentação, atualizar um changelog e publicar sobre isso nas redes sociais. Historicamente, os engenheiros faziam isso por conta própria

10:56 porque talvez lançassem um recurso maior uma vez por mês, então não tinha problema gastar algumas horas nisso. Mas agora, se eles deixam de fazer esse trabalho e realmente lançam muito produto, idealmente também querem automatizar esse tipo de processo de lançamento, porque, caso contrário, ficamos limitados pela rapidez com que conseguimos comunicar as mudanças. Então, pensamos em montar um redator de changelog que simplesmente atualizasse muitos dos recursos públicos com base no que lançamos. No entanto, surge a questão: estamos nos comunicando bem? Porque, se nos comunicarmos mal sobre o que lançamos, então, quero dizer, de certa forma

11:29 sabotamos nossos lançamentos se, por exemplo, representarmos incorretamente o que foi lançado. Então, a configuração é esta: temos um pull request de merge e um redator de changelog que sugere uma alteração na documentação. Depois, há uma etapa de revisão de código, como um pull request no GitHub, em que alguém pode revisar e aprovar no GitHub para que a alteração seja integrada, ou enviar solicitações de mudança indicando o que precisa ser alterado nessa mudança da documentação e no changelog. Então, o redator de changelog

11:59 agiria com base nisso mais uma vez para atualizar o rascunho até que ele fosse finalmente lançado. E agora, os dois tipos de sinal — aprovações ou solicitações de mudança — podem ser enviados à observabilidade e às evals de IA para servir de base ao aprimoramento automático desse agent redator de changelog. O que fizemos agora foi simplesmente usar um coding agent apontado para as agent skills da Langfuse. Mas, em geral, isso também funcionaria com outros sistemas. Só que a Langfuse está bem posicionada para isso. Pedimos: “Certo, o que aconteceu

12:30 nesta aplicação? Como podemos melhorá-la?” Vou pausar algumas vezes, porque, caso contrário, isso vai passar muito rápido. Por exemplo, identificamos aqui que o redator — o redator de changelog — é muito preciso nos fatos ao fazer alterações na documentação, mas a clareza é baixa. A proporção de edições feitas por nós, humanos, por meio do envio de solicitações de mudança ainda é alta, e estamos expondo jargão interno aos nossos clientes. Talvez nosso código tenha comentários internos que deixamos para nós mesmos, para o futuro, mas

13:01 nossos clientes não pensam na nossa aplicação como, não sei, um pipeline de ingestão ou algum tipo de fila de processamento em lote. Eles não sabem que isso é um detalhe de implementação. Deveríamos falar sobre isso usando a linguagem do domínio dos usuários. E essa é uma coisa que identificamos aqui. Agora, o agent sugere mudanças nos conjuntos de dados e nos evaluators para detectar o uso de jargão e também aumentar a clareza na linguagem do domínio do cliente.

13:32 basicamente, de linguagem. Então, agora o agent fecha essa lacuna, sugere mudanças nos conjuntos de dados e nos evaluators e, então, tem uma ideia de como mudar a implementação do agent para basicamente corrigir esse problema, porque, no fim das contas, é meio que só um problema de como fornecemos contexto, de como fornecemos a skill que então instrui esse redator de conteúdo. Agora podemos fazer um backtest, basicamente, no conjunto de dados atualizado para ver se a nova implementação se sairia melhor do que a antiga, e

14:02 Vou parar aqui de novo, no ponto em que temos a baseline. Então, basicamente, reproduzimos o problema da linguagem voltada aos usuários. Vamos falar sobre recursos da maneira como os usuários falariam deles. Reproduzimos esse tipo de problema com a baseline v1. Essa é basicamente a implementação existente do agent, e o agent criou uma nova implementação, que vemos como a candidata v2. Ainda estamos avaliando a conformidade com o formato e a precisão da mesma maneira que antes, mas melhoramos a linguagem voltada aos usuários. Então, vemos uma variação positiva, o que parece uma boa mudança

14:34 agora. Então, o agent raciocina sobre isso assim. Quero dizer, esta é uma aplicação interna, então é meio que no estilo YOLO. Pensamos: “Tudo bem, podemos simplesmente fazer o merge e depois agir de novo na próxima mudança”, porque esse agent nunca publica nada na produção de verdade. Ele só abre PRs em um repo. Então, tudo bem se ele meio que se aprimorar automaticamente; depois, damos feedback de novo para o próximo incremento. Aqui, usamos nossa lógica de gerenciamento de prompt para que o agent possa basicamente lançar essa nova implementação como um recurso e

15:05 agora ele só resume, basicamente, como agimos em relação a isso. Em linhas gerais, é isso que vimos a maioria dos nossos melhores usuários já fazer: coletar sinais de produção, acompanhá-los junto com traces de execução detalhados e depois executar agents em um loop, geralmente como um cron job, todo dia, toda semana, sempre que houver um lote de dados de usuários interessantes para analisar de novo e agir com base neles. Pode ser apenas feedback dos usuários

15:35 sobre como isso acontece neste caso, ou uma rotulagem interna feita em um sistema de produção. Mas também pode ser pedir que as pessoas anotem dados no app, por exemplo. No Langfuse, também permitimos que as anotações alimentem essa fila. E é isso, em linhas gerais, que observamos. Vai ser um prazer fazer uma demonstração mais aprofundada no nosso estande ou depois desta palestra, mas eu só queria encerrar de forma bem concisa, falando sobre como vemos esse espaço evoluir. Acho que o interessante aqui é que isso gera a necessidade de um sistema de dados muito escalável, porque vocês vão querer que os agents trabalhem continuamente com esses

16:06 dados e produzam muitas consultas. Vemos que, historicamente, o Langfuse era muito mais intensivo em gravação, para ingerir evals e traces. Agora, é muito mais intensivo em leitura, porque os agents conseguem processar muito mais dados. Interessante. Em primeiro lugar e em segundo, vocês realmente querem controlar a camada de dados, porque agora os traces de, por exemplo, um ano atrás, são um contexto interessante, e vocês não querem que fiquem presos em um sistema mais comercial ou algo assim, onde seja necessário amostrar os dados ou retê-los por um período longo ou curto. Queremos retê-los por muito tempo

16:36 e não os amostrar. E isso realmente gera a necessidade de uma solução escalável e barata. Já trabalhamos com muitos clientes nisso, então será um prazer conversar individualmente sobre o assunto se tiverem interesse. Muito obrigado pelo

Transcrição original

[00:01] [music] Everyone, super excited to be here. Ah, okay. My laptop was alerting me that this starts now. Uh, hi everyone. I’m Mark, one of the founders of Langfuse. super excited to chat about uh what we have seen how how people like self-improve agents now and what kind of like open source reference stack uh we see emerging. I mean obviously my view

[00:31] is based on working with our community of people that use language to trace and evaluate their their agents but I think I try to keep the talk mostly to to like more generic takeaways that work with whatever stacks you’re using. Um but yeah happy to chat about the different pros and cons after the talk. high level. I think this is the year uh where uh teams talk about like upleveling the the level of uh where where they operate themselves where increasingly good good models just abstract everything downstream. I mean coming from I don’t write prompts I have loops u Peter

[01:02] writing about it auto research becoming really popular. So I think this is kind of where things are going on the like like producing um application side but also on the how to actually um build good good agent applications and um over the years really models have have expanded a lot in capabilities um back when when we started working on length fuse this was right when ch was released so uh where like even the simplest applications didn’t really work so for example we built like github issue to pull request automation similar to what devon or kurs are building but back then

[01:34] we could only manipulate like single page applications like a single HTML file because multifile edits were too complicated. Since then all of these things really accelerated a lot and this really made made loops not possible. At the same time a more like reference tech emerged of how great AI agents are built because building agents is different from building applications. It’s like an like a link of like tracing and monitoring like online how users really use an agent application and then like an offline component of how to build data sets how to experiment uh regarding

[02:06] like making changes to these agents and then evaluating offline whether things work then deploying new to production then learning again for real users use the application uh so it’s like this this kind of loop where traditionally I mean you have like obsibility and the data docks here in the tracing monitoring side and you have like the ML ops toolings like MF flow weights and biases more on the like offline side where this new category emerged and that’s also why we built length fuse because you need to bring the online and the offline together as as otherwise like you either benchmark on data that’s inaccurate so the data sets they’re not in loop and like uh not in sync with

[02:37] what’s happening in production or you monitoring like production data but you don’t really benchmark offline so you need to bring the the both together but this has been like a lot of manual labor because you need to look at traces update these data sets think about like new evaluators uh then make these changes create new hypothesis like it’s it’s like a lot of work going into this process and since starting working on language we try to educate teams how to how to do this process well but it’s it’s usually like the ask them like oh models got better now how can we take ourselves out of the loop to uh to automate it because it’s really tedious

[03:08] uh to get things going and that’s what I want to talk about how we see how people go from manually driving this loop to using AI to to drive this loop um we use the visualization um like of for example like the loopcraft article or like many many articles in the space that like layer different loops on top of each other. How I mean at the at the lowest level you just have like this token loop of what’s the next what’s the next token that’s produced and on the very high level it’s uh like like the most abstract form of thinking where you as a human are still involved. So what we see how um we go through them one by

[03:41] one high level I just want to highlight these are again possible because models improve. So uh when when we started working on length in 2023 like I mean we had github copilot so like the lowest level or the uh level two u then level three was possible like more in 2024 and now2526 is more like the higher level loops of actually agents reasoning about what what to even fix uh how to propose new fixes and how to how to verify whether they actually work. Where humans are currently still involved is one you need to align data sets of example

[04:13] questions of how the agents are used. This is so like where where humans need to review um like like what what gets amended to the data set and how to then evaluate whether the agents actually work. These are the the two blue things in in loop number three. Then on the proposal of fixes because if um like your agent proposes how to change an agent, you still want to see what was changed because you have the risk of like overfitting it to um to like the data set and the failure definition. Um, so I mean usually agents find all sorts of different uh failure patterns, but

[04:45] maybe some of them don’t really matter that much and you’re like, huh, this kind of use case for the agent, it doesn’t really matter that much. Like this is like out of what the agent should be actually be doing. So we don’t need to over fit our application to this random quirk that we found in production, but we want to like be in the loop to to monitor this. And now coming from this loop pattern, we try to dissect it again into more like a workflow where where we currently see AI used the most is in proposing fixes. So if we have production traces and we have like evil criteria and data sets of how to reproduce issues that we find in

[05:16] production, then this how do we hill climb against the data sets? That’s like a really cool uh way to kind of like loop your way to a success with with agents because usually they’re like 10 different things of what you could be doing. I don’t know, use a different model like aggregate context in a new different way. Try whatever you find on X uh in a given week to to see whether it can like uh make a dent into improving the agent. But really like you maintain the boundary of what you optimize against. And you use AI mostly for like proposing improvements to the agent implementation.

[05:46] Like over the last I’d say month, we see more and more teams also using uh like like AI and and their loops to maintain evil criteria and maintain data sets. So uh usually what goes in here is you want to like align how a data set uh looks like for an agent with what actual users are doing. So for example if we have an customer support application like support agent then the data set should be like common support questions but like users do all sorts of things with a support application. So you need to continuously keep it in line with uh

[06:17] with what users are doing and you can use agents for that. And for EVAs as well if you see usual error patterns then you can reproduce the error patterns and propose new evil criteria on these offline data sets. So for example I don’t know I want I don’t want to name competitors. I want to be concise. I want to answer in the same language as the user actually requested. Um like the question in my customer support application. So you can also propose new evaluators. This is I think rather newish over the last months. um and where we see like the AI more autolooping. However, usually teams that

[06:48] are still involved in reviewing these changes because they create the new boundary for how then other agents try to auto improve against it. If you give this completely out of hand, you risk like that you just create more slop where we’ve used this in like a blog post of ours where I’d say the target of an AI application is always changing because you don’t really know like usually you start with a very high level task of I stick with customer support. You stick with someone says hey in our company customers need to wait a long time for support answers and we have a lot of people employed to respond to

[07:19] them. AI should be able to do this automatically or at least eight in customer support, but it’s a very wake target because people don’t even know what happens in customer support every day. So, it’s kind of like, oh, we want to automate all of it. However, then on the way of doing this, you figure things out based on like error cases of what you even need to do. And that’s like this kind of like map that you like you assemble the plane while you’re flying it. Um and how we then look at the uh at this kind of like looping graphic is you really want to be like involved in setting the setting like the the goals and how you make changes to data sets

[07:51] evaluators you want to be in that loop involved because you set there by the direction and then AI can automate against it and then off of the newly implemented changes you’ll see new error classes and you can then like change cause again on the most highest level but thereby you pull yourself out of a lot of like the more manual and tedious work on the lower levels. Um, this is then the high level view of how how I would conceptualize like the different scenarios that you can find yourself in. I’d say if you implement this uh like AI workflow well of tracing

[08:23] online uh how your agents are working implementing evals on how they are working um having data sets uh of example questions and then benchmarking against them you are in this era in this class like very high time invest because you need a team who really works with this data every week but also quality of the of the agents is pretty high I mean that’s what teams have been for example using length use for for the last years and this is how you can get to I’d say success with your agent application. Um, if you fully automate it, I would say you don’t really need to invest any time because you’re just like, I don’t know,

[08:53] codeex goal mode your way to success or like you add higher level loops on top of it, but you also risk that like it produces a lot of tokens, but don’t really make sense. So, I think you want to be in this kind of like promised land of you don’t really need to invest a lot of time, but you’re like in the loop at the most important steps of like setting the direction of where you want to go, but you take yourself out of everything that’s tedious. Thereby you’re way less time invested than running it manually. But also the quality can be even higher because usually if you need to do everything manually you’re bottlenecked

[09:24] by your own time your own like perseverance endurance uh or like patience to look through so much data and AI can just look so through like so much more error cases. This agent will be higher performing and you need less time invest. That’s the I think that’s what we were going for and how this then looks like is uh you involved at the top but also I mean you want ideally your application to feed in interesting signal. So for example when we talk about the like customer support application use case usually I mean customers can swear at the support agent

[09:55] customers can be like oh no you don’t understand uh like this was not correct or like you can propose messages to an internal agent who then can accept them or change them when sending them out. So there’s like a lot of like implicit signal that can feed into your process without you as the agent developer needing to do this manually. Uh thereby you have like an like an instream of of signal that your loop can act on. Um so it’s either you your team or some signal coming in um and the lower level loops can be automated. That that’s high level how we how we think about it. And like

[10:26] uh like we put together like a super quick demo application um that can that can show this. Um so for example like we as the language team we have a big problem now because our like engineering team uses AI a whole lot thus they ship a whole lot and somehow we need to update our customers uh and user base uh what is what is new every week because uh like in recent weeks like a lot was released uh and usually need to update documentation update a change log post about it on socials and historically like engineers did this themselves

[10:56] because they maybe released like a bigger feature like once every month so it’s okay to spend a couple of hours. But now if they take themselves out and really ship a lot of like product, they want to ideally uh like automate also that kind of like release process because otherwise we are bottlenecked by how fast we can communicate about changes. So um we thought about like putting together like a change lock writer that just uploads like like updates a lot of like the public assets based on what we’ve shipped. Um however then the question is is like how we communicate good because if we communicate badly about what we’ve released then I mean we we kind of like

[11:29] sabotage our releases if we like misrepresent for example what has even been released. So um setup is we have a merge PR, we have a change writer that uh suggests a change to documentation, but then there’s like a just like a code review step as like a GitHub PR where someone can review and either like approve on GitHub and get it merged or like submit like change requests of like what needs changes in this um in this in this change in documentation and and the change log. Then the change writer would

[11:59] act on this again to update the draft until it’s finally released. And now both of these kinds of like either like approvals or uh requests for changes can get feed into like the AI obserability and eval to to serve as a basis for auto improvement of that change writer agent. So what we’ve now done is um just use a coding agent pointed at the like length use agent skills but generally I mean this would also work with other systems but yeah length is like well positioned for this to to ask like okay what has

[12:30] happened in this application how can we improve it I’ll I’ll pause a couple times because otherwise it it’ll go it’ll go by very fast. So what we for example here identified that the writer uh so the chain lock rider is factually uh like very correct in how it makes changes to documentation but clarity is low. the edit ratio of us humans making ch like submitting change requests is still high and that we leak internal jargon to our customers because maybe our code has like internal comments that

[13:01] we leave there for ourselves for the future but uh like our customers don’t think about our application as like I don’t know like an ingestion pipeline or as like I don’t know some kind of like batched evil Q like they don’t know this is like an implementation detail we should talk about it as like an user domain language and that’s like uh something we have identified here we’re Now the agent suggests changes to the data sets and evaluators to test for leaking jargon and um also like increasing clarity in customer domain

[13:32] language basically. So um agent now closes this gap suggest changes to the data sets and evaluators and now um has an idea of how to change the agent implementation to basically fix this problem because in the end it’s kind of like just like a a problem of how we provide context how we like provide the skill that then educates this um content writer and now we can back test it basically on the updated data set to see whether the new implementation would do better than the old implementation and

[14:02] I’ll stop here again where we have basically the baseline. So um basically we reproduce the issue of userf facing language. So let’s talk about features in a way of how users would talk about it. So we reproduce this kind of problem with the v1 baseline. This basically existing implementation of the agent and agent came up with a new implementation where we see the v2 candidate. We are still doing on format compliance and accuracy in the same way as we did before but we improved on like userf facing language. So we see a positive delta which sounds like a good change

[14:34] now. Um so uh agent reasons about it as this. I mean this is a bit I mean internal application it’s a bit yolo. So we are like okay we are good of of just merging this and then acting again on the next change because this agent never publishes anything to actual production. It just raises PS on a repo. So it’s okay if it kind of like auto improves and then we just provide feedback again to whatever the next increment is. So um here we use our like prompt management logic so that the agent can just basically feature release this new um

[15:05] implementation and uh now it just summarizes basically um how how we acted on this. So high level um this is what we have seen like most of our best users do already uh when they when they build agents like collect production signals uh track them alongside like detailed execution traces and then run agents like on a loop uh usually like a crown job like every day every week whenever you have like a batch of basically interesting user data again to then act on it. Um either it’s just user feedback

[15:35] how how it’s happens in this case or internal labeling from like a production system but it could also be you ask people to annotate data like in app for example in langu we also allow like for annotations to feed into that uh into that queue and yeah that’s very high level what we’ve seen happy to give you like a more deep dive um demo at our at our booth or after this talk but just wanted to to wrap it up very concisely with how we see this this space evolves and um I think what’s what’s interesting here is it drives the need for like a very scalable data system because you’ll want to have agents really loop on this

[16:06] data and like produce lots of queries. This we see how langu was historically very right intensive to like um ingest evils and traces. Now it’s way more read intensive because agents can like like chew through so much more data. interesting number one and two you want to really like own the data layer because like now the traces of like for example a year ago are interesting context and you don’t want to want them to be locked up in like like a more commercial system or something where uh you need to sample data or retain them for a long short time period but we want to like retain them for a long time

[16:36] period and not sample them and yeah this really drives the need for like a scalable cheap solution and we’ve worked with many customers on this so happy to talk one about uh oneonone about this if you’re interested thank you so much for your