Continuamos reconstruindo nosso agente de IA. Veja o que resistiu — Fuad Ali, Arize AI

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: We Kept Rebuilding Our AI Agent. Here’s What Survived - Fuad Ali, Arize AI · Canal: AI Engineer · 19:41 · Assistir no YouTube

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

Resumo

Fuad Ali apresenta a evolução de Alex, o agente de produção integrado ao Arize X, e as decisões tomadas ao longo de dois anos de reconstrução. A equipe transferiu o controle do planejamento, do encerramento das tarefas e da memória para o harness, além de simplificar a arquitetura de vários agentes especializados para um único agente que carrega skills sob demanda. A palestra também aborda como usar sessões de produção como casos de teste e como combinar automação com avaliação humana. Entre os princípios que permaneceram estão rastrear tudo, usar código para cálculos e manter conjuntos de dados de referência avaliados por pessoas.

Pontos-chave

Alex evoluiu de um roteador de skills para um agente capaz de planejar tarefas, usar ferramentas e carregar instruções sob demanda.
A equipe transferiu gradualmente o estado e o controle do plano para o harness, reduzindo chamadas desnecessárias para atualizar listas de tarefas.
O harness aplica regras explícitas para encerrar turnos, inclusive quando há itens do plano ainda pendentes.
Resultados grandes de ferramentas são tratados como arquivos: o agente recebe uma referência e pode usar código para buscar detalhes quando necessário.
A memória de longo prazo usa um pequeno arquivo Markdown por usuário, em vez de estruturas mais complexas como grafos ou recuperação vetorial.
A equipe substituiu vários agentes especializados por um único agente que carrega skills e ferramentas conforme a necessidade.
O modelo mais recente nem sempre é a melhor escolha; a equipe prioriza modelos rápidos e bons o suficiente e investe no harness.
Sessões reais de produção viram casos de teste e conjuntos de dados de regressão, enquanto experimentos ajudam a avaliar mudanças no harness.
Falhas de agentes podem aparecer como padrões qualitativos, como chamadas repetidas a uma ferramenta, e não como erros explícitos.
Rótulos de referência, critérios de qualidade e decisões sobre velocidade versus qualidade ainda exigem julgamento humano.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação de Alex e escopo da palestra	Fuad Ali apresenta Alex, explica sua relação com outros agentes da Arize e descreve o percurso da palestra.
04:08	Evolução do agente e controle do planejamento	O apresentador percorre as principais reconstruções de Alex e explica como o planejamento foi migrando para o harness.
09:20	Encerramento de turnos e gestão de contexto	A equipe criou regras explícitas para finalizar tarefas e estratégias para lidar com resultados grandes e memória.
13:26	Agentes especializados e escolha de modelos	A equipe simplificou a arquitetura para um agente com skills sob demanda e discute como escolher modelos adequados.
15:31	Sessões de produção como testes	Traces de produção alimentam casos de regressão, enquanto Signal e avaliadores humanos ajudam a detectar e julgar problemas.
18:07	O que permaneceu após as reconstruções	Fuad resume os princípios duradouros de Alex e as decisões de arquitetura que outras equipes também precisarão tomar.

Citações

Não usamos um framework de agentes. O loop, o plano, a regra de parada e a memória são nossos. — 05:43

Às vezes, como engenheiros, gostamos tanto de construir coisas que acabamos atrapalhando a nós mesmos e complicando demais. — 12:25

A gente geralmente escolhe o que é rápido e bom o suficiente e investe bastante tempo no harness. — 14:30

Em agentes, bugs raramente aparecem como erros explícitos. — 16:33

Quem verifica as correções feitas pelo próprio agente? — 19:10

Conceitos e entidades

Alex (conceito): Agente integrado ao Arize X que analisa traces, cria evals e executa tarefas com várias etapas.
Signal (conceito): Agente que analisa traces de outros agentes e ajuda a identificar problemas, como loops de repetição.
Arize X (ferramenta): Produto no qual Alex está integrado para ajudar a trabalhar com traces, evals, conjuntos de dados e experimentos.
Arize AI (empresa): Empresa mencionada na apresentação como responsável pelo produto e pelo desenvolvimento de Alex.
Fuad Ali (pessoa): Apresentador da palestra e profissional de produto na Arize AI.
Harness (conceito): Código que controla o loop do agente, o plano, as regras de encerramento e a memória.
Signal (ferramenta): Ferramenta citada para automatizar a análise de traces e revelar problemas nas sessões do agente.
Sonar 4.5 (modelo): Modelo que se tornou o padrão de Alex após o relançamento 2.0, segundo a apresentação.

Tradução completa (pt-BR)

00:01 [música] >> E aí, pessoal? Obrigado por virem a esta palestra. Sei que estamos chegando ao fim do dia. Vocês já almoçaram e estão ficando cansados. Então, agradeço muito pela paciência. Vocês ouviram bastante de todos nós da Arize AI. Talvez tenham acabado de assistir à palestra da Sophia, se estavam aqui mais cedo. Então, obrigado mais uma vez. Meu nome é Fuad. Fiz uma palestra ontem, caso vocês não estivessem aqui. Trabalho com produto na Arize AI. Então, sou o que

