Como uma empresa de trading lança novos modelos de IA no mesmo dia — Noyan Tokgozoglu, Optiver

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: How a Trading Firm Ships New AI Models the Same Day - Noyan Tokgozoglu, Optiver · Canal: AI Engineer · 22:51 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Infraestrutura e hardware de IA, Modelos locais e open source

Resumo

Noyan Tokgozoglu, head de AI engineering da Optiver, explica como a empresa construiu uma plataforma modular de IA para operar em um ambiente de trading no qual mudanças podem afetar o P&L em poucas horas. A plataforma combina modelos de terceiros e modelos hospedados internamente, gateways de inference e de agents, evals, controles de custo e suporte global. A equipe busca avaliar e disponibilizar novos modelos no mesmo dia, além de otimizar o uso de tokens e oferecer ferramentas adequadas aos usuários. Na sessão de perguntas, Tokgozoglu aborda limitações de bases de conhecimento, avaliações de tool calls e a organização de sistemas multi-agent.

Pontos-chave

• Na Optiver, o impacto de mudanças pode aparecer no P&L no mesmo dia, o que torna a rapidez na tomada de decisão especialmente importante.
• A plataforma de IA foi projetada para ser modular, mensurável, segura e compatível com diferentes modelos e harnesses.
• A empresa busca avaliar novos modelos em golden sets internos e disponibilizá-los em fluxos de produção no mesmo dia, quando agregam valor.
• Um inference gateway centraliza o acesso a modelos, permite alternar entre provedores e oferece controles de custo e resiliência.
• A equipe reduz gastos com otimizações de contexto, MCP tool search, uso de CLI, ajustes de caching e melhor organização do conhecimento.
• Visibilidade de custos, limites definidos pelas equipes e modelos open source ajudam a obter mais retorno do uso de tokens.
• Um portal próprio permite gerenciar sessões e artefatos e apoiar a colaboração entre usuários e agents.
• A equipe registra interações e tool calls para evals, mas reconhece dificuldades para reproduzir o estado de sistemas externos durante uma avaliação.
• Em vez de concentrar muitas funções em um único agent, a empresa incentiva agents especializados que podem ser coordenados por um agent gateway.

Capítulos

Início	Capítulo	Resumo
00:01	Trading e o impacto imediato das decisões	Tokgozoglu apresenta a Optiver e explica como o P&L permite observar rapidamente os efeitos de mudanças.
03:09	Princípios da plataforma de IA	A plataforma prioriza rapidez, modularidade, medição, autonomia dos usuários, segurança e infraestrutura on-prem.
06:46	Lançar novos modelos no mesmo dia	A equipe avalia modelos com benchmarks internos, integra-os ao gateway e organiza suporte e comunicação global.
09:51	Controle de custos e otimização de tokens	Tokgozoglu descreve medidas para reduzir o contexto desnecessário e controlar gastos sem abrir mão do valor dos modelos.
13:58	Ferramentas internas para os usuários	A empresa cria um portal próprio para sessões, colaboração e uso compartilhado de agents.
16:04	Perguntas sobre bases de conhecimento e soluções próprias	Na sessão de perguntas, Tokgozoglu compara abordagens para conhecimento e explica por que a Optiver constrói parte da própria infraestrutura.
19:12	Evals, tool calls e estado dos sistemas	A equipe registra interações para avaliação, mas enfrenta dificuldades para reproduzir o estado de ferramentas e sistemas externos.
21:17	Agents especializados e orquestração	Tokgozoglu defende dividir responsabilidades entre agents especializados e coordená-los pelo agent gateway.

Citações

Se um novo modelo de fronteira for disponibilizado publicamente, queremos conseguir usá-lo em fluxos de produção no mesmo dia. — 06:46

Às vezes, as pessoas têm no mínimo 200 mil tokens de contexto em uma sessão nova. Isso é ridículo. — 10:52

Nossos usuários têm muita iniciativa. Se não construirmos algo para eles, vão construir por conta própria. — 15:01

Mantenha os agents focados em tarefas nas quais são bons e que possam ser medidos e gerenciados com facilidade. — 22:20

Conceitos e entidades

• Optiver (empresa): Empresa de trading que atua como market maker e desenvolve sua própria plataforma de IA.
• Noyan Tokgozoglu (pessoa): Head de AI engineering da Optiver e palestrante sobre a escalabilidade de IA na empresa.
• inference gateway (conceito): Camada que encaminha solicitações a modelos diferentes e ajuda a controlar custos e disponibilidade.
• Agent Gateway (conceito): Camada central que reúne agents e permite coordená-los com identidade e gestão compartilhadas.
• MCP (conceito): Protocolo e conjunto de ferramentas que a empresa integra e otimiza, inclusive por meio de busca de ferramentas.
• Codex (ferramenta): Ferramenta mencionada na discussão sobre agents gerenciados e execução em infraestrutura própria.
• Claude Code (ferramenta): Produto citado como um momento associado ao aumento do uso e dos gastos com IA.
• golden sets (conceito): Conjuntos de referência usados para avaliar modelos em tarefas relevantes para as equipes de trading.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é Nayan. Sou responsável pela engenharia de IA na Optiver e hoje vou falar um pouco sobre como ampliamos o uso de IA com o P&L em jogo. Mas o que isso significa, afinal? Primeiro, acho que, para contextualizar, vou contar um pouco sobre o que fazemos na Optiver. Somos formadores de mercado. Isso significa que facilitamos as negociações. Somos uma empresa de trading. Nós

00:32 negociamos com nosso próprio dinheiro. E não temos clientes. Basicamente, do ponto de vista tecnológico, recebemos muitos dados, construímos modelos e então tomamos decisões com eles. Essas decisões precisam funcionar com desempenho muito alto: fazemos mais de 10 milhões de negociações por dia, precificamos mais de um milhão de instrumentos e processamos petabytes de dados diariamente. Além disso, somos uma empresa bastante global. Temos mais de 10 localidades pelo mundo. Isso traz certas implicações, que já vamos abordar. >> [limpa a garganta] >> Normalmente, se você olhar para uma empresa de tecnologia tradicional, pode pensar em como ela mede quanto dinheiro ganha. É algo mais ou menos assim: você implementa uma mudança, disponibiliza para os usuários, e então eles a usam por dias, semanas etc., enquanto você coleta métricas de engajamento. Depois, ao longo de meses e trimestres, talvez anos, você analisa coisas como receita, valor do cliente ao longo do tempo etc. Eu trabalhava na Apple, então sei como isso funciona. Mas, na Optiver, implementamos algo. Disponibilizamos a mudança para nossos traders e nossos quants e, literalmente, em poucas horas, já é possível ver o impacto no P&L. Na verdade, no

