Como as fábricas de software se aprimoram — Suraj Gupta, Warp

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: How Software Factories Improve Themselves — Suraj Gupta, Warp · Canal: AI Engineer · 12:25 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Inferência e otimização de modelos

Resumo

Suraj Gupta, da Warp, explica como fábricas de software podem se aprimorar enquanto automatizam tarefas do triage à produção. Ele apresenta três mecanismos: skills atualizadas por um agente externo que observa execuções e feedback; memória persistente para reaproveitar aprendizados; e roteamento de modelos para escolher opções mais eficientes conforme a tarefa. O processo pode manter supervisão humana por meio de revisões de pull requests e de memórias rastreáveis e editáveis. A palestra também descreve o uso de evals específicos dos workflows para comparar modelos.

Pontos-chave

Fábricas de software podem aprimorar seus próprios processos, além de automatizar tarefas de desenvolvimento.
Um agente externo pode observar execuções de um agente interno e atualizar suas skills com base em erros e feedback humano.
Registrar as mudanças em um pull request permite acompanhar a evolução das skills e revisar as atualizações antes de aplicá-las.
A memória persistente armazena fatos e aprendizados para que agentes reutilizem contexto em execuções futuras.
Memórias podem ser rastreadas até suas fontes, revisadas, versionadas, editadas ou excluídas por pessoas.
O roteamento de modelos ajuda a evitar o custo de usar modelos mais caros em tarefas simples.
Regras de roteamento podem associar classes de tarefas a modelos específicos.
Evals personalizados podem comparar modelos em tarefas relevantes para os workflows de cada cliente.

Capítulos

Início	Capítulo	Resumo
00:12	Fábricas de software que se aprimoram	Suraj Gupta apresenta a Warp e explica por que fábricas de software também precisam melhorar com o tempo.
01:45	Aprimoramento de skills	Um agente externo observa o agente de triage, incorpora feedback e propõe atualizações de skill para revisão humana.
05:26	Memória persistente	Agentes armazenam aprendizados sobre problemas anteriores e podem reutilizá-los em execuções futuras.
08:39	Roteamento de modelos e evals	A palestra aborda regras de roteamento, custo dos modelos e evals personalizados para comparar opções em diferentes tarefas.
11:16	Avaliação de modelos na Warp	Um eval sidecar compara modelos em execuções paralelas para identificar opções eficientes para cada tipo de tarefa.

Citações

Menos se falou sobre como as próprias fábricas de software podem se aprimorar com o tempo. — 01:14

Todas as melhorias da skill do agente interno são rastreadas pelo Git. — 04:53

Você pode pensar nisso como um repositório de fatos associado a um agente. — 06:00

Isso é mais uma arte do que uma ciência. — 10:46

Tarefas de interface são muito bem executadas com GLM; não precisamos rodá-las com Opus. — 11:51

Conceitos e entidades

Suraj Gupta (pessoa): Palestrante que lidera o desenvolvimento de harness na Warp.
Warp (empresa): Empresa que desenvolve um ambiente de desenvolvimento agentic e uma plataforma de agentes na nuvem.
Oz (ferramenta): Plataforma de agentes na nuvem da Warp, onde é possível executar agentes e associar lojas de memória.
software factory (conceito): Automação de processos de desenvolvimento que pode abranger tarefas desde o triage até a produção.
persistent memory (conceito): Armazenamento de fatos e aprendizados que agentes podem consultar em execuções futuras.
model routing (conceito): Seleção de modelos para diferentes tarefas com base em regras ou avaliações.
Sentry (ferramenta): Agente mencionado como exemplo de análise de causa raiz e triage de problemas.
GLM (modelo): Modelo citado como opção eficiente para determinadas tarefas, como tarefas de interface.
Opus (modelo): Modelo citado como uma opção que pode ser cara demais para tarefas simples.
Qwen (modelo): Modelo citado como opção para tarefas como runbooks e documentação de API.

Tradução completa (pt-BR)

00:12 Meu nome é Siraj Gupta. Lidero o desenvolvimento do Harness na Warp. Caso você ainda não conheça a Warp, começamos criando um ambiente de desenvolvimento agentic de última geração. Temos cerca de um milhão de usuários ativos que usam esse ambiente. Ele surgiu de um terminal moderno. Hoje, estamos criando uma plataforma de agentes na nuvem para permitir que equipes construam fábricas de software. Hoje vou falar sobre fábricas de software que se aprimoram, o que pode soar meio da moda,