00:32 chamam de gerente de produto de IA, e vou falar um pouco sobre como isso se relaciona com a entrega de agents. Hoje quero falar sobre dois anos entregando nosso agent de produção integrado ao produto e algumas das lições que aprendemos. Espero que vocês tirem bons aprendizados para construir seus próprios agents em produção. Legal. Antes de começar, vamos entrar um pouco em metalinguagem, e espero que todos estejam acompanhando. Mas este slide foi feito com um agent. Sim, foi. Temos agents de programação que operam com o Alex, com o Signal e com outras partes do nosso produto que também são agents.

01:02 Temos o Signal, que é mais ou menos o agent que lê traces e lê os traces dos nossos agents, certo? Então, temos um agent lendo os traces de outro agent. Temos o Alex, o agent integrado ao produto. Dá para pensar nele como uma espécie de Cursor para engenharia de IA. É desse agent que estou falando hoje. Na verdade, usamos o Alex para depurar o Alex. Então, fica um pouco metalinguístico. Espero que vocês tenham uma ideia de como o Alex pode ajudar a avaliar seu agent e de alguns padrões de design que podemos aprender com o Alex e adaptar ao seu agent. Enfim, são tartarugas até o fim; agents até o fim.

01:34 E, se vocês ficarem confusos sobre de qual agent estamos falando, vou deixar isso claro. Então, vamos abordar como o Alex chegou até aqui. Tenho algumas capturas de tela antigas de 2023, que parece ter sido há muito tempo, mostrando como o Alex era. Ele costumava ser apenas um roteador em um ciclo de tool calling de skills. E vamos falar sobre como mudamos isso.

02:04 Também vou falar de algumas das decisões mais difíceis que tomamos ao longo do caminho. Especificamente: quem controla o plano, como encerrar um turno, como lidamos com a memória do agent, se devemos usar um agent ou vários subagents, qual modelo escolher como padrão e como testá-lo. Como mencionei, fica um pouco metalinguístico, mas depuramos o Alex com o Alex. E agora também temos o Signal. Então, vou mostrar como o Signal encontra os ciclos de repetição do Alex e alguns problemas reais que descobrimos no nosso agent usando o Signal. E, algo importante, o que ainda precisa de uma pessoa. Ou seja, onde o julgamento humano agrega valor e como entra o mundo dos gerentes de produto de IA. Também vou falar de algumas decisões que mantivemos ao longo da arquitetura do Alex.

02:35 O Alex é o agent dentro do Arize X. Ele consegue ler seus traces e transformar descobertas em testes, criando evals para você, conjuntos de dados e experimentos. Ele consegue planejar trabalho. Consegue executar tarefas com várias etapas. Pode criar dados sintéticos para você com base nos seus traces. E pode fazer muitas outras coisas. Esta é uma citação de um dos nossos engenheiros seniores: no primeiro protótipo, no fim de 2023, com modelos da era do 3.5, ele alucinava em cerca de 50% dos casos e, nos outros 50%… E vocês viram que estamos melhorando à medida que os modelos também ficam melhores. Aqui temos apenas um pequeno antes e depois das imagens, para dar uma ideia.

03:07 Então, você pode fornecer prompts que armazenou no Arize e pedir que ele os otimize. E, obviamente, ele tinha ferramentas para ler prompts do nosso banco de dados e coisas do tipo. Agora, temos um fluxo muito mais detalhado, com planejamento e uma interface muito mais bonita. O Alex explica o que está fazendo. Ele raciocina sobre as tarefas com muito mais consistência. Aqui, por exemplo, peço que otimize o próprio system prompt do Alex, e ele cria um plano para verificar recursos relacionados ao aplicativo também.

03:37 Então, sim, esta janela aparece no Arize. Você pode usá-la para depurar seus traces. Como chegamos até aqui? Um breve panorama cronológico. Começamos o protótipo no fim de 2023, com modelos da era do 3.5. Depois, decidimos rapidamente tirar muitos cálculos do modelo e colocá-los no código do harness, porque, se vocês se lembram de pedir para agents fazerem cálculos naquela época… Hoje em dia, eles resolvem problemas do nível das equações de Navier-Stokes, mas naquela época

04:08 não eram muito bons em matemática. Depois, fizemos o lançamento oficial. Na época, chamávamos de copiloto, quando todo mundo ainda chamava essas coisas de copilotos. Era um roteador de um conjunto de skills, uma árvore de decisão. Tínhamos algumas proteções. Reescrevemos boa parte em agosto de 2025. Entraram o tool calling iterativo e uma ferramenta de lista de tarefas. Assim, o agent consegue planejar o que está fazendo. O Alex 2.0 foi nosso grande relançamento, em fevereiro de 2026. O Sonar 4.5 passou a ser o modelo padrão, e

04:39 vamos falar também de como testamos esse modelo. O One Alex foi lançado em junho. Em vez de agents especializados, juntamos tudo em um único agent que carrega skills sob demanda. E, por fim, a memória. Agora temos memória de longo prazo. Conforme o usuário interage com o Alex ao longo da sessão, o agent mantém continuamente o histórico daquele usuário, que é gravado em segundo plano. >> [fungada] >> E, obviamente, não treinamos esses

05:10 modelos. Tudo o que reconstruímos foi código do harness, o que, na verdade, me dá um pouco de confiança no mundo da engenharia: ainda há problemas muito interessantes para resolver, e nem tudo depende do modelo. Não dá simplesmente para executar um modelo de fronteira e esperar que ele faça tudo por você. >> [fungada] >> Com certeza, os modelos melhoraram no ritmo deles, e tomamos algumas decisões levando isso em conta, mas praticamente tudo o que construímos foi código do harness. Não usamos um framework de agents. O ciclo, o plano, a regra de parada e a memória são todos nossos. Isso significa que temos muito

