Três perguntas que todo engenheiro de agentes deve saber responder

Autoria: LangChain · 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: Three Questions Every Agent Engineer Should Be Able To Answer · Canal: LangChain · 14:00 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos de IA

Resumo

O vídeo apresenta três perguntas essenciais para quem desenvolve agentes: como identificar falhas, como reproduzi-las de forma confiável e o que mudar para evitar que voltem a ocorrer. Para encontrar falhas em escala, o palestrante recomenda analisar traces de produção e usar avaliadores específicos para classificar comportamentos. Para reproduzir os problemas, propõe criar ambientes e tarefas que representem o mundo em que o agente opera, com atenção a desafios reais e à prevenção de reward hacking. Com esses testes, as equipes podem fazer melhorias no harness ou no modelo e acompanhar mudanças nos modelos e nos padrões de uso.

Pontos-chave

Analisar traces de produção ajuda a identificar comportamentos e mecanismos de falha dos agentes.
Avaliadores específicos podem extrair sinais úteis em escala, embora avaliadores baseados em LLM possam ter alto custo.
Avaliações robustas devem considerar o ambiente do agente, incluindo estado do banco de dados, permissões, schemas e ações anteriores.
Uma especificação do mundo descreve aspectos relativamente estáveis do ambiente; tarefas definem ações que o agente precisa executar nesse mundo.
As tarefas devem ser difíceis o bastante para representar desafios reais e evitar reward hacking.
Telemetria de uso real pode ser transformada em tarefas e ambientes de teste, embora isso exija organizar e deduplicar os dados.
As melhorias podem ser feitas no harness, por exemplo em prompts e schemas de ferramentas, ou na camada do modelo.
Ambientes e tarefas robustos ajudam a detectar regressões e a acompanhar como modelos e padrões de interação mudam.

Capítulos

Início	Capítulo	Resumo
00:03	Identificar falhas a partir dos traces	O palestrante apresenta as perguntas centrais sobre falhas de agentes e explica como traces e avaliadores podem revelar problemas em produção.
03:50	Reproduzir o ambiente e as tarefas	A seção propõe ir além de avaliações simples de entrada e saída, simulando o ambiente, as condições e as tarefas do agente.
08:41	Transformar dados de produção em testes	O palestrante explica como a telemetria de uso real pode ajudar a criar tarefas e ambientes próprios, que depois precisam ser organizados em um benchmark.
11:21	Melhorar e acompanhar o agente	Com tarefas de teste estabelecidas, as equipes podem alterar o harness ou o modelo e verificar regressões conforme os modelos e os padrões de uso evoluem.

Citações

Entre tudo isso, há muitos sinais valiosos que você pode usar para melhorar seu agente. — 01:40

Uma maneira que encontramos para fazer isso com sucesso é usar especificações para definir o mundo do agente e as tarefas dentro dele. — 05:30

Temos uma base sólida para melhorias adicionais e um benchmark para começar a fazer melhorias quantitativas no agente. — 10:50

Ser capaz de assumir o controle da própria inteligência é adaptar-se às mudanças nos modelos e nos padrões de interação dos usuários. — 13:29

Conceitos e entidades

LangChain (empresa): Empresa mencionada como responsável por desenvolver e aplicar métodos de avaliação de agentes.
production traces (conceito): Registros das trajetórias e ações de um agente durante o uso em produção, analisados para encontrar sinais de falha.
LLM as a judge (conceito): Uso de um LLM para avaliar saídas ou comportamentos, uma abordagem que pode ser cara em grande escala.
world spec (conceito): Especificação dos elementos do ambiente do agente, como permissões, regras de domínio, sistema de arquivos e dependências.
GTM agent (modelo): Agente interno da LangChain usado pela equipe go-to-market para tarefas como pesquisa de concorrentes e análise de oportunidades.
Gong (ferramenta): Sistema citado como uma das ferramentas com as quais o GTM agent interage.
Salesforce (ferramenta): Sistema citado como parte do ambiente integrado ao GTM agent.
Calendly (ferramenta): Sistema citado como parte do ambiente integrado ao GTM agent.
Google Calendar (ferramenta): Sistema de calendário citado entre as ferramentas acessadas pelo GTM agent.
reward hacking (conceito): Comportamento em que um agente explora uma forma fácil de obter recompensa sem cumprir adequadamente o objetivo pretendido.