00:43 mas vou explicar isso por partes e espero que vocês saiam daqui com algo concreto que possam implementar por conta própria. Provavelmente vocês já ouviram os dois termos — autoaperfeiçoamento e fábricas de software — usados ao longo desta conferência, mas tenho certeza de que já os ouviram separadamente. Vocês ouviram falar de como o autoaperfeiçoamento permite que agents, modelos e outros elementos melhorem com o tempo e, sabe, tirem os humanos desse ciclo, para que o ciclo de melhoria possa ser automático. E tenho certeza de que já ouviram falar de fábricas de software

01:14 como sendo a forma pela qual o paradigma do desenvolvimento de software está mudando, passando de agents de programação individuais para a criação de automações que levam o trabalho da triagem até a produção. Mas se falou menos sobre como as próprias fábricas de software podem se aprimorar com o tempo, para que a fábrica fique melhor, mais eficiente e mais rápida. E acho que isso vai se tornar uma parte extremamente importante do nosso trabalho como engenheiros de software, à medida que passarmos da criação de produtos para a criação de fábricas e para a

01:45 manutenção delas. Vamos começar. Autoaperfeiçoamento é um conceito bem amplo, mas vou me concentrar em três maneiras concretas pelas quais agents e fábricas de agents podem melhorar com o tempo. Vou começar pelas skills, depois falaremos de memória persistente e, por fim, vou falar sobre roteamento de modelos. As skills são uma ótima maneira de dar memória procedural aos seus agents. Acho que não preciso explicar isso em detalhes. Você descreve para o seu agent um procedimento que espera que ele execute repetidamente para realizar uma

02:15 tarefa. Por exemplo, digamos que você esteja criando um agent de triagem, algo bastante comum em uma fábrica de software. E você fornece a ele uma skill sobre como quer que ele reproduza issues. Essas skills ficam desatualizadas com o tempo. Humanos dão feedback aos agents. Os agents aprendem coisas em suas próprias execuções e trajetórias. E, com isso, a skill que você forneceu antes fica ultrapassada. Então, como corrigimos isso e permitimos que o agent melhore com o tempo usando essa skill?

02:45 Uma maneira de fazer isso é implantar um agent de ciclo externo. Foi o que fizemos em nossa própria fábrica de software interna, e tem sido muito produtivo. A ideia é que o agent do ciclo interno é o que realmente aplica a skill. É ele que faz a triagem. E então você tem esse outro agent, de ciclo externo, que observa as execuções do agent do ciclo interno e aprimora a skill com o tempo, procurando erros que ele cometeu ou analisando o feedback que os humanos deram. Vou mostrar um exemplo disso. Deixe-me mudar aqui. Ótimo. Então, este

03:20 é, na verdade, uma skill que usamos internamente na Warp. Abrimos o repositório do nosso cliente como open source, e ele é executado totalmente como uma fábrica. Este é um exemplo de uma skill que dá suporte a um agent de triagem que temos hoje. A ideia é que você recebe uma issue no GitHub e quer executar automaticamente um agent para descobrir que tipo de informação o usuário não forneceu, informação que vai nos ajudar a entender se é algo que devemos desenvolver, se é uma issue existente contra a qual talvez queiramos apenas deduplicar ou se é outra coisa.

03:51 E então temos um… Desculpem, deixa eu mudar aqui. E então temos um workflow que executa esse agent de triagem. Este é um workflow bem simples. Ele simplesmente… Toda vez que uma issue é aberta no repo, esse workflow é executado. E aqui está o agent de ciclo externo, que analisa o trabalho feito pelo agent de triagem e o aprimora com o tempo. A ideia é que o

04:22 agent analise as decisões tomadas pelo agent de triagem do ciclo interno e colete sinais de feedback, que podem ser, sabe, votos positivos ou negativos nas issues. Podem ser comentários de usuários na issue. Pode ser alguém da Warp, um funcionário da Warp, comentando na issue e dando feedback ao agent sobre o que ele fez. E, por fim, isso leva a uma síntese daquela iteração. Assim, acabamos atualizando nossa skill do ciclo interno com esses agents de ciclo externo.

