Agentes de longo horizonte precisam de experimentos, não apenas de prompts — Erina Karati

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: Long-Horizon Agents Need Experiments, Not Just Prompts — Erina Karati · Canal: AI Engineer · 20:41 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, RAG, busca e recuperação de informação

Resumo

Erina Karati apresenta o Project Paradox, um framework multiagente para criar personagens de jogos com memória, emoções e relações sociais. A equipe percebeu que, embora os agentes funcionassem bem em interações curtas, sua consistência social diminuía ao longo de períodos mais longos. A proposta é usar auto research para executar cenários controlados, registrar traces e avaliar o comportamento com métricas equilibradas, alterando apenas uma superfície de política restrita. A abordagem busca manter apenas mudanças que melhorem os resultados sem violar guardrails, e pode ser aplicada a outros agentes que mantêm estado ao longo do tempo.

Pontos-chave

• O Project Paradox oferece uma estrutura modular para agentes de jogos que interagem com o ambiente, outros agentes e jogadores.
• A arquitetura mantém memória separada por agente, acompanha emoções e crenças e atribui importância a eventos.
• Em tarefas de longo horizonte, informações podem perder sua origem, rumores podem virar fatos e agentes podem não agir com base no que sabem.
• O auto research é uma camada externa que analisa traces completos e avalia o comportamento da sociedade de agentes, não apenas uma resposta isolada.
• Cenários controlados podem testar difusão de fatos, preservação da incerteza de rumores e replanning diante de mudanças.
• Uma scorecard equilibrada deve avaliar dimensões como alcance da informação, atribuição de origem, preservação da incerteza, planejamento e privacidade.
• O harness, os cenários e as métricas devem permanecer fixos, enquanto apenas uma superfície pequena de políticas fica disponível para otimização.
• Mudanças devem ser mantidas somente quando melhoram a avaliação sem comprometer guardrails; caso contrário, devem ser revertidas.
• O método pode ser útil para agentes de suporte, assistentes pessoais, pesquisa, programação e workflow.

Capítulos

Início	Capítulo	Resumo
00:12	Project Paradox e agentes com estado	A palestrante apresenta o framework e descreve agentes que se movem, interagem e mantêm memória, emoções e crenças.
04:34	Limites da consistência em longo prazo	Um exemplo de rumor sobre mangas mostra como a informação pode perder sua origem ou deixar de orientar ações após vários eventos.
06:50	O ciclo de auto research	A proposta combina cenários, execução de simulações, coleta de traces, avaliação e mudanças limitadas às políticas dos agentes.
10:43	Cenários e métricas comportamentais	A palestra explica como testar difusão de fatos, incerteza de rumores e replanning com uma scorecard que também considera privacidade.
14:32	Superfície de política e reversão de mudanças	O auto research deve modificar apenas uma área controlada, e cada alteração precisa ser avaliada e revertida se causar danos.
17:28	Aplicações e receita para agentes de longo horizonte	A abordagem é relacionada a diversos tipos de agentes e resumida em uma receita de experimentos controlados e mudanças mensuradas.

Citações

Como melhoramos um sistema multiagente em comportamentos sociais de longo prazo, e não apenas em uma resposta? — 06:15

Não estávamos mais avaliando uma resposta; estávamos avaliando uma execução inteira. — 08:59

Memória não é suficiente aqui. — 16:51

Congele o harness, defina cenários, registre traces, avalie o comportamento e exponha apenas uma pequena superfície de política. — 19:35

Agentes de longo horizonte precisam de experimentos, não apenas de prompts. — 20:41

Conceitos e entidades

• Project Paradox (ferramenta): Framework modular criado para integrar agentes autônomos a um mundo de jogo e permitir que interajam, cooperem ou compitam.
• Erina Karati (pessoa): Palestrante da apresentação e ex-engenheira da Microsoft e da Supercell.
• Supercell (empresa): Empresa onde foi desenvolvido o Project Paradox, em seu laboratório de inovação em IA.
• Microsoft (empresa): Empresa na qual Erina Karati trabalhou anteriormente como engenheira.
• auto research (conceito): Ciclo experimental que executa cenários, analisa traces, avalia resultados e propõe mudanças controladas às políticas dos agentes.
• RAG (conceito): Abordagem usada para dar suporte à memória de cada agente por meio de recuperação de informações.
• cenários controlados (conceito): Situações de teste definidas para medir comportamentos específicos de agentes ao longo de interações.
• scorecard comportamental (conceito): Conjunto de métricas que avalia diferentes dimensões do comportamento e reduz o risco de otimizar apenas um resultado.
• Andrej Karpathy (pessoa): Pessoa mencionada pela palestrante como responsável por publicar uma proposta de auto research que despertou o interesse da equipe.