Tradução completa (pt-BR)

00:03 Sejam todos muito bem-vindos. Estou realmente ansioso para falar sobre como e por que, e sobre a metodologia por trás do que sabemos na LangChain sobre assumir o controle da própria inteligência. Este é nosso novo escritório. Estou muito animado por ter todos aqui. Temos uma programação incrível. Vou abordar o que significa assumir o controle da própria inteligência do ponto de vista de quem põe a mão na massa. Para quem está criando com agents e provavelmente está passando por muitos dos processos que vou abordar quando se trata de

00:35 criar e melhorar seu agent. Acho que há três perguntas principais para as quais qualquer pessoa que esteja criando um agent precisa ter uma compreensão muito sólida. E, se conseguir respondê-las bem, poderá afirmar com segurança que assumiu o controle da própria inteligência. Então, isso começa por entender, ao criar agents, o que dá errado e onde seu agent falha. Obviamente, esta é uma pergunta bem simples, mas, na verdade, é preciso muito trabalho de engenharia para entender se um agent falhou. Também é preciso bastante conhecimento de engenharia para entender como podemos

01:07 fazê-lo falhar de novo. Isso é obviamente fundamental no processo de conseguir criar agents que melhorem e de assumir o controle de todas as partes do seu modelo, talvez dos pesos, de todo o seu harness e dos pesos, e também dos pesos. E, por fim, conseguir responder o que precisa acontecer para que ele pare de falhar no futuro. Acho que, para responder à primeira pergunta e entender de fato como e por que seu agent falhou, é preciso ter uma compreensão muito sólida do tracing e entender o comportamento do seu

01:40 agent. Muitas vezes, isso vem da análise dos traces de produção do seu agent. Ao criar um agent, esperamos que você faça o tracing dele. Você terá muitas trajetórias e entenderá os diferentes tipos de comportamento que seu agent apresenta. E, em meio a tudo isso, haverá muitos sinais valiosos que você poderá usar para avançar na melhoria do seu agent. Por exemplo, podem ser situações em que o agent chamou uma ferramenta com sucesso ou a chamou incorretamente, o que frustrou o usuário porque

02:12 não tinha o contexto adequado. Há vários tipos de sinais nos traces do seu agent, sobretudo nos traces de produção, que são muito importantes de capturar para assumir o controle da própria inteligência e entender se o seu agent falhou ou não. Obviamente, o problema de fazer isso em escala é que, se seu agent tiver milhares de execuções por dia, ou milhões de execuções por dia, será muito difícil entender em escala se ele está tendo o desempenho esperado. Usar avaliadores de ponta, LLM-as-judges e avaliadores online é obviamente muito

02:46 eficaz, mas também muito caro em escala. Então, como exemplo, uma das maneiras que usamos para abordar isso — e uma das formas de buscar entender e extrair sinais dos traces do seu agent — é criar avaliadores específicos para a avaliação, que extraem e analisam os sinais de produção do seu agent. Fizemos isso recentemente na LangChain. Trabalhamos com fine-tuning, rotulagem e a produção de um avaliador para classificar se um agent estava proporcionando uma experiência agradável aos usuários,

03:17 ou se havia algum erro percebido. Isso pode ser, por exemplo, um agent frustrando o usuário, ou uma sequência de chamadas de ferramentas que o agent faz e que acaba levando-o a executar a ação errada, quando o usuário queria que ele fizesse outra coisa. Portanto, conseguir ter algum tipo de monitoramento e entender o que seu agent está fazendo em escala é um passo muito importante para entender se ele falhou ou não. Também é uma forma muito importante de agrupar os comportamentos e os mecanismos de falha que começam a surgir à medida que você cria e começa a melhorar seu agent.