01:04 começo de cada dia, basicamente zeramos o balanço patrimonial e, no fim do dia, vemos quanto dinheiro ganhamos. Isso tem certas implicações para como tomamos decisões sobre ampliar o uso de IA e sobre como queremos construir as coisas. >> [limpa a garganta] >> Para começar, o ciclo de feedback é muito mais imediato, certo? Quando você toma uma decisão, no fim do dia já começa a ver o impacto dela. É claro que, no longo prazo, há instrumentos que negociamos com horizontes mais longos e há mais valor a descobrir ao longo do tempo, mas você começa a ver o impacto de algo imediatamente. Por outro lado,

01:35 se você perder uma oportunidade, essa perda potencial pode sair bem cara. Especialmente se houver algo especial acontecendo no mercado. Digamos que haja uma IPO da SpaceX AI e você deixe passar; isso provavelmente vai sair bem caro. Isso significa que precisamos tomar decisões com bastante rapidez. Precisamos conseguir medi-las de forma realmente eficaz e eficiente. E precisamos ter uma tendência a agir. Isso significa que o teto do valor e da importância de uma decisão que você pode tomar é muito, muito alto. No caso de um

02:07 serviço, como um negócio de serviços voltado ao usuário, como o Spotify ou qualquer outro, a concorrência é, fundamentalmente, por uma quantidade finita da atenção dos clientes. Já no trading, quanto mais você negocia, mais dinheiro ganha, certo? Então, a economia funciona de maneira um pouco diferente. Para conseguir isso e poder ampliar e operar dessa forma, precisamos basicamente construir nossa própria plataforma de IA com base em alguns princípios fundamentais. Agir rápido. Já falamos disso. Mas, claro, parte de agir rápido é conseguir trabalhar de forma modular.

02:37 Porque, no mundo da IA, todo dia surge um novo modelo, um novo produto, um novo paradigma. Estamos fazendo loops, agora estamos fazendo swarms, agora estamos fazendo grafos etc. Precisamos conseguir levar isso em conta. Se esse paradigma for valioso, vamos avaliá-lo. E, se for, vamos incorporá-lo. Porque, assim que o incorporarmos, começaremos a obter mais valor. E, claro, para conseguir entender isso, precisamos construir tudo de modo que seja possível medir cada camada. É claro que trading envolve muitos backtests etc. Mas também precisamos, quando surge um novo modelo, saber que existem benchmarks externos que mostram como

03:09 esse modelo está se saindo, mas também precisamos entender como ele se sai nos nossos benchmarks internos. Porque a distribuição de dados dos benchmarks que temos é diferente daquela disponível externamente. Agora, nossos traders são pessoas muito inteligentes. São pessoas com bastante iniciativa. Então, queremos que nossa plataforma seja bastante self-service. Mas, é claro, sempre que você oferece algo totalmente self-service, pode haver bastante caos. Por isso, também precisamos oferecer boas configurações padrão. Uma maneira como trabalhamos com eles é também fazer deploy junto com eles. Temos uma equipe de engenharia de IA de tamanho razoável e levamos nossos profissionais para se sentarem com os traders, trabalharem com eles, entenderem como fazem trading, ensinarem como a IA pode agregar mais valor ao trabalho deles, aprenderem e levarem esse conhecimento de volta para a plataforma. Agora, é claro, todos vocês já ouviram as histórias da OpenAI, do Hugging Face etc. Então, à medida que fazemos cada vez mais com IA, também precisamos garantir que fazemos isso de forma segura. Como podem imaginar, pode haver impactos bem negativos se os agents saírem do controle e fizerem coisas com nossa stack. Mas quero enfatizar que todo mundo na empresa está usando IA.

03:39 Cada um usa de um jeito um pouco diferente, mas, no fundo, somos muito, muito nativos em IA — acho que esse é o termo que estamos usando agora. E, claro, como atuamos em um setor altamente regulado e damos muito valor à nossa propriedade intelectual, tudo o que fazemos fica on-prem. Temos nossas próprias GPUs on-prem, nossa própria infraestrutura on-prem etc. A única coisa que enviamos para fora da nossa infraestrutura é, basicamente, a inference de modelos de terceiros. E, claro, nesses casos, temos acordos com as empresas que incluem coisas como retenção zero de dados. Então, aqui está uma visão bem do tipo “choque e deslumbramento”, com muita informação no slide, da nossa plataforma de IA. Não espero que vocês assimilem tudo isso, mas, se quiserem tirar uma foto e conversar comigo depois, fiquem à vontade. Vou mostrar este slide de novo no final. Mas, em linhas gerais, quero destacar que todos precisamos responder por cada camada da stack. Na parte de baixo, temos modelos de provedores terceirizados. Também hospedamos nossos próprios modelos e modelos open source. Temos um gateway de inference que oferece recursos como o roteamento entre esses diferentes modelos.

04:11 Podemos medir quanto estamos gastando em cada um desses modelos. Podemos atribuir orçamentos etc. Vou falar disso daqui a pouco. E, claro, isso nos dá resiliência. Se um provedor sair do ar, podemos sempre mudar para outro provedor etc. Porque, mais uma vez, sempre que ficamos fora do ar, basicamente deixamos de ganhar dinheiro. Depois, temos nossa própria plataforma de agents, na qual os agents têm recursos registrados, como skills, plugins e ferramentas. Cada agent, em cada equipe que usa um agent, pode incorporar seu conhecimento e seus sistemas de memória. Temos um gateway de agents, que é

04:42 basicamente um registro único de todos os agents da empresa, para que possam se conectar, se comunicar e orquestrar pessoas e agents com gerenciamento de identidade semelhante etc. Isso se relaciona a conceitos como o agent swarm, sobre os quais vocês talvez também já tenham ouvido falar. Por fim, algo que é muito importante para mim, que também sou um cara de produto, é termos as interfaces certas para que nossos usuários interajam com os agents. Porque você pode construir uma ótima plataforma, mas, se ninguém quiser usá-la, gostar dela ou souber como usá-la, ela não faz diferença. Então, construímos nossa própria interface web para que as pessoas acessem, por exemplo,