04:53 E é isso que cria esse ciclo de autoaperfeiçoamento com skills. O que é muito bom nisso é que, na etapa quatro, vocês vão ver que adicionamos a skill de triagem e abrimos um pull request. Isso significa que todas as melhorias na skill do ciclo interno serão rastreadas pelo Git. Assim, você tem total visibilidade de como essa skill se transforma com o tempo. Isso também significa que um humano vai revisar essas atualizações da skill. Desse modo, esse agent de ciclo externo não comete um erro que acabe fazendo o agent de triagem ter um desempenho pior.

05:26 Então, é mais ou menos isso que eu queria dizer sobre skills. Agora vou falar sobre memória persistente. Vou voltar à apresentação. Ótimo. Skills são ótimas para lembrar procedimentos, mas e todo o resto? O que acontece quando seu agent do Sentry procura uma issue, encontra uma, faz um trabalho para reunir contexto sobre ela e a corrige, mas depois você encontra uma issue parecida no futuro?

06:00 Seu agent do Sentry pode ter sorte e conseguir descobrir a mesma causa raiz que descobriu da primeira vez, mas isso não é garantido. E, mesmo que consiga, provavelmente você desperdiçou muitos tokens reunindo de novo o contexto de uma issue que já tinha corrigido antes. É aí que algo como a memória persistente entra em cena. Você pode pensar nisso como um repositório de fatos associado a um agent. Seu agent é executado e, de forma parecida com o ciclo de aprimoramento de skills, você tem um agent de ciclo externo que vai extrair fatos, aprendizados e resultados do seu agent do ciclo interno.

06:30 Assim, execuções futuras do agent podem se apoiar no que já foi feito. Vou mostrar um exemplo disso. Vou voltar à apresentação. Na Warp — ou na Oz, na verdade, como mencionei — criamos uma plataforma de agents na nuvem, onde você pode executar agents na nuvem. E você pode anexar repositórios de memória a todos esses agents. Novamente, um repositório de memória é uma coleção de fatos. Neste caso, tenho um agent do Sentry que coletou algumas memórias ao longo do tempo sobre análises de causa raiz que fez

07:02 no passado. O legal é que você pode versionar essa memória, atualizá-la como humano, criar novas memórias ou excluí-las por conta própria, mas principalmente esse ciclo de criação de memória é conduzido por agents. Você também pode ver de onde essas memórias vieram. Então, posso abrir a execução aqui para ver… Ah, bem. Acho que meu endereço IP fica mudando, e nossa plataforma de staging tem acesso restrito a um endereço IP, mas, enfim, você pode ver de onde essas memórias vieram. Assim, você consegue

07:34 tipo, ah, talvez aquela não fosse realmente uma memória importante, ou talvez fosse uma espécie de máximo local que eu não quero incluir no meu armazenamento de memórias. E então, quando seus agents continuam rodando — neste caso, tenho o agent do Sentry, que já fez várias execuções depois de criar essas memórias —, ele pode se apoiar nessas memórias no futuro, quando estiver triando novos issues. Então, neste caso, você vai notar que esse agent rodou, fez bastante trabalho de análise de causa raiz e, no fim, informou quais memórias usou.

08:05 Neste caso, ele conseguiu usar aquelas cinco memórias que eu tinha no meu armazenamento de memórias para acelerar o trabalho que fiz desta vez. Legal. Vou voltar à apresentação. O que é legal no Oz é que a memória persistente funciona em todos os harnesses, então não importa se você está usando Warp Zone, um harness proprietário, Plot Code, Kodak ou qualquer outra coisa no Oz: as memórias serão criadas automaticamente para você. Mas você também pode revisar essas memórias, criar versões, excluí-las ou editá-las como quiser.

08:39 Tudo isso é totalmente rastreável. Legal. Era isso que eu queria dizer sobre memória. A última coisa de que quero falar aqui é o roteamento de modelos. Talvez você esteja se perguntando como isso se encaixa nos ciclos de autoaperfeiçoamento das fábricas. Primeiro, quero falar sobre por que o roteamento de modelos é importante em uma fábrica. Pode ficar proibitivamente caro executar todos os seus agents com Opus quando eles estão fazendo coisas simples, como triagem ou corrigindo falhas simples de CI. Isso vai ficar muito caro com o tempo, e tenho certeza de que alguns de vocês talvez já tenham sofrido com isso ou ouvido histórias de organizações que sofreram com isso.