05:43 controle sobre ele e também podemos aprender bastante ao longo do caminho. >> [fungada] >> Então, o primeiro tópico é planejamento e lista de tarefas. Tenho várias coisas nos slides, mas a analogia em que penso quando falamos de planejamento é a seguinte: digamos que você… não tenho filhos, talvez alguns de vocês tenham e consigam se identificar com esta analogia. Digamos que você queira que seu filho faça algumas tarefas domésticas. Você pode dar a ele uma lista de tarefas e pedir que marque cada uma conforme for concluindo

06:13 as tarefas. Você pode acompanhar o progresso continuamente e ficar com a lista, sem contar a ele sobre ela, exceto pela próxima tarefa, certo? Esse é um paradigma. E há vantagens e desvantagens em cada abordagem. No começo, demos ao modelo uma lista de tarefas, e o que vimos foi que ele passava a maior parte do tempo marcando itens na lista. Então, fazia muitas chamadas ao LLM para praticamente nada, sem nenhuma unidade de trabalho útil

06:44 além de atualizar a lista de tarefas. Também percebemos que ele tendia a perder o foco depois de várias chamadas a ferramentas, chegando a mais de 20 iterações nas próprias ferramentas de tarefas. Por isso, adicionamos isso como mais uma ferramenta ao seu repertório. Por fim, passamos o plano para o harness, uma parte de cada vez. O que quero dizer com isso é que, primeiro, adicionamos um status de “em andamento” para o modelo não perder o fio de onde estava. Depois, decidimos colocar o plano como uma mensagem, para que o harness renderizasse o plano

07:15 de trabalho além de atualizar uma lista de tarefas. Também percebemos que ele tendia a perder o foco depois de várias chamadas de ferramentas e, sim, mais de 20 iterações nas próprias ferramentas de tarefas. Então, adicionamos isso como uma ferramenta extra ao arsenal dele. E, por fim, transferimos o plano para o harness, uma parte de cada vez. O que quero dizer com isso é que a primeira coisa que fizemos foi adicionar um status de “em andamento”, para que o modelo não perdesse o fio de onde estava. Depois, decidimos colocar o plano como uma mensagem, para que o harness renderizasse o plano

07:47 a cada chamada ao modelo, sempre que o modelo recebe uma nova chamada, e as regras ficam junto dos dados, então fica um pouco mais fácil para o modelo interpretar em que ponto está. Na verdade, acabamos removendo o identificador de progresso, porque percebemos que estávamos fazendo duas chamadas para algo que, na prática, podia ser resolvido de outra forma: qualquer coisa que não esteja concluída já aparece em uma ordem de prioridade, e a próxima tarefa é a próxima a ser feita. Então, removemos isso. E agora estamos testando sem nenhuma ferramenta de lista de tarefas, apenas mantendo tudo completamente nas mensagens. Portanto, o harness mantém o estado e a

08:18 verificação de conclusão, e o modelo simplesmente consome isso e vai fazer a próxima coisa. Então, talvez algumas lições para vocês, enquanto criam listas de tarefas: os modelos podem ser muito ansiosos com listas. Agora, sobre o que encerra o turno: concluir virou uma etapa de controle imposta pelo harness. O que tentamos no início foi considerar que texto sem chamadas de ferramenta significava que a tarefa tinha sido concluída. Isso falhou com modelos que anunciam uma etapa em um turno

08:49 e fazem a chamada no seguinte. Como vocês vão perceber rapidamente ao mudar de modelo, algumas dessas coisas acabam quebrando. Uma das coisas que fazemos no Aux é permitir que os usuários escolham o próprio provedor. Então, não podemos garantir que testamos todos os modelos que alguém possa tentar usar com o Aux. Por isso, muitas das decisões que tomamos aqui servem para nos proteger contra esses casos. E sim, fazemos testes de regressão, verificamos vários modelos e comparamos o desempenho de diferentes modelos no Aux. Temos uma opinião sobre qual deve ser o padrão, mas, obviamente, alguns dos nossos

09:20 clientes usam exclusivamente Anthropic ou exclusivamente OpenAI. Então, para realmente permitir que eles usem os próprios modelos, tivemos que projetar algo que funcionasse com tudo o que estava disponível, certo? Agora temos uma chamada explícita de conclusão, que retorna um aviso quando ainda há itens no plano, por até três vezes; um aviso é emitido uma etapa antes do limite de iterações; e também há uma conclusão forçada. Memória: essa é boa. Na verdade, há vários problemas aqui e, como gosto de analogias, vou usar outra. É

09:50 como se você estivesse trabalhando à sua mesa e um livro enorme fosse colocado nela. Talvez um livro grande não seja problema. Você pode abrir o livro e procurar o que precisa. Mas, se o livro ficar longo demais, ele acaba sendo inútil, porque você vai passar o tempo todo lendo. Esse é um problema. É como quando o resultado de uma ferramenta é enorme demais para você ler, certo? Mas imagine que há vários livros na sua mesa, certo? Então, em algum momento, não é só que os livros são longos demais para você ler: também não sobra espaço na mesa, certo? Você simplesmente tem livros demais, certo? Então, nessa analogia, há várias maneiras de lidar com isso, certo? Você pode decidir guardar o livro e manter apenas uma referência para ele, certo? Foi mais ou menos isso que fizemos com os resultados das ferramentas. Agora tenho um bilhete adesivo na mesa que diz onde está o livro e, em linhas gerais, o que ele contém. Então, se eu precisar ler o livro, consulto o bilhete adesivo e depois