05:13 Saber, impacto e deslumbramento: uma visão com muitas informações no slide sobre nossa plataforma de IA. Não espero que você, sabe, absorva tudo isso, mas, se quiser tirar uma foto e falar de mim depois, fique à vontade. Vou mostrar este slide de novo no final. Mas, de modo geral, o que quero destacar é que todos temos de ser responsáveis por cada camada da stack. Na base, temos modelos de provedores terceiros. Também hospedamos nossos próprios modelos e os modelos open source. Temos um gateway de inference que oferece recursos como o roteamento entre esses diferentes modelos.

05:44 Podemos medir quanto estamos gastando com cada um desses modelos. Podemos definir orçamentos etc. Vou falar disso daqui a pouco. E, claro, isso nos dá resiliência. Se um provedor ficar fora do ar, podemos sempre trocar para outro provedor etc. Porque, de novo, sempre que ficamos fora do ar, basicamente não estamos ganhando dinheiro. E então temos nossa própria plataforma de agents, onde os agents têm recursos registrados, como skills, plugins e ferramentas. Cada agent de cada equipe que usa um agent pode trazer seus próprios sistemas de conhecimento e memória. Temos um gateway de agents que é

06:15 basicamente como um registro central de todos os agents da empresa, que podem se reunir, comunicar e orquestrar pessoas e agents com um gerenciamento de identidade semelhante etc. Isso se relaciona a conceitos como o enxame de agents, que talvez você também já tenha ouvido mencionar. E, por fim, algo realmente importante para mim, que também trabalho com produtos, é termos as interfaces certas para que nossos usuários interajam com os agents. Porque você pode construir uma ótima plataforma, mas, se ninguém quiser usá-la, gostar de usá-la ou souber como usá-la, então isso não importa muito. Por isso, criamos nossa própria interface web para as pessoas acessarem, por exemplo,

06:46 as sessões deles etc. Temos uma coisa chamada nossa bancada de trabalho de agents, que é basicamente gerenciamento de personas. As equipes podem criar seus próprios perfis de como usam os agents e compartilhá-los. Temos um assistente pessoal ao qual todos na empresa têm acesso. Sim. Então, de novo, volto a isso mais tarde, mas, se tiverem perguntas, podemos conversar depois. Certo. Então, como avançamos com esses princípios? Um dos princípios que temos é que, se um novo modelo de fronteira for disponibilizado publicamente, queremos poder aproveitá-lo em fluxos de produção no mesmo dia, porque há um valor imenso em

07:17 isso, se ele for valioso. Mas ele é valioso? Queremos poder avaliá-lo em conjuntos de referência. Isso significa que precisamos ter uma estrutura de avaliação madura. E então fazemos parceria com equipes-chave de trading, com as quais coletamos os benchmarks. Fazemos o onboarding delas e, sempre que recebemos um novo modelo, executamos o modelo nesses novos benchmarks, conhecemos imediatamente as métricas e podemos compartilhá-las com as pessoas da empresa para ver: “Ei, isso é realmente valioso para nossos casos de uso?” Mas, além disso, sempre que há um modelo diferente, geralmente precisamos disponibilizá-lo no nosso gateway, ter as APIs e interfaces corretas e configurar o gerenciamento de custos

07:49 corretamente, entre outras coisas. Muitas vezes, modelos novos significam que os harnesses precisam ser atualizados, entre outras coisas, e também gerenciamos essa atualização e entrega. E, claro, lançamos o modelo, mas isso também traz expectativas. Somos uma empresa global, então precisamos oferecer suporte ininterrupto. Nossa equipe tem escalas de suporte em diferentes regiões para garantir alta disponibilidade. Acho que algumas pessoas na plateia estão de suporte hoje, mas enfim. E, claro, executamos esses benchmarks, mas também precisamos garantir que as pessoas da empresa

08:20 entendam: “Certo, analisamos este modelo, fizemos o benchmark, eis o desempenho dele, eis como usá-lo, esta é a nossa recomendação”, e manter essa comunicação aberta. Outra coisa é que, como temos a opção de escolher entre diferentes modelos, queremos integrar qualquer modelo que agregue valor. E precisamos conseguir nos proteger contra a indisponibilidade de modelos em diferentes regiões ou em diferentes provedores de nuvem, entre outras coisas. Também temos a exigência de que algumas de nossas cargas de trabalho sejam executadas em uma zona completamente isolada, em uma DMZ local.

08:50 Também há motivos de custo para isso, além de motivos de isolamento. Por essas razões, queremos ser agnósticos em relação ao modelo e ao harness. Isso significa que temos provedores terceirizados e modelos locais, e tudo passa pelo nosso gateway de inference. Registramos tudo: cada interação com os modelos é registrada e também transferida automaticamente para nosso sistema de avaliação. Damos suporte a vários harnesses e, além disso, temos uma camada de meta-harness que basicamente permite que as equipes configurem suas

09:21 experiências nessa camada e tenham alguma portabilidade entre esses diferentes harnesses. Assim, as equipes podem definir as próprias configurações de harness nessa camada de meta-harness, que se conecta à base de conhecimento da equipe. O conhecimento é coletado automaticamente ao longo do tempo: analisamos os traces e, então, encontramos maneiras de obter ainda mais conhecimento. Por meio desse meta-harness, você pode implantar e gerenciar os agents na nossa plataforma ou acessá-los pelo portal web com a interface de IDE que descrevi antes. Vejo algumas pessoas tirando fotos, então vou

09:51 dar um segundo. Certo. Esse tipo de gráfico talvez seja familiar para muitos de vocês. Esta é uma representação aproximada de quanto estamos gastando com IA; não há números nele. Mas estamos fazendo mais com ela. Em dezembro, vocês veem o momento do Claude Code e o gasto aumenta. Aliás, este ponto de inflexão aqui foi quando entrei na empresa, então não sei se tenho algo a ver com isso. E aqui temos os grandes lançamentos de modelos de fronteira do verão. Como podem ver, os gastos dispararam, mas depois conseguimos colocá-los de novo sob controle porque criamos algumas otimizações no processo que nos ajudaram a manter isso sob controle.

