O loop é o produto — Roland Gavrilescu, Introspection

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: The Loop Is the Product — Roland Gavrilescu, Introspection · Canal: AI Engineer · 18:21 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Avaliação e benchmarks de IA

Resumo

Roland Gavrilescu apresenta três ideias para criar produtos de IA com agentes: o loop é o produto, a destilação do sistema é o modo de aprimorá-lo e o valor do trabalho por watt é a métrica a otimizar. Ele propõe reunir julgamentos, evals, ferramentas e ajustes em agent recipes versionadas e portáteis, que codificam o que os criadores consideram um bom resultado. O processo usa traces para identificar padrões, calibrar judges e evals e testar mudanças primeiro offline e depois em produção. A meta é permitir que agentes reproduzam esse julgamento e melhorem continuamente, mantendo a viabilidade econômica.

Pontos-chave

• O loop — a sequência de ações, observações e verificações — deve ser tratado como parte central do produto.
• A qualidade dos sinais e dos verificadores influencia o sucesso e a confiabilidade de cada loop.
• Cada loop pode gerar artefatos que alimentam uma segunda rodada de melhoria contínua.
• Agent recipes devem reunir e versionar evals, ajustes, ferramentas, perfis e julgamentos humanos.
• Falhas recorrentes podem virar judges e evals; comportamentos repetidos podem ser codificados em skills e prompts.
• O papel das pessoas é calibrar o julgamento e os critérios, enquanto agentes podem ajudar a implementar evals e mudanças.
• As mudanças devem ser verificadas offline e validadas em produção com usuários, inclusive por meio de testes A/B.
• O valor do trabalho por watt combina a utilidade entregue com a viabilidade econômica de produzi-la.

Capítulos

Início	Capítulo	Resumo
00:12	O loop é o produto	Roland introduz a ideia de construir loops de agentes como produtos e usa um exemplo de negociação de preço de carro.
03:19	Da execução à melhoria contínua	A qualidade dos sinais e dos verificadores determina os resultados, e os artefatos de um loop podem alimentar o próximo.
06:59	Agent recipes para codificar o julgamento	A proposta é reunir em receitas portáteis e versionadas os critérios, evals, ferramentas e ajustes que definem um sistema.
09:33	Valor do trabalho por watt	A apresentação propõe medir o valor entregue e garantir que sua produção seja economicamente viável.
12:10	Exemplo prático: agente de recrutamento	O exemplo percorre a identificação de padrões, a calibração de evals, a criação de mudanças candidatas e sua validação com usuários.
16:48	Síntese e próximos passos	Roland resume as três ideias centrais e convida empresas de software vertical e laboratórios de agentes a conversar sobre implantação.

Citações

O loop é o produto. — 01:14

Uma agent recipe permite criar sistemas de IA de ponta reproduzíveis. — 05:26

O valor do trabalho por watt é a métrica a otimizar. — 09:03

Você não precisa que as pessoas construam as evals; precisa que calibrem as evals. — 14:45

Conceitos e entidades

• Roland Gavrilescu (pessoa): Apresenta uma abordagem para criar e aprimorar produtos de IA com agentes.
• Introspection (empresa): Empresa que, na apresentação, desenvolve uma abordagem para gerar agent recipes.
• agent recipe (conceito): Conjunto versionado e portátil de elementos para reproduzir e aprimorar um sistema de IA com agentes.
• OODA loop (conceito): Ciclo de observação, orientação, decisão e ação usado na apresentação para explicar loops em ambientes dinâmicos.
• valued work per watt (conceito): Métrica proposta para relacionar o valor do trabalho produzido ao custo de recursos necessário.
• evals (conceito): Avaliações usadas para codificar critérios de qualidade e verificar o comportamento de agentes.
• Pi harness (ferramenta): Harness mencionado como base da abordagem de recipes apresentada.
• Harbor (ferramenta): Ferramenta mencionada como base para evals na abordagem da Introspection.
• OpenClaw (ferramenta): Projeto citado como exemplo inicial de um loop criado para negociar o preço de um carro.
• Cursor (empresa): Empresa citada ao descrever a progressão de produtos para evals e, depois, modelos.
• Cognition (empresa): Empresa citada junto com Cursor como exemplo dessa progressão.