03:50 Este é apenas o primeiro passo da jornada, porque, depois que conhecemos e classificamos os comportamentos do agent, precisamos tomar várias medidas para reproduzir esses problemas e, então, de fato corrigi-los à medida que continuam a surgir. Isso me leva ao próximo ponto sobre o que realmente significa assumir o controle da própria inteligência. Uma parte muito importante disso é conseguir reproduzir de forma confiável as situações em que seu agent está falhando. Trabalhei com várias equipes de aplicações, várias

04:23 equipes diferentes que estão criando seus agents e, de fato, nos últimos seis ou sete meses, isso começou a mudar bastante. A maneira típica de fazer isso — ou melhor, a maneira superficial de analisar a questão — é simplesmente avaliar se as entradas, ou se as saídas do seu agent, diante de uma entrada simples, produzem o comportamento esperado. Isso é muito útil para capturar vários mecanismos de falha de agents, mas, muitas vezes, não abrange o quadro completo. Isso porque o comportamento de um agent pode ser influenciado por fatores externos do

04:56 ambiente em que ele está. Isso pode ser, por exemplo, o estado do banco de dados com o qual interage, as permissões a que tem acesso, os esquemas específicos com os quais está trabalhando, ou até mesmo as ações anteriores que executou e que o levaram a estar naquele estado no ambiente. Então, o que realmente precisamos é de uma forma de simular a estrutura mais ampla da aplicação em que seu agent opera em produção. Isso me leva à criação de avaliações mais robustas, com uma forma de

05:30 reproduzir o mundo ou o ambiente em que seu agent existe. É um processo iterativo, mas o que encontramos — uma forma de fazer isso com bastante sucesso na LangChain, e que continua sendo avaliada — é trabalhar com especificações para definir o mundo do agent, assim como as tarefas dentro dele. Com isso, quero dizer ter algum tipo de especificação geral do mundo, que define os elementos que não mudam nesse mundo do agent. Isso pode incluir coisas como as permissões, ou as

06:03 regras específicas do domínio a que um agent tem acesso, ou coisas como o estado do sistema de arquivos e as dependências com as quais ele interage. São elementos que não mudam conforme o agent executa ações nesse espaço de ações. Um exemplo disso é um agent interno muito usado na LangChain, chamado GTM agent. Nossa equipe de go-to-market o usa, por exemplo, para pesquisar concorrentes em negociações ou para entender

06:34 e especificar o pipeline de um determinado tipo de oportunidade. Nesse caso, o mundo seria composto por todos os sistemas com os quais o agent precisa interagir: Gong, Salesforce, Calendly e Google Calendar. Na prática, são os sistemas que ele acessa e com os quais interage enquanto nossos vendedores o usam. As tarefas dentro desse mundo representam ações ou tarefas específicas que o agent precisa executar. Elas vão testar e, esperamos, revelar diferentes

07:07 comportamentos emergentes e aspectos que você está tentando testar. Por exemplo, uma tarefa nesse mundo do agent de go-to-market seria pesquisar todas as transcrições no Gong de um cliente específico que queremos investigar ou com quem estamos trabalhando e me ajudar a redigir a próxima melhor mensagem de contato. Então, se eu estiver criando um… ou se estiver criando um ambiente ou lugar onde possa testar de forma confiável meu agent de go-to-market em produção, provavelmente vou querer algum conceito de

07:37 um mundo robusto que reproduza o ambiente em que esse agent opera em produção. Isso vai muito além de uma avaliação simples baseada em entrada e saída. Porém, uma coisa que percebemos ao criar esses mundos, desenvolver essas especificações e trabalhar lado a lado com um agent de programação para desenvolvê-los é que os próprios agents não são muito bons nisso — ou melhor, precisam de supervisão e orientação constantes durante esse processo. Portanto, algo obviamente muito importante em tudo isso é garantir que as tarefas definidas pelo seu agent sejam confiáveis tanto