10:22 Então, quanto mais gastamos, mais valor podemos obter. Estamos bastante confiantes de que podemos continuar tendo retorno. Queremos garantir que estamos gastando com sabedoria, certo? Uma coisa que descobrimos foi que temos vários MCPs, várias bases de conhecimento e informações, entre outras coisas. Em uma sessão nova, percebíamos que, às vezes, as pessoas tinham, por padrão, pelo menos uns 200 mil tokens de contexto, às vezes até mais. Isso é ridículo, certo? Porque todo mundo estava colocando um monte de coisas ali. Esse é o tipo de problema de fazer tudo completamente em autosserviço, certo? Precisamos ter responsabilidade direta pelo resultado. Então implementamos várias mudanças. Trouxemos a busca de ferramentas do MCP. Demos aos agents a opção de, em vez de chamar MCPs, usar o próprio CLI, que encapsula vários MCPs e é muito mais eficiente. Analisamos as características do cache: quando os caches são invalidados, por quanto tempo precisamos definir esses parâmetros? Precisamos defini-los de outra forma? Defini-los dinamicamente?

10:52 E então trabalhamos com as equipes individualmente para encontrar mais otimizações para seus harnesses. Por exemplo, colocamos algumas coisas na base de conhecimento em vez de incluí-las em um system prompt enorme. O bom dessas melhorias é que todas escalam com o custo dos tokens, certo? Basicamente, quanto mais caros forem os tokens, mais você economiza com isso. Mas o ponto aqui é que

11:22 sim, você pode disponibilizar modelos para as pessoas. E nem estou entrando no trabalho que estamos fazendo em coisas como roteamento de modelos ou otimizações de subagents. Só nas coisas de uma única sessão, quase sempre há valor que não está sendo aproveitado. E estamos otimizando isso sem trégua. Isso mesmo. Já tínhamos lançado otimizações naquele momento, mas, claro, sempre há a implantação gradual e coisas do tipo. Nossa pilha tecnológica é um pouco interessante quando se trata de lançar atualizações nas

11:54 diferentes regiões globais. Mas outras coisas também nos ajudaram bastante a gastar menos. Acontece que, quando você informa às pessoas quanto estão gastando, dá a elas um pouco mais de visibilidade, mais alertas e autonomia para gerenciar isso por conta própria, elas fazem um bom trabalho. Criamos um sistema para que as equipes definam seus próprios alertas e limites. E vimos muitas equipes estabelecerem limites razoáveis para si mesmas. Outra opção é explorar modelos open source. Há vários modelos open source cujo custo por token é bastante competitivo em relação aos modelos de fronteira disponíveis.

12:24 Eles não são necessariamente adequados para todos os casos de uso, mas encontramos oportunidades em que são uma boa alternativa em termos de custo-benefício. E, basicamente, temos disponibilizado esses modelos internamente. Vimos cada vez mais pessoas aproveitá-los. Depois, claro, há coisas como o roteamento de modelos. Temos explorado diferentes abordagens para enviar dinamicamente o prompt a um modelo mais barato, por exemplo. Ou, às vezes, usar uma abordagem em que o plano é gerado por um modelo mais avançado e a implementação fica a cargo de

12:55 com um custo bastante competitivo em relação aos modelos de ponta disponíveis. Não é necessariamente a opção certa para todos os casos de uso, mas encontramos oportunidades em que são um substituto com bom custo-benefício. E basicamente disponibilizamos esses modelos internamente. E vimos cada vez mais pessoas aproveitarem esses modelos. Depois, é claro, há coisas como o roteamento de modelos etc. Temos explorado diferentes abordagens para enviar dinamicamente o prompt para um modelo mais barato etc. Ou, às vezes, ter uma maneira de gerar o plano com um modelo mais de ponta e fazer com que a implementação seja

13:26 divididos entre modelos menores etc. E, por fim, acho que as bases de conhecimento são subestimadas. Quer dizer, elas são muito importantes, mas também ajudam a controlar os gastos se você implementar sua base de conhecimento de forma eficaz, porque, no fim das contas, você recupera menos contexto se buscar apenas a quantidade certa. Resumindo, ainda estamos investindo — quer dizer, usando muitos tokens —, mas a questão é obter mais retorno sobre o investimento com os mesmos tokens. E, por fim, quero falar um pouco sobre atender às necessidades dos usuários onde eles

13:58 estão. Há alguns meses, estávamos numa situação em que várias pessoas usavam diferentes harnesses. Tinham toda sorte de configurações personalizadas e esquisitas para se conectar às próprias máquinas de desenvolvimento, e algumas pessoas estavam criando interfaces web improvisadas etc. Enfim, o que dissemos foi: “Tem várias pessoas fazendo esse tipo de coisa. Por que não criamos uma versão bem-feita e a disponibilizamos para todo mundo na empresa?” Foi exatamente o que fizemos. No nosso portal web, criamos um sistema em que você pode gerenciar suas sessões. Pode ter janelas de chat e artefatos ali.

14:29 Há produtos parecidos oferecidos por algumas das empresas de harness, mas achamos que essa solução funcionou muito bem com nossa infraestrutura e podemos iterar nela no ritmo que quisermos. Isso também chegou a um ponto em que diferentes traders da empresa estão contribuindo com código. Eles encontram algo que é útil para o workflow deles, enviam um PR e nós atualizamos a plataforma. Agora temos coisas como edição colaborativa de documentos e afins.

15:01 Na verdade, estamos chegando a um ponto em que estamos fazendo essa coisa de vários agents em grupo: agora tenho minhas sessões ali. Podemos criar salas com meus agents, seus agents e outros agents em deploy, e reunir tudo num só lugar. Isso realmente ajuda as pessoas a serem mais produtivas. Também temos um cliente do Slack, por exemplo. Então, dá para usar em qualquer lugar e coisas do tipo. Nossos usuários têm muita iniciativa. Se não criarmos algo para eles, eles vão lá e criam por conta própria. Então, simplesmente fizemos uma versão melhor disso.

15:31 É. Basicamente, essa é a filosofia geral por trás de como fizemos isso. Temos uma plataforma bem modular e continuamos iterando nela. Mas, até agora, estamos gostando bastante. Esse é o fim da apresentação. Se tiverem perguntas sobre qualquer coisa que mencionei ou sobre outra área, podemos conversar. E, a propósito, temos um evento de networking hoje à noite. Venham ao nosso estande e façam o cadastro. Vai ser divertido. Temos prêmios legais.

16:04 >> [aplausos] [aplausos] >> Perguntas? Sim. Então, com certeza exploramos várias opções diferentes. Pessoalmente, não estou satisfeito com nenhuma das opções disponíveis. Há vantagens e desvantagens, mas, se você perguntar a alguns dos laboratórios de fronteira o que fazem para ter uma base de conhecimento, eles dizem que usam apenas arquivos Markdown enormes, organizados hierarquicamente