10:20 vou buscar o livro na estante. Minha mesa fica um pouco mais livre, certo? É mais ou menos isso que fazemos com chamadas e resultados de ferramentas. Por exemplo, o Alex pode ajudar na análise de traces. Alguns desses traces pertencem a outros agents e podem conter muita coisa, certo? Então, se for um grande bloco de JSON, por exemplo, ele simplesmente aumenta demais nossa context window, e aí não dá para fazer quase nenhum trabalho útil. Em vez disso, truncamos o JSON e deixamos o agent escrever código para encontrar o que precisa com o JQ, caso precise do contexto completo.

10:51 Uma coisa que agents fazem muito, muito bem é escrever código e usar ferramentas parecidas com código para inferir coisas. Então, é isso que tentamos aproveitar com essa abordagem. A trajetória do próprio agent também pode ultrapassar uma determinada janela. O que fazemos agora é o harness fazer o modelo escrever um checkpoint e, em seguida, descartar o conteúdo que foi substituído. Temos um orçamento fixo de tokens para o histórico e entre sessões, o que me leva à parte de memória de longo prazo. Basicamente, nós

11:23 pedimos a um job em segundo plano para editar um arquivo pequeno por usuário. Vou explicar um pouco melhor mais adiante na apresentação por que decidimos fazer isso com a memória de longo prazo, mas, essencialmente, é assim que funciona. Para recapitular: trate um resultado enorme como um arquivo e simplesmente deixe-o de lado. Não despeje tudo no contexto. Não se preocupe em fazer nada sofisticado. Para a memória de longo prazo, um arquivo pequeno acabou sendo melhor do que um grafo inteiro, e tentamos coisas como recuperação vetorial,

11:55 armazenamentos episódicos e semânticos, grafos temporais de conhecimento e assim por diante. No fim, optamos por ter apenas um arquivo por usuário. É um arquivo Markdown. O limite é de 8.000 caracteres. Acho que há uma lição aqui: como engenheiros, gostamos de construir coisas, é muito divertido construí-las e, às vezes, nós mesmos atrapalhamos nosso trabalho e complicamos demais as coisas. Esse arquivo é carregado a cada solicitação completa. Ele é escrito por um job em segundo plano

12:25 depois que a sessão termina. É pequeno, preciso e fácil de carregar. Não aumenta demais o contexto e também é muito fácil para uma pessoa auditar. Você pode pedir a um avaliador humano para examinar esses arquivos de memória, determinar se as informações certas estão sendo armazenadas e editar as instruções do job em segundo plano. Além disso, há apenas um job, executado no final, que também pode ser tornado bastante seguro. Assim, você garante que não está gravando no arquivo memórias de outros usuários. Então,

12:56 sim, é uma ótima lição sobre não complicar demais os problemas. Falando rapidamente sobre especialistas: em 2025, tínhamos um agent de traces que inicialmente fazia apenas análise de traces. Depois, passamos a ter 10 especialistas, então cada página tinha seu próprio especialista. Se você estivesse na página de conjuntos de dados, por exemplo, havia um subagent especial que podia gerar dados sintéticos para você e examinar e analisar todos os seus conjuntos de dados. No fim, também voltamos atrás nessa decisão e passamos a usar apenas um agent, que

13:26 pode carregar instruções de skill quando necessário e ferramentas sob demanda. E simplesmente deixamos o agent decidir quais ferramentas usar, certo? Isso também reflete uma evolução na capacidade dos modelos, mas acho que há também uma simplificação. Quanto à capacidade dos modelos, também mantemos a posição de que o modelo mais novo nem sempre é o melhor como padrão. Há momentos em que atualizamos o modelo padrão, certo? E temos uma perspectiva sobre isso. Acho que temos, bem,

13:59 a pergunta sobre qual é o melhor modelo é muito subjetiva. Qual é o melhor modelo na fronteira geral é bem diferente do que pode ser melhor para vocês, no que estão desenvolvendo, ou para nós, no que estamos desenvolvendo. Em geral, escolhemos como padrão algo rápido e bom o bastante, e dedicamos muito tempo ao harness. Agora estamos começando a explorar o roteamento automático, ou seja, escolher modelos por tarefa, e a treinar nossos próprios modelos, como SLMs pequenos com pós-treinamento, para áreas muito específicas. E algumas dessas áreas nem sequer precisam do loop em

14:30 qual é o melhor modelo é uma pergunta muito subjetiva. O melhor modelo em uma fronteira generalizada é bem diferente do que pode ser melhor para vocês, no que estão construindo, ou para nós, no que estamos construindo. Em geral, simplesmente optamos por algo rápido e bom o suficiente e dedicamos bastante tempo ao harness. Agora estamos começando a explorar o roteamento automático, escolhendo modelos por tarefa e treinando nossos próprios modelos — SLMs pequenos com pós-treinamento, coisas assim — para casos de uso muito específicos. E alguns desses casos de uso, na verdade, nem precisam do loop em