09:12 Então, escolher quais modelos usar para cada tarefa é muito importante e é algo em que estamos trabalhando na Warp. Na Warp, você pode usar nossos roteadores de modelos prontos para uso, que chamamos de modelos automáticos. À medida que novos modelos são lançados, estamos sempre avaliando quais são os melhores em termos de eficiência de Pareto. Então, se você é um usuário novo e só quer começar a usar, é muito melhor do que fixar seu modelo em Opus ou Haiku, por exemplo.

09:44 Deixe-me mostrar essa experiência na Warp. Vou até aqui. Me deem um segundo. Preciso arrastar isto para cá. Aqui está meu aplicativo desktop da Warp, e vocês podem ver que, além de poder definir modelos, usar os modelos automáticos da Warp é uma opção. Vocês podem usar esses modelos aqui, mas também podem definir seus próprios modelos com roteamento, que basicamente se resumem a

10:15 um conjunto de regras que vocês podem nos fornecer, e nós tomaremos decisões sobre o roteamento de modelos com base nessas regras. Aqui tenho um exemplo de um arquivo de configuração que defini, com algumas regras diferentes: quero que as migrações de banco de dados sejam feitas com GLM, ou quero que runbooks e a documentação da API sejam feitos com Qwen. Isso permite definir classes de tarefas e dizer: “Certo, quero que esta classe de tarefas seja feita por este modelo porque é isso que você viu.”

10:46 Neste momento, porém, isso é mais uma arte do que uma ciência. O que estamos trabalhando para fazer a seguir é permitir definir evals voltadas aos clientes, nas quais vocês podem especificar que tipos de coisas são importantes para vocês e quais parâmetros querem ajustar nessas configurações. Assim, podem realmente ver: “Certo, Haiku é melhor do que GLM ou Opus em uma classe específica de issues?” Isso seria algo específico dos seus workflows, e não apenas algum benchmark genérico que alguém publicou online.

11:16 Deixe-me voltar. Um segundo. Legal, legal. E sim, estou na apresentação de slides. Aqui está uma visão geral de alto nível de como isso funciona hoje na Warp. Internamente, temos nossas regras de roteamento de modelos, mas também temos

11:51 um componente auxiliar de evals que determina quais tipos de tarefas são realmente mais adequados a cada modelo. Fazemos isso com uma abordagem simples de melhor entre k: quando você digita um prompt, executamos vários agents no Oz, usando um conjunto diferente de modelos. E tivemos sucesso ao determinar, por exemplo: “Ah, tarefas de UI são muito bem feitas com GLM. Não precisamos executá-las com Opus. É muito mais eficiente executá-las com GLM.” É assim que temos usado isso, mas em breve vamos incorporar esse recurso ao nosso produto, para que nossos clientes também possam usá-lo nos próprios workflows. Sim, era basicamente isso que eu tinha

12:25 para hoje. Estamos em um estande ali daquele lado. Se vocês tiverem interesse nesse tipo de coisa, venham falar comigo. Estou sempre disposto a conversar sobre isso. Mas, sim, obrigado pelo tempo de vocês hoje. Era só isso. >> [música]

Transcrição original

[00:12] Um my name is Siraj Gupta. I lead Harness development at Warp. Um in case you haven’t heard of Warp before, um we started off by building a state-of-the-art agentic development environment. Um we have about a million active users that use that. Um it was born out of a modern-day terminal. Um and nowadays we’re building a um cloud agent platform to enable teams to build software factories. Um today I’m going to talk about um self-improving software factories, which I know might sound kind of buzzy, um

[00:43] but I’m going to break it down and hopefully you can walk out of here with something concrete that you can implement yourselves. Um you’ve probably heard of both of these terms, self-improvement and software factories, used throughout this conference, but I’m sure you’ve heard of them independently. Um you’ve heard about how self-improvement is about agents being able to um improve over time and agents and models um and, you know, phasing out humans from that loop, so that way the the improvement loop can be automatic. Um and I’m sure you’ve heard about software

[01:14] factories being um the way that like the software development paradigm is shifting from individual coding agents to building out automations that take work from triage up until production. Um but less has been said about how software factories themselves can self-improve over time, so that the the factory can get better, more efficient, faster. Um and I think this is going to become an extremely important part of our jobs as software engineers as we transition from building products to building factories and and