Tradução completa (pt-BR)

00:12 Olá, pessoal. Sou Arena, ex-engenheira da Microsoft e da Supercell. Hoje quero falar sobre pesquisa automática em uma vila de IA multiagente. Vou usar um jogo como o AI Village como exemplo recorrente, mas a questão mais ampla é algo com que muitos engenheiros de IA estão começando a se deparar: como avaliamos e aprimoramos agents que mantêm estado por um longo período?

00:43 Antes de entrar na camada de pesquisa automática, quero falar um pouco sobre o Project Paradox. Desenvolvemos o Project Paradox no laboratório de inovação em IA da Supercell. Minha colega de equipe, Natural Money, e eu construímos um framework modular de IA que permite a qualquer desenvolvedor integrar agents autônomos inteligentes a um videogame, onde podem interagir, competir ou cooperar com outros jogadores ou agents, além de colocá-los, ah, e transformá-los

01:16 em companheiros dinâmicos de jogo. Para dar exemplos do que esses agents podem fazer: eles podem se movimentar com intenção. Podem ir a qualquer lugar ou pessoa e são guiados pelas próprias memórias, emoções ou curiosidade. Esses agents podem interagir com o mundo. Podem pegar objetos e deixá-los em qualquer lugar, além de terem consciência do contexto do próprio ambiente, como os objetos ou outros personagens e agents. Eu

01:49 também gostaria de observar que os desenvolvedores de jogos podem adicionar novas ações para esses agents realizarem dentro do nosso framework. Em vez de apenas deixar ou, ah, colocar objetos em algum lugar, os agents também podem, obviamente, reagir ao que está acontecendo ao redor deles. E esses eventos que acontecem ao redor também afetam suas próprias crenças e emoções em tempo real. E, claro, não estaria completo se os agents não pudessem iniciar conversas, certo? Nesse

02:23 cenário, os agents podem se aproximar de outros agents ou até mesmo do jogador, e isso faz o jogo parecer mais vivo. E, claro, essas conversas são armazenadas na memória deles e são de acordo com as próprias, hum, emoções e crenças ou objetivos deles também. E, no conjunto, esses agents formam nosso framework multiagente. É, sim, só um segundo.

02:57 Então, a arquitetura foi projetada intencionalmente para manter estado. A primeira parte importante era a memória por agent. Cada agent tem seu próprio namespace de memória, apoiado por RAG. Assim, as memórias não se misturavam entre os agents. Segundo, acompanhávamos as emoções como um pequeno vetor. Então, depois de um evento ou conversa, o sistema podia atualizar valores como alegria, tristeza, medo, raiva

03:27 ou nojo. Terceiro, os agents tinham pontuações de crença em relação aos outros agents e ao jogador. Dá para pensar nisso como uma matriz de confiança. Basicamente, depois que ocorre uma interação, o LM decide se a pontuação de confiança deve subir, cair ou não mudar. E, quarto, cada memória recebe uma pontuação de importância. Para explicar melhor: digamos que você tenha jantado alguns dias atrás; provavelmente

03:58 não se lembraria do que comeu no jantar, certo? Mas, se alguém tivesse sido assassinado alguns dias atrás, com certeza você se lembraria. Então, o agent avaliará — ou o LM avaliará — a importância de um evento e, se ela ultrapassar um limite, armazenará aquela memória específica em um cache separado, para que o contexto importante possa ser recuperado melhor mais tarde. E aqui está um exemplo disso funcionando. Vamos pedir a uma das

04:34 personagens que faça um piquenique conosco. Aqui, nossa personagem Blossom decide pegar um doce e ir até a área de piquenique, porque pedimos que ela fizesse isso. Lembre-se de que, durante a conversa, em segundo plano, ela planeja toda essa sequência de ações para realizar a tarefa. E, quando falarmos com ela depois, também responderá de acordo com o contexto. É. Mas foi aí que um problema interessante