Tradução completa (pt-BR)

00:12 Olá, pessoal. Como vocês estão? Estão prontos para mais alguns loops? Sim. Meu nome é Roland. Meu cofundador e eu estávamos naquele lugar mítico chamado XAI, trabalhando duro em infraestrutura para agents, e percebemos que havia algo novo que precisava ser feito de forma independente. Então saímos de lá há alguns meses para descobrir de verdade qual seria a próxima etapa para implementar essas tarefas de longa duração, sempre ativas e com horizontes longos

00:43 — e fico feliz em anunciar que temos algumas descobertas que gostaríamos de apresentar a vocês. Esta palestra é toda sobre como transformar essas ideias em produtos de maneiras que possam acompanhar o crescimento dos seus clientes. Vocês ouviram bastante sobre pesquisa automatizada. Acreditamos que há um plano para 2026 e além, sobre como pensar em pesquisa automatizada, e ele se resume a três ideias.

01:14 Vamos à primeira. O loop é o produto. Todos conhecemos isso. Começamos com a ideia de que tudo se resume a RL como o principal para os modelos e a como treiná-los para raciocinar cada vez melhor. Logo passamos aos harnesses e à ideia de que o modelo é uma commodity e que tudo gira em torno do harness. E agora estamos falando de loops e de como construir esses loops, sem mexer mais no código. Mas o que isso realmente significa e por que

01:45 todo mundo está dizendo isso? Vocês se lembram do clawbot? Esse era o nome original do que hoje é conhecido como open claw. Esse cara, AJ, construiu o primeiro loop em torno do cloudbot. O que ele fez foi encontrar uma maneira de conversar com concessionárias e usuários do Reddit para conseguir descontos maiores em um carro. Ele seguiu estes quatro passos. E é realmente o OpenClaw que fez isso: vá ao Reddit, encontre preços, encontre veículos em estoque, converse com as concessionárias, coloque uma concessionária contra a outra e tente descobrir como fazer com que ofereçam lances cada vez maiores umas contra as outras, tenha uma forma verificável de saber quando o preço está certo e, então, feche o negócio e compre o carro. E funcionou. Provavelmente foi quando todos os Mac minis estavam sendo vendidos a rodo, mas isso foi

02:15 o primeiro exemplo real de que o loop é o produto e de algo que provavelmente já deveria ser uma startup. Mas vimos como isso se tornou uma receita para todo mundo construir loops. Vamos dar um passo atrás. Por que estamos aqui? Acreditamos mesmo que os modelos foram treinados com esse loop em mente. E isso vem da ideia dos loops OODA. O termo foi cunhado na década de 1970 pela Força Aérea dos EUA e se refere à ideia de como esses caças a jato

02:46 reagem em ambientes de ritmo acelerado. Se pensarmos em modelos chamando ferramentas e recebendo observações, isso é algo para o qual fomos treinados como humanos, mas também como agents. Agora, o que acontece quando colocamos sinais fortes e trabalho verificável nas outras extremidades? Chegamos a esses trabalhadores ou agents do cloud code. E o que importa aqui é que a qualidade do sinal determina a

03:19 taxa de sucesso do loop, e a qualidade do verificador permite calibrar se esse sucesso está realmente correto ou não. Mas há outro loop aqui. O que acontece quando pegamos isso e o realimentamos no sinal? É disso que se trata dar voltas: como gerar esses artefatos ao final do primeiro loop para, então, executar um segundo loop com eles e ter uma maneira de melhorar continuamente. E

03:51 isso me leva ao segundo ponto. A destilação de sistemas é o caminho, e consiste realmente em entender o que deu certo e errado no primeiro loop e saber como processar isso no segundo. Então, como ajustamos esses sistemas de IA? Cada loop gera informações úteis sobre harnesses, perfis, evals, modelos, recursos, ferramentas e o ambiente. O que vocês realmente querem é