[01:45] maintaining them. Um so let’s dive in. Um self-improvement is a pretty broad umbrella, but I’m going to focus on three concrete ways that agents can improve over time, agent factories can improve over time. I’m going to start with um skills, then we’ll talk about persistent memory, and then I’ll finish off by talking about model routing. Um so skills are a great way to give your agents procedural memory. I don’t think I have to kind of spell that out for you. You describe a a procedure to your agent that you expect it to have to do a

[02:15] task over and over. Um for example, let’s say you’re building a triage agent, which is a pretty common thing you might build in a software factory. Um and you give it a skill on how you want it to go about reproducing issues. Um those skills get stale over time. Um humans give feedback to the agents. Agents learn things in their own um runs and trajectories. Um and the like the skill that you previously gave it becomes dated. So, how do we fix this and let the agent improve over time using that skill?

[02:45] Well, one way to do it is to deploy an outer loop agent. Um and this is what we’ve done in our own internal software factory that’s been really productive. The idea is that your um your inner loop agent is the thing that’s actually applying the skill. It’s like doing the triage. And then you have this other outer loop agent that is observing your inner loop agent’s runs and improving its skill over time by looking for um for mistakes it made or looking at feedback that the human has given it. Um so, I’m going to show an example of that. Um let me swap here. Cool. Um so, this

[03:20] is actually a skill that we’ve used internally at Warp. We’ve open-sourced our client repository and it’s fully run as as a factory. And so, this is an example of an of a of a skill that’s that’s backing a triage agent that we have today. The idea is that um you you get an issue that comes in on GitHub, and you want to automatically run an agent to figure out like what sorts of um like it what sort of information did the user not provide that is going to help us figure out if this is something that we should build, an existing issue that

[03:51] we might actually just want to dedupe against or something else. Um and then we have a Sorry, let me just switch over here. And then we have a workflow that actually like runs that that triage um agent. Um this is a pretty simple workflow. It just Every time an an an issue gets submitted on the repo, this um this workflow runs. And then here’s the actual outer loop agent, which is about looking at the the work that the triage agent has done and improving it over time. So, the idea is that the

[04:22] agent looks at the decisions that the triage the inner loop triage agent made, and it um collects feedback signals, which might be uh you know, thumbs up or thumbs down on the issues. Um it might be users commenting on the issue. It might be someone from Warp um an employee of Warp commenting on the issue, uh giving the agent feedback on what it did. Um and then ultimately that leads to like some synthesis of of the of that um iteration. And so, we we end up basically updating our inner loop skill

[04:53] with this outer loop agents. Um and that’s what leads to this self-improvement loop with skills. What’s really nice about this is that um the So, in step four, you’ll see we we added the triage skill, and then we open a pull request. So, that means that um all of the improvements to the inner loop skill are going to be tracked through get. So, you get like full observability into like how that skill is transformed over time. And that it also means that um a human is actually going to review those updates to the skill. So, that way, you know, this this outer loop agent doesn’t make a mistake and ultimately cause your triage agent to to actually perform worse.

[05:26] Um yeah, so that’s that’s kind of what what I want to talk about for skills. Um let me talk about persistent memory now. So, I’m going to go back to my deck. Um cool. So, skills are great for remembering procedures, but what about everything else? So, like what what happens when your Sentry agent um looks for an issue and and finds an issue, does some work to like gather context about it, and fixes it, but then now you have you encounter a similar issue in the future.

[06:00] Your century your agent might get lucky and like be able to figure out the same root cause that it did the first time around, but that’s not guaranteed. And and even if it does, you’re you’ve probably wasted a lot of tokens re-gathering context on an issue that you’ve already fixed before. So, that’s where something like persistent memory comes in. You can think of this as a fact store scoped to an agent. Your agent runs and similar to the skill improvement loop, you have an outer loop agent that’s going to extract facts, learnings, outcomes from your from your inner loop agent.

[06:30] So, that way future runs of the agent can lean on what’s already been done in the past. So, I’m going to show an example of this. Come back to the deck here. So, in warp or in Oz rather, like I mentioned, we built out a a cloud agent platform where you can run agents in the cloud. And for all for all these agents, you can attach memory stores to them. Again, a memory a memory store is a collection of facts. In this case, I have a century agent that has collected some memories over time about root cause analysis that it’s done