05:09 começou de fato. Como vocês viram no último exemplo, para uma jogabilidade de curto prazo, nossa arquitetura funcionou muito bem. Uma personagem podia elaborar um plano, se movimentar, conversar e se lembrar da interação recente, além de responder a nós ou a outras personagens. Mas, em horizontes mais longos, foi aí que notamos que a consistência social começava a enfraquecer. Neste exemplo, um agent espalha para outro agent um boato sobre uma promoção de

05:41 mangas, e esse agent recebe a informação e vai contar a outro agent. Mais tarde, depois de vários acontecimentos no intervalo, quando o jogador pergunta a um dos agents sobre as mangas, ele não armazena exatamente o contexto que esperávamos ou não nos dá o contexto que queríamos. E é aí que as coisas naturalmente começam a ficar confusas. O sistema talvez se lembre do assunto geral, mas perca a

06:15 origem do assunto. Um boato pode virar uma certeza, em vez de continuar sendo apenas um boato: o agent pode apresentá-lo como um fato ou, hum, um agent pode saber um fato, mas não conseguir executá-lo — não conseguir se lembrar dele ao elaborar um plano de ações. Então, a pergunta passou a ser: como aprimoramos um sistema multiagente em comportamentos sociais de longo prazo, e não apenas em uma resposta? Foi aí que quisemos incorporar a pesquisa automática. Como todos sabem, alguns

06:50 meses atrás, Karpathi publicou sobre pesquisa automática, e isso nos deixou imediatamente muito curiosos. Talvez pudéssemos fazer o sistema executar experimentos em si mesmo; será que também poderíamos usar isso no nosso sistema? Então, entendemos que, em vez de ajustar manualmente um prompt ou assistir a uma demonstração bonita, poderíamos definir uma suíte de cenários, executar os agents, coletar traces, pontuar o comportamento e

07:22 alterar uma pequena parte da política, mantendo apenas as mudanças que realmente melhorassem a pontuação. E é aqui que estamos tentando conectar o Project Paradox à pesquisa automática. Então, neste ponto, nosso framework multiagente, o Project Paradox, funciona mais como uma bancada de laboratório, e a pesquisa automática se torna o ciclo experimental em torno dele. E, o que é importante, isso não diz respeito apenas a aprimorar a recuperação de RAG. A perspectiva mais ampla é otimizar o protocolo dos agents

07:54 — como os agents escrevem memórias, recuperam-nas, comunicam incerteza, atualizam a confiança, atribuem fontes e refazem seus planos diante de novos fatos. Basicamente, é, sim, nesse contexto, ah, sim, nesse contexto, a pesquisa automática não é outro agent na vila. Como eu disse, é um metassistema fora da vila. Os moradores têm perspectivas locais

08:26 — claro, eles só sabem o que viram, ouviram, lembraram ou inferiram, porque não existe um banco de dados de memória compartilhado entre eles. A informação só se propaga quando outros agents a comunicam adequadamente. A camada de pesquisa automática tem uma função diferente aqui. Ela lê os traces completos de uma execução, compara o que acontece com a verdade de referência do cenário, pontua o comportamento e propõe uma mudança restrita

08:59 no protocolo dos agents ou na política cognitiva. Depois, executa o cenário novamente e pergunta: o comportamento no nível da sociedade melhorou? Essa é a mudança fundamental que estávamos buscando. Então, não avaliávamos mais uma resposta. Avaliávamos uma execução inteira. E é assim que seria um dos ciclos. Primeiro, definimos um cenário de controle, sobre o qual vou falar um pouco mais adiante. Por exemplo, um

09:32 agent aprende um fato público ou ouve um boato. Isso poderia ser um cenário controlado. Depois, executamos a simulação. Durante a execução, coletamos traces estruturados, observações, conversas, direitos de memória, recuperações, atualizações de crenças, tudo o que for relevante para nós naquele caso. Depois, pontuamos esse comportamento. A informação se espalhou como esperávamos? A atribuição da fonte foi preservada? Por exemplo, o agent se lembra de quem começou