04:24 ter uma maneira de manter tudo isso portátil, versionar e evoluir com o tempo. Se pensarmos nas receitas de dados usadas em pesquisa, foi assim que RL começou a funcionar muito bem. Entendia-se as receitas e como alterá-las continuamente para combater alguns comportamentos que podem surgir, como alucinações e reward hacking, e então se chega a uma stack que é a receita final de dados. Não temos isso para harnesses. Não temos isso para sistemas de IA em

04:55 geral. Então pensamos que há espaço para algo assim: algo que contenha os evals, os ajustes, o julgamento humano e todas essas coisas que não são predeterminadas no início, mas são definidas à medida que aprendemos mais sobre como o agent atua no ambiente. Achamos que receitas podem ser aplicadas a isso e que devemos usar o mesmo nome. Então, uma receita de agent é algo que permite criar sistemas de IA de ponta reproduzíveis. É algo que

05:26 permite ter um modelo que continua melhorando com o tempo e não está vinculado a nenhuma plataforma ou provedor. É algo que você controla, que fica na sua empresa e é independente dos modelos e provedores que você usa. E os loops devem se concentrar nisso. Os loops devem ser a maneira de destilar esses sistemas em receitas. Padrões de falha devem se tornar judges e evals. Comportamentos repetidos devem se tornar skills e prompts. A frustração dos usuários, as extensões e as memórias devem ir para

05:59 o seu harness, e assim por diante. Todos conhecemos isso, mas não tínhamos a terminologia certa para pensar sobre isso e definir o que é. E achamos que receitas são uma forma de reunir tudo em um repo git e tratá-lo como a sua estratégia contínua para criar esses sistemas que se aprimoram sozinhos. Nós somos a Introspection, mas vocês podem pensar na Introspection como a maneira de gerar

06:29 essas receitas. São receitas para fazer introspecção no seu sistema. Queríamos construir algo portátil e independente de provedores. Então criamos nossa abordagem de receitas com base no harness pi e no harbor para evals. Incorporamos isso a repos git para que tudo pudesse ser versionado e os agents pudessem acompanhar continuamente como e por que isso muda. A ideia é que pertença a você, mas seja gerenciado pelos seus

06:59 agents. E é assim que os produtos realmente devem ser construídos daqui para a frente. É algo que trata o proprietário quase como a pessoa de maior discernimento e personalidade na sala. Mas os agents devem tentar se calibrar pelo gosto de quem os criou. Então, achamos que as receitas devem basicamente codificar o gosto dos criadores na maneira como esses agents são construídos. E, se eu quiser usar a receita de outra pessoa, também devo poder incorporar esse gosto.

07:30 Não se trata apenas do harness, nem apenas do modelo: trata-se de como você chegou a essa receita específica e por quê. E isso é, mais ou menos, o que está por trás de produtos e serviços reproduzíveis envolvendo agents. Temos uma versão inicial das receitas chamada pi. Recipes. É muito parecida com o que as skills eram em 2025, mas vai um passo além. E isso é tudo de que preciso para ter um agent de ponta: tudo sobre como

08:01 codifico o gosto em evals? Como executo evals? Como criamos loops para melhorar continuamente esses evals ao longo do tempo? Como processamos sinais e sabemos quais são os sinais certos a usar? Quais são as ferramentas certas para trabalhar com determinados modelos? Como ter diferentes perfis do harness para trabalhar com diferentes modelos? E tudo o que há entre essas coisas. Então, deem uma olhada no que estamos construindo aqui. Ainda está no começo, mas esperamos que seja útil o bastante para vocês começarem. E sentimos que isso

08:33 vai crescer e se tornar algo que realmente permita usar o gosto de diferentes criadores, quase como diferentes receitas para o seu agent. E, por fim, o último ponto é trabalho valioso por watt. E por que essa é a métrica que devemos realmente otimizar? Pensem em como a cursor e a cognition passaram de construir o melhor produto a construir os melhores evals para o produto e, por fim,