15:00 Tudo. Você pode simplesmente fazer uma única chamada ao modelo. Um exemplo disso é… deixa eu ver se consigo abrir. Temos esse filtro com IA. Percorremos um longo caminho desde a geração de SQL de antigamente, e agora é muito, muito fácil gerar filtros com modelos bem pequenos. Então, esse é um exemplo de caso em que talvez não precisemos do loop inteiro e estejamos complicando demais as coisas de novo. Legal. Essa é uma boa conclusão. As sessões de produção se tornam nossos testes. É sobre isso que vou falar um pouco

15:31 mais, sobre a Arize como plataforma. Rastrear tudo é muito importante, certo? Então, rastreamos… Na verdade, se você olhar aqui, estes são os rastros desse agent. É bem metalinguístico. Mas, sempre que você faz uma pergunta ao Alex aqui, os rastros são do Alex. Ainda chamamos isso de Copilot prod. Então, esses são os rastros ao vivo que chegam da ferramenta. Isso facilita muito adicionar conjuntos de dados de regressão e acompanhar diferentes consultas de usuários que queremos

16:03 testar e usar em iterações. Assim, essas sessões de produção se tornam nossos casos de teste e nossas fixtures vivas ao longo do tempo. Elas crescem e mudam conforme encontramos novos casos de erro. Agora também podemos usar conjuntos de dados de sessões. Você pode armazenar uma sessão inteira como um conjunto de dados e reproduzir um turno específico por meio do agent, se precisar. Por fim, também usamos os experimentos da Arize em todo esse processo, para garantir que estamos fazendo testes A/B das mudanças no harness conforme avançamos.

16:33 Uma conclusão que quero que vocês também tenham em mente é que, em agents, os bugs raramente aparecem como erros explícitos. No mundo do software de antigamente, isso era muito… Não sei se era mais fácil, mas era diferente. Agora, é mais uma questão qualitativa: tudo parece estar certo, mas, se houver 43 chamadas idênticas à ferramenta no mesmo turno, provavelmente é algo que queremos corrigir. Métricas de software, como latência: acho que todos concordamos que 227 segundos é tempo demais para esperar por uma resposta,

17:05 mas o que é tempo demais depende muito do seu caso de uso. Agora usamos bastante o Signal para automatizar essa revisão. Cada vez mais, deixamos de depender de uma pessoa lendo o rastro. Nossos engenheiros seniores agradecem muito por isso. Mas ainda recorremos à experiência humana, e já vou falar um pouco sobre isso. >> [fungada] >> A correção também pode ser a próxima etapa. Esses conjuntos de dados de regressão são muito importantes, e recomendo que vocês os tenham em mente. Os juízes precisam dessa referência humana; é aí que incluímos a tarefa humana.

17:36 Alinhamos nossos avaliadores e garantimos que nossos juízes reflitam com precisão o que nossos engenheiros pensam. Isso é muito importante. Ainda mantemos muitas coisas sob responsabilidade humana: esses rótulos de referência e esses conjuntos de dados de referência para os juízes vêm de pessoas. O equilíbrio entre velocidade e qualidade depende do julgamento humano. Acho que não existe uma resposta única para toda a stack sobre quando se deve ser um pouco mais rápido, mas é aceitável

18:07 reduzir a qualidade. Ainda é uma decisão que depende do julgamento humano, mesmo que você tenha métricas para isso, como: mudar os modelos aumentará a latência em X e diminuirá — ou aumentará — a qualidade da resposta em Y. Se usássemos o Astra em todos os lugares, seria essa a decisão certa? Acho que ainda depende do julgamento humano. Temos métricas para embasar isso, mas ainda precisamos tomar essas decisões. E estas são, mais ou menos, as seis coisas que sobreviveram a todas essas reconstruções: rastreamento nos nossos próprios produtos, nos quais, é claro, ainda rastreamos tudo o que o Alex faz.

18:38 Matemática e dados no código. O código calcula as agregações; o modelo raciocina e explica. Depois, disponibilizamos isso para o modelo como ferramentas. Não damos ao modelo perguntas de matemática em texto simples. Na verdade, pedimos que ele use código para fazer esses cálculos. Conjuntos de dados de referência no CI, erros com uma correção óbvia, streaming e persistência, e skills. Mudamos o que chamamos de skills. Acho que vocês conhecem routers, ferramentas etc. Mas, no fundo, trata-se de dar ao modelo uma capacidade relacionada a

19:10 um sistema externo. Vocês vão se deparar com muitas decisões. Aqui estão algumas das que tomamos. Podem tirar uma foto do slide. Quem é responsável pelo plano? O que encerra o turno? Se a saída da ferramenta for grande demais para o seu context window, o que você faz? Quem deve escrever a memória de longo prazo? Você deve ter uma? Deve ter vários subagents? Qual modelo é bom e rápido o suficiente? E quem verifica as correções feitas pelo próprio agent? Então, é isso. No canto inferior direito da tela estão

19:41 meu LinkedIn e o X. O lema é: todos os dias usamos o Alex para construir o Alex. Temos várias publicações no blog com análises técnicas aprofundadas de como construímos isso. E recomendo que todos entrem em contato. Um grande agradecimento à equipe do Alex e aos nossos engenheiros por construírem isso. Obrigado. >> [aplausos]

Transcrição original