10:06 o boato? A incerteza permaneceu como incerteza? Os agents agiram com base no que realmente sabiam? E então a camada de pesquisa automática propõe uma pequena mudança na política. Isso é importante. Ela não deve reescrever o aplicativo inteiro, claro. Deve editar apenas uma parte controlada da política e, então, executamos novamente. Se a pontuação melhorar e as proteções forem mantidas, ficamos com a melhoria; caso contrário, simplesmente revertemos a mudança.

10:43 E, falando em cenários controlados, o motivo pelo qual o projeto dos cenários importa é que, caso contrário, o comportamento social é um pouco vago. Em geral, no sentido de que, se você simplesmente deixar os agents do nosso ambiente vagarem por aí, talvez pareça legal e você tenha interações interessantes, mas é muito difícil avaliar se o sistema realmente melhorou. É por isso que nós

11:13 Acredito que precisamos de cenários controlados. Por exemplo, um cenário poderia testar a disseminação de um fato público. Digamos que o agent A descubra que a padaria vai fechar amanhã. Os agents certos ficam sabendo? Eles se lembram de quem disse o quê? Eles mudam seus planos com base nesse fato? Outro cenário poderia testar a incerteza de um rumor. Digamos que o agent A ouça que o agent

11:43 C talvez vá embora da vila. Quando esse rumor se espalha, “talvez vá embora” de repente vira “está indo embora” ou continua sendo “talvez vá embora”? Quer dizer, vira um fato ou continua sendo um rumor? Outro cenário poderia testar o replanejamento. O grupo tem um plano, mas um agent descobre, digamos, que a rota que pretendiam seguir está bloqueada. Os agents atualizam essa informação e a comunicam uns aos

12:14 outros para evitar um plano inadequado ou ações desatualizadas? A questão não é que esses cenários específicos sejam universais. O que estamos tentando dizer é que o comportamento de agents em horizontes longos precisa de conjuntos de cenários. E, voltando ao nosso exemplo das mangas, depois de executar um dos nossos ciclos de pesquisa automática, desta vez após um longo período, quando o jogador finalmente perguntou a um dos agents sobre

12:48 a promoção das mangas, descobrimos que, dessa vez, o agent conseguiu responder com base no contexto, em comparação com a última vez. Para esta palestra, acreditamos que a fórmula exata é menos importante do que o formato do quadro de avaliação. Não queremos uma única métrica vaga, como “qualidade do agent”. Isso

13:20 esconderia todas as falhas interessantes. Em vez disso, queremos um quadro de avaliação equilibrado. Para a disseminação, vocês poderiam medir o alcance: quantos agents sabem do fato após determinado número de etapas. Para a proveniência, mediriam a retenção da fonte entre os agents que sabem do fato: quantos se lembram de onde ele veio, e assim por diante. Para rumores, poderiam medir a preservação da incerteza e a taxa de rumores falsos. Para o planejamento, poderiam medir a consistência das ações e o tempo para replanejar. E, para a privacidade, poderiam medir o

13:55 confinamento da informação. Isso importa porque otimizar apenas uma métrica pode gerar um comportamento ruim. Por exemplo, se vocês otimizarem apenas a disseminação, os agents podem aprender a compartilhar tudo em excesso. E, se otimizarem apenas a recuperação de memórias, podem acabar criando memórias ruidosas ou desatualizadas. Portanto, esse quadro de avaliação é o que mantém o sistema honesto e impede que o agent de pesquisa automática manipule o sistema para simplesmente aumentar uma métrica específica.

14:32 A outra lição importante de engenharia que aprendemos nesse projeto é que é importante manter bem pequena a superfície editável. A camada de pesquisa automática não deve ter permissão para reescrever aleatoriamente toda a base de código. Em vez disso, é muito importante congelar o harness, os cenários e as métricas. Assim, expomos apenas a parte do sistema que realmente queremos otimizar. No Project Paradox, isso significava coisas como a política de gravação de memórias, a política de recuperação, o prompt de comunicação, as regras de crença e confiança, a atribuição de fontes, os gatilhos de replanejamento e assim por diante.

15:06 Isso dá ao processo de busca espaço para melhorar o comportamento, mas também impede que ele manipule diretamente a avaliação, como mencionamos antes. E essa é a diferença entre o LM escrever patches aleatórios e o LM realmente buscar dentro de um espaço controlado de políticas.