09:03 vai crescer e se tornar algo que realmente permite usar o gosto de diferentes criadores, quase como receitas para o seu agent. E, por fim, o último ponto é o trabalho valorizado por watt. E por que essa é a métrica que devemos realmente otimizar? Pense em como Cursor e Cognition passaram de construir o melhor produto para construir os melhores evals para o produto e, por fim,

09:33 construir os melhores modelos com base nos dois artefatos anteriores. Achamos que essa é a receita para tudo daqui para frente. A programação foi o primeiro domínio em que isso deu certo. Tudo além do suporte ao cliente e da pesquisa jurídica — tudo — vai depender dessa ideia. Quanto valor estou obtendo por watt? Como medir o valor é o primeiro passo; como saber se estou obtendo um bom negócio por esse valor é o segundo. E talvez isso

10:04 deixe as coisas um pouco mais claras. Todos começamos com um harness básico e um conjunto básico de evals, e fomos em direção à fronteira. E só se chega lá executando esses sistemas em produção. Não há como saber onde fica a fronteira antes de começar. Mas a última etapa, que exige bastante pesquisa, é: certo, depois que chegamos à fronteira, como tornamos isso economicamente viável? Ou seja, como não gastamos mais

10:37 do que precisamos para gerar esse valor? Achamos que agora temos os componentes necessários para tornar isso acessível e bastante eficiente. Você já viu todas essas APIs de fine-tuning e toda a infraestrutura que foi abstraída para que você faça esse processo. O que ainda falta é o conhecimento prático, e esperamos poder impulsionar esse conhecimento: saber como codificar o gosto em evals e como validá-lo em experimentos. E vocês

11:09 já ouviram bastante sobre evals em experimentos, mas talvez não tenham pensado de verdade no que eles são. Não são apenas testes; são, na verdade, o gosto do criador que os agents devem conseguir reproduzir e em torno do qual devem conseguir se aprimorar. E ninguém pensou em como tornar isso suficientemente portátil. Como faço para que o meu gosto, como artista ou desenvolvedor de software, seja algo que qualquer pessoa possa baixar para o cérebro e se tornar uma réplica idêntica de mim? E isso

11:39 é mais ou menos o que o RL busca fazer agora: como transformar esses criadores de gosto em ambientes e evals em torno deles para, então, transferi-los para os pesos. Mas há mais do que isso. Você pode pensar no worker como o loop interno, que gera todos esses artefatos. Mas o gosto está em como você analisa os artefatos e sabe o que mudar. E é isso que gera candidatos para o que você deve mudar e como deve se adaptar

12:10 com base nisso. E os experimentos são o meio pelo qual você se autoc alibra: certo, meu gosto realmente foi validado em produção pelos usuários. Assim, garantimos que não só o criador fique satisfeito com os evals offline, mas também os usuários finais, e que eles concordem com o que consideramos bom. Vamos ver um exemplo prático de como isso funciona. Vamos partir de um agent básico, que poderia ser um agent de recrutamento de talentos. E

12:41 esse é um caso bem clássico: cada pessoa faz recrutamento de um jeito diferente, e a questão não é tanto o que é um bom recrutamento, mas quem está liderando o recrutamento e considera que ele é bom. Neste caso, começamos com algo bem simples: um conjunto de ferramentas — busca na web, LinkedIn, vários subagents que foram pré-popularizados por harnesses como Codex e Claude Code — e uma instrução do sistema que descreve

13:11 o seu recrutador. O primeiro passo é realmente entender os sinais. Você pode pensar nos padrões como uma forma de analisar os rastros, extrair comportamentos em comum ou frustrações recorrentes dos usuários e transformá-los em grupos. Digamos que o agent esteja entrando em contato com muitos funcionários de grandes empresas de tecnologia. Como recrutador, você não quer isso. Quer encontrar talentos escondidos. Não quer tentar contratar John Carmack. Mas um agent

13:44 pensaria: “Ah, John Carmack é ótimo. Por que eu não entraria em contato com ele?” Esse é um comportamento que você nunca pensaria em codificar, mas descobre que o agent tende a agir assim. Os padrões permitem descobrir esses sinais e indicam o que você deve fazer em seguida. Os juízes de calibração e os evals são como costumávamos pensar em codificar esses comportamentos em algo que pudesse aplicar o mesmo