08:09 difíceis e que realmente representem um desafio para que você possa melhorar continuamente seu agent. Além disso, não há métodos em que o agent tenha projetado tarefas fáceis de manipular por meio de reward hacking. Talvez você já tenha ouvido o termo reward hacking ou termos relacionados. Isso também é obviamente muito importante, porque garante que o mundo que estamos desenvolvendo e as tarefas que damos ao nosso agent sejam suficientemente difíceis para que, quando fizermos melhorias, elas sejam quantificáveis e realmente simulem o que o agent faria em produção.

08:41 Algo que considero realmente interessante e central para isso, e para esse mecanismo que temos agora, é saber que a maneira de realmente entender nossa própria inteligência e conseguir criar e desenvolver um agent que resolva problemas em um mundo que de fato simule o mundo em que ele — o tipo de ambiente em que ele opera — é poder transformar os dados que temos ao executar nosso agent em produção nesse tipo de tarefa, nesse tipo de mundo.

09:15 Então, não é surpresa que alguns dos melhores modelos que usamos hoje, produzidos por laboratórios de fronteira, sejam… não é surpresa que os laboratórios de fronteira produzam alguns desses modelos. Há obviamente muitos motivos, mas o capital que eles podem destinar à aquisição de dados para construir esses mundos e essas tarefas supera em muito o de uma empresa comum da camada de aplicativos. Um exemplo clássico disso, aliás, é o Google fazer uma oferta de US$ 10 milhões à Spirit Airlines, não para comprar a empresa, mas para comprar os memorandos internos do

09:45 Slack, os e-mails e a documentação, porque obviamente tudo isso será usado para desenvolver tarefas e conjuntos de dados de treinamento, permitindo criar modelos melhores. Mas essa é uma situação um tanto parecida com Davi e Golias, porque, ao contrário dos laboratórios de fronteira, os desenvolvedores e proprietários de aplicativos percebem os casos extremos nos modos como as pessoas usam seus agents. Por esse motivo, conseguem produzir dados a partir dessa telemetria ou entender como pessoas reais interagem com seus agents e os utilizam,

10:18 e, portanto, desenvolver tarefas e ambientes que um laboratório de fronteira jamais conseguiria. Assim, quando sabemos que, a partir dos rastros do nosso agent, de todos esses dados residuais, de toda essa base, podemos ajudar a projetar tarefas e mundos poderosos para melhorar nosso agent, fica óbvio que se trata de um problema de organização de dados, porque será preciso remover duplicatas e usar vários métodos diferentes para transformar esses rastros em tarefas confiáveis.

10:50 Mas, depois que fazemos isso, temos a base e os alicerces para muitas outras melhorias e desenvolvimentos do agent. Então, temos um benchmark sólido e um ponto de partida para realizar melhorias quantitativas no agent. Quando temos um mundo e um conjunto de tarefas dentro dele, o ideal é que cada tarefa tenha como alvo algum tipo de modo de falha que você tenha observado no seu agent, certo? Você projetaria tarefas em torno dos pontos em que observou seu tráfego de produção

11:21 ou seu agent em produção falhar. As mudanças acontecem em duas camadas. É aqui que assumir o controle da sua própria inteligência e dos mecanismos tanto do harness quanto dos modelos que alimentam seus agents começa realmente a gerar efeitos cumulativos, porque agora você tem total flexibilidade para fazer mudanças em todos esses níveis. Mudanças no nível do harness podem envolver alterações simples, como mudanças nos prompts ou no esquema das ferramentas, ou alterações na forma como o contexto é inserido, para que um agent, ao receber determinada tarefa, responda de determinada maneira.

11:54 E, quanto a fazer mudanças na camada do modelo, não vou me aprofundar muito, porque sei que Charlie vai abordar algumas das diferentes técnicas de pós-treinamento que podem ser usadas nesse nível. Mas, novamente, agora você tem a flexibilidade para escolher o algoritmo de pós-treinamento que preferir e fazer mudanças para corrigir o que quer que esteja tentando testar e, idealmente, mitigar. Depois disso, podemos executar novamente e confirmar que o ambiente e o agent executado nele conseguem passar nessas tarefas específicas