15:40 E aqui estão exemplos do tipo de mudança que eu gostaria que esse tipo de ciclo buscasse. Se a atribuição da fonte desaparecer, a mudança na política poderia ser preservar a fonte na memória e registrar as fontes nas memórias e nos resumos. Se os rumores se transformarem em fatos, a mudança na política poderia ser armazenar uma marca de confiança, distinguir informações de primeira e segunda mão e exigir que o agent use ressalvas ao repetir afirmações incertas. Se os fatos públicos continuarem restritos a grupos locais, a mudança na política poderia ser classificar

16:15 os fatos públicos úteis de outra forma e fazer com que os agents compartilhem proativamente evidências importantes sobre as fontes. O ponto principal é que essas são pequenas mudanças no protocolo do agent, mas podem ter efeitos maiores no comportamento da sociedade em sistemas multiagentes. Também é aqui que quero ter cuidado com o que afirmamos, porque, sem resultados repetidos dos ciclos de controle, eu não diria que o sistema simplesmente melhorou de modo geral. Estamos tentando dizer que esse é o tipo certo

16:51 de superfície para expor a um ciclo de pesquisa automática, porque é pequena o bastante para ser controlada, mas ainda rica o bastante para mudar, pelo menos até certo ponto, o comportamento social. E talvez a maior lição para mim tenha sido que a memória não basta. Você pode adicionar uma memória RAG a um agent e ainda assim não obter o comportamento de longo prazo que estava buscando. Isso porque às vezes os agents precisam saber de onde veio aquela informação.

17:28 É preciso preservar se a informação veio de primeira ou de segunda mão, se foi verificada ou se é incerta. Às vezes, também é preciso separar as memórias episódicas brutas daquilo em que o agent acredita no momento. E é preciso testar o comportamento por meio de cenários, não apenas com base em impressões. A outra lição é que a reversão também não é opcional. Ao otimizar o comportamento social, uma mudança pode melhorar uma coisa e prejudicar outra. Portanto, uma política que espalha fatos públicos mais

17:59 rapidamente também pode vazar informações privadas. Uma política que aumenta a recuperação de informações também pode aumentar o uso de memórias desatualizadas. Assim, o ciclo deve funcionar como uma catraca: testar uma mudança, avaliá-la e mantê-la apenas se o quadro de avaliação melhorar e as proteções continuarem funcionando. E acreditamos que isso não se aplica apenas a agents de jogos, porque, embora eu tenha dado um exemplo usando uma vila de jogo, acreditamos que, por exemplo,

18:32 agents de suporte precisam saber de onde vem cada atualização de política e se ela substitui uma resposta anterior. Assistentes pessoais, por exemplo, precisam se lembrar dos compromissos que assumiram anteriormente e fazer correções se o usuário quiser alterá-los. Agents de pesquisa precisam de citações de proveniência, tratamento de contradições e atualização de hipóteses. Agents de programação precisam manter o contexto por longos períodos entre

19:03 issues, arquivos, colegas de equipe e requisitos que mudam. Agents de workflow precisam de controles de acesso, transferências de responsabilidade e replanejamento quando o mundo muda. Todos esses sistemas têm o mesmo problema fundamental: mantêm um estado ao longo do tempo. E esse estado afeta as ações futuras. Por isso, estamos propondo cenários controlados e quadros de avaliação comportamental. Então, para resumir, uma receita para agents de longo

19:35 horizonte. Se há uma receita prática que eu gostaria que vocês levassem daqui, é: congelem o harness, definam cenários, registrem traces, avaliem o comportamento e exponham apenas uma pequena superfície de políticas. Busquem entre essas mudanças e mantenham apenas as que resistirem às medições. Acreditamos que esse é um padrão de engenharia que faz sentido para agents de longa duração. Acreditamos que a verdadeira pergunta é:

20:06 em execuções controladas, o sistema se comporta melhor? Para concluir, o Project Paradox começou como uma tentativa de fazer agents de jogo parecerem vivos em um mundo 3D. Mas, para nós, o problema mais profundo de engenharia não era a animação nem o diálogo. Era o estado: qual agent sabe o quê, qual agent contou a quem, o que é verdadeiro, incerto ou desatualizado, e se os agents agem com base naquilo de que se lembram. O Otter Research nos deu uma maneira de abordar isso de forma um pouco mais