16:34 em Markdown, etc. Há casos em que isso funciona, mas a busca vetorial tem suas próprias vantagens e desvantagens. Temos uma abordagem híbrida que nos permite explorar essas diferentes opções. Pessoalmente, gostaria que dedicássemos mais tempo a coisas como bancos de dados de grafos, por exemplo, que podem ser mais valiosos. Quer dizer, todo dia vejo no Twitter alguma nova maneira de lidar com memória e conhecimento. É um problema ao qual queremos dedicar

17:04 mais tempo. Não estou satisfeito com nossa solução. Pode falar. >> Há soluções feitas à mão ou… >> Sim, boa pergunta. Qual é o valor de usar soluções feitas à mão em comparação com o Codex? Há algumas coisas. Uma resposta meio sem graça é que, como tudo está na nossa própria infraestrutura, muitas dessas ferramentas não funcionam do jeito que você

17:35 gostaria. Até recentemente, o Codex não tinha a opção de executar agents gerenciados, por exemplo, ou algumas dessas coisas na sua própria infraestrutura. Agora começaram a oferecer isso e, na verdade, estamos trabalhando com eles nessa questão. Mas esse foi um dos motivos pelos quais começamos assim. Em segundo lugar, acho que a maioria dos lugares que oferecem esse tipo de solução também tenta deixar você preso ao próprio modelo ou a outra parte da solução. Mas, no momento em que seguimos por esse caminho, acabamos numa situação em que, se nossa

18:08 infraestrutura estiver muito dependente de um provedor específico, avançamos na velocidade que ele nos permite. Já passamos por isso com um dos provedores de gateway de inference que usávamos. Basicamente, havia situações em que algo era lançado e precisávamos daquilo, e eles diziam: “Tudo bem, vamos conversar com nossa equipe de GTM. Vamos incluir isso no roadmap.” Só que, a essa altura, a gente pensa: “Não, precisamos mesmo avançar mais rápido.” Esse também é um dos motivos. E, por fim, acho que em algumas dessas áreas temos estado

18:41 consistentemente à frente. Por exemplo, conversando com alguns dos laboratórios de fronteira, sobre a forma como implementamos recursos de agents gerenciados e coisas do tipo, eles nos pedem para explicar como fizemos. Sem querer me gabar demais, acho que temos bastante confiança na nossa engenharia e no nosso roadmap. Isso também tem funcionado bem. Não acho que essa abordagem funcione para todo mundo, mas acho que temos uma combinação singular de circunstâncias que nos permite fazer isso. Ótimo.

19:12 >> Pode falar um pouco sobre… É, só para ter certeza de que entendi sua pergunta. Quais são algumas das melhores práticas para integrar o restante disso às evals e à memória? Certo. Acho que começamos num ponto em que, como eu disse, registramos tudo: cada

19:44 tool call, entrada, saída etc. Simplesmente registramos tudo. E isso vai para o nosso sistema de avaliação. O desafio que encontramos — e eu diria que ainda é um problema em aberto — é que, quando você tenta avaliar uma tool call, por exemplo, temos um agent de suporte que executamos no Slack e queremos avaliar esse agent. Digamos que executássemos esse agent em outro modelo. O bot de suporte usa várias ferramentas que dependem do estado do mundo, que

20:14 era diferente quando você o executou. Esse é um problema bastante comum. Temos trabalhado em coisas como: será que podemos registrar o estado do mundo no momento em que essas ferramentas são usadas? A resposta depende do sistema com o qual você está trabalhando. Se for um banco de dados de backtest de trading, é fácil: você sempre pode consultar um momento específico. É o que fazemos. Mas, se for outro sistema, como o Slack, por exemplo, qual era o estado do Slack quando isso foi avaliado originalmente? Talvez haja maneiras de reproduzir o Slack a partir de um momento específico, mas, em outros sistemas, não muito. Então,

20:47 tentamos atribuir um valor de confiança que indique o quanto conseguimos consultar um momento específico para aquela invocação de ferramenta. E continuamos registrando isso dessa forma. Quando executamos as evals novamente, rodamos a ferramenta com uma solicitação para usar o snapshot. Temos um proxy em torno dos MCPs. Mas não é perfeito. E não sei se existe uma solução perfeita além de simplesmente registrar tudo. É, talvez dê tempo para mais uma pergunta?

21:17 Ótimo. Sim. Esse é um problema bem clássico que encontramos várias vezes. Sabe, tínhamos uma equipe que criou um agent para fazer programação e análise com eles. Ele era meio que limitado ao repo deles e… e se também tivéssemos

21:48 trabalhou com essa equipe e fez com que a solução deles também chegasse até nós, e ela imediatamente ficou muito mais complexa. Agora, está verificando vários repos que têm diferentes … etc., como num problema típico. Então, inicialmente, nossa solução foi explorar: e se simplesmente fizéssemos isso, literalmente? E se criássemos um novo agent que reunisse todas as funcionalidades? Mas, muitas vezes, isso acaba gerando muita dívida técnica, funcionando muito mal etc. Acho que nossa resposta atual a esse tipo de paradigma é, obviamente, versionar cada agent etc. Então, se forem pequenos incrementos,

22:20 você pode enviar uma nova versão para o agent e adicionar novas capacidades, mas, daqui para a frente, incentivaríamos mais as pessoas a basicamente aproveitar nosso agent gateway: em vez de um agent fazer umas dez coisas diferentes, delimite o escopo dos seus agents a uma tarefa na qual eles sejam bons. Você pode avaliá-los com facilidade, gerenciar facilmente o ciclo de vida deles e, então, haverá outro agent com quem eles poderão se comunicar facilmente, como se estivesse, sabe, operando por conta própria, porque temos essa estrutura que permite aos agents passar por um único livro-razão, iniciar uns aos outros etc. E isso vai nos ajudar a escalar esses tipos de

22:51 funcionalidades com mais eficiência, em vez de simplesmente sobrecarregar um único agent para fazer tudo. Isso acaba virando um problema de orquestração multiagent, mas, sabe, acho que manter as coisas mais mensuráveis é realmente importante, porque, se você sobrecarregar demais o agent, pode acabar em situações em que, sabe, algumas funcionalidades melhoram, outras pioram, e você não consegue ajustá-lo com facilidade.

Transcrição original

[00:01] [music] >> My name is Nayan. I’m the head of AI engineering at Optiver, and today I’m going to talk to you a little bit about how we scale AI with P&L on the line. Like, what does that mean though, right? So, first I think to contextualize, uh let me tell you a little bit about what we do at Optiver. So, we’re a market maker. Uh what that means is that we facilitate trading. Uh we’re a trading firm. We