12:27 e começar a se comportar como esperamos. Por fim, depois que estabelecemos um ambiente ou mundo robusto e um conjunto de tarefas, é inevitável que, conforme os modelos se desenvolvam, partes do que testamos mudem e que sejam introduzidas regressões. Mas partes do que projetamos para corrigir deficiências específicas do nosso agent também serão incorporadas ao modelo. Acho que isso não surpreende ninguém, mas temos

12:58 visto constantemente partes do harness serem incorporadas à camada do modelo, seja a decomposição de tarefas longas, seja o roteamento dinâmico de ferramentas. E veremos isso mudar. Mas conseguiremos testar essas mudanças, porque agora temos uma forma robusta de simular como nosso agent se comporta em produção. Além disso, também mudarão os padrões de interação das pessoas que usam seu agent. E teremos uma forma sólida de testar, implementar e determinar se o agent continua funcionando bem diante

13:29 desses padrões de interação específicos, já que agora temos essa forma realmente robusta e poderosa de testá-lo. Assim, assumir o controle da própria inteligência se resume a conseguir se adaptar às mudanças, à medida que os modelos melhoram e os padrões de interação dos usuários mudam. E nós, como criadores, quando entendemos isso e implementamos os mecanismos para testar comportamentos diferentes em ambientes robustos e com tarefas variadas, conseguimos acompanhar esse mundo acelerado em que estamos avançando.

14:00 E obrigado por ouvir.

Transcrição original

[00:03] Welcome, everybody. Really looking forward to covering how and why and the methodology around what we know at LangChain to be about owning your own intelligence. It’s our new office. Really stoked to have everyone here. We’ve got an awesome lineup. I’m going to approach what it means to own your own intelligence from a practitioner’s angle. For someone who’s building with agents and for someone who is probably going through a lot of the processes that it takes that I’m about to cover when it comes to

[00:35] building and improving your agent. I think that there are three main questions that any person who’s building an agent needs to have a very solid grasp of. And if they can answer them well, then they can definitively say that they do own their own intelligence. So, that starts with when you’re building agents, understanding what goes wrong and understanding where your agent fails. This is obviously a very, you know, this is a simple question, but actually there’s a lot of engineering work that goes into understanding if an agent failed. There’s also a lot of engineering understanding that goes into understanding how we

[01:07] can make it fail again. This is obviously key on the process to being able to build agents that improve and to be able to own all parts of your model, and maybe the weights, and the all your harness and the weights, and then the weights as well. And then finally as well, being able to answer what needs to happen to make it stop failing in the future. I think to answer the first question and to understand really how and why your agent has failed requires a very strong grasp of tracing and understanding your

[01:40] agent’s behavior. And this often comes from mining your agent’s production traces. Building an agent, hopefully you’re tracing it, you’re going to have a lot of trajectories and understandings of all of the different kinds of behavior that your agent is taking. And amongst all of this, there’s going to be a lot of valuable signal that you can use to move on the path to improving your agent. That might be, for example, times where the agent either successfully called a tool or it incorrectly called a tool, it led to frustrating the user because it

[02:12] didn’t have the right context. There’s a variety of different signal within your agent traces, particularly your production traces, that is a very important element to capture when it comes to owning your own intelligence and understanding whether or not your agent failed. The issue with doing that at scale, obviously, is that if you have an agent that has thousands of runs a day, millions of runs a day, it’s going to be very hard to understand at scale whether or not your agent is performing as you expect it to. Using frontier judges, LLM-as-judges, online evaluators, obviously is very

[02:46] effective, but also very expensive at scale. And so, as an example, a way that we approach this, and just one of the ways that you can look towards understanding and extracting signal from your agent traces, is by making the evaluation-specific judges to go and extract and actually mine your agent for production signal. So, we did this at LangChain recently. We worked with fine-tuning, labeling, and producing a judge to go and actually classify whether or not an agent was giving users a delightful experience, whether