20:41 sistemática. Não confiando em uma única demonstração nem ajustando prompts manualmente sem parar, mas executando experimentos controlados e mantendo apenas as mudanças que resistiram às nossas medições. Agents de longo horizonte precisam de experimentos, não apenas de prompts. Espero que essa seja a mensagem que vocês levem desta palestra. E, sim, entrem em contato conosco. Adoraríamos conversar se vocês tiverem alguma dúvida. Muito obrigado por ouvirem. É isso.

Transcrição original

[00:12] Hi everyone, I’m Arena, former engineer at Microsoft and Supercell. And today I want to talk about auto research in a multi- aent AI village. I will use a video game like AI Village as a running example here, but the broader question is one I think many AI engineers are starting to run into. How do we evaluate and improve agents that carry state over a long period of time?

[00:43] Before I get into the auto research layer, I want to talk a bit about project paradox. We developed project paradox at supercell’s AI innovation lab. Me and my teammate are natural money. We built a modular AI framework that allows any developer to plug in intelligent autonomous agents within a video game that can interact, compete or cooperate with other players or agents as well and place them uh and make them

[01:16] into dynamic game companions. Now to give examples of what these agents can do, the agents can move with intent. They can go to any location or person and they’re guided by their own memories, emotion, or curiosity. These agents can interact with the world. They can pick up objects, drop them anywhere, and they’re also aware about the context in their own environment, such as the objects or other characters or agents as well. I

[01:49] would also like to note that game developers can also add new actions for these agents to accomplish within our framework as well. Instead of just dropping or uh placing objects, agents can also obviously react to what’s happening around them. And these events that happen around them affect their own beliefs and emotions on the fly as well. And of course, it wouldn’t be complete if agents can’t start conversations, right? agents can in this

[02:23] scenario approach other agents or even the player as well and this makes the game feel more alive. And of course these conversations are stored within their memory and is according to their own um and affect their own emotions and beliefs or goals as well. And al together these agents make our multi- aentic framework. Um yeah yeah one second

[02:57] so the architecture was intentionally stateful behind this. The first important part was per agent memory. Each agent has its own memory namespace backed by rag. So memory did not bleed between agents. Second, we tracked emotion as a small vector. So after an event or conversation, the system could update values like joy, sadness, fear, anger,

[03:27] or disgust. Third, agents had belief scores towards other agents and the player. You can think of this as a trust matrix. Basically like after the interaction happens, the LM basically decides whether the trust score should go up, down, or whether it shouldn’t change at all. And fourth, every memory receives an important score. Um to to explain this better, like let’s say you had dinner a few days ago, you probably

[03:58] wouldn’t remember what you had for dinner, right? But um if someone was murdered a few days ago, you definitely remember that. So the agent will evaluate or the LM will evaluate uh an important score of an event and if it crosses a threshold, it will store that specific memory uh in a separate cache so that important context can be retrieved better later on. And here’s an example of it just working. Um, we going to ask one of the

[04:34] characters to go on a picnic with us. Here, uh, our character Blossom um, decides to pick up a pastry and go to the picnic area because we asked her to do so. Keep in mind during the conversation in the background, she plans all of these sequence of actions to accomplish. And one when we talk to her afterwards, she will also reply within context as well. Yeah. But this is where an interesting problem

[05:09] actually started. As you saw in the last example, like for shortterm game play, this our architecture worked pretty well. like a character could make a plan, move around, talk and remember the recent interaction and respond to us or other characters as well. But over longer horizons, this is where we notice the social consistency start to get weaker. So in this example, we have one agent spreading a rumor about a sale on

[05:41] mangoes to another agent and that agent receives that information and goes and tells another agent about it. Later on, after a number of events that occurred in between, when the player asks one of the agents about the mangoes, it doesn’t exactly store that context that we were expecting or it doesn’t give us the context that we kind of wanted to. And this is where things are starting to get messy naturally. Like the system may remember the rough topic but lose the