[00:01] [music] >> Uh what’s up guys? Thank you guys for coming to this talk. I know we’re getting to the end of the day. You had lunch, you’re getting tired. So I really appreciate the patience. You’ve been hearing a lot from all of us at Our Eyes. You just heard Sophia’s talk maybe if you were in the room earlier. So thank you again. My name’s Fuad. I did a talk yesterday if you weren’t here. I work on product at Our Eyes. So I’m what

[00:32] they call an AI PM which I’ll get into a little bit about you kind of how that relates to shipping agents. Um today I want to talk about uh two years of shipping our in-product production agent and some of the lessons we’ve learned. Hopefully there are good takeaways for you guys as you are kind of building your own agents in the wild. Cool. So before I start, we’re going to get a little bit meta here uh and hopefully you guys are all kind of following along. But you know this slide was made with an agent. Yes, it was. Um

[01:02] we have coding agents um that kind of operate with Alex, with Signal, with other parts of our product that are themselves agents. Uh we have Signal which is kind of the trace reading agent that reads our agent’s traces, right? So we have an agent reading the agent traces. We have Alex which is the in-product agent. You can think of it like kind of a cursor for AI engineering. That’s the agent I’m talking about today. Uh we actually use Alex to debug Alex. Um so it gets a little bit meta. Um and then hopefully you get you know kind of

[01:34] an idea of how Alex could help you evaluate your agent and some of the design patterns to be taken from Alex and how that could be translated to your agent. So anyways, turtles all the way down, agents all the way down. Uh and if you are confused about which agent we’re talking about, I will make sure to make that clear. So um what we’re going to cover is kind of like how Alex got here. I’ve got some nice throwback screenshots from 2023 which feels like ages ago, about uh of how Alex used to look. Uh where it used

[02:04] to be just a router over skills tool calling loop. Um and kind of how we’ve changed that. Uh some of the hardest decisions we made along the way. So, specifically who owns the plan, how to end a turn, how we dealt with memory across the agent, should we use one agent, should we use many sub agents? Uh what default model to choose and sort of how we test it as well. Um then, like I mentioned, it gets a bit meta, but we debug Alex with Alex. So, and now we have signals as well. So, how

[02:35] signals is finding Alex’s retry loops and some of the real issues we found with our agent using signal. Uh and then, importantly, what what still needs a person as well. And so, where the human value kind of adds judgment and the AIPM world kind of comes in. Uh and some of the decisions we kept that have lasted throughout the architecture of Alex. Um Alex is the agent inside Arize X. Alex can read your traces, turn findings into tests, so building your evals for you, data sets, experiments. It can plan

[03:07] work. It can run multi-step tasks. It can create synthetic data for you based on your traces. Um and it can do a lot of different things. I would say, yeah, this is a quote from one of our staff engineers, on the first prototype back in late 2023 with like 3.5 error models, it was about 50% hallucination, 50% And you saw that say we’re getting a bit better as models have gotten better as well. Uh this is just a little before and after of the visuals just to give you an idea.

[03:37] So, you can give it, you know, prompts that you stored in Arize, you can ask it to optimize those prompts. And obviously, it had, you know, kind of tools to read prompts from our database and things like that. Now, we have, you know, much more in-depth flow with planning, with much more beautiful UI. Alex kind of explains what it’s doing. Uh it’ll reason through tasks much more strongly. So, here I have like a request to optimize Alex’s own system prompt and actually makes a plan to check, you know, kind of resources around the application as

[04:08] well. So, yeah, this window shows up in a rise. You can use it to debug your traces. Um How do we get here? So, quick kind of like timeline. We started the prototype in late 2023. This is like with 3.5 error models. Um We then, you know, very quickly decided to move a lot of math out of the model and into the harness code because if you remember asking agents to do math back then, I mean nowadays they’re solving Navier-Stokes level problems, but back

[04:39] then they were not very good at math. Um Then we kind of had the official launch. We called it the copilot back then when things were still called copilots. A router of a set of skills, a decision tree. We had some rails. We rewrote a lot of it in August 2025. Um Iterative tool calling and a to-do tool come in. So, the agent can actually kind of plan what it’s doing. Alex 2.0 was our big relaunch in February 2026. Sonar 4.5 became the default model and

[05:10] we’ll talk through some of how we test that model as well. One Alex was just released in June. So, instead of specialist agents, we merged it into kind of like one agent that just loads skills on demand. And finally, memory. We now have long-term memory, so as the user kind of interacts with Alex throughout the course of their session, they are kind of continuously the agent continuously knows sort of the history of that user and that’s written in the background. >> [snorts] >> Um and obviously, we didn’t train these

[05:43] models. Everything we rebuilt was harness code, which I think um actually gives me a bit of faith in the world of engineering that there’s still very interesting problems to solve here and it’s not all up to the model and you can’t just run a frontier model and expect it to do everything for you. >> [snorts] >> Uh models got better on their own schedule for sure and we made some decisions around that, but pretty much everything we built was that harness code. We don’t use an agent framework. Um The loop, the plan, the stopping rule, and the memory are all ours. What that means is we have a lot of

[06:13] control over it and you know we get to learn a lot along the way as well. >> [snorts] >> So first one planning and to-do list. The analogy I have a bunch of stuff on the slides but the analogy I kind of think about around you know planning is like Let’s say you I don’t I don’t have kids maybe some of you guys have kids and you can kind of relate to this analogy but let’s say you want you know your kid to do some chores. You can give it a list of chores and ask it to or ask them to check off the list