[07:02] in the past. What’s cool is like you can actually version this memory, you can update it as a human, create new memories or delete them yourselves, but primarily this this memory creation loop is driven by agents. You can also see where these memories were sourced from. So, I can actually like open up the run here to see Oh, well. I think this my IP address here keeps changing and this my our staging platform is gated to an IP address, but anyways, you should like you can see where those memories were sourced from. So, that way you can be

[07:34] like, oh, like maybe that wasn’t actually an important memory or that was kind of like a local maxima that I don’t want to include in my memory store. Um and then when your agents continue to run, so in this case I have the sentry agent that’s um that’s done a bunch of runs after it’s created those memories, it actually can lean on those memories in the future um when it’s making um when it’s triaging new issues. So in this case, you’ll notice that um this agent ran, it did a bunch of work to do some root cause analysis, and then it ultimately reported back on which memories it used um

[08:05] uh in this case it it it it was able to use those um five memories that I had in that memory sort to to speed up the work that I did this time around. Um, cool. Uh let me go back to the deck. So, what’s cool in Oz is that persistent memory works across all harnesses, so Warp Zone, proprietary harness, plot code, Kodak, it doesn’t really matter what you’re running on Oz, um memories will automatically be created for you. Um, but you also have the control to to review those memories, version them, delete them, or edit them as you please.

[08:39] Um, all that being fully traceable. Um, cool. That’s what I wanted to say about memory. Um, last thing I want to talk about here is model routing. So, um you may be wondering how this plays into self-improvement loops for um factories. Well, first I want to touch on why model routing is important in a factory in the first place. Um, it can become prohibitively expensive to run all of your agents that are doing simple things like triage or fixing simple CI failures with Opus. That’s just like going to be really expensive over time, and I’m sure some of you have maybe been burnt by this or have heard stories of of or

[09:12] organizations being burnt by this. Um, so model like choosing which models you use for which tasks that is actually very important um and something that we’re we’ve been working on at work. Um, so in Warp, you can actually use uh our out-of-the-box model routers, we call them our auto models. Um, over like as new models come out, we’re all we’re always evaluating like what are the best models when it comes to Pareto efficiency. And so, like if you’re a new user and you just want to get started, it’s much better than like pinning your model to like Opus or or or Haiku, for example. Um

[09:44] let me show you all um that experience in Warp. So, let me go here. Give me 1 sec. Got to drag this over here. So, here I have my Warp desktop um and you can see that um alongside being able to define models um being able to use Warp’s auto models is one option, like these models here, but you can also define your own model routed um uh models, which uh basically boil down

[10:15] to like a set of rules that you can give um to us and we will like make decisions about model routing based on those rules. So, here I have an example of a configuration file that I’ve defined um where I’ve defined a few different rules about like I want database migrations done with with GLM fire with GLM or I want um you know, uh runbooks and API documentation done with Quen. Um So, this really allows you to like like to define classes of tasks and be able to say, “Okay, I want this this class of task done by this model because that’s

[10:46] kind of what you’ve seen.” At this point though, that’s kind of more of an art than a science um and so uh what we’re working on next is being able to define evals for um customer-facing evals where you can actually define what sorts of things you care about and what knobs you want to turn on these configurations and actually see, “Okay, is is Haiku better than fi- than GLM than Opus in a specific class of issues?” That’s like specific to your workflows and not just some like generic benchmark that um that

[11:16] someone posted online. Um let me go back here. Give me a sec. Cool. Cool. Um and yeah, so let me uh I’m in my slideshow. So, here is kind of like a a high-level overview of how this works in Warp today. So, um internally we have our model routing rules, um but then we have

[11:51] like an eval sidecar that’s determining um what sorts of tasks are actually better with which models. And we do this with a simple like best-at-k um approach where when you type a prompt, we run a bunch of agents in Oz uh across a different set of models. Um and we found success in like being able to determine, “Oh, like UI tasks are really well done with GLM. Um we don’t really need to run those with Opus. It’s much more efficient to run those with GLM.” Um so, that’s how we’ve been using it, but um sooner enough we’re going to be building this into our product so that way our our customers can actually use it in their own workflows. Um Yeah, that’s uh that’s mostly what I had

[12:25] today. Um we’re around in a booth around that side. So, if you’re interested in this kind of stuff, come talk to me. I’m always down to talk about this kind of stuff. But yeah, thanks for your time today. That’s all I had. >> [music]