[06:15] source of the topic. A rumor may become certain instead of just a rumor like the agent might state it as a fact or um an agent might know a fact but fail to execute fail to remember it while creating a plan for its actions. So the question here became how do we improve a multi-agentic system over longunning social behavior and not just over one response. And this is where we wanted to bring in auto research. As you all know, uh few

[06:50] months ago, Karpathi posted out auto research and this this made us immediately very curious. Uh perhaps we can make the system run experiments uh on itself and can we use this for our system as well. So what we understood is instead of manually tuning a prompt or watching one nice demo, we could define sen a scenario suit, run the agents, collect traces, score the behavior and

[07:22] change a small policy surface and only keep the changes that actually improve the score. And this is where we’re trying to bridge project paradox with auto research. So at this point basically our multi-agentic framework project paradox is more like a lab bench and auto research becomes the experimental loop around it. And importantly this is not only about improving rag retrieval. The broader framing is optimizing the agent protocol

[07:54] like how do agents write memories, retrieve them, communicate uncertainty, update trust attribute sources and replan around new facts. basically um yeah in this context uh oh yeah in this context art research is not another agent in the village like I said it’s a meta system outside the village the villagers have local

[08:26] perspectives of course they only know what they saw heard remembered or inferred because there isn’t a common memory database in between them. Information only travels once uh other agents communicate them properly. The auto research layer has a different job here. It reads the full traces of a run, compares what happens against the scenario ground truth, uh scores the behavior and proposes a constrained

[08:59] change to the agent protocol or cognitive policy. Then it reruns the scenario and asks society level behavior like did society level behavior get better. This is the key shift we were trying to look for. So we were no longer evaluating one answer. We were evaluating an entire run. And this is what one of the loops would look like. Like first we define a control scenario which I’ll elaborate a bit more about later. For example, one

[09:32] agent learns a public fact or one agent hears a rumor. Uh that could be a controlled scenario. Then we run the simulation. During the run, we collect structured traces, observations, conversations, memory rights, retrievals, belief updates, whatever is relevant to us in that case, we collect. Then we score this behavior. Did the information spread as we expected it to? Did the source attribution survive? Such as, does the agent remember who started

[10:06] the rumor? Did uncertainty stay uncertain? Did agents act on what they actually knew? And then the auto research layer here proposes a small policy change. And this is important. It should not rewrite the whole application of course. it should only edit a controlled policy surface and then we rerun. If the score improves and the guardrails hold, we we keep the improvement and if not we simply just revert back.

[10:43] And talking about controlled scenarios, the reason why uh scenario design matters is that social behavior is otherwise a bit fuzzy. uh in general in the sense if you just let the agents in our environment wander around it might look cool and you might get nice interactions but it’s actually very hard to evaluate on whether the system actually improved. So this is why we

[11:13] believe you need controlled scenarios. For example, one scenario could test a public fact diffusion. Let’s say agent A learns uh the bakery will close tomorrow. Do the right agents learn it? Do they remember who said what? Do they rem do they change their plans based on this fact? Another scenario could test rumor uncertainty. Agent let’s say agent A hears that agent

[11:43] C might leave the village. When this rumor spreads, does might leave suddenly become is leaving or does it stay as might leave? Like does it become a fact or does it still stay as a a rumor? Another scenario could test replanning. The group has a plan, but one agent learns, let’s say, the route they wanted to take is blocked. Do agents update this and communicate this uh with each

[12:14] other to avoid uh a improper plan or scale actions? The point is not that these exact scenarios are universal here. The point we’re trying to make is that long horizon agent behavior needs scenario suits. And talking about our Mango example again, after running one of our auto research loops, this time after uh a a long pro period of time, when the player finally asked one of the agents about

[12:48] the sale on mangoes, we did find that u the the agent was able to respond within context this time like compared to last time. Um yeah and for this talk the form the exact formula we believe is less important than the shape of the scorecard. Uh you do not want a single vague met metric like agent quality. This will

[13:20] hide all the interesting failures. Instead you want a balanced scorecard. For diffusion, you might measure reach like how many agents know the fact after end steps. For provenence, you measure source retention among agents who know it. How many remember it, where it came from, etc. For rumors, you can measure uncerny preservation and false surn rate. For planning, you can measure action consistency and time to replan. And for privacy, you can measure