[06:44] of chores as they go. Um You can check in with them continuously and hold the list yourself and not tell them about the list except for the next task, right? So that’s one paradigm. Um And there are trade-offs to kind of like each scenario. We initially just gave the model to do list and what we saw was it spent most of its time checking off the to do list. So a lot of LM calls for um pretty much nothing like no useful unit

[07:15] of work other than updating a to do list. It also we also realized it tended to lose focus after multiple tool calls and yeah 20 20 plus iterations on the to do tools themselves. So we added this as an extra tool in its arsenal. And we eventually moved the plan into the harness one piece at a time. So what I mean by that is first thing we did was we added an in progress so the the model wouldn’t lose track of where it was. Um Then we decided to put the plan as a message so the harness renders the plan

[07:47] to the model call every time the model gets a new call and the rules are next to the data so it’s a little bit easier for the model to interpret where it’s at. We actually ended up dropping the in progress identifier because we realized we’re just making two calls for effectively you know anything that isn’t finished is in in a stack ranked order is the next thing to do, so we remove that. Um and we’re actually testing now without a to-do tool at all, uh just keeping everything in line in the messages uh completely. So, the harness is keeping the state and the

[08:18] completion check, and the model just consumes that and goes and does the next thing. Um so, maybe some lessons for you guys as you’re building to-dos, uh models can be very eager with uh lists. Um then, kind of like what ends the turn, uh finishing became a gate the harness enforces. Um so, what we at first tried was, you know, kind of text without tool calls, uh meant and done. That broke on models that announce a step in one turn

[08:49] and make the call in the next, which [snorts] um you know, as you change models, you’ll you’ll quickly find some of these breaking things. And one of the things we do in Aux is we actually allow users to choose their own provider. Uh so, we can’t necessarily guarantee that we’ve tested every single model someone will try with Aux. So, a lot of um you know, some of the decisions we made here are to guard against those. And yes, we run regression tests and we check against a bunch of different models and we benchmark different models on Aux. We have an opinion on a default, but you know, obviously some of our

[09:20] customers are exclusive Anthropic customers or exclusive OpenAI customers. So, to actually empower them to use their own models, we kind of had to design against everything that was available, right? Um so, now we have an explicit finish call that bounces back uh when plan items are open up to three times, uh a warning set one step before the iteration limit, and then a force finish as well. Um memory, this is a good one. Um there are actually a number of problems here, and I’m I I like analogies, so I’m going to use another analogy here. It’s

[09:50] like, you know, you you’re working at your desk, um and a big book lands on your desk. And maybe one big book is fine. You can open the book, kind of search through the book. Uh if the book gets too long, then it’s kind of useless to now cuz you’re going to spend your entire time reading that book. That’s one issue. Uh and that’s sort of like, you know, one big tool result comes back and it’s too big for you to read, right? Um but you can imagine there’s actually multiple books on your desk, right? So, eventually not just are the books too

[10:20] long for you to read on your desk, but there’s no space left on your desk, right? You just have too many books, right? So, there’s a yeah, you know, in this analogy, um there’s a lot of ways you can approach this, right? You can decide to store that book and just have a pointer to the book, right? So, that’s kind of what we did with the tool results, where Okay, I now have a sticky note on my desk that says where the book is and what, you know, kind of high level the book contains. And so, if I need to go read that book, I’ll just reference my sticky note and then

[10:51] go find the book on the shelf. My desk clears up a little bit, right? So, that’s kind of what we do with tool calls uh and tool results. For example, like Alex’s uh you know, can help you with trace analysis. Some of these traces are other agents’ traces, and they can have a ton of stuff in the trace, right? So, um if it’s a big JSON blob, for example, that just blows up our context window and then you can pretty much do no useful work. So, instead, what we do is we truncate within uh the JSON and we just let the agent code to go find it if it needs the full context with JQ. Um

[11:23] one thing that agents are very, very good at is writing code and using code-like tools to uh kind of infer things. And so, that’s kind of what we try to leverage with that. Um the agent’s own trajectory also going past uh a certain uh window. Um so, what we now have is the harness makes the model write a checkpoint uh and then drops what it replaced. Uh we have fixed token budget for history um and across sessions, so I kind of got to like the long-term memory piece. Uh basically, we

[11:55] just ask the a background job to edit one small file per user. I’ll dive a little bit more into like why we decided to do this with with long-term memory uh later in the presentation, but essentially, that’s how it works. Um kind of talk through this. So, treat a huge result like a file and just scrap it. Uh don’t dump it all into context. Don’t worry about doing anything fancy. Uh for long-term memory, a small file actually beat an all graph and we we tried things like vector retrieval,

[12:25] episodic and semantic stores, uh temporal knowledge graphs, etc. etc. What we eventually landed on was we just have one file per user. It’s a markdown file. It’s capped at 8,000 characters. Um and you know, I I think there there is a lesson here that, you know, as engineers, um we like to build things and it’s really fun to build things and sometimes we get in our own way and we over-engineer. Um and this file is just loaded in on every full request. Uh it’s written into in a background job

[12:56] after the session finishes. It’s small. It’s exact. It’s easy to load in. It doesn’t blow up context and it’s very easy for a human to audit as well. Uh so, you can actually kind of have a human labeler go look at these memory files and and determine whether the right things are being stored and kind of edit instructions for the background job. So, um and then you also only have one job at the very end, which uh you can make very safe as well. Uh so, you’re you’re making sure you’re not writing memory from other users into the file. Um so,