[03:17] or not there was any perceived error. So, that might be, for example, an agent frustrating user, or it might be a, you know, a string of tool calls that an agent makes that actually leads it to performing the wrong action when a user was looking for it to do something else. And so, being able to actually have some form of monitoring and understanding what your agent’s doing at scale is a very important step towards understanding whether or not it failed. And also a very important way to be able to cluster the behaviors and the failure mechanisms that begin to emerge as you build and as you start to improve your agent.

[03:50] This is only the first step in the journey, though, because once we know and once we have classified agent behaviors, we then need to go and take a variety of next steps to go and be able to reproduce and then actually remediate these issues as they continue to develop. So, that brings me to my next point about what it really means to be able to own your own intelligence. A very important part of that is being able to reliably reproduce where your agent is failing. And I’ve worked with a variety of different application teams, a variety

[04:23] of different teams building their agents, and really over the past six or seven months, this has begun to take a pretty drastic shift. The typical way of doing this, and actually, rather, the shallow way of looking at this, is just evaluating whether or not the inputs, or evaluating whether or not the outputs to your agent given some simple input produces the behavior that you’ll expect. This is very powerful for capturing a variety of different agent failure mechanisms, but often doesn’t encapsulate the full picture. The reason why is an agent’s behavior might be influenced by external factors of

[04:56] the environment that it’s in. And so, that might be, for example, the state of the database that it’s interacting with, the permissions that it has access to, the particular schemas that it’s working with, or even the past actions that it’s taken that has led to it being in the environment in the state that it has. And so, what we really need then is a way for us to be able to mock out the broader application machinery of your agent as it stands in production. And that brings me to building more robust evaluations by creating a way where we

[05:30] can mimic the world or the environment that your agent exists in. This is an iterative process, but really what we… a way that we found to do this quite successfully at LangChain, and again, this is something that’s constantly evaluating, is through the idea of working with specifications to define the agent’s world as well as the tasks within it. So, what I mean by that is having some kind of generic world spec which defines the things that don’t mutate across that agent’s world. And so, that might be things like the permissions, or that might be like the

[06:03] domain-specific rules that an agent has access to, or that might be things like the state of the file system and the dependencies that it interacts with. This is things that don’t change across the agent’s actions that it takes in this action space. So, an example of this is we have a very commonly used internal agent at LangChain. It’s called the GTM agent. And so, our go-to-market organization will use it, for example, to do things like do competitive research on competitors in deals, or go and understand

[06:34] and spec out the pipeline of a particular sort of opportunity. The world in that case would be all of the systems that the agent needs to interact with: Gong, Salesforce, Calendly, you know, Google Calendar. And effectively the systems that it touches and interacts with as this agent interacts and is engaged with by all of our sellers. Tasks within that world represent specific actions or tasks that the agent needs to take, which will go and actually test and hopefully surface different

[07:07] emergent behaviors and things you’re trying to test for. And so, a task within that go-to-market agent world, for example, would be go and research all of the Gong transcripts for a particular customer that we’re looking to investigate or are in the process of working with, and help me draft a next best reach-out. And so, if I’m somebody who’s building a… or if I’m somebody who’s building an environment or a place where I can reliably test my go-to-market agent in production, I’m probably going to want to have some concept of

[07:37] a robust world where it mimics the environment that that agent is operating within production. And that extends far beyond just a simple input and output based evaluation. One thing that we’ve noticed, though, when kind of going and creating these worlds and developing these specs and working with an agent, coding agent, side by side to actually go and develop these, is that agents themselves aren’t very good, or rather, need actual constant supervision and guidance when building these out. And so something that’s obviously very important in all of this is to make sure that the tasks that your agent is defining are both reliably

[08:09] hard and actually present a challenge for you to be able to continuously improve your agent with. And also there aren’t methods where the agent has designed tasks that are easy to reward hack. You might have heard of the term reward hacking or, you know, adjacent terms. This is obviously really important as well because it makes sure that the world that we’re developing and the tasks that we’re giving our agent are sufficiently hard so that when we make improvements they’re quantifiable and actually mimic really what the agent would be doing in production.