14:15 julgamento a diferentes rastros e execuções. Digamos que criemos um agent que analisa uma trajetória e identifica exatamente esse padrão. “Ei, esse agent entrou em contato com funcionários do Google em vez de tentar encontrar talentos escondidos no GitHub?” A parte de calibração e a geração de evals não são tão difíceis. Agents deveriam conseguir fazer isso. Você só precisa de um humano no loop para dizer: “Ei, esta é a abordagem que estamos adotando. Você concorda com esse julgamento? Você realmente concorda que deveríamos procurar mais talentos escondidos, em vez de entrar em contato com funcionários de grandes empresas de tecnologia?” E é só isso. Você não precisa que o humano crie os evals. Precisa que ele calibre os evals. E os agents é que devem pegar o gosto do criador e transformá-lo em código. Depois disso, é bem fácil criar candidatos a receitas. E esses devem ser os diffs que você realmente

14:45 quer avaliar. Você pode ter um conjunto de evals offline bem bom em torno disso, mas o teste acontece quando você vai para produção. Então, os usuários finais concordam com o seu gosto de não entrar em contato com funcionários de grandes empresas de tecnologia? É isso que você quer: criar um produto que realmente destaque o seu gosto e, depois, garantir que seus usuários apreciem e valorizem esse gosto. Os testes A/B têm sido

15:15 uma forma de garantir que seja esse o caso. Por exemplo, com um cenário de bandit de múltiplos braços, você conseguiria fazer isso muito bem. Depois de validar que tenho bom gosto e que meus usuários também acreditam que tenho bom gosto, é aí que você promove a mudança e passa para a próxima versão da receita do agent. O segredo é continuar fazendo isso repetidamente, sabendo como codificar continuamente o seu gosto — aquilo que você considera bom — em um agent que

15:46 consiga reproduzir o mesmo serviço ou produto para outras pessoas, e que elas também concordem que você tem bom gosto e executa bem. E esse é mais ou menos o segredo para criar bons loops: alguém consegue iterar no meu sistema de uma forma… Um bom exemplo é Miranda, do produto Delor: o que Miranda faria em determinadas situações? Você quer codificar esse modo de pensar em agents que consigam fazer as mesmas coisas em um nível mais alto.

16:16 Então, os principais aprendizados são estes. O loop é o produto. Você tenta se automatizar como juiz de nível mais alto e quer garantir que seus agents de segundo loop consigam aplicar o mesmo julgamento aos agents que você está tentando levar para produção. O segundo ponto é que a destilação de sistemas é o modo de operação. Como você injeta continuamente esse gosto nesses workers, e como eles se verificam continuamente e trabalham juntos, é o principal em que você deve se concentrar. E quanto mais rápido você

16:48 fizer isso, mais rápido construirá uma abordagem defensável para se tornar uma empresa de IA vertical. Por fim, o trabalho valioso por watt é como você deve medir se está progredindo ou não. Primeiro, garanta que o trabalho que você gera tenha valor. Segundo, garanta que a economia faça sentido e que a diferença de preço seja basicamente aquilo que levaria as pessoas a sair do Claude Code e ir para

17:20 faça isso. Quanto mais rápido você construir uma abordagem defensável para se tornar uma empresa de IA vertical, melhor. E, por fim, o trabalho valorizado por watt é como você deve medir se está fazendo progresso ou não. Primeiro, certifique-se de que o trabalho que você está gerando é valioso. Segundo, certifique-se de que a economia faz sentido e que a diferença de preço é basicamente o que faria as pessoas deixarem o Claude Code para

17:50 algo que você fornece. Temos pensado bastante nessas ideias e estamos desenvolvendo alguns produtos muito interessantes sobre como implementar isso em produção. Adoraríamos ouvir você. Também gostaríamos de entender melhor como certas empresas verticais de SaaS estão buscando levar isso para produção, ou como os laboratórios de agents têm pensado nessa ideia de criar laboratórios de pesquisa automática em torno dos próprios produtos. Entre em contato. Vamos estar por aqui para conversar mais sobre isso. Estamos