[00:32] trade with our own money. Um and we don’t have clients. Uh basically, you know, we in in a tech sense, we take a lot of data, you know, we build models, and then we make decisions with them. And these decisions need to work in a very high-performance manner, you know, we make 10 million plus trades a day, pricing million plus instruments, and petabytes of data processed daily. And also, we’re a pretty global firm. We have 10 plus locations across the world. Um and that comes with, you know, certain implications that we’ll get into for a second. >> [clears throat] >> So, typically, if you look at a traditional tech company, you can think

[01:04] about how they think about, you know, how they measure how much money they make. Uh it’s something along the lines of you implement some change, you roll it out to users, and then users use it for days and weeks, etc., and you collect some engagement metrics. Uh and then over, you know, months and quarters, maybe years, you look at like revenue, long-time value, etc. I used to be at Apple, um so I know how this works. Um but um at Optiver, we implement something. Uh we roll out that change to our traders and our our quants, and literally within hours you can see the P&L impact. In fact, you know, at the

[01:35] top of every day, we basically zero out the balance sheet, and then look by the end of the day how much money we’ve made. So, this has certain implications around how, you know, we make decisions around how we want to scale AI and how do we want to build things. >> [clears throat] >> First of all, the feedback loop is much more immediate, right? Like, when you make a decision, by the end of the day you’ll start seeing the impact of that decision. Of course, like, over long term, there are instruments that we trade that are, you know, longer horizon and there’s more value to discover over long-term, but immediately you’ll start seeing the impact of something. But, the other side of that coin is that

[02:07] if you miss an opportunity, then that means that opportunity loss is potentially pretty costly. Especially if, you know, there’s like a special [clears throat] thing going on in the market, let’s say that there’s a SpaceX AI IPO or something like that and you miss out on that, then that’s probably, you know, pretty costly. Which means that we need to make decisions pretty quickly. Uh we need to be able to measure them really effectively and really efficiently. And we got to have a bias for action. Um that means like the ceiling of the value and importance of a decision decision you can make is really, really high. Um so, in the in the case of like a

[02:37] service, like a user-facing service business, like Spotify or whatever, like fundamentally, they’re competing for a finite amount of attention of the customers. Versus with your trading, the more you trade, the more money you make, right? So, you know, the economics are a little bit more different. So, to accomplish this and to be able to scale and operate at this way, we basically needed to build our own AI platform around a few core principles. Move fast. I mean, we talked about that already. But, of course, part of moving fast is that being able to be modular.

[03:09] Because, you know, in the AI world, every day there’s a new model, there’s a new product, there’s a new paradigm. We’re doing loops, now we’re doing swarms, now we’re doing graphs, etc. And we need to be able to account for that. And if that paradigm is valuable, like measure it. And if it is, bring it in. Because the moment you bring it in, you’re going to start, you know, getting more value. And of course, to be able to understand that, we need to build to measure at every layer. You know, of course, like trading means lots of backtesting, etc. But also, you know, we need to when a new model comes out, yes, there’s of course external benchmarks as to how

[03:39] this model is performing, but we also need to be able to understand how in our internal benchmarks these things perform. Because the data distribution of the benchmarks that we have is different from what they have available externally. Now, the thing is, traders are pretty smart people. They’re pretty high agency people. So, we want our platform to be very self-service. But, of course, anytime you provide something purely self-service, it can be really chaotic. So, we also need to be able to provide good defaults. Uh and one way we kind of have this um way of working with them is also being able to forward deploy. So, we have a

[04:11] fairly decently sized AI engineering team and we take our people, we have them sit down with the traders, work with them, understand how they trade, teach them how AI can add more value to them, learn and bring it back to the platform. Now, of course, you’ve all heard the stories of like opening eye hugging face, etc. So, of course, as we’re doing more and more with AI, we also need to make sure that we’re doing in a safe manner. As you can imagine, there’s potentially pretty negative impacts if the agents kind of go haywire and do stuff with our stack. Um but, I do want to underscore that everybody in the company is using AI.

[04:42] Like, everybody’s using it a little bit differently, but fundamentally we’re very very um AI native, I guess is the term that we’re using now. Um And, of course, because we’re a highly regulated industry and we value our IP deeply, everything that we do is on prem. So, we have our own on prem GPUs, our own prem infrastructure, etc. The only thing that we phone home outside of our service really is for like third-party model inference. And, of course, in those cases, we have like things like zero data retention, etc. agreements with the companies. So, here’s kind of like a very, you

[05:13] know, shock and awe, like a lot of information on the slide type of view of our AI platform. I don’t expect you to, you know, digest all of this, but, you know, if you want to take a photo and talk about me afterwards, be my guest. I’ll flash this slide again at the end. But, broadly, the things that I want to highlight is that um we all have to be accountable for every layer of the stack. At the bottom, you know, we have models from third-party providers. We also self-host our own models and the open-source models. We have an inference gateway that provides things like routing between these different models. Um

[05:44] we can uh, measure how much we’re spending on each of these models. We can assign budgets, etc. I’ll go to that in in a second. And of course this gives us resilience. Like if one provider goes down, we can always swap out to a different provider, etc. Because again, any time that we’re down, you know, that’s basically we’re not making money. Um, and then we have our own agent platform where uh, agents have uh, registered uh, capabilities like skills, plugins, tools. Each agent in each team with the using an agent can bring in their knowledge and memory systems. We have an agent gateway which is

[06:15] basically like a single ledger of all of the agents in the company being able to come in together, communicate, orchestrate humans and agents with similar identity management, uh, etc. So this kind of goes into things like the agent swarm, etc. concepts that you also may have heard about. And finally, what’s really important to me, I’m a product guy as well, is that um, we have the right surfaces for our users to engage with the agents because you can build a great platform, but if nobody wants to, likes to, or knows how to use it, then it doesn’t really matter. So we’ve built our own kind of um, web interface for people to access like

[06:46] their sessions, etc. Uh, we have this thing called our agent workbench which is basically persona management. Teams can kind of build their own profile of how they use the agents and share. Uh, we have a personal assistant that everybody in the company uh, has access to. Um, yeah. So again, I’ll get back to this later, uh, but if you have questions we can talk about it afterwards. Right. So how do we move on these principles? Uh, one principle that we have is that, you know, if a new frontier model is made available publicly, uh, we want to be able to leverage it in production flows the same day because there’s immense value in