[13:26] yeah, very good lesson on not over-engineering uh your problems. Um briefly on specialists, um you know, we had one trace agent that initially just did trace analysis back in 2025. Then we had 10 specialists, so every page kind of had its own specialist. If you’re on the data set page, there’s, you know, special sub agent that can generate synthetic data for you and look look and introspect on all uh all your data sets. Uh we ended up kind of rolling that back as well and just using one agent where

[13:59] the agent can load skill instructions on demand and tools on demand and we just let the agent decide what tools to do, right? So, it is a bit of an evolution also in in model capability, but I think simplification as well. >> [snorts] >> Um we on model capability, we also kind of stand by that the newest model isn’t always the best by default. Um there are times where we upgrade the model by default, right? And so, we have a perspective on that. Um I think we have um you know,

[14:30] what is the best model is a very subjective question. Uh what is the best model on a generalized frontier is very different from what may be best for you guys in what you’re building or what we’re building. Uh we generally just default to fast and good enough and spend a lot of time on the harness instead. Um we are now starting to explore auto routing, uh so choosing models per task and training our own models, so small post training SLMs, things like that on very narrow surfaces. Um and some of these surfaces actually don’t even need the loop at

[15:00] all. You can just make a single model call. So, an example of that is I wonder if I can pull it up. We have this like, you know, filter with AI. Um we’ve come a long way from SQL generation in the in the past and it’s actually very, very easy to generate filters with very, very small models now. So, um that’s an example where maybe we don’t need the entire loop and we’re just over-engineering again. Um Cool. So, that’s a good takeaway. Um production sessions becoming our test. So, this is where I’ll talk a little bit

[15:31] more about arise as a platform. Uh tracing everything is really important, right? So, we trace Actually, if you look at this, these are the traces from this agent. Uh so, it’s very meta here. Um but every time you ask Alex a ques- question here, the the traces these are the traces from Alex. We we still call it Copilot prod. Um so, those are our live traces coming in from the tool. Um this makes it very easy to add, you know, regression data sets and and keep track of different user queries that you want

[16:03] to go test against and iterate against. Um and so, those production sessions become our test cases and become our living fixtures over time. They grow, they change um as we see new error cases. Um and we also now have the ability to use session data sets as well. So, you can store an entire session as a data set and kind of play a specific turn through the agent if you need. Um finally, we use arise experiments throughout all this as well to make sure that we’re you know, kind of AB testing uh harness changes as we go through this.

[16:33] Uh one takeaway I want you guys to to kind of keep in mind also is that in agents, bugs rarely show up as explicit errors. Um in the old world software, this was a lot I don’t know if it was easier, but it was different. Um now it’s more of like a qualitative okay, the status says okay, but if there are 43 identical tool calls in the same turn, that’s probably something we want to fix. Um software metrics like latency, right? So, I think we can all agree 227 seconds is way too long to wait for a response,

[17:05] but what actually is too raw too long it really depends on your use case. Um so, we use signal a lot now to kind of automate this reveal. We we use less and less of the human reading the trace. Um our staff engineers are very grateful for that. Uh but we still do use kind of that human expertise, which I’ll get to in a bit. >> [snorts] >> Um the fix can also be the next box. So, these regression data sets are are really important and I would encourage you guys to keep them in mind. Judges need that human baseline, so that’s where we kind of impart the human task.

[17:36] We align our evaluators and we make sure that our judges actually accurately reflect what you know, our engineers think as well. Uh so, that’s very important. Um I think we we still keep a lot of things with the human, those gold labels, those golden data sets uh for judges come from people. Um the speed versus quality is a human judgment call. I don’t think there’s any single answer across the stack on when you should be a little bit faster, but it’s okay to

[18:07] degrade quality. It is still you know, kind of like a human judgment call even if you have the metrics around it like okay, changing models will increase latency by X and decrease uh or increase quality response by Y. If we just use Astra everywhere, would that be the right decision? Still a human judgment call, I think. We have the metrics to support that, but we still have to make those decisions. Um And these are kind of the the six things that survived all these rebuilds. Tracing to our own products that we

[18:38] of course still trace everything that Alex does. Math and data in code. So, code computes the aggregations, the model reason and explains. And then exposing those as tools to them to the model. So, we’re not giving the model plain text math questions. We’re actually asking it to use code to go do that. Golden data sets in CI, errors with an obvious fix, streaming and persistent, and skills. Um We’ve changed what we call skills. I think, you know, routers, tools, etc. But really it’s give the model a capability around

[19:10] an external system. So, a lot of decisions you’ll face. And here’s some of what we chose. So, if you’ll go ahead and take a picture of the slide. Who owns the plan? What ends the turn? If your tool output is too big for your context, what do you do? Who should write the long-term memory? Should you have one? Should you have multiple sub agents? What model is good enough and fast enough? And who checks the agent’s own fixes? So, yeah, that’s me. On the bottom right of the screen there

[19:41] my LinkedIn and X. The tagline is everyday we use Alex to build Alex. We have a bunch of blog posts on sort of like technical deep dives into how we built this. And yeah, I encourage you guys to all reach reach out. And big shout out to the Alex team and our engineers for building this. Thank you. >> [applause]