18:21 por aqui para conversar mais sobre isso. Muito obrigado.

Transcrição original

[00:12] Hello everyone. How’s everyone doing? Are you guys ready for some more loops? Yeah. My name is Roland. My co-founder and I were in this mythical place called XAI working hard on agent infra and we realized there’s something new that has to be done in a standalone way. So we left a few months ago to really figure out okay what’s the next stage of how we should deploy these always on longunning

[00:43] horizon tasks. Um and I’m happy to announce we have a few findings that we would like to present you. Um, and this talk it’s all about um, how you should productize these ideas in ways that can scale with your customers. Um, you’ve heard a lot about auto research. Um, we think there’s a blueprint for 2026 and beyond on how you should think about auto research and it really comes down to three ideas.

[01:14] Let’s go through the first one. The loop is the product. We’re all familiar with this. We’ve started with everything goes down to RL chief for models and how you should train the model to become better and better reasoning. We then quickly moved to harnesses and how the model is a commodity and it’s all about the harness. And now we’re talking about loops and how you should build these loops uh and not touch code anymore. But what does it really mean and why is

[01:45] everyone saying that? Do you guys remember clawbot? That was the original um original name of what is now now now known as open claw. And this guy AJ built the first loop around cloudbot. What he did was to find a way to talk to dealers and talk to Reddit users to get bigger discounts on a car. He followed these four steps. Um and is really open

[02:15] call the one that did it. Go on Reddit, find prices, find inventory, talk to the dealers, put dealers head-to-head, and try to figure out how to make them outbid each other, have a verifiable way to know when the price is right, and then lock in, get the car, and it worked. Um, probably this was when all the Mac minis were uh selling off the shelves, but this was

[02:46] the first real example of loop is the product and something that probably should be a startup at this point. Um, but we’ve seen how this became a recipe for everyone to build loops. But let’s take a step back. Why are we here? Um, we really think models have been trained with this loop in mind. And it comes from this idea of udala loops. It’s a terminology coined back in 1970s by the US air force and is the idea of these um

[03:19] jet fighters how to react in fast-paced environments. If you think of models calling tools and taking observations, it’s it’s what we’ve been trained on uh as humans but also as as agents. Now, now what happens when you put strong signals and verifiable work uh at the other ends? You get to these workers or cloud code agents. Um and and what matters here is the quality of the signal determines the

[03:51] uh success rate of the loop and the uh quality of the verifi verifier um um is able to calibrate if that success is actually correct or not. But there’s another loop here. Um what happens when you take that and feed it back into the signal? And this is what looping around is all about is how do you generate these artifacts at the end of the first loop to then run a second loop on and have a way to continuously improve. And

[04:24] this goes to my second point. System dillation is the mode and is really the ability to understand what went well and wrong in the first loop and know how to process that in the second one. So how do we tune these AI systems? Each loop generates useful information around harnesses, profiles, evals, models, resources, tools, and the environment. What you really want is

[04:55] to have a way to keep this portable, to have a way to version this and to evolve it over time. If you think about data recipes in research, this is how RL started to work really well. you understood the recipes and how to continuously change the recipe to combat some of the behaviors that may happen around hallucinations around reward hacking and then you get to a stack which is your final data recipe. We don’t have that for harnesses. We don’t have that for like AI systems in the

[05:26] general term. So we thought there’s space for something like that. something that contains the evils and contains the tweaks and the human judgment and all these things that are not predetermined at the beginning but they’re defined as you learn more about your agent acting in in in the environment. We think recipes can be applied to this and we should use the same name. So an agent recipe is really something that enables you to create reproducible frontier AI systems. It’s something that

[05:59] allows you to have a mode that keeps getting better over time, which is not tied to any platform or any provider. It’s something that you control lives in your company and is agnostic to the models and providers you use. And loops should focus on this. Loops should be the way you distill these systems into recipes. Failure patterns should become judges and evals. Repeated behavior should become skills and prompts. user frustration, extensions and memories to