[07:17] that if it is valuable. But is it valuable, right? We want to be able to benchmark it on golden sets. So that means that we need to have a mature evaluation framework. Um, and then we partner with key customer trading teams where we collect their benchmarks. We onboard onto them and whenever we get a new model, we run the model on these new benchmarks, immediately know the metrics, and can share with the folks in the company to see, “Hey, is this really valuable for our use cases?” But additionally, you know, anytime there’s a different model, usually that means that we have to make the model available in our gateway, we have the right APIs, interfaces, we have the cost

[07:49] management, etc. set up correctly. And often times new models mean like the harnesses need to be updated, etc. and we also manage the update and delivery of that as well. And then of course, yes, we launch it, but then that also comes with the expectations. We’re a global company, so we need to have round-the-clock support. So our team, you know, has in different regions support rotations to make sure that the uptime is high. I think some people here in the audience actually are in support today, but anyway. Um and then of course, like we run these benchmarks, we also need to be able to have um the people in the company

[08:20] understand like, okay, we looked into this model, we benchmarked it, here’s how well it works, here’s how you use it, here’s our recommendation, and kind of keep that communication line open. Um another thing is that because we have optionality between different models, uh if any model’s adding value, we want to integrate it. Uh and we need to be able to insulate against model availability in like different regions, uh or different, you know, cloud providers, etc. Uh and also we have a requirement that some of our workloads run in a completely DMZ on-prem zone.

[08:50] Uh so we also there’s cost reasons for that, there is um reasons of isolation for that. So for those reasons, we want to be able to be agnostic to the model and harness, so which means that we have the third-party providers, uh we have on-prem models, and all of it kind of goes through our inference gateway. We log everything, uh every interaction going with the models is logged, and we also automatically move them to our evaluation system. Uh we have a bunch of different harnesses that we support, and on top of that we have a meta harness layer that basically lets teams configure their

[09:21] experience on top of that and have some portability between these different harnesses. Um >> [clears throat] >> so teams can define their own harness configs in this meta harness layer, and that plugs into the team’s knowledge base. Automatically knowledge is harvested over time, we look at the traces and then derive ways to uh get additional knowledge as well. Uh and then through this meta harness, you can either deploy manage the agents on our platform or you get access to them through the web portal IDE UI that I described earlier. I see some people taking photos, so I’ll

[09:51] give it a second. All right. >> [clears throat] >> So, um this type of a chart may be familiar to a bunch of you. Uh this is kind of a roughly illustrated version of how much we’re spending on AI, no numbers on it. Um but we are doing more with it. And this is, you know, in December you see like the Claude code moment and things go up. By the way, this inflection point here is like when I joined the company, so I don’t know if I have anything to do with that. Um and then um then we have here, you know, like the big frontier model releases of the summer. As you can see, like spend

[10:22] really shot up there, but then we kind of got it back under control because we built some optimizations into the process that helped us really get this thing uh in check. So, um the thing is the more we spend, the more value we can get. We are pretty confident that we can, you know, keep getting returns. We want to make sure that we’re spending wisely, right? So, one thing that we discovered was that um we have a bunch of MCPs, we have a bunch of knowledge bases and information, etc. Um and on a fresh session, we were seeing that, you know, sometimes people have

[10:52] like 200k tokens worth of context like by default minimum, sometimes even more. That’s That’s ridiculous, right? Because everybody was kind of dumping a bunch of stuff in there. This is the kind of problem with like doing things completely self-service, right? We need to have skin in the game. So, we implemented a bunch of different changes. Uh we brought in MCP tool search. Uh we gave the agents the option to um rather than calling MCPs, have their own CLI that’s wrapping around a bunch of the MCPs, which is like much more efficient. Um we looked at the caching characteristics of like when caches are

[11:22] getting invalidated, how long do we need to set these parameters? Do we need to set them differently? Do we set them dynamically? Um and then we work with the individual teams to kind of come up with further optimizations to their harnesses. You know, we do we put some things into knowledge base rather than this like massive system prompt etc. And the good thing about these improvements is that um these things all scale with token cost, right? So basically if the tokens are more expensive, you’re saving more on this. But the point here is that

[11:54] um yes, you can dump models out there, make them available to people. And I’m not even going into the work that we’re doing on things like, you know, model routing or sub-agent optimizations etc. Sheer single session stuff, there’s almost always value left on the table. And we’re, you know, ruthlessly optimizing towards that. Yeah, there we go. And we shipped optimizations at this point in time, but of course there’s always like roll out etc. Our tech stack is a little bit interesting when it comes to rolling out across the

[12:24] different global regions. But then also other things that really helped us spend less was that um turns out that if you tell people like how much they’re spending and like give them a little bit more visibility, a little bit more alerting, and give them the agency to self-manage, they actually do a pretty good job, you know. We built a system to basically have teams kind of set their own alerting and limits. And we’ve seen like many teams, you know, basically set reasonable limits for themselves. Another option is, you know, exploring open-source models. Uh you know, there are a bunch of open-source models that are on token

[12:55] cost pretty competitive with the frontier models out there. It’s not necessarily right for every use case, but we found opportunities where they’re a good value replacement. And we’ve been basically making that available internally. Uh and we’ve seen more and more people leverage those. Then of course, like there’s things like model routing etc. There’s we’ve been exploring different approaches to dynamically send the prompt to like a cheaper model etc. Or sometimes have a way where we have the like plan generated by like a more frontier model and the implementation be

[13:26] broken down by smaller models, etc. Um and finally, you know, I think knowledge bases are underrated, uh which yeah, I mean they’re very important, but they also help get spend in control if you do your knowledge base effectively because then you’re retrieving less context fundamentally if you just retrieve the right amount of context. Um so, long story short is that we’re still investing I mean using a lot of tokens, but this is just about getting more ROI out of the same tokens. And finally, I kind of want to talk about uh meeting the users where they’re

[13:58] at. Um so, a few months ago we were in this place where like a bunch of people are using different harnesses. They have all these weird bespoke setups to kind of team up into their dev boxes and some people were building, you know, hacky web UIs, etc. etc. Whatever. So, basically what we said was like, “Hey, you know, there’s a bunch of people doing these types of things. Why don’t we just build a nice version of this and then make it available to everyone in the company?” So, that’s exactly what we did. In our web portal, we built this basically system where you can manage your sessions. You can have chat windows. You can have like artifacts in there. Um