[13:55] containment. This matters because optimizing only one metric can create bad behavior. Because let’s say if you only optimize for diffusion, the agents may learn to overshare everything. And let’s say if you only optimize for memory recall, you might create noisy or steal um like memories. So this scorecard is what keeps the system honest and prevents the auto research agent from gamifying the system to just increase one specific score.

[14:32] The other important engineering lesson that we learned over this project is that um it’s important to keep the editable surface really small. The auto research layer should not have permission to randomly rewrite the whole codebase. Instead, it’s really important to freeze the harness, the scenarios, and the metrics. So, we’re only exposing the part of the system that we actually want to optimize. Here in project paradox for

[15:06] us that meant things like memory writing policy, retrieval policy, communication prompt, belief, trust rules, source attribution, replanning triggers, etc. This gives the search pro process room to improve behavior, but also prevents it from gaming the evaluation directly as we mentioned before. And this is the difference between the LM writing random patches versus the LM actually searching within a controlled policy space.

[15:40] And here are here are examples of the kind of changes I want this kind of loop to search over. If if source attribution disappears, the policy change might be preserve source in memory and uh write uh memory rights and summaries. If rumors harden into facts, the policy change might be stored confidence mark firstand versus secondhand and require hedging when retelling uncertain claims. If if facts if public facts stay local, the policy change might be classify

[16:15] useful public facts differently and make agents proactively share important source evidence. The key is that these are small changes to the agent protocol, but they can have larger effects on a society level behavior for multi-agentic systems. This is also where I kind of want to be careful about our claims here because with we believe without repeated current loop results like I wouldn’t say the system just generally improved. We’re trying to say this is the right

[16:51] kind of surface to expose to an auto research layer uh loop because it is small enough to control but it’s still rich enough to change the social behavior to some extent at least. And the biggest lesson for me perhaps was that memory is not enough here. You can add a rag memory to an agent and still not get the current long-term uh horizon behavior that you were looking for. Um because agents need to sometimes know where that information came for uh

[17:28] came from. You need to preserve whether it was firsthand, secondhand, verified or uncertain. Sometimes you need to separate raw episodic memories from what the agent currently believes too. And you need to test behavior through scenarios not not just through vibes. So the other lesson is that uh roll back also is not optional. When you optimize social behavior, a change can improve one thing and damage another. So, a policy that spreads public facts uh

[17:59] faster might also leak private information. A policy that increases recall might increase stale memory usage. So, the loop should basically be like a ratchet. Try a change, score it, keep it only if the scorecard improves and guard rails whole. And we we definitely believe this is not only relevant for game agents cuz although I gave you an example using a game village um we believe like let’s

[18:32] say for example support agents support agents need to know which policy update comes from where right and whether it supersedes an older answer. Personal assistants for example need to remember commitments that they previously made and h make corrections if uh if the user u wants to change those personal commitments. Research agents need pro uh provenence citations contradiction handling and hypothesis updates. Coding agents need longunning context across

[19:03] issues, files, teammates and changing requirements. Workflow agents need access controls, handoffs, and replplanning when the world changes. All of these systems have the same underlying problem. They maintain state over time. And that state affect affects future action. So they need control scenarios and behavioral scorecards is what we are proposing. So again in brief, a recipe for long

[19:35] horizon agents. If there’s one practical recipe I want you to take away, freeze the harness, define scenarios, log traces, score behavior, and expose only a small policy surface. Search over these changes, keep only changes that survive your measurement. And this is an engineering pattern that we believe would uh make sense for longunning agents. The real question we believe is

[20:06] across controlled runs, does the system behave better? To close, project paradox start as an attempt to make game agents feel alive in a 3D world. But the deeper engineing problem was not animation or dialogue for us. It was the state such as which agent knows what, which agent told whom, what is true, uncertain or outdated, and do agents act on what they remember. Otter research. Otter research gave us a way to approach this a bit more

[20:41] systematically. Not by trusting one demo and not by endlessly handtuning prompts, but by running control experiments and keeping only the changes that survived our measurement. Long horizon agents need experiments and not just prompts. And I hope that’s the takeaway that you get from this talk. And yes, please do connect with us. We’d love to talk if you have any questions. Thank you so much for listening. Yeah.