[06:29] your harness and so on. You we’re all familiar with this, but we didn’t have the the the right like terminology of how we should think about it and how we should define it. And we think recipes is a way to put everything together into a git repo and treat it as your ongoing um strategy for for uh building these self-improving systems. So we are introspection but you can think of introspection as the way you generate

[06:59] these recipes. So they’re recipes for introspecting on your on your system. We wanted to build something that is portable and provider agnostic. So we built our um approach to recipes on the pi harness and on harbor for evals. We baked it into uh git repos so uh everything could be versioned and agents could have a way to continuously track how this change and why and is meant to be owned by you but managed by your

[07:30] agents. And this is how products should really be built going forward. It’s something that treats the owner as the um almost like the the the higher taste um personality in the room. But agents should try to calibrate themselves to to the taste of the of the maker. So we think recipes should be basically encoding the taste of the makers into how you build these agents. And if I want to use someone else’s recipe, I should be able to also bring that taste.

[08:01] It’s not just the harness, it’s not just the model, is how did you arrive at this particular recipe and why? And that’s kind of like what uh what is behind uh reproducible um uh products and services around agents. Um we have an early release of recipes is called pi. Recipes. It’s very similar to what skills uh used to be in 2025 but is going a step forward. And this is what do I need to have a frontier agent is everything about how

[08:33] do I codify paste into evals? How do I run evals? How do we have the loops to continuously improve those evals over time? How do we process signals and know what are the right signals to to use? Um what are the right tools to work with certain models? How do I have different profiles of the harness to work with different models? Um and everything in between. So have a look at what we’ve been building here. It’s still early uh but hopefully it’s useful enough for you guys to to get going. And we feel this

[09:03] is going to grow into something that um really allows you to to use uh different um almost like different the to to be able to use the taste of of different makers as recipes for your agent. And finally, the last point is valued work per watt. And why is this the score to really optimize for? Think of how um cursor and cognition went from building the best product to then building the best evals for the product and finally

[09:33] building the best models based on the previous two artifacts. We think this is like the recipe for everything going forward. Um code was the first domain where this um was successful. Um everything beyond customer support, legal research um everything is going to come down to this idea. How much value am I getting per watt? Um, how do I measure the value is the first step and how do I know I’m getting a good deal on that value is the second. And maybe this

[10:04] makes it a bit more clear. We’ve all started from a base harness and a base set of evals and we went to go to the frontier. Um, and you only go through that by running these systems in prod. There’s no way you you know what frontier is before you uh you start. Um but the the the last step here which is what is requiring a lot of research um is okay once you’ve reached frontier how do we make this um uh economically viable which is how do we not spend more

[10:37] than than uh we need for generating this amount of value um and we think we have the building blocks now to make this accessible and pretty efficient in the sense of you’ve seen all these fine-tuning APIs all the infrastructure that has been abstracted away for you to do do this process is just the knowhow that uh is not there yet and this is what we we we hope we can like push for the knowhow for knowing how to codify taste into evals and how to validate that in experiments um and you you’ve

[11:09] you’ve heard a lot about evals in experiments before but you didn’t really think of them of like what are they is it’s not just tests is is really what is the taste of the creator that agents should be able to reproduce and self-improve around. And no one has thought of how do I make this as portable enough? How how do I make my taste as an artist or as a software developer um something that anyone can download in their brain and be able to be a onetoone replica to me? And this is

[11:39] kind of like what RL is is is about now is how do we uh turn these um taste makers into uh environments and evals around them so then we can move them into the weights. But um there’s more than that. Um you can think of the worker as the inner loop and it generates all these artifacts. But how you look at the artifacts and know what to change is the taste. Uh and this is what creates candidates of what you should change and how you should adapt

[12:10] based on that. And experiments is what how you self-calibrate that okay my taste is actually validated in production with users and we make sure that not only the maker is happy through the um offline evals but the end users are happy as well and they agree with what we consider good. Let’s go through a practical example of how this works. Let’s take a baseline um agent which could be a talent sourcing agent. Um and