[14:29] there are similar products out there offered by, you know, you know, some of the different uh harness companies, but we feel that this worked very well with our infrastructure um and we can kind of iterate it at the rate that we would like to. Um so, basically this was actually uh also at a at a place where different traders in the company are now kind of contributing code. They find something that’s valuable to their workflow and then they did they just send up a PR and we just update it and then now we have things like, you know, collaborative document editing and things like that.

[15:01] And in fact, we’re kind of getting this to a place where uh we’re doing this, you know, agent multiplayer thing where now I have my sessions in there. We can create rooms with like my agents, your agents, like other deployed agents and we can kind of have all of that in one place and this really helps uh people be more productive and uh you know, we have now a Slack client, etc. So, you can also do it on the go and whatnot. So, basically, um our users are very high agency. Uh they will go and build something if we don’t build it for them. So, we just built a better version of

[15:31] it. Yeah. So, uh basically, this is um the overall overarching philosophy of how we did this. Uh we have a platform, very modular, uh and um we continue to iterate on it. But, so far, we’re having a pretty good time. Um that’s the end of the talk. Uh but, if you have questions about anything on this or any other area, we can talk. And by the way, we have a networking event uh this evening. Uh please come to our booth and register. It’s going to be fun. We have cool prizes.

[16:04] >> [applause] [applause] >> Questions? Yeah. So, we’ve um definitely been exploring a bunch of different options. Um personally, I’m not happy with any of the options out there. There’s tradeoffs, but I mean, if you ask like some of the Frontier Labs what you do for knowledge base, they’re like just huge markdown files, hierarchical

[16:34] markdown, etc. Um there’s places where that works, but um there is um vector search has its own benefits and disadvantages. We have a hybrid approach that kind of uh allows us to explore these different options. Personally, I want us to spend more time around like doing things like perhaps some graph databases, etc. that are going to be uh more valuable. I mean, every day on Twitter, I see something like new way of like handling memory and knowledge. Um that’s a problem that we want to spend

[17:04] more time on. I’m not happy with our solution. Go ahead. >> There’s hand built or >> Yeah, good question. Um, value gained from using hand built solutions versus Codex. So, there’s a few things. Um, I mean, one kind of boring answer is that because everything is kind of in our own infrastructure, a lot of these tools don’t work in the way that you would

[17:35] want them to. Um, un- until recently, Codex didn’t really have the option to kind of run managed agents, etc. or some of these things on your own infrastructure. Now, they’ve started offering them and we’ve been working with them on it, actually. But, um that was one reason why we started this way. Secondly, I think the um most Many of the places that offer these types of solutions also try to kind of lock you into either their model or some rest of their solution. But, the moment we kind of go down that path, then we end up in a place where if our

[18:08] infrastructure is overly invested in one particular provider, we move at the speed that they let us move. Uh, we’ve actually encountered with um that was one of the uh inference gateway providers that we used to use. Um, and basically, we would encounter scenarios where something comes out, we need it, and they’re like, “Okay, uh let’s talk to our GTM team. Let’s put you on the road map.” Well, it’s like and then by that point, it’s like, “Okay, no, we need to actually move faster.” Um, so that’s also one of the reasons. Uh, and finally, I think the in some of these areas, we’ve been um

[18:41] consistently ahead of the curve. Like, uh talking to some of the frontier labs, um the the way that we’ve been doing managed agent capabilities, etc. like, they’re asking us to tell them how we did it. Not to be bragging too much, but I think the um we feel pretty confident in our engineering and kind of our road map. So, that’s also uh been well. I don’t think this approach works well for everybody, but I think we have a unique um coalition of circumstances that allow for us to do that. Good.

[19:12] >> Can you talk a bit about your Um yeah. So, just to make sure I understand your question correctly. What are some of the best practices of how we integrate the rest of this into eval and memory? Right. Um so, I think the we started at a place where, you know, we log everything, like I said, every

[19:44] tool call, input, output, etc. Just hotel logging. And that goes into our evaluation system. Um the challenge that we found with that, and we it’s kind of an open problem, I would say, is that um when you’re kind of trying to evaluate like a tool call, I mean, we have like, for example, a support bot agent that we run in Slack. And we want to evaluate that agent. Let’s say, what if we ran this agent on a different model? Well, the support bot is leveraging a bunch of tools that depend on the state of the world that

[20:14] were different at the time when you ran it. And that’s the pretty like typical problem. Um we’ve been working on basically things like, can we snapshot world states with these tools? And depending on the system that it ingresses with, it’s, you know, there’s different answers to that question. If you’re looking at some like trading back test database, easy. Like that you can always point in time. That’s what we do. But if you’re looking at some other system, like if you’re looking at Slack, for example, what was the state of Slack when this was originally evaluated? Maybe there’s some ways to kind of replay Slack from a particular point in time, but other systems, not really. So,

[20:47] we kind of try to assign the confidence value as to how well we can point in time this particular tool invocation. And we still log it as such. And when we’re rerunning the eval, we will run the tool with kind of saying, okay, I want to kind of the snapshot. We have like a proxy around the MCPs. But, you know, it’s imperfect. And I don’t know if there’s a perfect solution other than just record, you know, everything. Yeah, I maybe I talk time for one more?

[21:17] Good. Yeah. That’s a very classic problem that we’ve actually run into several times. You know, we had this one team that built an agent that did like coding and like analysis with them. It was kind of scoped to their repo and it was like, well, what if we also had

[21:48] worked with this team and have their thing also come to us and immediately kind of explodes in complexity. Now it’s checking out multiple repos that have different off, etc. like typical problem. So, initially our solution was explore, okay, what if we like literally just did that? What if we just made the new agent that just had a union of the functionality, but often times that ends up, you know, a lot of tech debt, works very poorly, etc. I think our current answer to that type of paradigm is obviously every agent is version, etc. So, you can if it’s small increments,

[22:20] you can push a new version to the agent, make make new capabilities, but going forward we would more encourage people to basically leverage our agent gateway where rather than one agent having like a 10 different things that it does, scope your agents to like a task that they’re good at. You can easily measure them at, you can easily manage the life cycle of it and then there’ll be another agent that it can talk to easily as if it was, you know, kind of operating on itself because we kind of have this construct of agents being able to go through one ledger, spin up each other, etc. And that will help us scale these types of

[22:51] functionality more effectively rather than just bloating one agent to do everything. It becomes kind of like a multi-agent orchestration problem, but you know, that’s I think keeping things more measurable is really important because if you really bloat the agent then you can end up in scenarios where like, you know, some of the functionality gets better, some gets worse, and you can’t really, you know, tweak it easily.