[08:41] Something that I think is kind of really interesting and core to this, and once we have this kind of like mechanism now of knowing that the way for us to really kind of get a handle on our own intelligence and be able to create and develop an agent that is solving problems in a world that actually mimics the world that it’s, that the kind of environment that it’s operating in, is that we have the ability to go and do this through turning that data that we have from running our agent in production into this kind of, these kinds of tasks, into these kinds of worlds.

[09:15] So it’s no surprise that some of the best models that we use today, produced by frontier labs, are… it’s no surprise that frontier labs are producing some of these models. And the reason why, obviously there are many reasons, but the capital that they can allocate towards acquiring data to build these worlds and to build these tasks far supersedes that of the average app-layer company. A classic example of this, by the way, is, you know, Google making a $10 million tender offer to Spirit Airlines not to buy the company, but to buy the internal

[09:45] Slack memos, the emails, the documentation, because obviously all of that’s going to be used to develop tasks and develop you know, training datasets to be able to actually go in and produce and make better models. But this is a bit of a David and Goliath situation because, unlike frontier labs, application developers and application owners see the spiky edges around the ways that people are using their agents. And for that reason, they’re able to produce data from that telemetry, or they’re able to understand how real people are actually interacting with and using their

[10:18] agent, and therefore develop tasks and develop environments that a frontier lab never could. And so, once we know that from the traces of our agent, from all of this exhaust, from all of this substrate, we can really help design powerful tasks and worlds to be able to go in and actually help improve our agent. Then obviously we know that it’s a data-wrangling problem, because there’s going to need to be deduplication, there’s going to need to be all sorts of different ways that we turn these traces into reliable tasks.

[10:50] But once we do, we have the substrate and we have the foundation for a lot of further agent improvement and development, and really then we have a strong benchmark and starting point for us to be able to go and actually make quantitative agent improvement. And so, once we have a world, once we have a set of tasks within that world, ideally a task targets some kind of failure mode that you’ve seen in your agent, right? You would design tasks around where you’ve observed your production

[11:21] traffic, or you’ve observed your production agent to be failing. Really then changes come at two layers. And this is really where owning your own intelligence and owning the mechanisms around both the harness and the models that are powering your agents really begins to compound, because now you can have full flexibility to make changes at all levels here. Changes at the harness level might involve simple changes like prompts or tool schema changes, or changing the way that context is injected so that an agent given a certain task can answer in a certain way.

[11:54] And then making changes at the model layer, I’ll kind of, I won’t dive into it too much because I know that Charlie here is going to cover some of the different post-training techniques that you can do at this level, but again, now you have the flexibility to be able to go in and choose your post-training algorithm of choice and make changes to help go and remediate whatever it is that you’re trying to test for and ideally mitigate. Once you’ve got that, then we can rerun and then we can establish that the environment and the agent running in that environment can pass those particular

[12:27] tasks and begin to behave as we expect it to. Finally, once we’ve established a robust environment or world and set of tasks, it’s inevitable that as models develop, parts of what we test for will change and, you know, regressions will be introduced, but also parts of what we designed for to solve for particular deficiencies in our agent will be absorbed as part of the model. And I think that this is kind of no surprise to anyone, but we’ve

[12:58] constantly seen parts of the harness, whether it’s, you know, long task decomposition or whether it’s dynamic tool routing, be absorbed into the model layer. And so, we’ll see that change. But we’ll be able to test for it because we now have a robust way to actually simulate how our agent is behaving in production. Also, what will be… also, as well, the interaction patterns of people using your agent will obviously change, and having a strong way to be able to go and test and actually roll out and determine whether or not your agent holds up under

[13:29] those particular interaction patterns will still be available given that we have this really robust and powerful way to now test it. And so really being able to own your own intelligence comes down to being able to adapt to changes as models improve, as user interaction patterns change. And as builders, once we are aware of, and when once we have put the mechanisms in place to be able to go and test different behaviors through robust environments and through different tasks, we really then can stay on top of this fast world that we’re moving in.

[14:00] And so, thank you for listening.