[12:41] this is a very classical case of everyone is doing recruiting differently and is very much about not what is good recruiting but who is leading that recruiting that considers recruiting as good. So in this case we’re starting with something pretty simple. um a a bunch of tools, web search, LinkedIn, uh a bunch of sub aents that have been pre-popularized by harnesses like codeex and cloud code and uh system instruction which is about

[13:11] your recruiter. First step is really understand the signals. So you can think of patterns as being a way to look at the traces, extract some common um behaviors or common user frustrations and turn them into like a cluster. So let’s say this idea of uh the agent is going uh and reaching out to a lot of big tech employees. As a recruiter, you don’t really want that. You want to find hidden gems. You don’t want to try to hire John Carmarmac. But an agent would

[13:44] think that’s, oh, John Carmarmac is great. why would I not reach out to him? Um, so so this is a behavior that you you’d never think of codifying, but you discover the agent tends to do that. Um, patterns is how you discover these signals and inform you what you should do next. um calibration judges and evals is how we used to think about how do we codify these these behaviors into um something that can try to uh apply the same

[14:15] judgment across traces and across uh execution. So let’s say we we build an agent that looks at a trajectory and um identifies exactly that pattern. Hey, did did this agent reach out to Google employees instead of trying to uh find hidden gems on GitHub? Um, and the calibration bit and the eval generation bit is not that hard. It it it should be doable by agents to build. You just need a human in the loop to say, hey, um, this is the approach we’re taking. Do

[14:45] you agree with this judgment? Do you really agree that we should look more towards hidden gems rather than reach out to um um big tech employees? And that’s about it. You don’t need the human to actually build the evals. You need them to calibrate the evals. And agents should be the ones that really take the the the taste of the maker and and put them in into code. Once you have this, it’s pretty easy to create recipe candidates. And this should be the the diffs that you really

[15:15] want to taste. Um, and you can have a pretty good offline evil set around this, but the the the test here is when you go to prod. So, do the end user agree with your taste of not hitting up um big tech uh employees, right? And this is kind of like what you want is you build a product that really emphasizes your taste and then you you make sure that your users appreciate and value that taste. and AB tests have been

[15:46] a way to to to make sure that that’s the case. Um so with a multi-arm banded um scenario for example you you’d be able to do that pretty well. So once you validate okay I have great taste and my users believe uh I have great taste as well that’s when you promote and that’s kind of when you go to to the next version of an agent recipe. The secret is you keep doing this over and over again and you know how to continuously codify your taste and your um what what what good is to you into an agent that

[16:16] can reproduce the same service or product uh for other people and they also agree you have great taste and you have great execution. And this is really kind of like the the secret of building good loops is okay can can someone iterate on my um system in a way as uh you know um a good example here is like Miranda from the Delor product right what would Miranda do uh in certain cases and you kind of want to codify that that thinking into like agents that can do the same stuff at a higher level.

[16:48] So the takeaways are this. Um the loop is the product. You try to automate yourself as the u as a um higher level judge and you want to make sure your second loop agents are able to apply the same judgment to to the agents you’re trying to to to push to prod. Second bit system dissolation is the mode. So, how do you continuously inject that taste into these uh workers and they how how they continuously self-verify and work together is uh the biggest thing that you should focus on and the faster you

[17:20] do it uh the the the faster you you build a defensible um approach to to becoming a vertical AI company. And finally, valued work per watt is how you should measure um am I making progress or not. So first make sure that uh the the the work you’re generating is valuable. Second make sure that the economics makes sense and the um the the difference in price is is basically what um people would would switch away from cloud code to to

[17:50] something you provide. We’ve been thinking a lot about these ideas and we’re building some very interesting products around how to deploy this in production. We’d love to hear from you. would love to get um to to understand more about how how certain um vertical SAS companies are are looking to go to prod with um or how agent labs have been thinking about this idea of um um creating these like auto research uh labs around their their own products. um get in touch. Uh we’re

[18:21] gonna be around the block for for chatting more about this. And thank you very much.