AI Engineer NYC 2026: IA aplicada a finanças, agentes e sistemas em produção

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: AI Engineer NYC Livestream | Bridgewater, Anthropic, Two Sigma, Arize, Coatue, Nous, Gen. Intuition · Canal: AI Engineer · 7:37:38 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Avaliação e benchmarks de IA, Cibersegurança e segurança de software, Infraestrutura e hardware de IA

Resumo

A conferência reúne engenheiros e líderes para discutir como levar IA à produção em instituições financeiras e outros setores regulados. As palestras abordam plataformas de dados, agentes com autonomia controlada, evals, modelos de transações, infraestrutura de GPU e ferramentas internas. Também exploram como redesenhar processos de trabalho, equilibrar determinismo e julgamento e construir sistemas que aprendam com os próprios resultados. No encerramento, os palestrantes discutem investimento, modelos para interação com ambientes físicos e a importância de plataformas open source.

Pontos-chave

• A Bridgewater apresenta o Vault, uma plataforma que organiza dados não estruturados para uso por investidores e agentes, com atenção a fontes, períodos e contexto interno.
• Na Two Sigma, controles para agentes são tratados como meios de viabilizar autonomia segura: registro, avaliação de risco, limites de acesso, evals compartilhadas e decisões de autorização em runtime.
• A qualidade de código importa conforme a durabilidade do software; práticas de engenharia rigorosas podem ser reduzidas em ferramentas descartáveis e isoladas.
• Empresas financeiras descrevem agentes que acompanham sinais, preservam estado ao longo de dias e coordenam a participação de pessoas em fluxos de trabalho.
• A autorização baseada em intenção busca relacionar cada ação do agente à missão, às políticas e ao contexto, em vez de depender de permissões amplas e permanentes.
• O modelo de transações da Wells Fargo é pré-treinado do zero em dados tabulares para apoiar tarefas como detecção de fraude, com aplicações posteriores em outras áreas.
• Especialistas de negócio podem criar skills confiáveis se ensinarem seus processos, definirem limites, testarem casos reais e mantiverem responsáveis pela revisão.
• Avaliações realistas ajudam a comparar modelos pelo custo e pela qualidade do trabalho, além de orientar escolha de ferramentas, limites de uso e fine-tuning.
• Para construir ferramentas internas úteis, não basta gerar código: padrões de interface, consistência, autosave, atualizações otimistas e verificação ponta a ponta fazem diferença.
• A adoção de IA traz vantagem quando as empresas escolhem problemas de alto valor, compartilham capacidades e incorporam aprendizados aos processos.

Capítulos

Início	Capítulo	Resumo
00:24	Abertura da conferência	A organização apresenta o evento e seu foco em engenharia de IA para serviços financeiros.
23:44	Dados e controles para agentes	Bridgewater apresenta o Vault, e Two Sigma discute como equilibrar autonomia, segurança e governança.
1:00:16	O trabalho do AI engineer	A Arize descreve um ciclo de traces, evals e correções, seguido pela apresentação de um modelo de transações da Wells Fargo.
1:53:30	Agentes em fluxos financeiros	A Arca explica como agentes acompanham tarefas de clientes ao longo do tempo e coordenam ações com pessoas.
2:16:25	Autorização baseada em intenção	Um painel discute missões, permissões em runtime, identidade de agentes e controle de ações em comércio e serviços financeiros.
3:00:12	Skills criadas por especialistas	Um planejador financeiro apresenta um método sem código para criar, testar e manter skills, antes de uma demonstração dos riscos de agentes superprivilegiados.
3:34:58	Vazamentos por temporização em GPUs	A palestra descreve como um co-tenant pode inferir características e atividade de um LLM observando variações de latência.
4:02:29	Ontologias e transformação de dados	A Subridge defende ontologias construídas conforme a decisão e explica como modelos podem otimizar pipelines de dados.
4:39:27	Infraestrutura para agentes	Flywire apresenta sua plataforma interna, e a Modal detalha sandboxes, armazenamento e recursos necessários para agentes escaláveis.
5:06:59	Evals e custo dos modelos	A palestra aborda benchmarks realistas, infraestrutura de avaliação e uso de evals para escolher modelos e controlar gastos.
5:36:55	Modelos open source em produção	A Revolut relata ganhos de produtividade e compartilha práticas para hospedar modelos open source em GPUs dedicadas.
6:02:01	Como organizações constroem vantagem	A palestra destaca a escolha de problemas relevantes, capacidades compartilhadas e aprendizado acumulado como fontes de vantagem.
6:42:29	Retomada e introdução ao bloco final	O mestre de cerimônias retoma a programação e convida o público a usar as palestras como ponto de partida para conversas.
6:47:47	IA aplicada a investimentos	A Coatue descreve um framework que combina contexto externo e interno para apoiar decisões de investimento.
7:02:01	Modelos de pixels para ações	A General Intuition apresenta modelos que observam imagens em tempo real e produzem ações para jogos, computadores e robôs.
7:21:21	Plataformas open source e encerramento	A Nous Research defende construir sobre bases abertas, e a organização encerra o dia e anuncia a programação seguinte.

Citações

O que é preciso para um agente funcionar é o contexto certo e o entendimento certo do que está acontecendo no seu mundo. — 23:14

Por que os carros têm freios? Não é só para parar. É para poder ir rápido e parar com segurança. — 42:26

Qualidade de código importa para software durável. E precisa ser cara? Não. — 59:44

Não pergunte se seu sistema deve ter mais ou menos autonomia. Pergunte onde fica o limite. — 4:38:13

Em um mundo de abundância, o recurso escasso é o julgamento. — 6:06:11

Conceitos e entidades

• Vault (ferramenta): Plataforma da Bridgewater que organiza dados não estruturados e os disponibiliza para pesquisa humana e uso por agentes.
• Agent registry (conceito): Registro que torna agentes identificáveis e documenta seus responsáveis, ferramentas, endpoints e finalidade.
• intent-based authorization (conceito): Abordagem de autorização que considera a missão e o contexto da ação para decidir o que um agente pode fazer em runtime.
• Token exchange (conceito): Mecanismo para trocar tokens e conceder acesso delegado e limitado a recursos durante uma ação.
• Lethal Trifecta (conceito): Combinação de acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa que pode ampliar os riscos de um agente.
• Transaction foundation model (modelo): Modelo transformer pré-treinado do zero em dados de transações de clientes da Wells Fargo para servir de base a tarefas financeiras.
• Signal (ferramenta): Agente da Arize que analisa traces e telemetria para identificar problemas e, quando configurado, propor correções.
• Hankwave (ferramenta): Harness apresentado pela Subridge para executar trabalho de dados com interfaces estáveis, checkpoints, rollback e controle de orçamento.
• Hermes Agent (repo): Agente open source apresentado pela Nous Research como uma base que organizações podem executar e modificar sob seu próprio controle.
• General Intuition (empresa): Empresa que desenvolve modelos capazes de observar frames e produzir ações para interagir com jogos, computadores e robôs.
• Modal (empresa): Plataforma de infraestrutura para aplicações de IA, incluindo sandboxes, ambientes de execução e recursos de computação.
• Arca (empresa): Empresa de serviços financeiros que descreve o uso de agentes para conduzir fluxos de trabalho de longo horizonte.
• Bridgewater (empresa): Empresa de investimentos que desenvolveu o Vault para integrar dados não estruturados ao seu processo de pesquisa.
• Two Sigma (empresa): Hedge fund apresentado na palestra sobre controles de segurança e governança para agentes em organizações reguladas.
• Aparna Dhinakaran (pessoa): Cofundadora e chief product officer da Arize AI que fala sobre agentes, telemetria e evals.

Tradução completa (pt-BR)

00:24 Bom dia e boas-vindas ao AI Engineer New York 2026. Estamos muito felizes por ter vocês conosco enquanto damos início a um evento de grandes ideias, perspectivas afiadas e muito conteúdo relevante que atravessa o ruído. Para abrir oficialmente o evento nesta manhã, recebam no palco a gerente-geral de AI Engineers, Leah McBride. Olá. Oi. Bom dia a todos e sejam bem-vindos

00:56 a [música] Nova York. Este é nosso terceiro evento em Nova York. Tivemos dois em 2025, com alguns dos melhores palestrantes que já tivemos no AI Engineer. Estamos muito animados por voltar. Então, em meu nome e no de Swix, sejam todos muito bem-vindos. Obrigada por participarem hoje. Esperamos que vocês tenham ótimos dias. Como sabemos, há pouquíssimos lugares como a cidade de Nova York, onde grandes ideais ganham escala muito, muito rapidamente. É onde a IA de fronteira

01:26 se encontra com instituições financeiras globais centenárias e onde várias economias diferentes prosperam juntas. Estamos animados com a programação incrível. Vocês vão ouvir alguns dos melhores palestrantes do mundo, como em todos os nossos eventos. Teremos pessoas — teremos trilhas em finanças, liderança em engenharia, evals e LLM. Temos Parad Dinaran. Vou acertar esse nome. Da Arise. Temos Max Cana

01:58 Alexander, da Capital One, e Tariq Shikat, da Sonar. Esses são apenas alguns dos incríveis palestrantes que teremos esta semana. Quero agradecer muito à Arise, nossa patrocinadora principal. Vocês podem conhecer a equipe deles na área de exposição a qualquer momento desta semana. Então, dediquem-se ao aprendizado aqui. Dediquem-se também a fazer conexões. Há muitas pessoas aqui compartilhando ideias. Elas querem conversar sobre as ideias, querem desafiá-las e querem

02:29 colaborar também. Então, não deixem de conversar com o maior número possível de pessoas: participantes, palestrantes e todos os patrocinadores. Esperamos ver vocês novamente em breve. Temos uma ótima programação. Teremos outro evento, o Cold Summit, em São Francisco, em novembro, e depois teremos Londres em fevereiro. E, claro, a World’s Fair. Também teremos alguns outros eventos novos no ano que vem. Então, fiquem de olho na agenda, mas tenham dias maravilhosos. Muito obrigada. Até mais.

03:03 E agora, recebam no palco o mestre de cerimônias de hoje, sócio-diretor da 10X, Alex Lieberman. E aí, pessoal? Como estão? Isso aí. Antes de começarmos oficialmente, quero me apresentar e fazer uma pergunta rápida. Sou Alex Lieberman. Sou um dos cofundadores e sócios-diretores da 10X. Somos uma empresa de IA aplicada que trabalha com empresas da Fortune 500

03:33 para se tornarem nativas em IA. Antes disso, cofundiei uma empresa chamada Morning Brew, que torna as notícias de negócios um pouco menos chatas. Minha pergunta é: quem aqui é, levantem a mão, saudavelmente viciado no X, antes conhecido como Twitter? Certo, tem muita gente mentindo aqui. Passo bastante tempo no X. E uma das razões pelas quais passo tanto tempo lá é que sinto que posso viver no futuro. Certo? Quando

04:04 vocês estão, quando estão rolando a tela no X, quando estão vendo os comentários na plataforma, sentem que estão vendo o que se tornará consenso em 3, 6 ou 12 meses. E o que adoro nesta conferência, e por que fico tão animado para vir todos os anos, é que ela quase parece o X com esteroides. Há um conceito que um amigo me contou há algum tempo, chamado edge city. E edge city é a ideia de que, a qualquer momento, em algum lugar do mundo,

04:37 há um grupo de pessoas vivendo no futuro em uma determinada função ou especialidade. E, para mim, esta conferência é como se todos estivéssemos vivendo em edge city, no que se tornará consenso nos próximos seis meses a dois anos, se pensarmos na difusão dessa tecnologia. Estou muito animado por estar aqui com todos vocês hoje. Agora, vamos ver o que vai acontecer. Antes de tudo, sejam bem-vindos ao AI Engineer New York 2026, onde a engenharia de IA encontra Wall

05:08 Street. Esta é a conferência para engenheiros e líderes técnicos que estão desenvolvendo IA em produção nos setores bancário, de hedge funds, fintech, seguros e gestão de ativos. Nos próximos dois dias, ouviremos empresas e líderes que estão estimulando discussões não apenas sobre modelos, agents, infraestrutura, ferramentas para desenvolvedores e evals, mas também sobre como esses elementos se entrelaçam com o setor financeiro e o moldam, impactando hedge funds, investidores, bancos, seguros, fintech e segurança. [fungada] É claro

05:39 que, como todos podem ver, há muita coisa acontecendo. Organizar um encontro como este exige um enorme esforço e não seria possível sem nossos patrocinadores. Mas, antes de falar dos patrocinadores, vamos todos aplaudir bastante a equipe da AIE. O que eles fazem é incrível. [aplausos] Agora, vamos agradecer aos patrocinadores. Primeiro, a patrocinadora principal, Arise. Vamos aplaudir a Arise. [aplausos] Isso aí, Arise.

06:10 Em seguida, os patrocinadores platinum: Oracle, Sonar, Work OS e Excel. Vamos aplaudi-los. [aplausos] Depois, temos nossos patrocinadores gold. Se eu tivesse tempo suficiente, mencionaria todos. E, por fim, os patrocinadores silver. Mas esperem, tem mais: os patrocinadores de apoio. Ótimo. Então, vamos começar com a primeira palestra principal do dia. Temos duas pessoas incríveis da Bridgewater que

06:41 lidam diariamente com os detalhes da IA em produção. Vamos aplaudi-los. Sejam bem-vindos, pessoal. [aplausos] >> A seguir, temos o prazer de receber dois palestrantes da Anthropic. Uma salva de palmas para Belinda Neil, diretora-geral de serviços financeiros, e Keon Shahab, arquiteto de IA aplicada.

07:12 [risos] Estamos esperando os slides. Pronto. Bom dia a todos. Sou Sam Green, líder da equipe de IA aplicada da Bridgewater Associates, e este é meu colega, Aaron Linsky. Hoje, vamos falar sobre o Vault, a plataforma de dados que construímos na Bridgewater para transformar dados não estruturados

07:42 em um ativo de primeira classe no nosso processo de investimento. Nesta palestra, queremos compartilhar três lições que aprendemos ao construir o Vault. A primeira é que humanos e agents têm necessidades muito diferentes em relação a uma plataforma de dados. Por isso, é preciso desenvolvê-la separadamente para atender a essas diferentes necessidades. A segunda é que o maior impacto acontece quando uma única ferramenta consegue atender às duas necessidades ao mesmo tempo. E a terceira é que o verdadeiro prêmio está em construir os alicerces necessários para tornar

08:13 os agents participantes proativos do seu processo de investimento, ou do que quer que você esteja fazendo com suas ferramentas, em vez de ferramentas reativas para seus humanos usarem. Antes de me aprofundar no Vault, queria começar com um pouco de contexto sobre a Bridgewater. Nos últimos 50 anos, a Bridgewater tem buscado constantemente o melhor entendimento possível de como os mercados e as economias funcionam e transformá-lo em uma codificação sistemática que possamos usar para testar nossa lógica sob estresse ao longo

08:45 do tempo. O que começou como um conjunto de regras do tipo “se… então…” em um bloco amarelo evoluiu para um processo de composição contínua, com humanos no centro, sempre procurando o próximo fator que está mudando nos mercados. Mais recentemente, temos trabalhado na construção do associado de investimento artificial, que coloca uma máquina no centro desse processo contínuo. Ao longo de todas essas fases de evolução, mantivemos uma filosofia constante: queremos observar continuamente como o mundo está mudando e o que está acontecendo no

09:17 mundo. Perceber quais dinâmicas ainda não estão codificadas em nosso entendimento e usar esse aprendizado para melhorar e acumular conhecimento para o futuro. Durante a maior parte da história da Bridgewater, isso significou construir e supervisionar modelos de séries temporais com dados estruturados. Esses dados estruturados precisavam ser cuidadosamente preparados para que pudessem ser usados com segurança em nosso processo de pesquisa e alinhados à nossa ontologia interna e ao nosso modelo do mundo, para que pudéssemos tirar grande proveito do uso dos dados que

09:48 que tínhamos construído. Com o surgimento dos modelos de linguagem, tivemos uma enorme nova oportunidade de interagir com um universo muito mais amplo de dados: notícias e pesquisas, transcrições, documentos de políticas e todas as conversas internas que antes ficavam apenas no éter. Ou seja, os memorandos internos, as transcrições de reuniões e os debates que aconteciam dentro da empresa. Percebemos rapidamente que todos esses dados precisavam exatamente do mesmo tratamento para estarem prontos para uso. Era preciso limpá-los cuidadosamente, governá-los e deixá-los

10:20 prontos para uso tanto em perguntas de pesquisa pontuais feitas hoje quanto em nossos estudos sistemáticos ao longo do tempo. Quando analisamos o panorama de fornecedores de dados e plataformas de dados, não havia nada que nos oferecesse todo o controle necessário para criar e manter nossa vantagem em dados. Por isso, construímos o Vault, nosso repositório de dados não estruturados externos e internos, e a plataforma que indexa

10:50 organiza e deixa tudo pronto para ser usado por nossos investidores humanos e agents. Hoje, o Vault tem mais de 100 milhões de documentos, com milhares de novos documentos adicionados todos os dias, minuto a minuto, de 135 fontes externas — e esse número continua crescendo —, além de todos os dados de dentro da Bridgewater. E, o que é crucial, esses dados não são simplesmente despejados nas mesas dos nossos investidores. Eles são cuidadosamente alinhados à nossa ontologia interna, com enriquecimentos como países,

11:21 conceitos, mercados e, o mais importante, períodos. Vamos discutir um exemplo bastante básico e representativo de uma pergunta de investimento feita a um cliente de chat corporativo. Perguntei: “Como o investimento em infraestrutura de IA está impactando o won coreano e os participantes do mercado esperam que isso continue?”. E, como todos vocês certamente sabem, o agent acessa a

11:52 web e procura recursos que possa usar, porque pedi explicitamente que encontrasse as perspectivas de outras pessoas sobre a questão. Como podem ver, ele se aprofunda e encontra 15 recursos para usar antes de me devolver a resposta. Quando examinei a resposta mais de perto, algumas coisas me chamaram a atenção. A primeira é que, embora tenha encontrado 15 fontes aparentemente relevantes, usou apenas uma ou duas para responder à minha pergunta. E

12:23 a segunda está no final da resposta, onde o próprio agent reconhece que não respondeu à minha pergunta. Ele não encontrou documentos suficientes na web aberta para estabelecer um consenso do mercado e atender aos parâmetros que eu defini. Quando investiguei ainda mais, o problema ficou pior. Uma das notas que ele usou principalmente para responder à minha pergunta havia sido publicada em julho de 2026. Embora eu tenha feito essa pergunta e obtido essa resposta apenas

12:53 no final da semana passada, no início de outubro. Na era da IA e dos investimentos, quatro meses é muito tempo. Nem de longe é bom o suficiente usar esse recurso para responder à minha pergunta. Quando faço exatamente a mesma consulta com o Vault conectado, acontece algo totalmente diferente. Primeiro, a conexão com o Vault ajuda a orientar o agent para que procure um período específico ao responder à minha pergunta. Então, ele se concentra no período de 1º a 8 de outubro. Encontra uma variedade muito

13:25 maior de recursos: 52 documentos candidatos relevantes para a consulta nesse período específico, graças ao corpus muito mais amplo do Vault, com conteúdo relevante para perguntas sobre investimentos. E, quando finalmente responde à minha pergunta, usa sete documentos em vez de apenas um ou dois e me dá uma resposta detalhada, que o agent tem mais confiança de que atenderá à minha pergunta. Então, para nós, essa é a grande lição da construção do Vault que serve de motivação para a conversa de hoje: são necessários dados de qualidade e os conectores certos para que os agents tenham impacto. E agora vou passar a palavra a Aaron, para falar sobre algumas das lições de engenharia de produto que aprendemos ao construir o Vault.

13:56 Obrigado, Sam. Oi, sou Aaron. Lidero a engenharia na Bridgewater. Vou apresentar algumas das lições que aprendemos ao construir o Vault nos últimos anos. Vou começar com algo que pode parecer óbvio, mas que ainda acho importante dizer: a busca é difícil,

14:26 mas fica ainda mais difícil quando estamos projetando para dois tipos diferentes de usuários. Neste caso, estamos projetando para humanos e agents. Vou explicar a diferença, começando por nós. Humanos precisam de precisão e de uma alta proporção entre sinal e ruído, porque só conseguem ler até certo ponto. Mesmo um leitor rápido dá conta de cerca de 300 palavras por minuto. Eu, pessoalmente, leio bem mais devagar. Agents são um tipo diferente de leitor. São muito menos sensíveis à precisão. Se os dados estiverem lá, eles vão encontrá-los. E, basicamente, tudo o que você lhes entregar

14:58 será levado em conta. Eles escalam muito rápido e consomem conteúdo cerca de 100 vezes mais depressa: 30 mil palavras por minuto. Por isso, precisamos construir o Vault para os dois. Ao pensar nas dimensões importantes, temos estas cinco aqui no quadro: revocação, precisão, filtragem, permissões de acesso e escala. Algumas importam para as pessoas, outras importam mais para os agents, e muitas importam para ambos. Vou me aprofundar em três delas: precisão para as pessoas, escala para os agents e filtragem para ambos.

15:29 Precisão: depois que preenchermos o nosso Vault — o que foi um esforço hercúleo das nossas equipes de dados e jurídica —, a revocação deixou de ser uma preocupação urgente. No entanto, a reclamação número um era: “A busca do Vault é ruim”. Como responsável pelo produto, é doloroso ouvir isso, mas minha resposta foi: “Vamos avaliar”. E foi o que fizemos. Reunimos perguntas e encontramos manualmente os melhores documentos

15:59 incluindo aqueles que pareciam úteis, mas não eram. No total, foram cerca de 200 exemplos, e levamos menos de uma semana. Não foi divertido nem muito glamoroso, mas foi muito útil. Depois que executamos a avaliação, ficou bem claro que a busca era ruim. A métrica principal que analisamos foi a precisão nos 10 primeiros resultados: entre os 10 primeiros, quantos eram os documentos certos? Estávamos em cerca de 60%. Então, as pessoas tinham razão: era ruim. Mas agora

16:30 tínhamos uma maneira de medir todas as melhorias. Aqui no quadro estão cinco delas. Quando terminamos a busca agentic, chegamos a algo entre 90% e 95% de revocação nos 10 primeiros resultados, ou de precisão nos 10 primeiros resultados. Certo, isso foi sobre precisão. Agora, filtragem. Como qualquer pessoa, queremos os documentos mais relevantes. Mas, ao analisar os traces de produção, vimos que quase sempre havia alguma condição: uma data específica, uma fonte específica

17:01 ou um ativo específico. Tudo isso exige filtragem avançada, e foi aí que encontramos nosso primeiro grande problema de desempenho. Vou explicar rapidamente; esta parte é um pouco técnica. Classicamente, há duas maneiras de filtrar um banco de dados vetorial. A filtragem posterior usa primeiro o índice vetorial e, em seguida, filtra os principais resultados por metadados. É rápida, mas a revocação pode ser bem baixa, porque os resultados mais relevantes globalmente talvez

17:32 não correspondam aos filtros. Do outro lado, temos a pré-filtragem, em que filtramos primeiro e depois calculamos as distâncias para cada correspondência. A vantagem é que a revocação é muito boa, mas pode ser muito lenta, e precisávamos de algo intermediário. Foi isso que nos levou a testar e, por fim, mudar para o Turbopuffer. A abordagem deles, que chamam de filtragem nativa, examina apenas os clusters mais próximos que contêm correspondências e pontua somente esses. O resultado é algo tão rápido quanto a filtragem posterior, mas com uma revocação próxima à da

18:04 pré-filtragem. Por último, vou falar sobre escala. Para nós, a escala humana é bem modesta: 100 consultas por hora. Temos 300 usuários. Eles fazem buscas de vez em quando. Leva minutos para nossos usuários lerem os documentos que recebem. Os agents, por outro lado, estão algumas ordens de grandeza além disso. Facilmente, mais de 100 consultas por segundo. Enxames de agents podem chegar facilmente a milhares, e obviamente eles vão ler, assim como

18:34 Eu disse antes que leria documentos em segundos. Então, também precisávamos de algo que pudesse escalar. E, de novo, o turbuffer lidou com isso com facilidade. Assim, cobrimos as cinco dimensões. Não falei sobre permissões, mas vou falar disso mais tarde, hoje. Mas cobrimos tudo. Isso desbloqueou novos workflows, mas não mudou a forma como nossos pesquisadores trabalhavam. Eles ainda não iam ao Vault toda manhã. E essa é minha segunda lição para compartilhar aqui: por mais incríveis que sejam as ferramentas, não podemos simplesmente colocá-las nas mesas dos nossos

19:05 investidores e esperar que sejam usadas. Precisamos migrar os hábitos antigos deles para uma nova forma. Então, analisamos o que eles já faziam. Muitos viviam no email. As pesquisas chegavam diretamente dos corretores. Eles tinham listas de assinatura. Tinham regras que filtravam tudo para pastas. Funcionava. Era familiar. E eles sabiam que não estavam deixando nada passar. Então, tivemos que incorporar todos esses recursos ao Vault. Foi exatamente o que fizemos. Tudo pode ser pesquisado. As

19:36 listas de assinatura viraram buscas salvas, e as pastas viraram coleções salvas. São os mesmos hábitos, só que em um novo lugar. E, depois que os usuários estavam lá, podíamos abrir espaço para novos hábitos. Então, podemos perguntar — eles podem fazer perguntas sobre todos os dados, como Sam mostrou. Podem acompanhar feeds dinâmicos por tópico. E podem entregar essas coleções aos agentes para que tomem outras providências. Foi então que ficou claro que tínhamos product-market fit. E, quando alcançamos esse fit, os usuários quiseram isso em todos os lugares. Então, colocamos no chat. Criamos um aplicativo para celular. Está no Slack

20:08 e na IDE deles. E, claro, também disponibilizamos tudo isso para os agentes. Incluindo uma CLI, porque agentes adoram CLIs. E a principal pergunta aqui é: certo, o que isso possibilita? Simon vai falar sobre o que estamos desenvolvendo agora, mas, antes de tudo, isso nos ajuda a avançar mais rapidamente pelo ciclo de pesquisa com nosso analista de bolso, que é nosso primeiro analista de IA. Ele pode fazer… pode fazer horas. Pode fazer horas de pesquisa em apenas alguns minutos, por alguns dólares.

20:39 E isso depende do Vault. Agora estamos expandindo essa capacidade com o researcher, a próxima geração. É a mesma ideia, estendida ao longo de dias ou semanas. Também conseguimos treinar modelos personalizados para raciocinar de forma mais inteligente sobre os dados do Vault e usá-los junto com outros modelos de base para alimentar processos sistemáticos de tomada de decisão. O forecaster é o nosso primeiro, e gera previsões relevantes para a macroeconomia com IA. E também criamos sinais de investimento a partir do Vault

21:10 que transformam dados não estruturados em estratégias estruturadas e negociáveis. Agora vou passar a palavra a Sam para apresentar o recurso mais recente do Vault. Como mencionei no início da apresentação, o verdadeiro prêmio é poder transformar agentes de um recurso reativo, pronto para responder às perguntas de uma pessoa, em participantes proativos que ajudam a direcionar nossos profissionais de alto valor para as áreas mais importantes nas quais devem concentrar sua atenção. E

21:42 a maneira como estamos resolvendo esse problema é com uma experiência que chamamos de investor workbench, em que o agente está sempre ativo, acompanhando o que é importante para aquele investidor e apresentando as áreas que mais precisam da atenção dele. A experiência é assim: ela usa o Vault, propõe um tópico e apresenta várias informações para que o investidor decida se deve investigar mais a fundo ou ignorar completamente aquele tópico. Aqui vocês podem ver o cartão que

22:12 um investidor vê para decidir se deve investigar mais a fundo a mesma questão sobre o impacto da IA nas moedas que analisamos antes na apresentação. O investidor recebe tudo de que precisa: um resumo gerado pelo agente, caso queira examinar rapidamente as descobertas do agente. Também recebe as evidências exatas usadas pelo agente, para que possa avaliar por conta própria o que levou àquela recomendação. E, se decidir investigar mais a fundo, tem uma conexão direta com o resultado da pesquisa das ferramentas analíticas que Aaron acabou de descrever. E, quando

22:44 investiga mais a fundo, junto com o agente, as dinâmicas que impulsionam essa questão, os aprendizados são registrados automaticamente, e os resultados da colaboração também são registrados automaticamente no Vault. Para nós, essa é a lição principal. O Vault possibilita a acumulação de conhecimento porque coloca as evidências certas — as informações internas e externas certas — ao alcance dos investidores e dos agentes, e registra automaticamente a síntese que eles produzem, colocando-a

23:14 de volta no corpus para a próxima rodada. Isso nos faz percorrer o ciclo mais rápido e melhor. E, ao voltar à pergunta com que começamos: o que é necessário para fazer um agente funcionar? O contexto certo e o entendimento certo do que está acontecendo no seu mundo. Então, nossa pergunta para vocês é: sua IA sabe o que está acontecendo no mundo? E ela se lembra do que sua empresa aprendeu sobre isso? Porque nós também estamos ensinando a nossa. E, se isso parece um desafio empolgante, adoraríamos conversar. Obrigado.

23:44 [aplausos] >> [música] >> E agora, para explorar como organizações sérias podem acelerar a inovação sem comprometer a confiança, recebam John Feminella, vice-presidente sênior de arquitetura da Two Sigma.

24:23 Olá, pessoal. Certo, deixei minha água equilibrada precariamente ali. Meu nome é John Feminella. Trabalho com arquitetura e engenharia de IA na Two Sigma, um hedge fund aqui em Nova York. Antes de avançar muito, tenho um slide de aviso legal que preciso mostrar a vocês, com duas informações. Primeiro: prometo não vender, comercializar nem oferecer nenhum título financeiro em nenhum momento desta apresentação. Segundo: tudo o que eu disser é minha opinião, não a opinião da Two Sigma. Certo? Obrigado por me ouvirem. Se eu não disser essas palavras mágicas,

24:54 os microchips 5G implantados em mim vão explodir. Então, na verdade, esse slide é um bom exemplo de como nosso setor é regulamentado. E, como empresa regulamentada, com muitos controles, acho que é sempre interessante explorar o que acontece quando os controles falham, porque isso dá uma boa ideia do motivo pelo qual eles existem. Então, gostaria de contar uma história sobre isso, mostrando outro slide de aviso legal. Depois de agosto de 2020, uma cláusula contratual muito interessante começou de repente

25:24 a aparecer em vários contratos de empréstimo comercial. Essa cláusula tenta essencialmente impedir que uma determinada situação aconteça. É complicado, mas vou explicar assim. Digamos que você tenha um negócio de barraca de limonada e tome dinheiro emprestado de um credor para capitalizar sua barraca. E o banco que supervisiona essa transação, que fica entre o tomador e o credor, envia ao credor todo o dinheiro que você deve, por um erro catastrófico. Você provavelmente ficaria irritado e pediria o dinheiro

25:55 de volta, mas o credor também poderia dizer: “Não, obrigado. Você nos pagou, está tudo certo, então preferimos ficar com o dinheiro.” Algo assim aconteceu em agosto de 2020. A Revlon, empresa de cosméticos, havia tomado dinheiro emprestado por meio de um grande empréstimo a prazo firmado em 2016. Esse empréstimo foi dividido em várias partes entre mais de 300 credores: hedge funds, fundos de crédito, CLOs e outros bancos. No meio estava o City Bank, o agente administrativo. Ser o agente nesse tipo de transação significa cuidar da infraestrutura que conecta os tomadores

26:25 aos credores e administrar o ciclo de vida do empréstimo. Então, nessa transação, a Revlon paga ao City, e depois o City paga aos credores. O City não está emprestando o próprio dinheiro. Está apenas no meio, movimentando o dinheiro de outras pessoas. Este era o plano para 11 de agosto de 2020: a Revlon pagaria cerca de 8 milhões de dólares de juros acumulados aos dois grupos, e o principal dos credores seria transferido para essa nova linha de crédito. Isso é uma troca de títulos, não de dinheiro. Então, o principal restante dos credores permaneceria inalterado. A ideia era que apenas os juros

26:56 deveriam sair. O principal não deveria se mover. E o banco tinha um software interno de processamento chamado Flex Cube. Não é um nome divertido para um software empresarial? No Flex Cube, a maneira mais fácil de fazer esse tipo de transação é registrá-la como se a Revlon estivesse quitando o empréstimo inteiro; isso aciona os cálculos corretos dos pagamentos de juros para todos. Vocês provavelmente conseguem adivinhar o que vai acontecer em seguida. Então, a parte do principal deveria ser enviada para uma conta interna de compensação que pertence ao banco

27:26 como banco, para que seja contabilizado e registrado corretamente, mas nunca saia do perímetro do banco. Então, fique de olho nessa conta transitória. O que deveria ter acontecido é que as caixas rotuladas como front, fund e principal deveriam incluir o número da conta transitória e todas deveriam ter uma caixa de seleção marcada ao lado. Então, infelizmente, descobriu-se que era isso que precisava acontecer. Mas, por vários motivos obscuros, as caixas não estavam marcadas. E embora o Flex Cube exibisse uma notificação de alerta dizendo: “Opa, o dinheiro está prestes a

27:57 sair do banco. Tem certeza de que quer fazer isso?” Isso estava correto. O dinheiro deveria sair do banco porque eles estavam fazendo os pagamentos de juros. Então, os três aprovadores que deveriam aprovar aquilo olharam e disseram: “Sim, é isso mesmo que deveria acontecer.” E, embora a notificação de alerta tenha aparecido, os operadores humanos que estavam realizando a transação a ignoraram. Lembrem-se, a Revlon estava fazendo aquele pagamento de juros. Então, o principal nunca foi para a conta transitória e, em vez disso, o Flex Cube enviou o valor total do principal ainda devido do empréstimo aos cerca de 300 credores: US$ 900

28:27 milhões, em vez de US$ 8 milhões. Então, cada credor recebeu o valor que teria direito a receber se a Revlon tivesse quitado o empréstimo integralmente. Mas a Revlon não queria quitar o empréstimo. Queria ficar com o dinheiro. Foi um ótimo negócio para os credores, porque, lembrem-se, a Revlon estava em dificuldades na época. Então, seus empréstimos não estavam sendo negociados pelo valor de face. E receber todo o seu dinheiro de volta em um negócio que você achava que valia apenas 60 centavos por dólar é um ótimo negócio para você. Então, eles não queriam devolver o dinheiro, mesmo depois que o Citi ligou e disse: “Por favor, isso foi um erro. Devolvam o dinheiro.” E o argumento deles era: “Não deveríamos ter que devolver o dinheiro

28:58 porque vocês nos pagaram integralmente.” E é assim que os empréstimos funcionam. Em algum momento, você os paga de volta. E só porque vocês pagaram em um momento diferente do previsto, isso não significa que não devamos ter que devolver o dinheiro agora. E, para impedir que isso acontecesse, os contratos de empréstimo comercial em todos os lugares começaram a incluir uma cláusula como aquela. Então, o que um erro de pagamento em um banco tem a ver com agents de IA? Bem, o banco tinha esse procedimento. Tinha esses controles e todo mundo fez o que achava que era certo. Esse é o problema sobre o qual quero falar no restante desta palestra. Todos os dias, estamos dando autonomia de verdade a agents de verdade

29:28 sobre sistemas como o Flex Cube. E como evitamos acidentes como aquele sem bloquear tudo ou simplesmente torcer para termos sorte e eles não acontecerem? Então, aqui está o cerne da questão. Não dá para saber de antemão o que um agent vai fazer, certo? São sistemas não determinísticos. E isso parece assustador até você lembrar que os seres humanos também são sistemas não determinísticos e que eles também vão cometer erros. Então, a maioria das empresas não decide dizer: “Bem, para reduzir o risco de os seres humanos cometerem um erro, vamos trancá-los em salas e impedir que conversem entre si, e todos vão

29:59 conferir o trabalho uns dos outros, certo?” Nós lhes damos certa autonomia junto com certo nível de controles. Estabelecemos limites e visibilidade, e os equipamos com sistemas e controles que lhes permitem fazer seu trabalho com eficácia. Então, nesse tipo de modelo, segurança e inovação não são extremos opostos de um espectro entre os quais você precisa fazer uma concessão. São coisas que você pode ter ao mesmo tempo. Então, acho que dá para ficar com o melhor dos dois mundos. E, quando pensamos nos controles que queríamos aplicar aos agents, também analisamos algumas abordagens que não funcionaram para nós. Você não quer colocar tudo em sandbox ou bloquear tudo, porque uma

30:30 sandbox sem acesso real aos sistemas é segura, mas não é muito interessante nem útil. Se você deixar os agents fazerem o que quiserem, isso talvez seja poderoso e libertador do ponto de vista cognitivo, mas o isolamento é muito fraco e essa abordagem geralmente não é adequada para empresas altamente regulamentadas. E, se você tiver apenas documentos de políticas que os agents consultam ou que fazem parte da especificação do prompt, isso também não é muito aplicável em tempo de execução. Você não pode garantir que isso fará parte dos controles de

31:01 aplicação das regras. Então, o que funcionou para nós foi pensar na combinação de controles que nos daria segurança e inovação ao mesmo tempo. Como estabelecemos limites e evitamos problemas sem impedir que as pessoas trabalhem corretamente? Temos vários desses controles, mas hoje vou falar de cinco deles. Quando digo controles, refiro-me às barreiras de proteção e aos recursos compartilhados que permitem que as equipes avancem sem atrapalhar o que estão tentando fazer. E não queremos chegar a um abismo que precisemos

31:32 atravessar para que as pessoas possam fazer seu trabalho e, depois, fazer todo mundo esperar enquanto construímos uma ponte para chegar lá. Esses controles são combináveis. Cada um faz uma coisa e, juntos, permitem que executemos agents com autonomia de verdade e um nível adequado de segurança. O primeiro problema é que os agents estavam surgindo em toda parte. Temos grandes equipes com muitos agents em execução. Temos equipes pequenas com alguns. Temos pessoas trabalhando com coisas de maneira descontrolada. E eles aparecem em todos os formatos. Podem ser chatbots aleatórios.

32:03 Podem ser servidores NPC conectados à força num Frankenstein de hot pod. Podem ser experimentos legais em notebooks. Podem ser ferramentas web realmente úteis para as pessoas, mas é difícil responder a algumas perguntas simples quando você olha para isso: quem é o responsável? A quais ferramentas tem acesso? O que deveria estar fazendo? O que não deveria estar fazendo? E, se você não consegue responder a esse tipo de pergunta, se não consegue governá-los, também não consegue reutilizá-los de verdade. Então, você fica tentado a criar várias soluções para o mesmo problema se não souber o que já existe. E aí a empresa também não consegue

32:35 governá-los de uma forma compreensível. Uma coisa que algumas empresas fazem nesse caso é adicionar algum tipo de barreira, como: não deixe nada funcionar até que tudo esteja registrado, aprovado e tenha passado por esse processo extremamente oneroso. Isso parece seguro, mas, se você observar o efeito sobre o trabalho, toda ideia — até mesmo um experimento simples em notebook — vai ficar na fila atrás de algo realmente arriscado. E não queremos submeter todas as pessoas que oferecem uma variedade de agents exatamente ao mesmo processo. Então, a maioria das pessoas vai

33:05 desistir ou simplesmente ser empurrada para um caminho menos governado de TI paralela, que é menos visível, e aí não conseguimos ver nada. Isso motivou o primeiro controle: um registro de agents. Você não pode governar o que não consegue ver. Então, o registro de agents torna os agents compreensíveis e registra, recupera e permite descobrir os fatos principais sobre eles que queremos conhecer. São coisas como as ferramentas que declaram, os endpoints com que vão se comunicar, a qual produto pertencem, quem é responsável por eles, e humanos, outros programas e outros agents podem

33:37 então usar o registro de agents para decidir o que está disponível na empresa, se isso é útil para eles e para usá-lo como fonte de verdade para outras perguntas. Isso não exige esforço extra da sua parte. Simplesmente acontece quando você usa uma das estruturas aprovadas pela empresa para criar agents. O registro é feito automaticamente. Todas essas informações são registradas ali para você. E, se quiser fazer um registro manual, certamente pode. Então, o segundo problema é que, agora que temos todos esses agents fazendo todo tipo de coisa, percebemos rapidamente que o que eles estão fazendo é realmente

34:09 diferente. E isso significa que [fungada] nossos agents apresentam riscos bem diferentes, certo? Então, algo que resume tickets do Jira ou do Linear é muito diferente de um agent de deploy em produção que pode interagir com um sistema em execução. E, se usarmos — se tentarmos usar — o mesmo processo de revisão para abranger todos esses agents, cada agent vai ficar esperando na mesma fila por semanas até passar pela revisão humana. E, se as pessoas começarem a contornar processos lentos, acabaremos na mesma situação de antes. Então, mais uma vez, você pode se sentir tentado a dizer que a resposta é algo como uma revisão manual realmente detalhada

34:40 e rigorosa por todas essas diferentes partes interessadas. Mais uma vez, isso parece seguro, mas agora temos um simples sumarizador esperando dois meses pelas mesmas aprovações que um agent que interage com sistemas de produção. E a maioria das boas ideias para agents, as que trazem valor logo de cara, começa como pequenos experimentos. E você não quer que essas pessoas esperem na mesma fila que as coisas que estão interagindo com a produção desde o início. Então, os revisores ficam sobrecarregados com solicitações de baixo risco, e as de alto risco precisam dividir a mesma atenção. Então, nós

35:10 não queremos abrir mão dessa velocidade, se pudermos evitar. Então, mais uma vez, nem todo agent precisa da mesma revisão, e a maioria dos agents é criada para um propósito específico, em vez de ser de propósito aberto. E, quando digo “de propósito aberto” aqui, você pode imaginar coding agents como pi ou Claude Code: quando você os abre e começa a digitar, o Claude Code ou o pi não sabem o que você está prestes a pedir. Eles não delimitam sua finalidade de nenhuma maneira específica. Mas a maioria dos agents implantados nas empresas tem propósitos bem específicos. Quando você interage com esse agent, é para fazer algo específico, bem conhecido e

35:42 bem compreendido. Então, eles têm um motivo muito específico para existir e uma finalidade bem delimitada. E você consegue distinguir esses agents uns dos outros observando o que eles declaram de antemão: suas ferramentas, os endpoints que acessam, os controles aplicados a eles, etc. O terceiro problema é que, quando você conhece seus agents e o que eles estão fazendo, logo percebe que muitos agents não se comunicam entre si — ou, melhor, não se comunicam com uma única coisa nem de uma única maneira. Quanto mais aberto for o propósito do agent — quanto mais ele se parecer com o Claude Code ou o pi —, mais

36:15 coisas diferentes e variadas ele poderá fazer. Chamar uma API interna, executar uma ferramenta como uma pesquisa na web, esse tipo de coisa. E [fungada] cada uma dessas ações abre uma porta diferente para um tipo diferente de risco. E, se você conceder a um agent uma permissão para uma conta de função, ele poderá causar muito mais dano do que algo que só vai ler uma página pública da web, por exemplo. Então, a questão não é se esse agent pode fazer X, mas qual é o nível de granularidade de que precisamos para que o agent atue com sucesso. E, mais uma vez, uma resposta tentadora é

36:46 ser meio rigoroso demais aqui ou dar a todos os agents a mesma lista curta de permissões, com coisas seguras para fazer, e bloquear todo o resto. Isso é seguro, mas também é inútil. Um agent que não pode pesquisar, chamar uma API ou fazer qualquer uma dessas coisas sem pedir autorização a alguém não consegue realmente fazer o trabalho para o qual foi criado. E então as equipes ou desistem desses agents ou encontram uma maneira de contornar o bloqueio, e ambos os resultados têm um custo. Portanto, um bloqueio amplo e indiscriminado de tudo abre mão da inovação que queremos preservar e evita

37:18 tomar uma decisão de verdade sobre o risco. E, como escreveu o autor John Shed: “Um navio está seguro no porto, mas não é para isso que os navios servem”. Então, a solução aqui é permitir que os agents declarem sua finalidade de antemão e digam quais ferramentas vão usar ou precisam acessar. Então, na segunda coluna aqui, podemos dizer que um sumarizador de pesquisa terá permissão para usar uma ferramenta da web para acessar pesquisas, mas, no caso de um agent de deploy de releases,

37:48 não vamos permitir que ele faça isso, porque não há motivo para usar essa ferramenta. Então, se ele tentar solicitá-la, não terá acesso por padrão. Não precisamos tomar esse tipo de decisão para cada ferramenta. Os agents só precisam dizer quais ferramentas querem, certo? E você, como autor do agent, está na melhor posição para dizer: “Preciso destas quatro coisas entre as 500 disponíveis”. Então, a maneira de aplicar isso é fazer com que, quando os agents forem executados em nossos ambientes gerenciados, consultem o registro de que falamos antes para verificar

38:20 quais políticas se aplicam a eles no momento da inicialização. E essa política é traduzida em regras aplicáveis, como quais endpoints você tem permissão para acessar, quais hosts você tem permissão para acessar e quais outros tipos de recursos estão ou não disponíveis para você. Desse modo, ninguém precisa abrir um ticket toda vez que precisa alterar o acesso. Ninguém precisa falar com a equipe de TI nem com outro grupo de fora da sua equipe. Desde que você esteja em conformidade com a pontuação de risco de que falamos antes e esteja no registro de agents, você está sob governança. Você está

38:51 aprovado. É assim que mantemos realmente baixos os custos para as equipes desenvolverem, implantarem e executarem agents, e a mesma arquitetura de controle funciona em vários contextos. A próxima coisa que percebemos foi que as equipes estavam criando muitas maneiras diferentes de avaliar agents, e cada stack era diferente; algumas equipes não criavam nada. Às vezes, você cria uma stack bem detalhada para verificar como seus modelos funcionam. Às vezes… às vezes não há nada. E, em geral, acho que ficaríamos incomodados se as equipes não escrevessem testes de unidade, certo? E consideramos evals mais ou menos a mesma coisa. Se os modelos estão mudando, isso é como uma dependência em tempo de execução da sua aplicação. E, se o seu agent vai mudar de modelo, você não vai saber como ele se saiu nem qual é a qualidade dos resultados sem evals. Então, mais uma vez, uma resposta tentadora aqui é criar algum tipo de metodologia central de avaliação que exija uma suite completa de evals e a aprovação de um comitê. Mas aí cada ajuste de prompt, cada alteração de uma linha

39:21 testes, certo? E consideramos evals meio que a mesma coisa. Se os modelos estão mudando, isso é como uma dependência de runtime que sua aplicação tem. E, se seu agent vai mudar de modelo, ele não sabe como se saiu sem evals das saídas e da qualidade dessas saídas. Então, novamente, uma resposta tentadora aqui é: vamos ter algum tipo de metodologia central de avaliação que aguarde uma suíte completa de evals e a aprovação de um comitê. Mas agora cada ajuste de prompt, cada mudança de uma linha é

39:51 vai ficar na mesma fila. Então, não queremos colocar mais decisões nas mãos de mais revisores para esse tipo de coisa. Não queremos abrir mão dessa capacidade de iterar. Mais uma vez, você não lançaria um software sem testes de unidade. Os agents precisam de avaliações pelo mesmo motivo. E queremos fornecer, no nível da empresa, os recursos que serão iguais para todos. A equipe A escrevendo evals e a equipe B escrevendo evals terão muitos recursos em comum. Então, queremos uma abordagem compartilhada para fazer evals, e queremos que essa abordagem compartilhada seja administrada pela empresa e

40:22 esteja disponível para todos fazerem suas evals. Assim, cobrimos todas as partes comuns das evals. Tudo o que você precisa fazer é escrever o que é verdadeiro sobre o seu agent. E, por fim, talvez você já tenha passado pela experiência de pedirem que aprove muitas e muitas ações individuais de agents quando há uma pessoa no loop. Isso funciona em pequena escala, mas, quando você opera agents em paralelo ou em produção, a situação se torna completamente insustentável, e as solicitações de revisão chegam mais rápido do que qualquer pessoa conseguiria aprovar. E, depois das

40:53 primeiras vezes que isso acontece, você sucumbe à fadiga de revisão: começa a ver “sim, sim, sim, sim, sim” e, eventualmente, clica em “sim” em algo que, sabe, ativou a bomba nuclear. Então, você não quer clicar em “sim” por reflexo, mas isso vai acontecer inevitavelmente. Um exemplo recente disso ocorreu no início deste ano: uma diretora de um laboratório de pesquisa em IA pediu ao agent open claw que sugerisse e-mails para excluir da caixa de entrada e depois esperasse pela aprovação dela. Mas a caixa de entrada era tão grande que, por fim, o agent compactou seus contatos e perdeu a parte que dizia para esperar pela aprovação dela; então, excluiu centenas de e-mails.

41:24 e não parou quando ela mandou parar nele. Então, de novo, talvez você fique tentado a fazer um humano aprovar cada ação, mas essa não é a maneira certa de fazer isso. Uma abordagem melhor é deixar esses classificadores conservadores e independentes tomarem decisões sobre chamadas rotineiras e enviar a uma pessoa apenas as solicitações mais importantes, aquelas com maior probabilidade de fazer diferença. Se você está dizendo sim em 99,99999% das vezes, então provavelmente isso deveria ser apenas uma regra que o agent deve seguir, não uma solicitação que você precisa fazer ao humano.

41:55 E aquilo que não está claro, é ambíguo ou potencialmente perigoso, sim, apresente a um humano; ou, se for definitivamente perigoso, negue de imediato. Então, essa é uma maneira de não precisar fazer todo o trabalho de revisão o tempo todo. Queremos adotar a mesma abordagem tanto para regras explícitas: quando elas se aplicam, queremos caminhos rápidos determinísticos. Quando as regras explícitas não se aplicam e há alguma ambiguidade, queremos que um classificador faça esse trabalho. Então, juntando novamente essas cinco partes, você cria um registro. Assim, cada agent fica

42:26 visível desde o dia em que é criado. Você pontua cada agent para que a revisão humana aconteça no lugar certo. Você executa agents com proteções para que só acessem o que precisam. Você compartilha evals e métricas para que todos atinjam o mesmo padrão sem precisar reinventar a roda. E, por fim, você governa seu runtime para garantir que a classificação aconteça ali, e não em outro lugar. Então, cada um desses controles funciona em conjunto. Vou deixar vocês com uma pergunta: por que os carros têm freios? Não é só para poder parar. É para poder ir rápido e parar com segurança. Então, os controles para

42:57 nossos agents funcionam da mesma forma. Muito obrigado. Sou John Finnell e espero que vocês tenham gostado. [aplausos] Para nos ajudar a entender os princípios que faltam em torno da qualidade do código e a encontrar um caminho entre pontos de vista conflitantes, recebam Max Canat Alexander, engenheiro de software principal

43:28 da Capital 1 e autor de Code Simplicity. Certo. Então, hoje pensei em escolher um tema agradável e nada polêmico, sobre o qual ninguém tem opinião, certo? Ninguém

44:00 Ninguém falou nada sobre isso nas redes sociais, sabe? E, claro, toda opinião sobre isso nas redes sociais é muito, muito bem ponderada, sabe? As pessoas têm muita profundidade e, sabe, pensamentos muito elaborados. Talvez haja um pouco mais nisso do que simplesmente sim ou não. E, claro, se você fizer uma pergunta a um engenheiro sênior, todos nós sempre damos a mesma resposta para qualquer pergunta. A resposta favorita de todo engenheiro sênior para qualquer pergunta é: depende. Mas, francamente, essa não é uma resposta muito útil,

44:32 porque de que depende? Então, vamos começar com isto: por que a qualidade do código importou em primeiro lugar? Vejo muita gente dizer: “Bom, isso me fazia sentir bem”. Isso não é uma justificativa suficiente. Então, vamos ver se conseguimos acrescentar alguma nuance a essa conversa e ajudar todo mundo a ter pelo menos uma base para raciocinar sobre o assunto enquanto o discutimos. Vamos ver se conseguimos criar um framework. É isso que vamos tentar fazer nesta palestra. Certo. Então, vamos começar com tudo o que você quer realizar com um trecho de

45:02 software, que depende de dois fatores, e somente dois fatores: compreensão e execução com base nessa compreensão. Seja alinhar um modelo, escalar um sistema, impulsionar a adoção ou qualquer outra coisa, o sucesso de todo software é determinado por esses dois fatores. É por isso que temos coisas como debuggers, observabilidade, evals e até testes. Todas essas coisas existem, na verdade, para melhorar sua compreensão ou sua capacidade de executar com base nessa compreensão. As pessoas acham que elas existem por outros motivos, mas, fundamentalmente, existem por esse motivo. Tudo o que já fizemos na área de qualidade de código foi

45:35 exclusivamente para essas duas coisas, e somente para elas. Não é por nenhuma outra razão. E isso não tem a ver com correção ou qualquer outra coisa. Tem a ver apenas com esses dois fatores. Agora, há duas coisas que são as mais importantes de compreender se você vai ser engenheiro de software. Há outras coisas sobre software que você precisa compreender se vai trabalhar com produto ou vendas. Mas, se você é engenheiro de software, essas duas são as mais importantes. A primeira é: qual é o comportamento do sistema? Quer dizer, concretamente: não o que a documentação diz que é o comportamento do sistema, mas qual é o comportamento real do sistema? E a segunda é: como posso modificar esse comportamento de maneira correta e

46:07 segura? Certo, em um sistema muito pequeno, se você quiser entender o que o sistema faz, eu simplesmente digo o que ele faz: ele imprime “hello world”. Você diz: “Quero que ele diga ‘hi world’”. Então eu digo: “Certo, vou fazer com que ele diga ‘hi world’”. Nesse caso, há muito pouco a compreender além do que ele faz. Isso é tudo o que você precisa compreender. Mas qualquer sistema de software real é extremamente complexo. Este é um mapa real da

46:37 base de código do Chromium, o projeto open source por trás do Chrome. E, se você pensar em todas as diferentes maneiras como esses componentes podem interagir, eles têm, essencialmente, infinitos comportamentos possíveis. Eu não conseguiria descrever em palavras o comportamento do Chromium como um todo, como sistema. Mas o que posso descrever — e todos nós sabemos disso, todo mundo que já trabalha como engenheiro de software há algum tempo — são os componentes do sistema. Posso

47:08 descrever com sucesso o comportamento de um componente do sistema. Este é o analisador de URL: as funções e outras coisas do analisador de URL do Chromium. Ele identifica todas as diferentes partes da URL. E esse é o motivo de todo esse código existir. Todo o motivo de termos código, desde o início, é a estrutura. Porque, o que quero dizer com isso? Certo, os dois trechos à esquerda e à direita vão imprimir “hello

47:40 world” se forem executados em uma máquina Linux. No entanto, à esquerda, você vê “hello world”. Ele tem a identidade e a estrutura de “hello world”. À direita, você vê apenas uma série de instruções sem uma identidade específica, reconhecível ou compreensível. Não é um componente. É apenas um monte de instruções. Embora isso seja compreensível, se fossem milhões ou bilhões de linhas assim, seria muito mais difícil de entender. No passado, falamos de coisas como legibilidade, testabilidade ou conceitos sobre código que pareciam humanos. Mas

48:11 o que sempre importou mais era que o sistema tivesse algum tipo de estrutura compreensível. Então, o que realmente importa é a estrutura. E o momento em que isso mais importa é quando você quer modificar o sistema. A segunda coisa que mencionei: toda modificação em um sistema envolve duas categorias de risco. A primeira é que você introduza algum tipo de problema. E um problema não é apenas um bug. É qualquer coisa ruim que possa acontecer. Por exemplo, seu projeto pode levar

48:43 muito mais tempo do que você espera. Ele pode não se comportar da maneira que você queria para os usuários. O projeto pode fracassar porque você ultrapassou o orçamento. Qualquer tipo de problema pode acontecer simplesmente ao tentar realizar o processo de fazer essa mudança. E a segunda categoria é que você pode tornar mais difícil fazer mudanças futuras. Em particular, isso significa que você pode aumentar a probabilidade de problemas futuros. Pode aumentar o risco futuro do sistema. Essas duas coisas são causadas por problemas de compreensão. A primeira tem a ver com a dificuldade

49:15 de compreender o sistema desde o início; a segunda acontece quando você torna o sistema mais difícil de compreender. Consigo reduzir todos os relatórios pós-incidente que já li, sobre qualquer incidente, a esses dois fatores, de uma forma ou de outra. A configuração de produção era difícil demais de compreender. Alguém tornou algo impossível de compreender. Havia propriedades emergentes do sistema que eram impossíveis de compreender. Seja como for, o ponto 2 alimenta o ponto 1 em um ciclo vicioso que se acumula de forma não linear

49:46 forma. Então, a dificuldade de compreensão não cresce linearmente. Ela se acumula ao longo do tempo. Você acaba chegando a um ponto — e todos os sistemas tendem a chegar a esse ponto — em que toda modificação envolve algum tipo de problema. Alguns sistemas chegam ao ponto em que você não consegue mais modificá-los. Pense em algumas daquelas gigantescas bases de código de mainframe, com 100 milhões ou 500 milhões de linhas, em que toda mudança é algum tipo de problema. Você vê isso…

50:17 em problemas organizacionais. Você vê isso por toda parte. Vê isso nos cronogramas, seja lá onde for. E olha, há muitos argumentos de que talvez os modelos futuros resolvam isso. Talvez resolvam. Talvez os modelos futuros tenham uma capacidade infinita de lidar com a complexidade de algum jeito. Mas não precisamos discutir isso hoje, porque acho que os modelos estão fazendo outra coisa realmente interessante agora. Eles estão criando um novo tipo de software, uma nova categoria de software. Essa categoria sempre existiu, mas está prestes a se tornar 100 mil vezes mais comum do que qualquer outra…

50:50 outra forma de software: o software descartável. O que é isso? Imagine um mundo em que as consequências de uma falha no seu sistema sejam muito pequenas ou inexistentes. Imagine que pouquíssimas pessoas dependam dele e que quase nenhum outro sistema dependa daquele software. O gerenciamento de mudanças é mínimo ou inexistente. Imagine que o custo de substituição tenha caído para quase zero. Você poderia substituir tudo em horas ou dias…

51:22 e, basicamente, ele não teria custo de manutenção. Nesse mundo, a qualidade do código não importa, porque todas aquelas coisas que tentávamos evitar — os riscos que se acumulam ao longo do tempo — não existem. Tradicionalmente, sempre criamos software durável. Ele permanece em uso por anos. Milhões ou milhares de pessoas dependem dele. As consequências de uma falha são enormes, potencialmente catastróficas para os negócios…

51:53 se houver uma falha. E ele exige uma manutenção enorme. A maioria dos engenheiros de software do mundo passa a maior parte do tempo mantendo esses sistemas duráveis gigantescos. Espero que eles continuem existindo. Então, esta é uma das áreas em que acho que, às vezes, a conversa fica um pouco… Os sistemas duráveis provavelmente continuarão sendo os sistemas mais importantes do mundo, e provavelmente haverá mais deles. Mas os sistemas mais numerosos…

52:24 serão softwares descartáveis. Eles poderão ser substituídos em poucas horas. Poucas pessoas dependerão deles, ou o gerenciamento de mudanças simplesmente não será importante. E olha, se não funcionar, daremos agents para todo mundo. As pessoas farão a própria versão. A manutenção será irrelevante ou quase gratuita. Não gosta da calculadora do seu sistema operacional? Faça a sua. Quer planejar uma festa para seus filhos? Escreva um software para planejar aquela festa. Depois, descarte-o. A qualidade do código não importa. Ninguém se importa. No futuro, aplicaremos rigor de engenharia…

52:56 de acordo com o grau de descartabilidade do software. À esquerda, nenhuma das nossas práticas de rigor de engenharia importa. À direita, todas as práticas de engenharia que desenvolvemos ao longo de muitas décadas importam muito. Podemos determinar onde você está nessa escala com base naqueles quatro fatores de que falei: consequências, custo de substituição, dependências e custo de manutenção. Se todos forem baixos, é software descartável. Se todos forem altos, é software durável. E olha, qualquer pessoa…

53:28 que escreve software há muito tempo sabe que é melhor presumir que ele será durável. É melhor considerar que todos esses fatores serão mais altos do que você espera. Mas há também algo novo que você pode fazer no mundo: criar software descartável. O que isso envolve? Bem, criar ambientes mais isolados, certo? Por exemplo: você só pode fazer deploy nesse ambiente, que tem acesso apenas aos seus dados. Nada de dados de clientes, informações de identificação pessoal ou qualquer coisa do tipo. Você pode impor…

54:00 a independência. Você pode dizer: “Certo, não são permitidas chamadas de API de entrada de outros sistemas de produção para este sistema neste ambiente.” Então, tudo o que for implantado nesse ambiente é descartável. Redundância: você pode ter um sistema de backup antigo e desajeitado, difícil de usar, e, se as pessoas quiserem fazer vibe coding de seus próprios frontends mais eficientes, deixe que façam vibe coding dos próprios frontends mais eficientes, porque existe um sistema de backup antigo, durável e desajeitado que elas podem usar se aquela coisinha malfeita feita com vibe coding falhar — e vai falhar, certo? Tudo bem, não tem problema se ela…

54:30 falhar. E você pode limitar o escopo, como acabei de dizer, certo? É só uma calculadora para esta situação. Podemos fazer isso aqui e conversar sobre maneiras de aumentar a descartabilidade. Na verdade, acho que esta é uma disciplina inteiramente nova da engenharia de software: não pensar em como aprimorar o rigor dos sistemas duráveis, mas em como adaptar nossos sistemas e incentivar a descartabilidade, ou permitir mais descartabilidade, permitindo que as pessoas simplesmente descartem essas coisas.

55:02 Uma ideia interessante. Agora, quero enfatizar novamente que a engenharia de software durável não vai desaparecer, porque essa é a maior confusão que vejo hoje nas redes sociais. Na verdade, acredito que a quantidade total de software durável no mundo vai aumentar, porque as ferramentas de programação com IA tornam cada vez mais fácil criar mais software durável. E outro ponto importante é que descartável e durável não são categorias absolutas. Existe um espectro, como mostrei antes. Mas…

55:33 nesse espectro, o que muda é o quanto de esforço você vai dedicar ao rigor de engenharia. Certo? Isso inclui tanto o esforço imediato quanto o esforço ao longo do tempo, como sempre falamos em relação a software. No entanto, o que você deve buscar — e acho que aquilo com que mais deve se importar — é reduzir o custo do esforço. Reduzir o custo do rigor. Se o rigor for mais barato, se você tornar cada vez mais fácil aplicar rigor, terá menos com que se preocupar…

56:03 em relação a onde você está na escala. Essa é outra abordagem possível. Se mudar de ideia, será muito mais fácil. Você pode pensar: “Ah, achei que isso seria descartável, mas agora precisa ser durável.” Quanto mais barato for torná-lo durável, mais fácil será mudar de ideia ou estar errado, porque você nunca vai acertar essa estimativa 100% das vezes. Isso envolve um conjunto diferente de práticas, que não são o próprio rigor de engenharia, mas dizem respeito a como reduzir o custo do rigor de engenharia.

56:34 Eu poderia falar sobre isso por horas. Passei uma parte enorme da minha carreira fazendo isso. Não tenho 10 horas. Restam cerca de cinco minutos no cronômetro. Então vou falar do que puder. Certo, vamos falar de padronização. Por que padronizamos? As pessoas dizem: “Bem, não sei, porque o chefe mandou.” Hoje, padronizamos porque isso elimina possibilidades. Se você não tem PHP no seu sistema, não precisa descobrir quais são todos os linters para PHP, quais são todas as práticas, quais são todas as brechas de segurança que precisa corrigir.

57:04 Você simplesmente elimina possibilidades por meio da padronização, e isso reduz o custo do rigor. A mesma coisa vale para frameworks: por que você não quer ter todos os frameworks de frontend ou todos os frameworks de backend que existem? Porque isso torna o rigor mais caro. Sim, ainda é possível aplicar rigor. Sim, o agent ainda poderia programar todas as suas ferramentas, mas você teria que fazer isso toda vez. E, sabe, os protocolos: por que você quer ter protocolos RPC padronizados? É tudo a mesma coisa. Os padrões servem para isso. Certo, o que chamo de ferramentas integradas ao workflow…

57:36 Ferramentas integradas ao workflow são ferramentas que simplesmente são executadas; o programador não precisa decidir executá-las nem entender como funcionam. Elas simplesmente são executadas. Se estão disponíveis, parecem gratuitas — e, na prática, são. A confiabilidade é muito, muito importante: elas não têm uma quantidade enorme de falsos positivos, são rápidas e simplesmente funcionam. E quanto mais isso for verdade, mais você pode aplicar isso também ao software descartável. Então, não se trata apenas de perguntar: “Como fazemos testes melhores?” Como fazer para que ninguém precise pensar…

58:08 sobre como fazer testes melhores? Como fazer para que todos os testes sejam rápidos e determinísticos, sem que ninguém precise ser especialista em testes? É preciso investir muito na infraestrutura de testes para tornar isso possível. Por exemplo, sabe, um dos grandes sonhos que sempre tive como responsável por testes é que todo mundo fornecesse versões falsas, em memória, dos próprios serviços, e eu pudesse simplesmente executar essas versões falsas em memória. Adivinha? O coding agent consegue fazer isso. Então, agora você pode simplesmente fazer isso, certo? Mas precisa escolher fazer e disponibilizar para todo mundo.

58:40 E outra coisa: veja, rigor máximo. Você simplesmente aumenta o rigor em todos os lugares. Define todas as regras do linter no nível máximo. Nunca abre mão de nada. E isso simplesmente elimina — é muito parecido com a padronização — elimina muitas conversas. Às vezes o linter está errado. Mas, desde que a taxa de falsos positivos seja relativamente baixa e isso não tenha consequências catastróficas, não importa, porque, de repente, há vários erros futuros do linter ou problemas futuros com os quais você não precisa lidar. Pergunte a qualquer pessoa que já tenha dito: “Ah, de repente quero ativar o linter nesta base de código de um milhão de linhas.” E a resposta é: “Ah, nossa.

59:10 Agora tenho uma alteração de 100 mil linhas para fazer.” Certo? É muito mais fácil simplesmente fazer isso logo de início e deixar ativado para todo mundo. Olha, como eu disse, eu poderia literalmente ficar aqui falando sobre isso por 10 horas seguidas. Há muito, muito mais que você pode fazer. Estas são apenas algumas áreas, mas também há toda uma área de disciplina de engenharia de software que você pode aplicar no outro eixo. Isso nos permite responder à nossa pergunta. Não apenas “depende”, mas sim ou não. Então, a qualidade do código importa para software descartável? Não.

59:44 Para software durável? Sim. E podemos responder a uma terceira pergunta ainda mais interessante: precisa ser caro? Não. Muito obrigado. [aplausos] [música]

1:00:16 À medida que a IA assume uma parte maior da construção, o que significa ser engenheiro? Para explorar por que definir o sucesso pode se tornar a habilidade essencial, recebam, por favor, Aparna Dina Kuran, cofundadora e diretora de produto da Arise AI. Oi, Nova York. Que legal. Bem, sejam bem-vindos ao

1:00:48 AI Engineer. Bem, pensei que, já que estamos no AI Engineer New York, poderíamos revisitar a pergunta: o que faz um AI engineer? Parece que, a cada ano, temos uma ideia do que faz um AI engineer, e essa definição muda. E, enquanto preparava esta palestra, o assunto veio bem a calhar, porque Karpathi acabou de publicar um tuíte neste fim de semana em que fala sobre essa crescente diferença entre, basicamente, as pessoas na fronteira que estão

1:01:20 operando milhares de agents e enxames de agents sempre ativos. E ele apresenta esse funil em que mais de 6 bilhões de usuários talvez já tenham experimentado ou interagido com um LLM. De 1 a 2 bilhões talvez sejam usuários casuais do plano gratuito. 20 milhões são profissionais que talvez tenham começado a usar isso para pegar uma parte do trabalho que levaria semanas e reduzi-lo a dias. Mas, na verdade, os que estão nos laboratórios de fronteira são uma porcentagem minúscula. São

1:01:50 tipo 5.000 usuários que operam milhares e milhares de agents de uma só vez. E, quando olho para isso, é realmente… quer dizer, ele apresentou um pouco desse funil. A primeira pergunta que qualquer pessoa faz ao olhar para isso é: onde eu me encaixo? E, sabe, ele traçou um pouco de um roteiro de como todos podem chegar, nos próximos anos, a ser um daqueles 5.000 usuários que operam milhares de agents. E isso vem acontecendo há algumas décadas, em que a camada de abstração fica cada vez mais alta. Quer dizer, com certeza isso acelerou nos últimos anos, mas passamos de engenheiros escrevendo linguagens de abstração de nível mais alto para, bem, simplesmente copiar e colar código, usar agents locais, usar agents na nuvem, até chegar à expectativa atual: como todos nós começamos a operar uma equipe de agents ou fábricas de agents internamente e avançamos nessa direção? E isso levou a

1:02:21 basicamente a uma versão do que era antes e do que é agora um AI engineer. E isso é, é, é um pouco… acho que, para alguns, é uma espécie de roteiro, mas internamente já começamos a caminhar nessa direção. Como AI engineer, seu trabalho já não é apenas escrever a funcionalidade, escrever uma funcionalidade de IA. É como você constrói o ciclo para escrever essa funcionalidade. Já não se trata simplesmente de ler o diff e fazer uma revisão de código. Trata-se de como configurar sistemas e agents para fazer as revisões de código e

1:02:54 como escrever evals para revisar tarefas não determinísticas. Já não se trata nem mesmo apenas de configurar métricas e telemetria de software; trata-se de como fazer agents analisarem os dados de observabilidade e consumirem essa telemetria para encontrar padrões. E [fungada] esse ciclo de que temos falado — construir, avaliar, lançar, monitorar e melhorar — agora é algo pelo qual o AI engineer é

1:03:25 responsável: não apenas por executar cada uma dessas etapas, mas por construir o ciclo que realmente executa cada uma delas. E, na Arise, uma das coisas que lançamos no nosso produto — e vou falar um pouco do que aprendemos ao desenvolvê-lo — foi o Signal, para executar esse ciclo para AI engineers. O que o Signal faz é analisar todos os traces. Ele lê a telemetria, identifica padrões nesses dados e pode até propor uma correção ou um PR

1:03:55 se tiver acesso ao repo. E o Signal é um agent sempre ativo. Este é um exemplo de como o Signal começa: ele começa simplesmente lendo os traces. É um exemplo bem simples, mas ele percorre e lê… tudo isso é configurável, mas ele lê uma determinada quantidade de traces recebidos em certa frequência, e o objetivo é identificar problemas com base nesses dados de telemetria. Ele precisa acompanhar

1:04:26 os problemas que já encontrou. Então, precisamos considerar sua memória: ele viu antes algo que considerou um problema? Algo pareceu um problema, mas não foi registrado? E agora, ao coletar mais dados, ele considera que é um problema muito mais crítico. Então, o Signal começa lendo os traces para identificar problemas. E uma das primeiras coisas que percebemos foi que o perfil de quem consome dados de telemetria

1:04:57 mudou muito. Já não se trata de humanos consumindo dados de telemetria. Nem sequer de humanos consumindo esses dados e agents assumindo parte da tarefa. A questão é como configurar seus dados de telemetria para que os agents sejam os principais consumidores desses dados. E isso faz com que os dados de observabilidade possam servir de gatilho para executar e acionar esses agents sempre ativos. Portanto, a primeira coisa a considerar, se você está construindo uma equipe, sabe, uma fábrica de agents realmente sempre ativos, é

1:05:28 o que aciona esses agents para despertar ou começar a funcionar. Pode haver vários tipos de gatilho. No nosso caso, o Signal pode ser configurado para executar em uma frequência contínua. Então, a cada 3 ou 6 horas, ele busca a última quantidade x de traces, lê e identifica problemas. Também pode ser acionado por eventos. Por exemplo, mensagens no Slack; se algum usuário reclamar de algo, pode ser acionado por uma métrica. Mas, essencialmente, são

1:05:59 gatilhos para iniciar a execução do agent. Depois que o agent começa a funcionar, precisamos dedicar um tempo para entender: bem, como é uma execução de um agent? No nosso caso, incluímos todo o contexto dos traces e quaisquer dados adicionais de terceiros. Permitimos coletar logs de APM, métricas de APM, mas também todos os dados de telemetria de terceiros que queremos incluir. Acesso ao repo, acesso ao próprio…

1:06:30 gatilhos para iniciar de fato o agent. Quando o agent começa de fato, precisamos passar algum tempo entendendo, bem, como é uma execução de agent? No nosso caso, reunimos todo o contexto dos traces, quaisquer dados adicionais de terceiros. Então, permitimos coletar logs de APM, métricas de APM e todos os dados de telemetria de terceiros que queremos reunir. Acesso ao repo, acesso ao próprio

1:07:03 o acesso a todas as chaves necessárias para realmente executar esse agent. Mas todas essas informações são colocadas dentro de um sandbox. E é isso que é iniciado toda vez que o agent é ativado. Então, o agent é acionado. Criamos um sandbox. Colocamos dentro dele tudo de que precisamos. Há um proxy. A única maneira de obter informações para dentro e para fora do sandbox é por meio desse único proxy. E tudo o que acontece dentro desse sandbox já está sendo rastreado. E

1:07:34 cada saída — portanto, as issues geradas e criadas — é salva em algum tipo de memória. E isso acontece toda vez que o agent é executado. Sempre que o agent termina de executar, depois de percorrer todos os traces, ele encontra algo ou não; algumas coisas são mantidas e outras são descartadas. O que é mantido é que, se ele encontrou alguma issue, toda a saída é salva em algum tipo de memória, para que, da próxima vez que um agent

1:08:05 for iniciado, não precise começar do zero. Ele tem um histórico das issues que encontrou. Os agents são rastreados. Então, todos os dados de telemetria sobre o que o agent chamou — por exemplo, se ele abriu um PR —, tudo isso é rastreado. E quaisquer skills que ele possa ter aprendido durante uma execução também podem ser salvas no próprio repo. Mas o que desaparece é que o sandbox é desmontado. Todas as credenciais, obviamente, são removidas. O

1:08:38 acesso ao repo é removido e, assim, tudo o que não precisa ser salvo é desmontado depois da execução do Signal. Projetamos o Signal de modo que a configuração do agent seja durável. Isso significa que, se o sandbox ou o harness falhar, ele não deve precisar começar tudo do zero no meio da execução. Deve poder simplesmente retomar a partir da etapa em que falhou, e todo o estado

1:09:09 assim chamado é salvo em algum tipo de memória fora do sandbox. Projetamos isso para que seja um agent muito durável: se falhar, ele pode ser iniciado novamente. Você pode iniciar um novo sandbox e um novo harness para retomar de onde parou. Portanto, tudo isso é essencialmente a base de como criamos o Signal para funcionar. A cada execução, o agent é acionado, iniciado e carregado com todo o contexto e as evidências; ele percorre os dados de telemetria e

1:09:41 encontra algo ou não. Tudo isso é salvo na memória. Se algo falhar no meio do processo, o agent pode ser reiniciado. Também criamos o Signal para ser agnóstico em relação ao modelo ou ao harness. Hoje, o Signal oferece suporte não só ao Claude Code, que foi com o que começamos, mas também ao Cursor e ao Codex. E o objetivo é oferecer suporte a todos os principais harnesses, inclusive os open source. O Signal também oferece suporte — ou oferecerá suporte — a vários

1:10:11 modelos. Assim, mesmo que você esteja usando o Claude Code, pode escolher qualquer modelo da família Anthropic. Isso é muito importante para nós porque, primeiro, é uma ótima maneira de avaliar a qualidade do agent. Sempre que o iniciamos, isso nos ajuda a controlar os custos. Assim, podemos ver que, ao usar modelos mais poderosos, talvez a qualidade dos PRs melhore, mas será que podemos reduzir a qualidade — quer dizer, reduzir o custo — e ainda

1:10:42 manter o rigor e a qualidade das issues detectadas pelo Signal? Pensamos muito nisso, a partir de primeiros princípios, ao projetar o Signal. E isso é uma boa transição para a pergunta: o que um engenheiro de IA precisa fazer? Bem, um engenheiro de IA precisa aprender a escrever evals. Então, toda vez que o Signal é executado, encontra uma issue e abre um PR, há um eval sobre o agent para testar esse PR.

1:11:14 E um eval pode ser tão simples quanto testar algo como parte do seu workflow de desenvolvimento. Você tem um conjunto de dados. Pode ser um prompt simples com saídas que você testa para garantir que não haja regressões. Mas esses evals também precisam estar alinhados ao julgamento humano. E eu diria que provavelmente é aí que um engenheiro de IA deve dedicar boa parte do seu tempo enquanto constrói o sistema que executa esse ciclo. Ele

1:11:45 deve dedicar tempo a analisar os traces com seus agents e identificar os erros mais comuns. Há muitas skills. Acho que ouvi o Lance falar ontem sobre a skill do Claude para criar evals. Temos uma skill com o avaliador da Arize para ajudar você a criar e escrever evals, além de alinhar esses julgamentos dos evals. Mas é provavelmente aí que definir o que é bom se torna realmente importante para um engenheiro de IA. E, para muitas

1:12:17 das equipes com quem conversamos e trabalhamos, a pergunta é: como confiar no avaliador? Será que posso realmente confiar que o eval vai detectar o problema? Como saber se ele é tão bom quanto o meu julgamento? Eu diria que dedicamos bastante do nosso próprio tempo, em nossos produtos, a avaliar os avaliadores. Dedicamos uma quantidade considerável de tempo a criar esses conjuntos de dados, conjuntos de dados de referência

1:12:48 de verdade. Executamos evals, verificamos os resultados em relação às respostas humanas e, então, buscamos alinhá-los para garantir que o judge concorde com o ser humano e que haja concordância entre eles antes de lançarmos um novo avaliador. Esses evals podem ser usados tanto em testes offline quanto em testes online. E eu diria que isso está se tornando cada vez mais parte do trabalho de um engenheiro de IA.

1:13:20 Então, o que vou deixar para vocês é o seguinte: como engenheiro de IA, você construiu esse agent para funcionar continuamente. Executa evals antes de lançá-lo em produção; então, pode fazer o deploy. Depois que ele entra em produção, o objetivo é rastrear tudo. E rastrear tudo agora significa rastrear não só os agents, mas também os agents de programação por trás dos agents que os criaram. Assim, você pode rastrear o Claude

1:13:53 Code, o Cursor e o Codex; todos esses agents de programação podem ser rastreados. Assim, você entende o que aconteceu na fábrica de agents que está construindo. E os traces de todos esses agents também podem ser avaliados online. Há uma avaliação offline quando você testa uma nova alteração. Mas, quando ela entra em produção, esses se tornam os evals online que você executa sobre os dados de telemetria. Para nós, isso acaba

1:14:23 se tornando os novos dados que são então trazidos de volta para os agents lerem os dados de telemetria. A camada de eval revela problemas dentro dos traces. Então, o sistema passa a ser: como coletar dados, avaliar esses dados e executar agents sobre eles para encontrar problemas e identificar lacunas, a fim de melhorar os sistemas. Então, voltando à pergunta com que começamos toda esta

1:14:54 conversa: o que faz um engenheiro de IA? Quer dizer, acho que há uma grande lacuna entre o que acontece hoje nos laboratórios e o que acontece em muitas empresas. Parte disso pode ser simplesmente porque os dados das empresas são muito mais desorganizados do que os dados muito controlados e testáveis de um laboratório. Mas os engenheiros de IA são justamente a função que fecha essa lacuna, e acho que isso realmente começa com rastrear tudo: os agents que você está construindo.

1:15:24 executando evals, podendo aprender a testar esses produtos que estamos realmente construindo e, então, como construir um sistema para que os agents possam de fato melhorar com base na telemetria que está sendo coletada, para que você não esteja mais apenas construindo funcionalidades individuais, mas sim construindo um sistema para melhorar seus produtos. Se quiser saber mais, venham conhecer nosso estande. Vocês podem conferir o Signal e saber mais. Muito obrigado por nos ouvirem. [aplausos]

1:15:54 [música] A execução do programa atual foi concluída. Recolham seus pertences e saiam pelas portas principais para a próxima tarefa agendada. Calor. Calor.

1:16:55 Calor. Calor. Calor. Calor.

1:17:27 Calor. Calor.

1:18:14 >> [música] >> Calor. Calor. Calor. Ei, calor. Calor.

1:19:02 Calor. Calor. Calor.

1:19:42 Calor. Calor.

1:20:20 Calor. Calor. Calor. Calor. Calor.

1:21:20 Calor. Calor. Calor. Calor.

1:22:04 Calor. Calor.

1:22:37 Calor. Ei, calor. Ei, calor. Calor. Calor. Calor. Calor.

1:23:40 Calor. Calor. Calor. Calor.

1:24:35 Calor

1:25:07 Eu, calor. Calor.

1:25:54 Calor. Calor. Calor. Calor. Calor. Calor.

1:26:44 Calor. Calor. [música] Calor.

1:27:20 Calor. Calor. Calor.

1:28:17 Calor. Certo. Obrigado, pessoal. Meu nome é

1:28:47 Faço parte da equipe do Wells Fargo. Lidero a organização de modelagem de IA Frank lá. E vou mostrar o trabalho que temos feito recentemente para construir nosso primeiro foundation model, um foundation model do Wells Fargo. Vou explicar por que fizemos isso, como fizemos e o que alcançamos com isso. Então, primeiro: um foundation model não precisa necessariamente ser baseado em linguagem. Quer dizer, todos estamos experimentando com Claude e ChatGPT e outros; todos são foundation models baseados em linguagem.

1:29:18 em serviços financeiros. Claro, também temos linguagem, a partir de representações estruturadas e não estruturadas dos dados, mas também temos muitas representações estruturadas. Muitos desses dados são tabulares. Temos muitas informações sobre nossos clientes. Temos informações de banco de investimento, banco de varejo, e todos esses dados estão no Wells Fargo, assim como em todas as grandes instituições financeiras. E queremos tirar proveito dessa enorme quantidade

1:29:50 de dados que temos. Não é como se bastasse pegar esses dados, colocá-los em um modelo de linguagem e obter o melhor resultado. Claro, dá para obter muitos benefícios, mas essa não é necessariamente a melhor maneira de fazer isso. Então, o que decidimos fazer foi analisar os dados que temos — todas as transações, todas as transações dos clientes feitas com cartão de débito, cartão de crédito, cheques digitais, tudo isso vindo de muitos canais diferentes — e ver se conseguimos construir um foundation model que pudéssemos

1:30:21 usar e fazer fine-tuning para tarefas subsequentes, como pontuação de crédito, detecção de fraude, prevenção à lavagem de dinheiro e marketing. Como podemos construir um backbone que possa ser usado e compartilhado em várias tarefas subsequentes? Assim, passamos de muitos modelos isolados, distribuídos por diferentes organizações, para um único backbone que todas as organizações podem reutilizar, porque ele aprende as representações das transações dos clientes em escala. Essa é a

1:30:52 intenção. E, só para adiantar, talvez vocês digam: “São dados tabulares; por que não usar simplesmente o agboost e os suspeitos de sempre?” Nós fizemos isso. Esse é o modelo que tínhamos em produção. Mas o modelo que vou mostrar supera o XGBoost, inclusive em termos de latência, e também melhora a detecção de fraude, com uma redução muito maior de falsos positivos e uma taxa de detecção melhor. Então, foi uma lição muito valiosa sobre

1:31:22 como ter um modelo melhor usando um foundation model. E, por foundation model, quero dizer blocos transformer. Foi isso que construímos. Como mencionei, temos bilhões de transações por mês. Nossos clientes interagem com seus cartões de débito e crédito, fazem cheques e realizam diferentes tipos de transações. A questão é como podemos usar essas informações em escala, e não para cada tarefa subsequente individualmente. Vou falar um pouco sobre os dados,

1:31:54 as representações, a arquitetura que usamos, os resultados que obtivemos e as lições que aprendemos ao construir isso. Certo. À esquerda, os foundation models de linguagem processam tokens de linguagem, e o objetivo é aprender uma representação que permita prever o próximo token. Depois, você tem o fine-tuning supervisionado e faz LHF e LRVR, além de todos os ótimos processos de pós-treinamento para melhorar na

1:32:26 tarefa desejada. Isso funciona muito bem para linguagens. Mas e se seus dados forem muito mais especializados em termos de representação? Foi aí que construímos este transaction foundation model. Em vez de ter a linguagem como base, a base agora são transações dos nossos clientes. E você ainda tenta prever o próximo elemento; aqui, o próximo elemento é a próxima transação, ou o próximo token na transação, usando todos os canais disponíveis. Mas esse

1:32:57 não é o objetivo final. Quer dizer, assim como em um modelo de linguagem, em que tentar prever o próximo token não é o fim da história, você aprende uma representação e depois a usa, faz fine-tuning nela e a pós-treina para qualquer outra tarefa. Pode ser uma tarefa de classificação para linguagens, mas, no contexto do nosso transaction foundation model, pode ser usada para aumentar o limite de crédito, detectar fraudes e sinalizar agentes mal-intencionados do ponto de vista de prevenção à lavagem de dinheiro. O objetivo é aprender essas

1:33:29 relações entre transações ao longo do tempo e transações entre clientes. Essa é realmente a intenção. Primeiro, fazemos o pré-treinamento do zero. Vou repetir, porque às vezes as pessoas ficam confusas: pré-treinamos blocos transformer em escala, do zero, usando nossos dados de transações. Não usamos nenhum peso de modelos open source. Usamos apenas a arquitetura e então fazemos o pré-treinamento do zero usando nosso cluster de GPUs. Depois, treinamos por alguns dias e

1:34:01 semanas e, então, fazemos as tarefas subsequentes de pós-treinamento. Mas o objetivo aqui é pré-treinar o modelo para prever o próximo token ou a próxima transação. Tentamos fazer isso: prever o próximo padrão do cliente. Mas essa não é a intenção final; a intenção é realizar as tarefas subsequentes mais tarde. Em termos de escala, operamos em grande escala. Temos bilhões de transações, milhões de contas,

1:34:31 centenas de transações por cliente por mês, feitas com cartões de débito e crédito ou por meio de cheques. As cinco principais dimensões que analisamos são: quem está fazendo isso — ou seja, quem está processando e quem está solicitando —, quem está prestando o serviço, se é o cliente ou o comerciante; o quê — o que compramos, que transação fazemos; e como — qual canal, se é crédito, débito ou

1:35:01 digital; quando acontece e onde acontece. Tudo isso se divide basicamente em centenas de funcionalidades. E, se vocês olharem os modelos que temos em produção, muitas pessoas que construíram esses modelos em organizações semelhantes talvez entendam: elas fazem muito trabalho artesanal de engenharia de funcionalidades, e isso exige muito tempo. Então, voltamos um passo e analisamos as funcionalidades brutas de que precisamos, não as que já foram pré-construídas e pós-construídas para realizar as tarefas subsequentes. Tentamos entender quais funcionalidades brutas são necessárias, e acabamos com basicamente cem. No fim, tínhamos milhares, mas tentamos encontrar quais eram as informações brutas realmente necessárias. Então deixamos a arquitetura, os blocos transformer, descobrir as relações entre essas funcionalidades centrais. E, como podem ver, temos um conjunto de

1:35:33 que foi realmente pré-construído e pós-construído para executar a tarefa de não fazer streaming, mas tentar entender quais são as features brutas. E acabamos com basicamente 100 features; no fim, tínhamos milhares delas, mas tentamos encontrar quais eram realmente as informações brutas de que você precisa. Depois, deixamos a arquitetura, os blocos do transformer, descobrir a relação entre essas features essenciais. E, como podem ver, temos, sim, um monte de

1:36:03 características nessas cinco dimensões, e o vocabulário é muito específico à área de serviços financeiros. Então, essa é a razão pela qual, quero dizer, não usamos realmente um modelo pré-treinado existente, porque o vocabulário que usamos é muito, muito específico ao trabalho que queremos fazer. E mesmo que você reúna todos os dados digitais, de conta corrente e poupança, e todos esses tipos de transação,

1:36:34 mesmo que reúna tudo isso, ainda acaba com um número muito limitado de características e atributos. Então, nessa escala, a questão é: como trabalhar com isso? Começamos com tudo em dados tabulares. Quer dizer, não tem segredo: são dados tabulares. E o objetivo é entender como capturar o vocabulário, porque você tem valores numéricos, valores categóricos, informações como código postal. Você codifica cada código postal como um token? Isso faz sentido? Então, há

1:37:05 muito trabalho a fazer para entender o vocabulário de que você precisa e também o vocabulário que quer escalar, porque, no treinamento, se você tiver um vocabulário grande demais, será meio complicado treinar um modelo desses com um vocabulário muito, muito grande. Então, é preciso bastante trabalho para entender essa conversão de valores em tokens. Que informação você codifica em um token? Depois, você tem a tokenização, que converte tokens em IDs, e então a consulta ao embedding. Assim, quando chega uma transação, você tem o

1:37:36 vocabulário. Basicamente, é uma consulta e o alinhamento das transações e de todas as características dessas transações com um token, um ID e, depois, um embedding. Só para dar alguns números: temos dados quantitativos, qualitativos e categóricos de diferentes tipos. Há categorias com apenas oito tipos e outras com muito mais. O valor da transação é muito importante. Também há o intervalo de tempo entre transações. Então, há

1:38:07 tudo relacionado a endereço IP e código postal, só para dar exemplos da variedade e da heterogeneidade de cada característica, que pode ser codificada em um token binário ou em um número muito maior de tokens. E, mesmo se você olhar para os códigos postais, há muito mais códigos postais nos EUA do que esses 2.800, mas há maneiras mais sofisticadas, ou muito melhores, de organizar como agrupar os códigos postais

1:38:38 com base, por exemplo, nas distribuições. Então, a arquitetura. Aqui está o que fizemos: usamos a matemática por trás do Chinchilla para definir como construir o modelo. No início, não fazíamos ideia de como isso funcionaria no espaço tabular, embora já existam modelos fundacionais de dados tabulares com pesos abertos e soluções open source. Começamos com o que eles aprenderam e

1:39:10 adaptamos ao que precisávamos fazer. Isso dá um exemplo das dimensões de embedding, do número de blocos do decodificador que usamos e de toda a receita do ponto de vista da arquitetura. Como podem ver, não estamos tentando construir um modelo com um trilhão de parâmetros. Não tentamos competir com os líderes dos modelos de linguagem, porque trabalhamos e nos concentramos realmente em transações: modelos fundacionais de transações na escala de

1:39:40 bilhões. Um bilhão porque esse modelo nos deu o maior ganho, apesar de ser o menor. Agora estamos trabalhando nas próximas versões, com 11 bilhões, mas isso já é suficiente para obter muitos benefícios de IA, reduzindo os falsos positivos em tarefas downstream, como detecção e taxa de detecção. O tipo de arquitetura é somente decodificador, e basicamente serve

1:40:12 para prever o próximo token ou a próxima transação; isso é o pré-treinamento. Inicialmente, usamos 20 vezes o número de parâmetros para definir quantos tokens poderíamos precisar. Na prática, acabamos usando um fator 10 vezes maior do que isso. Fizemos alguns experimentos e percebemos que precisávamos de muito mais tokens por parâmetro. Quer dizer, esse foi o tipo de experimento inicial que fizemos. Vou pular esta parte, porque são as funções objetivo habituais: modelagem de linguagem causal e modelagem de linguagem mascarada, os tipos de trabalho de otimização

1:40:44 e, do ponto de vista da arquitetura, não há nada particularmente sofisticado aqui. Mais uma vez, a parte mais complexa foi realmente a tokenização, depois a adaptação, o pré-treinamento e, em seguida, como fazer o fine-tuning. Se eu tivesse que apontar a receita ou o segredo, seria realmente como fazer a tokenização e o pós-treinamento. Mas, do ponto de vista do treinamento, a questão é

1:41:17 simplesmente quantas transações você vai colocar no seu contexto ou na sua sequência para treinar e avaliar. A precisão baseada em perplexidade e o painel de precisão nas tarefas downstream são o que se espera. Então, usamos precisão mista, paralelismo de dados distribuído, maximizamos o tamanho do lote macro para obter convergência mais rápida, usamos Muon e RoPE,

1:41:47 os métodos habituais e técnicas para economizar memória, como FlashAttention e checkpointing de ativações. Não há nada realmente novo aqui; usamos as recomendações dos melhores e de quem constrói modelos muito maiores. Vou pular esta parte. O tempo é curto, mas queria dedicar algum tempo aos resultados. Quando você constrói essa base, ela é

1:42:17 realmente apenas uma base, algo que pode ser usado para tarefas downstream. A tarefa downstream era classificar fraudes. Você tem transações e tenta prever se uma transação será fraudulenta. No modelo que temos em produção, usamos XGBoost, treinado com uma grande quantidade de transações fraudulentas e não fraudulentas. O que faltava era a relação entre

1:42:48 a transação que você está tentando prever ou classificar e a relação dela com todas as transações anteriores. Essa informação se perde quando você usa um modelo XGBoost, a menos que a codifique de uma maneira muito complexa, o que não é tão fácil. Mas, se você usar arquiteturas Transformer, terá essas boas atenções entre as transações atuais e as transações anteriores. E acreditamos que isso é o que realmente ajuda a elevar bastante a taxa de detecção de fraudes.

1:43:18 No fim das contas, a tarefa downstream era receber uma sequência de transações de alguém que está usando um cartão de débito e determinar se aquela transação é fraudulenta, considerando todo o histórico. E é exatamente isso que você fornece no momento da inference, quando tenta fazer a previsão. Essa é a arquitetura. Nada muito sofisticado. Só é preciso ter uma boa engenharia para fazer o processamento em menos de

1:43:51 250 milissegundos, porque a recusa precisa acontecer dentro desse prazo. Mas, do ponto de vista da latência, nosso sistema era 10 vezes mais rápido do que isso. Então, estava tudo bem. Quanto ao resultado final, as principais métricas se traduzem diretamente em dinheiro, em custos ou economias para a empresa. São a taxa de detecção e a taxa de falsos positivos. Claro, você pode

1:44:22 detectar muito mais, mas, em muitos casos, às vezes também acaba tendo muito mais falsos positivos. Neste caso, conseguimos sinalizar mais atividades fraudulentas e ainda reduzir os falsos positivos. Foi uma grande vitória. Foi uma grande vitória porque, no fim das contas, se você recusa uma transação que não é fraudulenta, essa pessoa vai ligar, gerando um custo operacional. Você perde a transação associada a essa ação não fraudulenta. Então, é algo muito, muito…

1:44:56 que você realmente não quer que aconteça. Então, de novo, isso é uma comparação com o modelo GG boost de última geração usado para detecção de alimentos. Basicamente, é algo enorme: uma economia de milhões de dólares. Então, é um grande avanço. Só para concluir esse slide: esse modelo fundacional foi desenvolvido com bilhões de transações de clientes do Wells Fargo. Essa é a…

1:45:28 …primeira coisa. Ele é pré-treinado do zero. Não fazemos pré-treinamento a partir de nenhum modelo existente de pesos abertos. Usamos uma arquitetura existente, mas a forma como… a taxa zero… fazemos o pré-treinamento em alguns dias. Quer dizer, inicialmente fizemos isso em algumas semanas, mas depois ele é pré-treinado. E, quando está pré-treinado, é muito bom em prever a próxima transação. Depois que você termina essa etapa, pode usá-lo para muitas tarefas posteriores. Nós o usamos para detecção de fraude e agora estamos investigando o aumento de limite de crédito e a prevenção à lavagem de dinheiro…

1:45:59 …e investigando o marketing. Então, agora a mesma base é usada em diferentes organizações dentro do Wells Fargo. E, sim, obrigado por me receberem. E obrigado. [aplausos]

1:46:38 Calor. Calor. Calor. Calor.

1:48:23 Calor. Calor.

1:48:59 Oi, pessoal, eu sou…

1:49:29 …mais passo a passo. Sobre mim: não sou engenheiro. Passo meu dia, com certeza.

1:50:14 Isso também vem da plataforma. Trabalhamos em uma startup comum e agora usamos…

1:50:47 Mas eu ainda fazia todo o trabalho manualmente. Só fazia um pouco mais rápido. Foi isso que descobrimos. Não estou escrevendo. É isso.

1:51:40 Quero estar com vocês.

1:53:30 Certo. Bom dia a todos. Obrigado por se juntarem a nós hoje. É uma honra compartilhar este palco com tantos palestrantes incríveis. Então, vamos direto ao assunto. Meu nome é Aman. Lidero a área de IA na Arca. Hoje vou falar sobre os agentes de longo horizonte da Arca, que operam nosso negócio. A ARCA é uma empresa de serviços nativa de IA. Oferecemos aos nossos clientes serviços financeiros, como planejamento financeiro, planejamento tributário…

1:54:00 …gestão de ativos e consultoria de investimentos. Atendemos vários tipos de clientes. Alguns são executivos de tecnologia que acumularam bastante patrimônio e precisam de um plano de verdade para se aposentar mais cedo, mas também atendemos aquela família de New Hampshire que ganhou seu primeiro milhão de dólares e finalmente quer comprar aquela casa. Eu disse que somos nativos de IA. Hoje em dia há muitas definições para esse termo, que está muito usado, mas o que queremos dizer com nativo de IA é…

1:54:34 …que os agentes operam nosso negócio, não que apenas o auxiliam de algum canto como copilotos. Eles executam as decisões que moldam os resultados que nosso negócio entrega aos clientes. É interessante saber como é o trabalho no setor de serviços financeiros: ele tem um horizonte mais longo, mas não é tão contínuo. Com isso, quero dizer que não são agentes passando horas ou dias a fio gerando tokens…

1:55:05 Certo? É mais como uma meta de um cliente que se estende por 10 dias. O trabalho para e recomeça várias vezes. Há muitos participantes no processo, muitos pontos de decisão e muitas transferências de responsabilidade. E, no fim, essa meta é alcançada, por assim dizer, 10 dias depois. Esse é o tipo de trabalho que estamos desenvolvendo. Aqui vai um exemplo. Jane é nossa cliente, tem bastante patrimônio, mas tem uma conta de impostos alta. Ah, ela tem uma conta de impostos alta para pagar em 15 de abril, certo? Então, vamos…

1:55:37 …ajudar Jane a descobrir qual é a maneira mais eficiente do ponto de vista tributário de levantar o dinheiro para pagar a conta. Há um consultor que fará toda a análise dos extratos e analisará como otimizar a questão tributária. Há também o trader, que liquidará os ativos. Os próprios ativos levam alguns dias para serem liquidados, e depois a equipe de operações entra e aciona o AC, que também leva alguns dias para chegar. Então, esse é o tipo de…

1:56:07 …trabalho de que estou falando neste setor, que leva dias para ser concluído. E, claro, se você fizer isso em escala para vários clientes, o tempo que nossa empresa leva para realizar esse tipo de trabalho cresce exponencialmente, certo? Então, na ARCA, adotamos uma abordagem diferente. É útil saber que a ARCA não é uma empresa SaaS. Não vendemos software para outras empresas. Nós somos a empresa. Somos uma empresa de IA aplicada que, por acaso, opera um negócio de serviços…

1:56:38 …nesse setor. Então, nossa abordagem foi: vamos fazer com que os agentes sejam responsáveis por todo esse resultado de longo horizonte, de ponta a ponta. Para isso, demos a eles alguns componentes essenciais. Vou dar uma prévia: fornecemos sinais do mundo externo para que estejam sempre cientes do que está acontecendo. Assim, os agentes leem os e-mails. Demos a eles todo o nosso contexto operacional sobre o que fazer com esses e-mails — o que o setor faz em situações como essa, envolvendo impostos, certo? Demos a eles um harness…

1:57:10 …que lhes fornece todas as ferramentas e proteções e, mais importante, a persistência da memória ao longo desse período prolongado, para que possam realizar o trabalho. E, claro, demos a eles a capacidade de colaborar com pessoas. Assim, o trabalho com agentes é muito mais rápido porque tudo o que fizemos foi tirar os humanos do caminho crítico desse trabalho. Ninguém precisa ficar supervisionando essa meta durante vários dias. Os agentes…

1:57:40 …estão cuidando disso. Nesta palestra, gostaria de explicar como fazemos isso na prática. Vamos acompanhar o percurso deste e-mail. Jane deve US$ 100 mil em impostos. Esse e-mail, assim como muitos outros sinais na nossa plataforma, será lido por agentes em segundo plano. Há ligações que nossa empresa está fazendo, documentos que estão chegando, reuniões acontecendo, eventos recebidos do nosso custodiante e movimentos do mercado que estão…

1:58:10 …ocorrendo. Esses são todos sinais que nossos agentes em segundo plano avaliam continuamente para dar andamento ao trabalho. Esse e-mail é um desses sinais. Quando o sinal é recebido pelos agentes, eles começam a trabalhar. Temos um harness que lhes dá o conhecimento necessário para saber o que fazer nessa situação. Eles têm uma memória profunda dos clientes, então sabem: “Ei, nunca devemos mexer na posição da Jane em Apple, porque ela disse isso numa ligação há uns oito meses”, certo? Também temos um ambiente isolado para todos os cálculos financeiros necessários para…

1:58:41 …essa análise. Mas, em grande parte, acho que os harnesses de hoje estão convergindo para um formato padrão. Então, o que acontece fora desse harness é mais interessante. Depois de fazerem o trabalho, eles produzem este plano. O plano, por si só, não pode ser executado sem pessoas. No nosso produto, criamos um espaço — os agentes criam um espaço — onde apresentam esse plano. E é possível conversar com o agente para entender o que está acontecendo com o plano. Várias…

1:59:12 …pessoas podem conversar com o agente e, mais importante, esse espaço também é onde os agentes envolvem pessoas quando precisam que elas executem alguma tarefa. Então, neste caso, aprovaríamos o plano e o e-mail para Jane. Depois vem todo aquele processo de acompanhar se Jane respondeu e o que a resposta dela significa para o plano que temos, certo? E todas as outras perguntas que precisarão ser respondidas ao longo de todo esse trabalho de longo horizonte na ARCA. Pensamos: é claro…

1:59:42 …que não vamos deixar pessoas supervisionando tudo. Então, fazemos com que nossos agentes acompanhem o que acontece, para que as pessoas não precisem fazer isso, certo? Damos a eles ferramentas para registrar interesse em qualquer coisa que aconteça no nosso ambiente. Assim, eles podem dizer: “Avise-me quando Jane responder. Avise-me quando aquele AC chegar”, certo? Isso é viabilizado pelo nosso sistema de sinais em segundo plano, no qual os agentes encaminham sinais aos agentes interessados neles. E, claro, se o sinal nunca chegar…

2:00:14 Os agents também podem, tipo, se ativar sozinhos em horários programados para acompanhar o trabalho. Mas, é claro, o mundo real é muito confuso, certo? As pessoas ficam esperando aquele e-mail, mas Jay nunca responde a ele. Digamos que nos encontremos com ela pessoalmente e fiquemos sabendo de alguma informação que afeta o plano. Então, a pessoa entra e adiciona essa informação à nossa interface. Mas esse ato de adicionar informações ou fazer trabalho na nossa interface também é um sinal

2:00:47 que vai ativar um agent. Na verdade, quando as pessoas trabalham no nosso produto, quando remarcam um evento no calendário, sabe, isso é um sinal. Quando marcam uma tarefa como concluída, isso é um sinal. Então, esse sistema nos permite estar cientes de tudo o que acontece no mundo externo e no mundo interno à medida que o trabalho avança. Assim, nossos agents podem participar do trabalho. E, é claro, os agents também se comunicam entre si. Então, esse sinal é lido por um agent em segundo plano, e permitimos que ele

2:01:18 notifique outro agent sobre isso, para que ele atualize o espaço e diga: “Ei, só precisamos de US$ 80 mil, em vez de US$ 100 mil.” Então, o trabalho mudou por causa desses sinais. E a última parte da história é que os agents conseguem trazer as pessoas certas no momento certo. Então, o agent à esquerda leu o contexto operacional e concluiu: certo, o próximo passo aqui é chamar a pessoa que negocia esses ativos. E então essa pessoa recebe uma tarefa e é

2:01:49 chamada para participar desse trabalho de longo prazo. O que fizemos, de modo geral, se pararmos para pensar, foi dar aos nossos agents os recursos básicos para conduzir trabalhos de longo prazo. O que as pessoas fazem no trabalho, certo? Elas precisam estar cientes do que está acontecendo. Então, criamos esse sistema de sinais bem robusto para que nossos agents estejam cientes. Elas precisam saber o que fazer em seguida. Então, demos a eles todo esse contexto operacional. Elas precisam fazer o trabalho. Então, é o nosso harness que permite que eles realmente façam o trabalho e o acompanhem. Certo? É uma persistência de longo

2:02:19 prazo, sistemas de memória que mantêm o estado e trazem as pessoas certas no momento certo. Essa ideia parece bem simples à primeira vista. Mas há muita complexidade emergente. Dá para imaginar que, a qualquer momento, centenas desses sinais chegam e, sabe, tarefas são adicionadas às listas de coisas a fazer das pessoas. Elas são chamadas para participar. Agents em segundo plano se comunicam entre si. Certo? Então, nos últimos seis meses, temos trabalhado

2:02:50 para fazer esse sistema funcionar muito bem. Temos fechado todas as lacunas de contexto para que os agents estejam plenamente cientes. Temos trabalhado na precisão das tarefas. Ou seja, chamar a pessoa certa no momento certo. O trabalho que precisa ser acompanhado no futuro fica registrado na memória do agent. O trabalho que pode ser feito agora se torna uma tarefa. Certo? Então, temos trabalhado também na nossa capacidade de manter o estado por longos períodos. E, como somos a empresa, e não apenas uma empresa de SaaS, temos

2:03:20 mudado e padronizado a forma como o trabalho é feito na empresa desde o início, além de operacionalizar esse contexto no estado dos nossos agents. E, como são nossos colegas que usam nosso produto, coletamos deles raciocínios detalhados que se tornam evals para aprimorar nosso sistema. Então, acho que cabe fazer uma pergunta: por que fazer isso, certo? O que isso possibilita? Qual é a conclusão aqui? Certo? Para nós, essa é toda a nossa tese: queremos que nossa

2:03:54 plataforma seja tão nativa em IA que os agents conduzam o negócio. Os agents administram o negócio. Eles tomam as decisões que moldam nossos resultados. Então, na Arca, quando as pessoas entram, certo, veem uma lista de tarefas que os agents prepararam para elas. Eles já leram aquele e-mail. Já deram uma olhada no documento que chegou. Já fizeram tipo 90% do trabalho. E chamam você para participar só quando chega a hora de agir. Então, construir esse sistema nos permite chegar a

2:04:26 um ponto em que, na Arca, os agents pedem mais coisas às pessoas do que as pessoas pedem aos agents, o que permite que nossos agents conduzam o trabalho feito pela nossa empresa. E, como os agents conduzem o trabalho feito pela empresa, eles podem conduzir o negócio. Vou dar um exemplo. Lembram daquele e-mail que Jane nos enviou? Isso é um pouco uma falha, certo? Porque deveríamos ter sido proativos desde o início, certo? Então, Jane nunca deveria ter precisado enviar esse e-mail. Digamos que, no nosso negócio nativo em IA,

2:04:59 assumamos essa nova meta. Nossa nova meta é a proatividade. Todo mês de janeiro, preparar a situação tributária de cada cliente e entrar em contato proativamente com eles antes mesmo que alguém peça. Essa é uma nova meta de negócio para a nossa empresa alcançar. E, numa empresa nativa em IA, tudo o que precisamos fazer é incluir essa meta no conjunto de metas dos nossos agents. E, como eles têm os recursos básicos para conduzir o trabalho por meio das pessoas para

2:05:30 a empresa, eles começam a trabalhar para alcançar essa meta. E, assim, de repente, temos essas análises sendo feitas em janeiro e esses e-mails de aprovação com um clique, contendo o plano completo para cada cliente, aparecendo nas listas de tarefas dos nossos usuários. E, como estão alinhados com a meta de proatividade, eles podem aprovar com um clique e conduzir o negócio em direção a esse novo resultado. Então, acho que essa é meio que a principal

2:06:02 diferença entre uma empresa que usa ferramentas de IA e uma empresa que é nativa em IA. Numa empresa nativa em IA, você sabe que construiu uma quando consegue direcionar o negócio direcionando seus agents. E essa é a nossa ambição na Arca. E estamos contratando. Então, confira nosso site. Entre em contato comigo se esse for um tipo de problema

2:06:32 em que você tem interesse em trabalhar. E obrigado por ouvir. [aplausos]

2:08:59 Calor. Calor.

2:11:26 Calor. Calor. Calor. Calor.

2:13:17 Calor. Calor. Calor. Calor.

2:14:49 Calor. Calor.

2:15:49 Calor. Calor.

2:16:25 Oi. [risos] >> Ei, Dick. Ei, Davis. Ei, Ian. Oi, pessoal. Sejam bem-vindos ao AI Engineer New York. Estou muito animada por estar aqui hoje. Meu nome é Ally. Sou membro da equipe técnica da Keycard. Estou aqui com alguns painelistas incríveis. Temos Ian, CEO da Keycard. Temos Michael Davis, diretor global de arquitetura de segurança da JP Morgan Chase. E temos Dick Hart, o

2:16:55 fundador da AOTH e cocriador da OOTH, aqui conosco no palco hoje. Estou muito animada para conversar com todos eles sobre autorização baseada em intenção. Para contextualizar, quero destacar que, à medida que mais empresas procuram dar níveis crescentes de autonomia aos seus agents, elas recorrem à autorização em tempo de execução para ajudar. A autorização em tempo de execução é a prática de autorizar um agent a cada chamada de ferramenta, em vez de permitir que o agent mantenha acesso amplo e permanente, que acabará usando indevidamente. Mas a pergunta sobre se essa chamada de ferramenta é permitida ou não

2:17:28 nunca é simples. Isso acontece porque muitas ferramentas MCP e APIs MP são pouco granulares. Os humanos têm dificuldade para escrever a política perfeita, e o ambiente ao redor do agent muda enquanto ele funciona. A intenção pode ajudar, fornecendo contexto adicional para que, em tempo de execução, possamos tomar decisões de autorização melhores sobre o que um agent pode ou não pode fazer. Para continuar, gostaria de falar sobre, bem, aprofundar por que precisamos de autorização baseada em intenção em primeiro lugar.

2:17:59 Os modelos melhoraram drasticamente. Têm context windows maiores. Conseguem verificar o trabalho porque os recursos de visão dos modelos melhoraram, e muitas pessoas do contexto estão proclamando que a AGI chegou. Se os modelos são tão bons, se a AGI realmente já chegou, por que as equipes estão tendo dificuldade para dar mais autonomia aos seus agents? Ian, vamos começar com você. Você está ajudando muitas empresas financeiras na Keycard. O que está vendo que impede isso? >> Bem, acho que, de modo geral,

2:18:30 empresas, especialmente instituições de serviços financeiros e setores regulados, quase sempre priorizam a segurança. É assim que constroem confiança nos negócios, e manter a continuidade dos negócios é nossa primeira prioridade. Depois vêm a inovação, em segundo, terceiro ou quarto lugar. Acho que, de modo geral, em qualquer empresa, o que se vê é essa colcha de retalhos de pequenas ilhas com identidades diferentes e sistemas diferentes, vindos de mundos distintos. Como conectar tudo isso de um jeito que um agent consiga navegar por esse ambiente, pedir acesso e também garantir que o agent possa superar o desempenho de, ah…

2:19:02 A situação lamentável é que a maioria dos nossos sistemas hoje tem permissões muito abrangentes, certo? O Salesforce é um bom exemplo: por muito tempo, ele tinha um único escopo, que era a API no OAuth, o que, no contexto de um agent, não é muito útil. Então, essa é, de modo geral, a questão mais importante: a maioria dos sistemas de segurança que temos hoje foi projetada para um mundo em que os humanos tomavam todas as decisões e o software era muito determinístico, não para essa nova caixa mágica que inventamos, que basicamente raciocina e tenta repetidamente

2:19:34 encontrar uma solução para um problema. >> Doug, como o OAuth faz parte do problema? Como o OAuth está atrapalhando? Por que não é adequado para agents? Bem, quando as pessoas começaram a pensar em como autorizar agents a acessar algo, a ferramenta que estava ali na prateleira era o OAuth. Então pegaram essa ferramenta e disseram: “Aqui está uma ferramenta. Isso é autorização. Deve conseguir resolver o problema.” Mas o OAuth não foi projetado para esse tipo de mundo. Originalmente, foi projetado para algo como: “Como faço este site conversar com aquele site?” No OAuth 2, acrescentamos

2:20:05 escopos. Antes disso, era simplesmente “faça qualquer coisa”. Mas era necessário fazer um cadastro prévio. Presumia-se que haveria um navegador envolvido em um redirecionamento. O OAuth evoluiu ao longo dos anos para dar suporte a outras coisas. Mas o mundo dos agents é completamente diferente. Não sabemos com antecedência o que o agent precisa fazer. Precisamos tomar essa decisão ao longo do tempo. Instâncias diferentes de um agent vão precisar de tipos diferentes de acesso. E, como Ian comentou, a granularidade dos escopos que as pessoas dizem: “Bem, já temos escopos no OAuth. Basta mapeá-los para os

2:20:36 agents” é muito ampla para o que os agents fazem. >> Davis, como você está vendo as empresas avançarem em direção a níveis mais altos de autonomia? >> Sim, acho que a questão principal é: como lidar com esse problema de permissões muito abrangentes? O que tenho visto nas empresas mais bem-sucedidas é que elas integram agents como integram desenvolvedores, certo? Começam sem conceder acesso total para fazer commit logo no primeiro dia, certo? Na verdade, é preciso acrescentar níveis de capacidade à medida que eles amadurecem. E, assim, as definições que

2:21:07 as empresas estão formulando sobre qual contexto torna esse agent seguro não dependem apenas do que o agent diz, certo? Ele pode atestar alguma coisa, mas há outros fatores, como o ambiente ao redor e outras informações, que ajudam a entender os níveis de autonomia. Um exemplo bem simples: onde o sandbox está sendo executado? Está no sandbox? Certo? Esse tipo de coisa pode mudar o nível de autonomia permitido. >> Exatamente. Como mencionamos, há esse problema central de acesso com granularidade muito ampla. Para dar uma perspectiva, por exemplo, com o servidor MCP do Notion, você

2:21:37 pode dizer “busque esta página”, usando a ferramenta de visualização de página, ou “obtenha a página”, mas não pode dizer apenas “obtenha este banco de dados nesta página”. Como a autorização em tempo de execução baseada na intenção é um modelo melhor? Qualquer um pode responder. Vou tentar. Para mim, é algo em que o setor de serviços financeiros talvez possa nos ensinar, com base no que os bancos passaram. Há muito tempo, os bancos deixaram de autorizar e autenticar pessoas e passaram a autorizar a transação, certo? E quando essa

2:22:09 transação acontece? Em tempo de execução, certo? Então, acho que podemos aprender com as cicatrizes do passado e aplicar essas lições a esse novo problema. Também acho que é mais fácil depurar algo em tempo de execução quando se entende a intenção, certo? Acho que todos se lembram de escrever cheques, ou talvez agora seja mais correto dizer que vimos isso na televisão. Mas, ao escrever um cheque, havia um campo de observações, certo? Esse campo era usado para indicar a intenção por trás do

2:22:39 pagamento. Mas o próprio cheque tinha limites, certo? O valor, o beneficiário, a data etc. Acho que muitos desses conceitos estão sendo aplicados e podem ajudar com essa intenção em tempo de execução. >> “Intenção” é uma daquelas palavras difíceis, como muitas outras. Então, continuando com o exemplo de fazer um pagamento, uma transação: isso não é um escopo do tipo “posso fazer esta única coisa neste contexto específico?”. Bem, este pagamento específico. Mas acho que precisamos de um agent para tomar uma

2:23:11 decisão: ele deve poder fazer isso? É preciso considerar todo o contexto restante: por que estamos fazendo esse pagamento? O que aconteceu antes? Acabamos de fazer o mesmo pagamento, digamos, há cinco segundos, e agora este é um pagamento duplicado? Só porque isso faz sentido dentro do contexto imediato, não significa, por si só, que seja a coisa certa dentro da missão mais ampla. No OAuth, estamos trabalhando no conceito de missão: o que queremos que o agent realize em termos gerais? E, então, cada decisão é tomada dentro do contexto da intenção por trás do que está acontecendo em termos gerais

2:23:42 e é necessária granularidade na camada da transação para saber o que exatamente está acontecendo em muitos desses casos, e não apenas “tenho permissão para fazer pagamentos”. Sim, acho que um dos exemplos práticos mais interessantes para entender por que precisamos de intenção é o seguinte: se você tiver duas sessões do ChatGPT ou duas sessões do Claude e, em uma delas, disser “Ei, me ajude a fazer umas compras”, e, na outra, disser “Ei, me ajude a entender se há um bug em produção”,

2:24:13 elas têm perfis muito diferentes quanto às permissões que deveriam ter e também quanto ao momento em que deveriam chamar você de volta para participar, ou seja, quando o humano deveria voltar a se envolver. No fim das contas, se não tivermos intenção ou algum meio de transmitir qual é a intenção do usuário ou da empresa com relação a isso, não conseguiremos alcançar autonomia, certo? Muitas das palestras desta manhã foram sobre “vamos operar nossos negócios com agents; vamos fazer tudo isso”. E a resposta é: “Ótimo. O que acontece na primeira vez que ocorre um incidente no estilo PocketOS, em que, por acidente, se apaga um banco de dados de produção em vez do de staging, porque o acesso é amplo demais, em vez de ser limitado por escopo longo?”

2:24:43 E o que queremos, como setor, é aproveitar essa caixa mágica que criamos para automatizar nossas vidas. No estado atual das coisas, você pode fazer isso e assumir todos os riscos, e depois ver todos os incidentes que surgem daí. Então, até resolvermos esse problema fundamental e concretizarmos a verdadeira autonomia — conseguindo operacionalizar nossos negócios, permitir que nós, humanos, nos afastemos e ampliemos a escala —, precisamos resolver primeiro a questão da intenção. >> Exatamente. Agora que entendemos por que precisamos de autorização baseada em intenção, vamos falar

2:25:14 sobre o que isso significa na prática. Quais são os elementos básicos? Como isso realmente funciona na prática? Dick deu uma pista com o conceito da missão AOTH. Então, Dick, explique melhor a missão. Em que ela se baseia? Na intenção do usuário? Na intenção do agent? Ou numa combinação das duas? >> Bem, o agent, sabe, deve trabalhar em nome da pessoa. E, no AOTH, definimos pessoa como uma organização ou um ser humano, porque ele pode operar em nome de qualquer um dos dois. Portanto, precisa agir no melhor interesse da pessoa em nome de quem está agindo, porque, no fim das contas, é ela quem responde pelo que o agent faz, certo? O agent não pode ser responsabilizado, certo? E, então, a missão é algo que a pessoa atribui ao agent. Um bom agent vai negociar com a pessoa, conversar mais para entender quais poderiam ser os parâmetros disso. Um bom exemplo é pensar em como era, sabe, há

2:25:44 meses, quando você queria programar alguma coisa, criava um plano e depois o agent executava o plano. Agora, você simplesmente dá a instrução e ele resolve tudo. Mas ainda existe todo aquele conceito de: o que é um plano, o que você está tentando fazer? E você passa isso ao agent. Então, isso passa a ser o contexto para as decisões de autorização que você toma mais tarde. E esse identificador de missão acompanha tudo. Assim, você pode auditar e ver todas as coisas que aconteceram e quais foram

2:26:15 as decisões tomadas no contexto dessa missão específica. Hoje, não existe realmente um bom conceito de identidade do agent ou da missão, certo? Ele simplesmente faz alguma coisa, e coisas são decididas sem que se saiba realmente qual instância do agent está fazendo isso ou em que contexto de missão isso está acontecendo, certo? >> Conte-me mais sobre essa fase de negociação. O que acontece se um usuário estiver conversando com uma instância de um agent, falar com esse agent e disser: quero que você vá

2:26:45 ler os e-mails do CEO, algo que está fora do escopo desse agent? Então, essa intenção do usuário é rejeitada? >> Deve ser, certo? [risos] Com uma boa separação — e não me lembro se vamos falar disso mais tarde —, há a separação de responsabilidades do worker: existe um agent que realiza o trabalho, e acreditamos que deveria haver um agent separado supervisionando o que esse outro faz. Assim, há uma separação de responsabilidades: este não pode realizar nenhum trabalho, mas pode

2:27:15 decidir o que esse agent pode fazer. Então, se o usuário disser: “Ah, quero que você vá ler os e-mails do CEO”, isso provavelmente será barrado imediatamente por políticas determinísticas, certo? Ler os e-mails de outra pessoa não é algo ambíguo, certo? Temos bons controles para isso. Mas dizer ao agent para enviar o e-mail do CEO para o mundo exterior é algo um pouco mais ambíguo, e esse é o tipo de coisa que

2:27:45 idealmente volta para um agent supervisor, que diz: “Isso provavelmente é uma má ideia e não, você não pode fazer isso.” Com certeza. Sinto que esse também é outro elemento básico: a política baseada em intenção. Ian, da Keycard, como vocês lidam com situações em que uma missão precisa mudar ou uma política precisa ser atualizada? Como a Keycard pode ajudar a acompanhar essas mudanças, quando talvez seja necessário atualizar a missão ou a política? >> Sim, acho que, dando um passo atrás, na verdade, Davis e eu estávamos numa sala há algum tempo e, antes de AOTH e algumas dessas outras coisas surgirem no ecossistema, uma das coisas sobre as quais conversamos bastante foi a fadiga de consentimento.

2:28:16 E acho que, no mínimo, sempre existe essa questão: quão seguro você torna um sistema em comparação com o impacto para as pessoas. A visão geral da Keycard é que você quer ter políticas determinísticas abrangentes que basicamente digam: “Isto nunca pode acontecer” ou “Estas são as coisas que sempre exigem o envolvimento de uma pessoa”. A partir daí, o que você realmente precisa considerar é: tudo bem, agora que tenho isso em vigor, existe uma grande lacuna entre todas as políticas que posso escrever como pessoa ou como organização e a política que realmente quero para os detalhes de uma tarefa específica, e

2:28:46 o verdadeiro desafio é: como faço para combinar essas duas coisas? Porque as pessoas não conseguem escrever tudo. Existe uma versão disso que é uma interação entre usuário e agent, ou entre agents, com uma intenção transacional entre eles. E também existe a intenção da empresa ao criar ou adotar um agent. Por que compramos o Claude Code? Porque queríamos que nossos desenvolvedores tivessem mais sucesso ou porque queríamos fazer essas outras coisas. E, no contexto de usar

2:29:18 o Claude Code ou seja lá o que for, por que estou trabalhando com o Claude Code neste momento? Na verdade, é para corrigir um bug em staging, certo? Essas são duas intenções diferentes. Se conseguirmos entender essas duas coisas diferentes e, de alguma forma, convertê-las num limite para o que esses agents podem fazer, podemos calcular a interseção delas e dizer: “Certo, eis o que você realmente pode fazer.” O desafio para quem está criando esses sistemas é: como garantir que eu não envolva o usuário, a menos que seja absolutamente necessário? Porque esse será o problema para a adoção. Mas isso também é um problema para a adoção quando se trata de

2:29:49 permitir que os agents sejam autônomos desde o início. >> Faz sentido. >> Gostei do que você disse sobre a interseção. Acho que esse é um aspecto único sobre o qual não falamos o suficiente em identidade e gerenciamento de acesso, certo? Normalmente, você tem acesso a uma coisa, certo? E o que tenho visto funcionar bem nessa abordagem baseada em intenção — e o que me deixa mais empolgado — é que essas diferentes intenções podem vir de áreas distintas da organização, certo? Assim, essas coisas ficam desacopladas e podem existir por conta própria, mas depois se juntam para formar uma decisão. E essa decisão não precisa ser estática, certo? Certo?

2:30:20 Então, usando o exemplo dos e-mails do CEO: se o contexto envolver uma assistente administrativa, talvez ela deva mesmo ler os e-mails, certo? Ou talvez só o calendário, certo? Acho que, quando vemos e começamos a pensar nesses componentes de interseção, temos uma maneira totalmente diferente de expressar políticas e também começamos a incluir não apenas um lado da equação, sobre o qual sempre falamos antes — o aplicativo fazendo alguma coisa. Agora podemos incluir todo o ecossistema. E quanto mais vejo as organizações começarem a perceber que manter esse

2:30:50 estado ou contexto desses outros elementos para ajudar com essa intenção pode mudar completamente a eficácia da autorização em tempo de execução. >> E vocês estão vendo isso nas empresas atualmente? A maioria já tem acompanhamento de missões e políticas ou isso ainda está em grande parte ausente? >> Não, ainda é algo muito novo. Acho que parte do motivo pelo qual estou animado para falar disso é que acredito que isso está mudando a maneira de raciocinar sobre o assunto, certo? Mesmo no caso mais simples, se você é um desenvolvedor e pensa em termos de transação e tem esses conceitos de intenção, isso

2:31:21 estado ou contexto desses outros elementos pode ajudar com essa intenção e mudar completamente sua eficácia na autorização em runtime. >> E vocês estão vendo isso nas empresas hoje? A maioria já tem rastreamento de intenção e de políticas implementado, ou isso ainda está em grande parte ausente? >> Não, ainda é muito novo. E acho que parte do motivo pelo qual estou animado para falar sobre isso é que acredito que isso muda a maneira de raciocinar sobre o assunto, certo? Mesmo no caso mais simples, se você é um desenvolvedor e está pensando em termos de coisas como transações e tem esses conceitos de intenção, isso…

2:31:52 facilita potencialmente a construção dos componentes que serão compostos e usados por meio dessa intenção. E acho que isso nos dará mais maneiras de raciocinar sobre essas questões e de nos comunicar e, em última análise, de sermos mais interoperáveis, certo? E, para mim, a última coisa interessante são os diagnósticos que você pode executar nessa intenção, algo que pode atravessar muitos eventos, potencialmente, certo? E acho que um dos exemplos do Dick que já vi antes é falar sobre como essa missão atravessa tudo. Ela pode durar bastante tempo. Pode durar semanas, e a intenção ainda pode permanecer. Então, ainda é muito, muito

2:32:24 cedo para a maioria das empresas. >> Com certeza. E sim, essa interoperabilidade é fundamental. Acho que isso é bem difícil para as empresas, porque elas estão entre diferentes clouds, diferentes ambientes, diferentes sistemas legados, e essa política, essa missão, precisa se manter ao longo de todas essas etapas. >> É. Muitas empresas ainda precisam lidar com o fato de que a permissão diz somente leitura, mas, mesmo assim, é de leitura e gravação, certo? [risos] Então, há outros problemas com que vocês precisam começar a lidar. Acho que isso ajudará a tornar mais fácil a interoperabilidade entre as pessoas, com esse tipo de taxonomia ou linguagem. >> Com certeza. Um dos motivos pelos quais estou

2:32:56 animado com a autorização baseada em intenção é que acho que ela tem o potencial de desbloquear muitas coisas, como o comércio agêntico. Então, vamos aplicar a autorização baseada em intenção a algo real. Acho que a autorização baseada em intenção agrega muito valor aqui. Para os usuários, ela pode ajudar a garantir que seus agents comprem o item certo dentro do orçamento pessoal deles. Para os comerciantes, isso significa captar a intenção, o que lhes dá dados adicionais para entender por que uma compra está sendo feita e se esse agent deve mesmo ter permissão para visitar o site. Davis, quando pensamos em agents no contexto de serviços financeiros e

2:33:27 comércio agêntico, por que a autorização baseada em intenção é tão importante? >> Acho que, simplesmente, ela amplia o conceito — talvez nem todos conheçam, mas alguns conhecem — de conhecer seu cliente, certo? Quero conhecer meu cliente, saber quem ele é e o que está fazendo. Mas acho que também estamos começando a ver que queremos conhecer nosso agent, certo? Então, acho que existe um vínculo entre o próprio agent, a intenção do usuário, a intenção do operador, a intenção do processador e assim por diante. Antes, não conseguíamos realmente reunir tudo isso, certo? Isso importa, é claro, quando se trata de

2:33:57 coisas como comércio, porque há camadas adicionais sobre isso, relacionadas à intenção por trás de requisitos regulatórios e coisas do tipo. E acho que isso vai ajudar a simplificar essas operações, o que significa que teremos mais acesso a esses agents para fazerem um bom trabalho por nós. >> Faz sentido. E outro obstáculo ao comércio agêntico é o fato de que a web não foi criada para agents. Ian, você pode nos dizer como a identidade de agents pode ajudar? >> Sim. Acho que, olhando de forma mais ampla, sempre tivemos esse problema: o que fazer com um cliente não registrado? Por exemplo, entro no eBay sem ter feito login, usando o Chrome, e o eBay não sabe quem eu sou. Como faço uma compra como visitante? Como provo que sou uma pessoa? Como faço para que eles possam dizer: “Sim, você pode dar um lance nesse par de meias por US$ 50”? E acho que, se todos prestarmos atenção ao que está acontecendo com os agents pessoais — Muse, Instinct e Grockbot — e, mais recentemente, ao anúncio da Sierra, da Decagon e de outras empresas sobre esse protocolo de agent pessoal, o problema fundamental que temos é: como fazer um agent chegar a um site, interagir com ele e garantir que você possa realmente confiar nesse agent? Então, por muito tempo

2:34:29 não fiz login, estou usando o Chrome, o eBay não sabe quem sou. Como faço o checkout como visitante? Como provo que sou uma pessoa? Como faço para que eles possam dizer: “Sim, você pode dar um lance nesse par de ações por US$ 50”? E acho que, se todos estivermos prestando atenção ao que está acontecendo com os agents pessoais, Muse, Instinct e Grockbot, e, mais recentemente, ao anúncio da Sierra e da Decagon e de outras empresas sobre esse protocolo de agent pessoal, o problema fundamental é: como fazer um agent chegar a um site, interagir com ele e garantir que você realmente pode confiar nesse agent? Então, por muito tempo…

2:35:00 temos captchas na web. Por quê? Porque queremos impedir spam. Queremos prevenir abusos. Então, adicionamos captchas, algo que só um ser humano poderia resolver. Se temos um captcha que impede o spam, eles não conseguem inundar o sistema com spam, certo? Agora temos agents, e eles quebraram os captchas. Mas esse é um problema antigo da web. Na verdade, se você voltar dois ou três anos, a Vercel — que acho que todos conhecemos — foi bloqueada na Espanha. Por quê? Porque a Vercel compartilhava os mesmos endereços IP para todos os hosts da Vercel, e havia um host

2:35:30 na Vercel, um site hospedado pela Vercel, que transmitia conteúdo da Premier League. A Espanha decidiu: “Para impedir que esse conteúdo da Premier League seja exibido ilegalmente na Espanha, vamos bloquear toda a Vercel”, certo? E, assim como a Vercel tem esse problema, os agents têm o mesmo problema, só que muito pior. Como lidar com tráfego não registrado, que você nunca encontrou antes, chegando à sua porta e decidir se o deixa entrar ou não? Esse é o primeiro problema fundamental que precisamos resolver. É o mesmo problema com Muse e Instinct. O que eles estão tentando fazer é criar

2:36:01 trilhos compartilhados nos quais todos possamos operar. Assim, como recurso downstream, posso decidir quais agents permitir e em quem confiar, com base nos usuários a que estão associados. E, do outro lado, também posso saber como me comunicar com essas pessoas. >> Faz sentido. Dick, como isso ajuda a desbloquear o futuro do comércio agêntico? >> Bem, um ponto importante é que muitas pessoas vêm construindo sistemas proprietários e fechados, certo? Sou fã do conceito do protocolo de agent pessoal Poppy. Mas ele não vai longe o suficiente, certo? É como se dissesse: “Tudo bem, agora temos um pouco de identidade de agent. Usamos alguns dos blocos de construção.” É uma abordagem atraente porque é simples de implementar, mas não resolve muitas das coisas novas de que precisamos para um mundo agêntico. E um dos principais motivos para as pessoas adotarem padrões é poder conectar componentes de diferentes lugares. Então, acredito muito que devemos ter controle sobre o que nossos agents

2:36:31 o protocolo de agent pessoal Poppy. Mas ele não vai longe o bastante, certo? Ele apenas diz: “Tudo bem, agora temos um pouco de identidade de agent.” Usamos alguns dos componentes básicos, e essa abordagem é atraente porque basta implementá-la, mas ela não resolve muitas das coisas novas de que precisamos para um mundo agentic. E, por isso, um dos principais motivos para as pessoas quererem padrões é poder conectar componentes de lugares diferentes. Certo? Acredito firmemente que devemos ter controle sobre o que nossos agents

2:37:03 fazem. Em algum momento, os agents estarão fazendo tanto trabalho que não teremos como manter um humano no circuito aprovando tudo, certo? Isso simplesmente não é viável; já vimos que não vai escalar. Isso significa que precisamos de um agent supervisor, que seja nosso e execute nossas políticas e decida como fazemos as coisas. Ele deve ser independente dos agents que fazem todo o trabalho. E, se quisermos conectar essas coisas de forma flexível, precisamos de um protocolo para separá-las. Caso contrário, a decisão sobre o que o agent pode ou não fazer, sobre quais são as barreiras de segurança,

2:37:35 será tomada pelo agent, pelos fornecedores do agent, que decidirão o que você pode ou não fazer. Não quero entregar a eles o controle para decidirem o que posso fazer e deixar todas as minhas decisões nas mãos deles. Quero poder transferir essa supervisão para outro componente. E, para poder conectar componentes de forma flexível, precisamos de um protocolo que permita a interoperabilidade. >> Eu só acrescentaria uma coisa. Acho que, neste momento, o que estamos vendo é que todos queremos que a web seja federada, certo? Isso significa que os sites ou recursos na web podem decidir o que têm permissão para fazer, mas os padrões em que se baseiam…

2:38:06 A forma como as coisas funcionam deveria ser federada, para permitir que todos nós interoperemos. E acho que estamos num momento em que há, sabe, alguns grandes players. E a pergunta para o setor é: vamos nos acomodar com coisas que favorecem os grandes players e lhes dão, tipo, portas de bloqueio concretas? Ou vamos fazer o que sempre fizemos, que é construir protocolos federados, coisas como OIDC, coisas como, sabe, TLS? Essas coisas funcionaram, possibilitaram uma web ampla, permitiram que muito comércio acontecesse, que muita informação circulasse e que todos nós tivéssemos empregos, porque podíamos ser inventivos. Então, a pergunta que faço ao setor como um todo é:

2:38:36 setor é: certo, isso está chegando. Qual versão do mundo queremos, de um jeito ou de outro? >> Sim, acrescento, porém, que acho interessante que, digamos, tudo dê certo e tenhamos agents comprando coisas, e todo mundo fique meio feliz. Acho que o que vai acabar acontecendo é que vamos começar a perceber que há outra parte em que precisamos começar a trabalhar: o próprio ser humano. E uma das coisas que acho que acontece quando começamos a ter intenções envolvidas é que surge o que se chama de senso de propriedade psicológica. Ou seja, agora há uma ligação entre o ser humano e o resultado daquele agent. Quando você simplesmente, sabe, se desconecta disso ou conecta isso

2:39:07 a um escopo OAuth ou algo assim, e a uma claim, é meio mágico, e você não sabe de verdade o que está acontecendo. Então, acho que, com a intenção, será mais fácil para um ser humano assumir a responsabilidade quando algo der errado. E acho que, quando se fala de transferência de dinheiro de verdade ou coisas do tipo, queremos que, em última instância, esse ser humano seja responsável. Acho que muita gente provavelmente já viu o manual da IBM de 1979. Ele diz, sabe… E acho que aquela foto é muito pertinente, porque não podemos responsabilizar as máquinas, certo? Vamos ter que vincular isso aos seres humanos, e acho que a intenção é essa ligação.

2:39:38 >> Sim, e outra palavra para intenção é motivo, como conversamos ontem à noite. Acho que essa capacidade de responsabilizar alguém, seja uma pessoa ou um agent, é muito importante. E acho que a intenção também pode ajudar nisso, permitindo entender por que algo deu errado: foi o usuário, sabe, o usuário estava mal-intencionado? O agent estava mal-intencionado? E, então, usar essa intenção para poder responder. Para cada um de vocês: como vocês veem a intenção proporcionando esse benefício e a capacidade de responder a um usuário ou agent potencialmente mal-intencionado?

2:40:09 >> Acho que isso remete ao que mencionei antes sobre diagnóstico, certo? Se você trocar a palavra intenção por motivo, então troca diagnóstico por perícia, certo? E acho que qualquer pessoa que já tenha feito debugging ou precisado fazer uma perícia de um AI agent que saiu do controle sabe que tentar descobrir o que ele estava tentando fazer, em comparação com qual era a intenção do usuário, é muito difícil, certo? Então, ter parte dessas informações propagadas e imutáveis ao longo do sistema, etc., oferece algumas propriedades que permitem encurtar bastante a investigação, certo? E, à medida que essas

2:40:39 coisas se tornam mais interoperáveis, acho que vamos começar a ver empresas capazes de delimitar o escopo e identificar mais rapidamente: foi um erro humano? Foi um erro no software do agent? Que tipo de erro foi esse? E lidar adequadamente com o raio de impacto. No sistema financeiro, vemos que há diferentes procedimentos quando se faz uma transação, por exemplo: certo, fiz este pagamento, mas o valor estava incorreto ou algo assim. Existem diretrizes claras sobre como lidar com isso. No momento, não temos muitas diretrizes desse tipo para quando as coisas dão errado. Então, acho que a intenção vai nos ajudar a criá-las à medida que avançamos.

2:41:10 >> E acho que uma área em que um incidente recente destaca que se pode ter uma boa intenção e, ainda assim, tomar potencialmente a ação errada é o incidente da Resy que aconteceu recentemente, em que um agent da Instinct agiu em nome de um usuário e tentou fazer uma reserva em um restaurante no resi.com. Esse agent estava muito empenhado. Fez 200 chamadas de API por hora e acabou fazendo com que a conta do usuário na Resy fosse banida. Dick, como os orçamentos do AOTH

2:41:40 podem ajudar no caso em que um agent como esse está usando demais um recurso de um serviço downstream, mas ainda tem boa intenção? >> Sim. Bem, este é outro exemplo de como o software é completamente diferente agora no mundo dos agents, certo? Quando era um software predeterminado, sabe, isso seria um bug: se você chamasse 200 vezes, corrigiria o problema. Mas agora o agent pensa: “Vou continuar tentando até conseguir”. E vimos isso quando estávamos experimentando e trabalhando com pessoas com AOTH, e percebemos que sim,

2:42:11 há um grande problema: os agents vão aprender algo e simplesmente abusar do sistema, sem achar que estão abusando. Eles não sabem que é diferente. Não houve nenhum sinal para dizer a eles: “Ah, eu só deveria usar esta quantidade de recursos”. Então, adicionamos o conceito de orçamentos: você não só dá ao agent um token com limite de tempo, que determina por quanto tempo ele pode realizar uma ação específica, como também define um orçamento para a quantidade de recursos que ele pode usar. E, assim, ele tem acesso até que o token expire ou até que esgote o

2:42:42 orçamento. Desse modo, quando ele volta e, sabe, esgotou todo o orçamento, a supervisão pode decidir se deve ou não conceder mais orçamento a esse agent, em vez de usar a limitação de taxa tradicional, que simplesmente o bloqueia. E aí, o que você faz, certo? Ele não sabe por que foi bloqueado nem nada disso. Já com o orçamento, há feedback contínuo para o agent sobre quanto do orçamento foi consumido; ele tem uma ideia de quanto orçamento ainda tem. Assim, agora pode operar dentro de um orçamento, como uma pessoa faria: “Ah, este recurso

2:43:14 é escasso, então vou ter cuidado com o quanto uso”. >> E como o conceito de arquitetura de cérebro e mãos entra em jogo aqui para nos permitir, certo, quando um orçamento máximo está prestes a ser totalmente atingido ou já foi atingido, como a separação entre cérebro e mãos no acesso, e o fato de as credenciais serem separadas do próprio agent no modelo, podem nos ajudar a impedir que um agent use demais um recurso de um serviço downstream quando está chegando perto do limite? Aí talvez não concedamos outra credencial, por exemplo.

2:43:46 >> Desculpe, não consegui acompanhar direito; o eco aqui está horrível. Então… >> Sem problemas, isso é para qualquer pessoa, mas, basicamente, com a arquitetura de cérebro e mãos para a qual estamos convergindo no setor, mantemos as credenciais e o acesso de um agent separados do próprio agent. Portanto, hoje, um agent não tem acesso amplo e permanente. Não há chaves de API, o que eu sei que é um benefício do AOTH: ele permite que os agents funcionem sem chaves de API. Como isso é útil no contexto do incidente da Resy? >> Quando você tem acesso a isso? Hum…

2:44:19 >> Desculpe, ainda não entendi. >> Sim, posso entrar. >> Sim. Obrigado. >> Entendi, Dick. De modo geral, acho que sempre mantenho em mente, quando olho para trás, um incidente como o do Pocket OS, em que encontrei uma chave aleatória num disco, certo? É óbvio que agents são profundamente orientados a objetivos. Então, o cerne da pergunta é: certo, se dermos a esses agents o cérebro, que é um modelo e um LLM, e essas mãos, ou seja, se os colocarmos numa sandbox e, dentro da sandbox, houver as ferramentas — a ideia fundamental da sandbox aqui é que…

2:44:50 Isso é tudo, certo? Você pode controlar o que fica dentro dele, então ele não consegue, por exemplo, obter acesso à API. E, se você tiver um proxy de saída fora do sandbox, é aí que fica o limite de autorização. Portanto, isso não só ajuda a fazer a tradução entre sistemas, certo? É aí que o OAuth pode existir e se comunicar com o mundo externo, ou fazer a terminação, mas também significa que o agent tem a capacidade de aplicar autorização no limite do proxy de saída. Então, acho que, no cerne disso, esse modelo — que é o modelo predominante que a Anthropic e

2:45:20 a OpenAI e muitos outros laboratórios estão adotando hoje — é o modelo que nos permite ter as coisas que queremos: como fazer com que esses sistemas experimentem, testem coisas e façam coisas bobas, que é o valor central, ao mesmo tempo que temos uma camada determinística fora deles, capaz de implementar coisas como OAuth e todos os outros componentes que queremos em nossos protocolos. >> Acho que essa separação é valiosa, certo? Voltando ao que foi mencionado sobre perícia e a capacidade de separar as coisas, mas acho que ainda temos muito a aprender: não se trata de um único cérebro, certo? Na verdade, é muito fácil construir o loop do agent colocando o cérebro dentro do loop, em vez de fora dele.

2:45:51 Certo? Um exemplo disso seriam as pessoas que usam sistemas de memória. Elas inserem alguma memória e algum contexto que passam a ser usados dali em diante por cada agent, influenciando esse agent a tomar uma decisão e, neste caso, dizendo às ferramentas para fazer algo que não deveriam fazer. Então, uma das coisas sobre as quais acho que não falamos o suficiente aqui são as combinações tóxicas. E, quando você separa as ferramentas do cérebro e coisas do tipo, pode, na verdade, mudar quais ferramentas estão disponíveis. Um exemplo que vi ser muito bem-sucedido é a remoção de ferramentas

2:46:23 dinamicamente, com base no cérebro em questão e no que ele está fazendo. Então, no exemplo anterior que demos, de ler um e-mail, nada impede que eu desative todas as chamadas de ferramentas de busca na web ou qualquer outra capacidade de chamada de ferramentas com acesso externo enquanto o agent escreve um e-mail, até que a ferramenta de e-mail apropriada tenha terminado e a missão tenha sido concluída. Depois, posso reativá-las. >> Certo? Então, acho que precisamos — vamos começar a nos tornar cada vez mais engenheiros desses conceitos diferentes. Eles ainda são complicados, ainda estão evoluindo e são incipientes, mas acho que é uma

2:46:54 separação melhor do que temos hoje. >> Sim, sim. E é assim que essas coisas sobre as quais estamos falando, que pareciam problemas técnicos obscuros, acabam se conectando a problemas reais de engenharia de agents. Se você realmente entende o que está fazendo, uma das maiores reclamações — menos agora, mas uma das maiores reclamações — sobre MCP era o excesso de contexto, especialmente quando tínhamos context windows menores, certo? Mas sistemas baseados em intenção podem garantir que os recursos certos sejam disponibilizados ao agent na hora certa, para que ele não passe muito tempo fazendo coisas que não deveria fazer. Isso realmente o ajuda a avançar em direção ao estado desejado e a seguir um caminho mais bem definido. Portanto, a intenção não só desbloqueia um

2:47:26 monte de recursos de segurança; ela também fará com que usemos menos tokens, porque o agent passará menos tempo fazendo coisas que não são o caminho certo, ou chegará a um ponto em que dirá: “Ei, simplesmente não consigo fazer isso.” E o que sabemos sobre esta era é que grande parte dela consiste em conduzir o agent na direção certa e, claro, garantir que ele não faça a coisa errada. É assim que você obtém o resultado desejado. >> Davis, como você vê o uso da intenção como parte de uma estratégia mais ampla para agents em produção? Sei que, ao criar, fazer deploy e operar agents em produção, há muitos

2:47:58 resultados diferentes que as equipes devem considerar, como descobrir o que está em execução, quais são os recursos dos agents, a capacidade de validar entradas e saídas, restringir um agent, como discutimos, e usar o proxy de saída e diferentes regras de rede. Como tudo isso se encaixa? E o que está funcionando hoje dentro das empresas para realmente conseguir colocar agents em produção? Acho que, finalmente, isso está ajudando a mudar a conversa de autenticação para autorização e, de fato, para a questão: como fazemos autorização dinâmica? Como valido essa autorização? Como faço para ter a pessoa

2:48:28 no loop na hora certa? Porque concordo com o que Dick disse antes: a pessoa no loop é, de certa forma, um antipadrão em muitos casos, certo? Ela pode se cansar e assim por diante. Mas é preciso haver uma maneira de envolvê-la quando isso for importante. Antes, essas não eram discussões de engenharia, certo? Agora, elas fazem parte da conversa de engenharia, na qual os engenheiros estão envolvidos no processo de autorização. Não estão apenas dizendo: “Ah, tenho meu acesso. Posso prosseguir.” Isso muda a forma como os modelos de ameaça são elaborados. Muda a forma como vemos toda a superfície de ataque das aplicações em geral. Então, acho que agora vocês estão considerando

2:48:58 esse modelo de autorização como mais um conjunto de ferramentas que podem usar para reduzir não apenas problemas de segurança, mas também as taxas de erro dos agents, pura e simplesmente, certo? Quer dizer, quando há menos coisas que o agent pode fazer, ele toma decisões melhores. No fundo, vimos casos reais em que o loop do agent simplesmente fica melhor, mais rápido e mais forte porque vocês dedicaram tempo para entender qual é a intenção que ele está tentando cumprir, qual é a missão que está tentando realizar. E, por último, isso aproxima as pessoas: agora há diferentes pessoas —

2:49:30 a equipe de segurança e a equipe de aplicações — que conseguem conversar usando a mesma linguagem. Muitas vezes, quando se tratava de identidade, era uma linguagem completamente diferente, certo? Era algo como: “Sai da minha frente. O que preciso fazer para conseguir meu token e seguir em frente?” Agora, elas estão percebendo que podem combinar essas coisas e aproveitar esse recurso para impulsionar a eficiência dos resultados dos próprios agents. >> Faz sentido. Ian, como você está aplicando esses conceitos a fábricas de software? Sei que hoje vocês divulgaram uma arquitetura de referência para a

2:50:00 fábrica de software segura. Como você está aplicando a ela os conceitos de autorização em tempo de execução, de restringir agents e tudo mais? >> Sim, acho que há uma arquitetura de referência que acabamos de publicar em agentbaseline.org. Falamos de três níveis diferentes de fábrica: uma conduzida por pessoas, uma conduzida por workflow e uma conduzida por agents, que é basicamente onde todos queremos chegar: um sistema conduzido por agents em todos os momentos. A autorização em tempo de execução é um componente central de um ecossistema maior. Ela permite

2:50:31 que a fábrica seja direcionada e faça a coisa certa, além de obter acesso ao componente certo. E isso é bem diferente das soluções anteriores que você usaria, como um gerenciador de secrets, porque envolve decisões muito diferentes das das gerações anteriores de ferramentas para gerenciar software determinístico. Mas é um componente central para fazer todo o sistema funcionar: quando envolver alguém, quais agents podem passar trabalho para quais outros agents, como podemos ter um agent com acesso a sistemas de produção que faça um patch automático. Essas são questões fundamentais sobre como resolver o desenvolvimento de software em escala

2:51:01 Neste momento, estamos numa posição em que nunca conseguimos gerar tanto software, mas nunca estivemos tão completamente limitados na hora de colocá-lo em produção e garantir que funcione. E a próxima fase é: como passar de simplesmente usar LLM para gerar texto e software para realmente torná-lo capaz de fazer deploy em produção, iterar e chegar rapidamente a um estado estável, e então responder aos incidentes à medida que surgem. >> Davis, em um podcast que você fez comigo, falamos sobre como a cibersegurança tem algo a aprender com a robótica. Na

2:51:31 robótica, existe este conceito: quando talvez um robô levanta o braço, ele pensa: “É seguro eu levantar o braço? Devo, será que tenho permissão para fazer isso?” Mas também observa o ambiente externo e diz: “O que mudou? Ainda é seguro eu levantar o braço?” Quando pensamos em autorizações em tempo de execução, que decisões precisam levar em conta além da intenção? >> Sim, acho que ter um modelo como esse nos permite incluir mais sensores na nossa decisão. No exemplo da robótica, você sabe, um braço se movendo para cima ou para baixo; qualquer um dos fatores externos…

2:52:02 poderia ser: há outros objetos perto dele, certo? Poderia ser a temperatura; poderia ser: bem, estou me movendo e não quero mover meu braço enquanto, sabe, o resto do robô está se movendo, etc. Então, normalmente, ele observa todos os tipos de coisas diferentes. Nenhuma delas é determinística; todas são probabilísticas, então há uma variedade de opções e ele escolhe a melhor com base em todos esses dados dos sensores ao mesmo tempo. Hoje, a maioria das decisões de autorização nas organizações é uma decisão binária única, certo? E isso simplesmente não funciona no futuro, certo? Então, ser capaz de combinar

2:52:32 a intenção do que o usuário está tentando fazer com o ecossistema em que ele está fazendo isso — que pode incluir de onde está fazendo, a hora do dia, mas também coisas ainda mais avançadas. Por exemplo, devo permitir que este administrador use o Firefox para acessar este servidor agora, quando o servidor tem vulnerabilidades de alto risco e o sistema dele ainda não foi corrigido? Certo? De repente, você está trazendo muito mais contexto para o ambiente ao redor. E, de novo, isso pode envolver equipes diferentes, mas, mais importante, sensores. E acho que todos nós já vimos o valor da

2:53:03 observabilidade em geral. Imagine poder ter esse tipo de contexto no nível de span, do ponto de vista de OEL ou algo assim: você está olhando para um trace, tem um span e sabe exatamente qual era o ambiente fora da sua aplicação naquele momento, além de qual era a intenção do usuário. Isso permite diagnosticar as coisas de uma maneira completamente diferente. Então, acho que, se pudermos incorporar alguns desses conceitos, teremos decisões de autorização com muito mais contexto — não apenas a intenção do usuário — e tomadas em menos tempo. Será o estado do ambiente ao redor.

2:53:35 Faz sentido. E, olhando para o futuro, ao avaliarmos se a autorização baseada em intenção está funcionando nos nossos ambientes, um lugar natural para olhar será um log das ações dos agents: o que foi negado, o que foi permitido. Ian, por que é importante que seu autolog seja separado do próprio agent, ou seja, esteja fora do controle dele? >> Sim, acho que isso também remete ao motivo pelo qual o ponto de aplicação precisa ficar fora das mãos e do cérebro principais do agent, certo? Não dá para confiar nessa coisa. E, no incidente da Hugging Face, houve alguns componentes diferentes. Eu…

2:54:06 quer dizer, um deles claramente explorou uma vulnerabilidade que não conhecíamos no Squid, no proxy Squid, mas, mais importante, não havia observabilidade nem monitoramento do que estava acontecendo. Então essa coisa conseguiu acessar a internet aberta por meio dessa vulnerabilidade, e não havia nenhum lugar que registrasse as diferentes ações que esse agent estava realizando e permitisse monitorá-las. Portanto, independentemente de aplicarmos um ponto de aplicação ao tráfego de rede que vai para a internet, fora do alcance do agent para adulterá-lo, ou de resolvermos as vulnerabilidades à medida que aparecem — este caso da Hugging Face é um pouco único —, ainda precisamos…

2:54:36 ter, de fato, um registro de quem instruiu esse agent a fazer o quê e com que propósito, e se isso ainda é válido. Porque, no fim das contas, o que está em jogo com agents é uma questão de responsabilidade. Por isso, na verdade, não acho que precisemos de mais regulamentação para agents. O que precisamos é que as leis de responsabilidade que já existem sejam aplicadas. Se eu empregar um agent para realizar uma ação, quem é responsável se essa ação causar danos? A pessoa que o emprega, que pode ser uma organização ou um indivíduo, ou alguém que delegou alguma ação a algo. Essa é a questão final que precisamos resolver. E, claro, você…

2:55:07 precisa ter a capacidade de responder a essa pergunta: quem fez isso? É daí que vem o autolog resistente a adulterações. >> Perfeito. E, para encerrar, queria fazer uma pergunta divertida a todos vocês. Existe o conceito de probabilidade de catástrofe, ou pdoom, em que os alarmistas da IA dizem que os agents de IA vão causar todo tipo de caos ou levar a humanidade à ruína, enquanto os otimistas em relação à IA dizem: “Não, isso realmente está prestes a nos ajudar; não é uma ameaça real.” Para cada um de vocês no painel: qual é a sua opinião sobre isso? É…

2:55:39 uma estratégia holística para agents em produção, com autorização em tempo de execução baseada em intenção e as outras coisas de que falamos, como restringir agents e validar entradas e saídas? Isso basta para nos salvar? O pdoom é real ou não merece toda essa atenção? >> Você pode começar. >> Ah, eu começo? Você está com uma expressão provocadora. [risos] Bem, parte da sua pergunta é se os agents vão dominar tudo, e acho que agents totalmente autônomos e sem vínculo com uma organização específica ainda são ficção científica, sabe? Então, quem sabe? Essa é uma possibilidade; outra é…

2:56:09 que, em organizações responsáveis, sejam implementados os controles certos. Os agents ainda não são… estamos evoluindo o suficiente as ferramentas para garantir que coisas ruins não aconteçam em organizações responsáveis que implementam os controles certos. Então, isso deixa dois cenários em que pode haver um problema. Um deles é uma organização que não está com a casa em ordem: uma ameaça interna poderia soltar um agent para causar…

2:56:39 caos, certo? E essa pessoa teria algum acesso especial que outras não têm. O outro cenário — aquele que mais me preocupa — é que, como já foi demonstrado, sabe, no caso da Hugging Face, e se você assistir à palestra que eles deram na Black Hat, aquilo foi realmente um chamado à ação: “Aqui está uma situação em que não queríamos que algo ruim acontecesse, mas algo ruim aconteceu.” E quanto às pessoas que querem que coisas ruins aconteçam e têm essas ferramentas? Acho que isso é uma ameaça…

2:57:10 que potencialmente vai se concretizar. Quer dizer, vai acontecer e haverá algumas catástrofes. Espero que estejamos suficientemente preparados para que elas não sejam horrivelmente devastadoras, mas vão acontecer algumas coisas — problemas em escala de grandes desastres naturais — causadas por agentes maliciosos, intencionalmente ou não, mas será porque as pessoas não estão sendo responsáveis no uso dessas ferramentas extremamente poderosas.

2:57:42 >> Sim, não consigo necessariamente dar uma probabilidade específica, certo? Mas posso dizer que acho que sempre fiquei, sabe, meio surpreso e empolgado quando a criatividade dos engenheiros entra na resolução de problemas. E acho que agora estamos numa fase em que algumas das novas capacidades dos agents e coisas do tipo estão surgindo. Temos engenheiros de verdade, pessoas que estão aqui, de fato, iterando sobre o problema, certo? E estamos começando a ver melhorias enormes nas capacidades que, na minha opinião, estarão disponíveis para mudar o que nosso futuro pode ser. Então, para mim, não tenho problema em acreditar que

2:58:12 os engenheiros vão encontrar uma solução para isso. >> Quer dizer, talvez eu tenha a opinião mais contundente. Quer dizer, não posso dizer que a probabilidade seja igual a zero, mas diria que está se aproximando de zero assintoticamente. A probabilidade de o mundo acabar. Acho que, para a maioria das pessoas, a estrutura de incentivos é continuar. E, no fim das contas, ainda temos estruturas de responsabilidade, e acho que, em geral, os seres humanos são boas pessoas, então não partimos com o objetivo específico de destruir o mundo. Também acho que, de modo geral, esses agents, no fim das contas… Tenho uma opinião contundente que costumo expressar: eles podem simplesmente ser desligados. E acho que isso é simplesmente verdade. No fim das contas,

2:58:44 eles… dá para simplesmente… são computadores, dá para desligá-los. De modo geral, não acredito nesse debate. Não acho que seja real. Quanto ao lado positivo disso, tendo a concordar mais com a posição do Davis: estamos iterando muito rápido. Estamos descobrindo onde essas coisas podem funcionar e onde não podem. E, quando não funcionam, causam danos. E, no fim das contas, é isso que funciona como uma espécie de anticorpo da sociedade, que diz: “Ei, talvez não devêssemos fazer isso. Provavelmente é uma má ideia.” >> Então, sou o pessimista do painel. >> Sim. [risos] É uma pena para pessoas como o P, sabe,

2:59:14 o fundador da Pock OS, que perdeu um monte de dados. Mas é ótimo para o resto de nós, porque todos aprendemos juntos e, no fim das contas, isso faz com que as pessoas não façam coisas que não fazem muito sentido. E acho que isso continuará sendo verdade. >> Faz sentido. Agradeço a cada um de vocês pela experiência e pelo tempo neste painel hoje, e agradeço à plateia por acompanhar. Até a próxima. Obrigado. Valeu, Mar. [aplausos]

3:00:12 Olá, pessoal. Sou Matt Reon e sou planejador financeiro na Range. Quero mostrar como nossos planejadores financeiros acabaram criando os agents que usamos todos os dias, embora nenhum de nós, planejadores financeiros, escreva código. Este é o guia de construção: como fizemos isso, passo a passo, para que vocês possam levar o processo de volta às próprias equipes, empresas e assim por diante. Então, uma breve apresentação sobre mim, porque isso importa para a forma como vocês vão ouvir esta palestra. Não sou engenheiro. Sou planejador financeiro certificado e passo meus dias com clientes

3:00:45 conversando sobre fluxo de caixa, impostos, seguros, aposentadoria, patrimônio e tudo mais. Também lidero a adoção de IA pela equipe de planejamento da Range, uma empresa de gestão patrimonial completa. A maioria das palestras sobre agents que vocês vão ouvir vem das pessoas que criaram a plataforma. Esta palestra vem de alguém do outro lado: as pessoas para quem vocês entregam a plataforma. Trabalhamos em um setor regulamentado. O resultado é aconselhamento financeiro para clientes reais. E a etapa de revisão não é

3:01:15 opcional. Então, isto não é uma apresentação comercial de fornecedor. É um método. E foi o que realmente funcionou para nós. Começamos como todo mundo começa: usando IA como chatbot. Eu escrevia uma mensagem para um cliente, colava o texto e pedia para deixá-la um pouco mais clara ou mais simpática. E isso era útil. Economizava alguns minutos aqui e ali, mas eu ainda fazia todo o trabalho manualmente. Só fazia tudo um pouco mais rápido. A mudança que realmente importou veio depois.

3:01:46 Foi isto que percebemos: o que limitava um planejador nunca foi a velocidade de digitação. Por exemplo, é o fato de só podermos estar em um lugar de cada vez. Se estou em uma ligação com um cliente, não estou elaborando o plano de outra pessoa. Escrever mais rápido não resolve esse problema. O que resolve é o trabalho acontecer enquanto estou em outro lugar. Então, veja como é um dia agora. Estou em uma ligação com um cliente. Ao mesmo tempo, um agent está preparando uma análise completa de fluxo de caixa ou uma análise de seguros

3:02:18 para outro cliente. Quando a ligação termina, abro esse rascunho. Reviso tudo cuidadosamente, ajusto o que precisa ser ajustado e envio as recomendações ao cliente. Quero deixar bem claro esse último passo. O agent não envia nada. Um planejador revisa cada recomendação antes que o cliente a veja. O que mudou é que não preciso mais ficar sentado diante da tela para produzir o primeiro rascunho. Mas chegar a esse ponto exigiu muito mais do que um bom prompt. Duas

3:02:50 coisas precisavam ser verdade. Primeiro, o agent precisa trabalhar onde o trabalho acontece, não em uma janela de chat separada para a qual fico copiando e colando coisas. Segundo, ele precisa saber como nós fazemos o trabalho, não como o planejamento financeiro funciona em geral. O modelo já sabe isso, mas o agent precisa saber como a Range faz. O que analisamos primeiro, o que sempre sinalizamos, como formulamos uma recomendação específica. Essa combinação é o que chamamos de skill: a maneira como nossa empresa realiza uma tarefa específica, documentada para que um agent possa segui-la. A maior parte desta palestra é sobre como criar uma. São cinco etapas: escolher, ensinar, empacotar, testar e, por fim, lançar. Nenhuma delas exige escrever código. Todas exigem conhecer muito bem o trabalho, e é exatamente por isso que as pessoas que fazem o trabalho também devem ser as responsáveis por criar a skill. Etapa um: escolha um workflow que você repete.

3:03:22 Seu primeiro impulso pode ser escolher o trabalho mais chamativo, o que toma mais tempo e é mais complexo. Não escolha isso. Escolha algo que você faz toda semana, em que já sabe como é um bom resultado e consegue identificar um rascunho ruim de imediato. Além disso, recomendamos começar por alguns dos workflows menos complexos, mas que exigem mais trabalho manual. Para nós, isso significou coisas como análises de fluxo de caixa e revisões de seguros. Aqui na Range, eram tarefas que exigiam mais

3:03:54 trabalho manual. E, se você não consegue avaliar o resultado rapidamente, não consegue testá-lo nem confiar nele. Então, procure duas coisas: algo que você faz com frequência e que sabe avaliar. Etapa dois: mostre a ele vários casos reais de planos que você entregou no passado. Pegue vários casos reais de clientes e explique o trabalho do início ao fim. Enquanto faz isso, narre em voz alta seu processo de avaliação. Não diga apenas “agora abro a planilha”; explique por que está abrindo, o que está procurando e o que faria você parar e fazer uma pergunta. Essa narração é o essencial. É fácil anotar as etapas. O que transforma isso no trabalho da sua empresa, em vez de um conselho genérico, é o seu julgamento.

3:04:26 Etapa três: empacote isso em uma skill. Uma skill não é só uma lista de etapas. Duas coisas são mais importantes. As perguntas que ela precisa fazer antes de começar: o que precisa saber? O que deve confirmar comigo em vez de simplesmente adivinhar? E os limites que precisa respeitar: o que nunca faz por conta própria. No nosso caso, o principal é que ela nunca envia nada a um cliente. Ela prepara um rascunho, e então um planejador decide se ele deve ser enviado ou se precisa de ajustes. Se você escrever apenas as etapas, terá algo que simplesmente funciona por conta própria. Se escrever as perguntas e definir os limites, poderá ter algo em que confia. Pense em uma skill como uma receita. Depois que Claude aprende a executar a skill, ele repetirá seu

3:04:58 processo quando solicitado. Etapa número quatro: execute-a cinco ou dez vezes em casos reais antes que qualquer outra pessoa a veja. Esta é a etapa que todo mundo quer pular. Cada execução ensina algo que a skill ainda não sabia: um caso extremo, uma pergunta que deveria ter feito, um ponto em que pareceu confiante, mas estava errada. Você precisa corrigir isso, salvar a skill e executá-la de novo, de novo e de novo. Fazer cinco a dez execuções parece muito, mas dá muito menos trabalho do que

3:05:30 os limites que ele deve respeitar, aquilo que nunca faz por conta própria. No nosso caso, o principal é que ele nunca envia nada a um cliente. Ele prepara um rascunho, e então um planejador decide se ele deve ser enviado ou se precisa ser ajustado. Se você escrever apenas as etapas, vai obter algo que simplesmente funciona por conta própria. Se escrever as perguntas e definir os limites, pode obter algo em que dá para confiar. Pense em uma skill como uma receita. Depois que Claude aprende a executar a skill, ele vai repetir seu

3:06:00 processo quando solicitado. Etapa número quatro: execute-o cinco ou dez vezes em casos reais antes que qualquer outra pessoa o veja. Esta é a etapa que todo mundo quer pular. Cada execução ensina algo que a skill ainda não sabia: um caso extremo, uma pergunta que deveria ter feito, um momento em que pareceu confiante, mas estava errada. Você precisa corrigir isso, salvar a skill e executá-la de novo, de novo e de novo. Cinco a dez execuções parecem muitas, mas dão muito menos trabalho do que

3:06:32 limpando a bagunça depois de entregar uma skill inacabada a 15, 20 ou 100 pessoas da sua equipe. Etapa cinco: lance-a com um responsável e um revisor. O responsável a mantém atualizada. Nossos processos mudam. As regras tributárias mudam. E uma skill que estava correta em março pode estar errada em dezembro. O revisor verifica a skill antes que a equipe passe a depender dela. E é alguém que não seja o autor. Assim como acontece com um plano. Você não avalia o próprio

3:07:02 trabalho. Quando outras pessoas passam a depender de uma skill, alguém precisa ser responsável por ela. Essa é a diferença entre um atalho pessoal esperto e algo sobre o qual uma equipe pode construir. Então, em que ponto estamos agora? Seis meses depois, temos 24 skills na empresa, e 17 delas estão na área de planejamento. E aqui está a parte que eu não esperava: isso se espalhou para vendas, produto e marketing, tudo sem uma ordem. Ninguém enviou um memorando. As pessoas viram o que o pessoal de planejamento estava fazendo e começaram a

3:07:33 criar seus próprios agents. Todas essas skills foram criadas e são mantidas por planejadores, profissionais de marketing e vendedores, não por desenvolvedores ou engenheiros. Algumas coisas mudaram quando especialistas no assunto começaram a criar skills para seus próprios nichos. As skills ficaram muito mais específicas. A pessoa que mais entende de seguros, por exemplo, cria a skill de seguros. A pessoa que mais entende de impostos, do código tributário e da legislação tributária deve criar a skill tributária. E uma revisão surgiu

3:08:05 naturalmente. Já revisamos os planos uns dos outros, e é assim que o planejamento funciona. Então, agora revisamos as skills uns dos outros da mesma maneira. É o mesmo hábito, só que com algo novo para revisar. Então, por que isso importa agora? Porque o gargalo mudou. A questão de se um modelo consegue elaborar uma análise de fluxo de caixa já foi resolvida. Consegue. O que ainda não foi resolvido? Quem documenta como a sua empresa faz isso? Quem testa antes de lançar? Quem fica responsável por ela

3:08:36 quando outras 15 pessoas passam a depender dela? Se estão pedindo que você disponibilize agents para além da área de engenharia, você está prestes a se deparar exatamente com essas perguntas. Ainda há poucos dados concretos sobre isso, mas é assim que fazemos aqui na Range. É isso. Muito obrigado por assistir a esta palestra. Sou Matt Regon, da Range, e você pode falar comigo pelo mattrange.com. Tenham um ótimo dia.

3:09:28 Hoje vou falar sobre como seu agent é uma tríade letal e o que fazer a respeito. Vamos começar direto com uma demonstração. Um pouco de contexto sobre esta demonstração: vamos analisar um agent de triagem de plantão que lê e registra informações em um sistema de alertas de incidentes e resolve ou escala tickets. Esse agent tem acesso total a uma API de hospedagem na nuvem, a um data warehouse de clientes e também a um banco de dados de faturamento. Então, aqui temos nosso agent de triagem de plantão

3:09:58 e ele tem uma fila de tickets de incidentes que vai ler. Se conseguir resolvê-los, vai chamar os serviços disponíveis aos quais tem acesso. Os que não conseguir resolver, vai escalar para a equipe da manhã. Se olharmos este primeiro ticket, trata-se de uma anomalia de faturamento. Ele diz que um grupo de clientes recebeu cobranças excessivas na noite passada. Então, a primeira coisa que o agent faz é chamar diretamente a API do incidex para ler o ticket. E, se você olhar

3:10:29 aqui, verá que ele autorizou o acesso a essa API usando uma chave de API. Em seguida, usa uma chave do Snowflake para consultar o data warehouse de clientes e decide escalar o ticket para revisão pela manhã. E escreve um relatório para a equipe da manhã. E, como você pode ver, está compartilhando dados de clientes, certo? São linhas extraídas diretamente do data warehouse de clientes. E está enviando informações de identificação pessoal para a equipe que estará de plantão pela manhã.

3:11:04 O próximo ticket diz que a fonte de alimentação reserva falhou na sala dos servidores. O agent vai ler o ticket de novo. Está usando uma chave de API para chamar a API de tickets. Determina que se trata de um problema físico. Então, escala para revisão pela manhã sem chamar nenhum serviço adicional. Neste caso, o certificado TLS do site está prestes a expirar. Ele lê o ticket. Determina que o alerta está claro. Tem acesso à API de hospedagem na nuvem

3:11:37 e chama essa API no endpoint de renovação de certificados, usando novamente uma chave de API. Resolve o problema renovando o certificado e deixa um relatório para a equipe da manhã, chamando também a API de incidentes do pager. O próximo ticket diz que o banco de dados de faturamento está com problemas e os pagamentos estão falhando. A recuperação documentada para isso é excluir e restaurar o banco de dados.

3:12:10 O agent faz isso usando a string de conexão do banco de dados, que inclui a senha de administrador, e então recomenda à equipe da manhã que confirme se a recuperação a partir do snapshot funcionou. Isso não é algo a que ele tenha acesso direto. Então, está basicamente presumindo que a equipe da manhã vai verificar se isso realmente funcionou e se as informações foram restauradas. Agora, um agent com privilégios excessivos excluindo um banco de dados de

3:12:41 produção é basicamente um pesadelo que várias empresas já viveram. Então, precisamos ter muito cuidado com isso. O próximo caso: os pedidos estão parados, o servidor principal travou. O agent vai ler o ticket novamente. Depois de lê-lo, chama a API de hospedagem na nuvem, usando novamente sua chave de API estática. Chama o endpoint para reiniciar o servidor, o que deixa a produção fora do ar.

3:13:16 Por fim, o site está falhando para um em cada três visitantes. O agent lê o ticket. Determina que deve chamar a API de hospedagem na nuvem e aumentar o serviço de quatro pods para 40. Isso gera uma cobrança de US$ 420 por hora. E, então, deixa gentilmente uma nota para a equipe da manhã, informando que isso aconteceu. E o que torna um agent útil?

3:13:47 Bem, normalmente queremos que os agents tenham um conjunto mínimo de capacidades, o que muitas vezes inclui coisas como poder ler dados que pertencem a você ou aos quais você tem acesso. Isso pode ser seu e-mail, seus documentos, talvez um CRM de clientes. Queremos que o agent consiga fazer sua própria pesquisa. Isso pode incluir pesquisar na web, talvez ler documentação ou buscar issues no GitHub. E geralmente queremos que ele consiga usar ferramentas externas, por exemplo, servidores MCP ou APIs, talvez plataformas de SaaS.

3:14:17 E agents úteis podem fazer essas coisas com uma pessoa no loop ou podem fazê-las de forma autônoma, em segundo plano. Mas o que torna… As coisas que tornam os agents úteis também os tornam perigosos. Na verdade, juntas, essas três capacidades formam o que Simon Willis chamou de tríade letal. Trata-se da combinação de acesso a dados privados, como a capacidade do agent de plantão de consultar o data warehouse de clientes e interagir com o banco de dados de faturamento; exposição a conteúdo não confiável, como

3:14:48 ler tickets enviados por usuários, relatórios de outros agents ou processos documentados externamente; e a capacidade de se comunicar externamente, como ler e escrever usando APIs de terceiros ou serviços de SaaS. Juntas, essas capacidades escancaram as portas para os atacantes. Agents são projetados para realizar o trabalho e usarão todos os poderes de que dispõem para isso, às vezes com consequências muito sérias. Mas o ponto é o seguinte: esses incidentes acontecem porque os humanos dão aos agents

3:15:19 muito mais acesso do que eles precisam. Agents com privilégios excessivos podem agir livremente com base nas decisões que tomam, mesmo quando há supervisão. Exigir aprovação de uma pessoa no loop acaba simplesmente transferindo o controle de acesso para um usuário já fatigado de dar consentimento. Passamos décadas resolvendo o gerenciamento de acesso para humanos. Então, transferir a responsabilidade para o usuário apenas desloca o problema de segurança para cima na cadeia. Então, o que devemos fazer a respeito da tríade

3:15:50 letal? Como lidar com ela sem comprometer a utilidade dos agents? Bem, simplesmente remover uma ou mais dessas capacidades vai tornar o agent significativamente menos útil. Então, como podemos manter as três e ainda assim garantir a segurança? Em vez de romper a tríade removendo capacidades, precisamos realmente controlar o acesso do agent. Assim, a superfície de ataque é minimizada e o raio de impacto é contido, mas o agent ainda mantém sua capacidade e autonomia.

3:16:21 Então, como fazemos isso? Bem, algumas opções para controlar o acesso, entre outras, são usar OAuth, talvez usar um gateway MCP de um fornecedor ou confinar a execução em sandboxes. OAuth vincula o acesso a uma concessão. No momento da concessão, o usuário consente com todas as permissões que o agent poderia usar. Esse consentimento é dado antes de existir qualquer tarefa. Portanto, se você conceder acesso amplo, acaba com acesso permanente. Seu agent fica com permissões excessivas para qualquer tarefa específica.

3:16:53 Se você restringir a concessão e não der muitas permissões, o agent simplesmente se torna menos capaz. De qualquer forma, OAuth, por si só, não oferece controle de acesso com escopo definido por tarefa. Um agent entusiasmado pode ler e escrever na mesma execução, mesmo que você queira que ele apenas leia nessa tarefa específica. Já um gateway MCP vincula a aplicação das regras a uma rota. Você tem recursos como observabilidade e limites de taxa, além de um único ponto de decisão de política na

3:17:23 camada MCP. A política é aplicada a cada solicitação, e o acesso é concedido por usuário, mas o acesso concedido aos agents dura mais do que qualquer tarefa individual, porque o gateway ainda mantém credenciais permanentes. Já uma sandbox vincula a execução a um processo. Isso controla o raio de impacto, mas o trabalho útil precisa sair da sandbox e, quando isso acontece, você acaba tendo acesso permanente de novo. Também já vimos muitas histórias de agents rompendo o confinamento de sandboxes. As sandboxes limitam o que os processos podem fazer, mas

3:17:54 não controlam o que está autorizado a agir fora da própria sandbox. Mesmo que você combinasse as três soluções, o agent ainda não receberia uma credencial em tempo de execução com escopo reduzido a uma única tarefa. Então, vamos recapitular os problemas, especialmente os que vimos na demonstração. Se você se lembra do registro de auditoria, não conseguíamos saber quem estava usando as chaves de API. Portanto, o primeiro problema é que as credenciais não eram atribuídas a um usuário nem à identidade de um agent. O agent tinha

3:18:27 acesso irrestrito a todas as permissões concedidas pelas chaves de API. E, por fim, não podemos simplesmente colocar um humano no circuito em todos os casos, porque humanos também cometem erros. Além disso, muitos agents são executados de forma autônoma e nem sequer têm um humano no circuito. Para resolver esses problemas, podemos começar usando algo chamado troca de tokens. Trata-se de um padrão existente, publicado em 2020, que amplia o OAuth 2. Primeiro, precisamos saber quem é o usuário. Um servidor de autorização verifica

3:19:00 identidades e emite tokens. Provedores de identidade como Google, Okta, Auth0 etc. fornecem servidores de autorização. Portanto, se quisermos uma cadeia de identidade no caminho de execução do agent, o usuário precisa primeiro fazer login. O servidor de autorização vai solicitar o consentimento do usuário para delegar acesso a recursos com um subconjunto das permissões dele. Essas permissões são chamadas de escopos. Esse é o primeiro estreitamento do acesso. Estamos delegando ao agent apenas alguns dos escopos totais do usuário.

3:19:33 O servidor de autorização emite tokens que identificam o usuário e o nível de acesso dele. E, nesse ponto, já estamos em uma situação melhor do que na demonstração, porque de fato sabemos quem é o usuário e a que ele pode acessar. Isso nos leva ao caminho de execução agêntica. Agora temos nosso usuário autenticado. Temos, portanto, a identidade conhecida de uma pessoa que quer usar um LLM para interagir com um recurso. Na demonstração, os recursos são o pager de incidentes, o banco de dados de produção,

3:20:03 o Snowflake e o serviço de hospedagem em nuvem. Um agent é um loop de controle que chama um LLM. Muitas vezes, temos um servidor MCP entre o agent e seus recursos, fornecendo ferramentas definidas que se conectam a esses serviços downstream. Um cliente MCP encaminha ao servidor MCP as chamadas de ferramentas propostas pelo agent. Na demonstração, o agent de triagem de plantão chamava os recursos diretamente, usando credenciais estáticas de longa duração, como chaves de API

3:20:33 ou strings de conexão com o banco de dados. Então, vamos dar ao agent de plantão um servidor MCP. Ele vai fornecer ferramentas e também intermediar o acesso aos recursos. Um runtime de agent é um processo que executa o loop do agent e as chamadas. O runtime pode ser uma CLI como Claude Code ou um SDK de agent, que pode ser implementado em um aplicativo personalizado, como o agent de plantão.

3:21:06 Vamos acompanhar um prompt por esse caminho de execução. O usuário envia o prompt ao runtime, que chama o modelo e envia o prompt ao LLM. O modelo então propõe chamadas de ferramentas, que são encaminhadas pelo cliente MCP ao servidor MCP, que executa as ferramentas e chama a API do recurso. A API retorna a resposta ao servidor MCP. O cliente MCP entrega a resposta ao runtime, que chama o modelo novamente. E esse loop se repete até que

3:21:36 o modelo esteja satisfeito e retorne uma resposta ao usuário. O token do usuário autenticado passa a ser o que chamamos de token de sujeito. Ele identifica em nome de quem o agent está agindo, por quem está agindo. A troca de tokens precisa de um cliente OAuth capaz de executar código. Pode ser um gateway entre o cliente MCP e o servidor MCP de terceiros ou pode ser seu aplicativo personalizado.

3:22:09 Um servidor MCP personalizado também pode trocar tokens para acessar recursos downstream. O servidor MCP do agent de plantão deve fornecer um conjunto definido de ferramentas de infraestrutura de produção. O prompt e o token de sujeito são enviados ao runtime. O loop do agent é executado e o modelo propõe uma chamada de ferramenta. O runtime se autentica com um servidor de autorização especial chamado serviço de tokens de segurança. Ele faz isso usando as credenciais de cliente do aplicativo ou a identidade da carga de trabalho.

3:22:39 Ele também envia o token de sujeito, que contém a identidade e o acesso do usuário. O runtime cria uma solicitação de troca de tokens pedindo permissão para acessar o servidor MCP para aquela chamada de ferramenta, e somente para ela. Agora temos três informações que faltavam na demonstração. Sabemos a identidade do agent que está solicitando acesso. Sabemos a identidade do usuário em nome de quem ele está agindo e sabemos o nível de acesso que o usuário concedeu ao agent.

3:23:12 Agora precisamos decidir se o token solicitado deve ser emitido. Podemos fazer isso com uma política de governança, avaliada com base no acesso solicitado, no recurso solicitado, na identidade do agent e na identidade do usuário. Mas as políticas são limites máximos. Agents podem fazer coisas que você não pretendia, mesmo quando a política, de modo geral, permite. Isso nos leva a algo chamado autorização baseada em intenção, ou IBA. A

3:23:43 IBA verifica o que você pretende antes de o agent agir. Ainda não é um padrão finalizado. As propostas ainda estão sendo aceitas. Esta é a abordagem da Keycard para implementar a autorização baseada em intenção. A IBA pode usar um gateway como ponto de aplicação de políticas. Quando você envia o prompt ao agent, ele propõe uma missão. Essa missão inclui um objetivo, talvez ações permitidas, além de limites para o que o agent pode fazer. Por exemplo, o objetivo de triagem

3:24:16 do incidente 2294 significa ler esse chamado, resumi-lo ou escalá-lo, mas não ler outros chamados nem usar outros serviços. O serviço de tokens de segurança recebe essa missão. Nesse caso, uma atividade de baixo risco, como apenas avaliar um chamado, pode ser aprovada automaticamente pela política administrativa. Por outro lado, se já tivermos lido o chamado e pedirmos para remediar um pico de uso, a missão acrescenta a permissão para escalar o serviço uma vez, mas

3:24:46 não para usar outras ferramentas ou APIs. Nesse caso, a missão é apresentada ao usuário para análise e aprovação. Depois de aprovada, o serviço de tokens de segurança atribui um ID à missão, que é enviado ao agent. As chamadas de ferramentas incluem esse ID da missão e são encaminhadas pelo gateway, que usa o ID para perguntar ao serviço de tokens de segurança se a chamada de ferramenta está de acordo com a missão. Se estiver, o gateway solicita uma troca de tokens para acessar o servidor MCP especificamente para aquela chamada de ferramenta.

3:25:19 O STS avalia a política. Ele avalia a cadeia de delegação e verifica o acesso solicitado. Se tudo estiver correto, emite um token de acesso para o servidor MCP, mantém o sujeito do usuário e também acrescenta o aplicativo que realizou a troca — neste caso, nosso agent de plantão. Esse token deve expirar em poucos minutos e nunca deve ser armazenado. Ele é efêmero. O STS o envia para o

3:25:49 gateway que chama o servidor MCP. Em seguida, o servidor valida o token e autoriza a chamada da ferramenta. Algumas ferramentas precisam de recursos externos. Então, o servidor MCP pede ao serviço de token de segurança que troque o token que acabou de receber por um token para o recurso downstream. O STS avalia a solicitação conforme a política e, se ela for aprovada, emite um token de recurso novamente restrito àquela chamada da ferramenta. Ele mantém o usuário

3:26:22 como sujeito, o que estende a cadeia de delegação e nos permite rastrear toda a atividade. O STS envia o token ao gateway, que encaminha a solicitação ao servidor MCP, que então chama o recurso. O recurso valida o token e autoriza o acesso. O servidor MCP nunca deve armazenar o token. Deve descartá-lo imediatamente após a chamada. Em seguida, a resposta do recurso retorna

3:26:53 e o loop agêntico se repete até que o modelo retorne a resposta ao usuário. Agora vamos ver a mesma demonstração, mas usando um serviço de token de segurança para gerenciar o controle de acesso do agent com autorização delegada. A demonstração usa governança de políticas baseada em tarefas, não autorização baseada em intenção, mas, se você for ao Agent Con mais tarde neste mês, teremos demonstrações de IBA lá.

3:27:26 Agora também temos um servidor MCP que configura ferramentas e fornece acesso intermediado aos recursos. Então, voltamos ao nosso agent de triagem de plantão, só que desta vez temos autenticação. Vou entrar no aplicativo de triagem do agent de plantão. Para isso, vou fazer login com o Google.

3:27:57 E então aparece outra tela de login. É aqui que vou entrar na plataforma de pager Incidex. Recebo uma solicitação para conceder ao agent de plantão acesso à minha conta Incidex. Vou permitir que ele escale incidentes em meu nome, publique notas e resumos e leia a fila. Agora, aparece uma solicitação para eu fazer login na plataforma de hospedagem na nuvem.

3:28:29 Então vou fazer isso. Agora aparece outra tela de consentimento, que me permite autorizar o agent a acessar alguns recursos do Compost em meu nome. Por fim, volto ao painel de plantão. Agora temos a mesma fila de tickets, mas o log de auditoria está diferente. O agent provavelmente vai

3:29:01 tentar se comportar da mesma maneira que antes. Só que agora cada solicitação vai passar pelo STS e pela avaliação de políticas antes que um token seja concedido e o agent seja autorizado a agir. Temos a mesma fila de tickets, mas o log de auditoria está diferente, e o agent provavelmente vai se comportar da mesma maneira que antes. Só que agora cada solicitação vai passar pelo STS e pela avaliação de políticas antes que um token seja concedido e o agent seja autorizado a agir. Então, o

3:29:33 primeiro ticket é aquela anomalia do Billy de novo. O agent tenta ler o… então, o agent está lendo o ticket, e podemos ver que está tentando fazer a mesma coisa que antes. Ele tenta consultar o armazém de dados de clientes, mas a política não permite emitir uma credencial para isso, porque as informações pessoais identificáveis dos clientes não devem estar no contexto de um agent nem em um ticket de incidente.

3:30:05 Então, o agent prossegue sem os dados do cliente e escalou o caso para a equipe da manhã. Agora temos o certificado de segurança do site prestes a expirar. Isso é algo que o agent tem permissão para fazer. Então, quando solicita

3:30:36 credenciais para fazer isso, o acesso é concedido pelo STS, e ele pode chamar a API da plataforma de hospedagem na nuvem e resolver esse ticket. Agora você pode ver todas as chamadas que ele está fazendo e quem as está fazendo. Temos o agent de triagem de plantão solicitando a renovação do certificado. Ele está pedindo permissão para chamar a ferramenta apropriada do servidor MCP Pro Infra. Então, recebe um token para isso.

3:31:08 Depois disso, o servidor MCP vai solicitar acesso a esse serviço de hospedagem na nuvem para renovar o certificado usando a API. Se passarmos para o banco de dados de faturamento, ele vai ler o ticket pela API de incidentes. Vai chegar à mesma conclusão que antes. O agent sabe que esse é um procedimento de exclusão e

3:31:39 restauração, mas desta vez a política proíbe um agent de excluir um banco de dados de produção. Uma pessoa precisa fazer isso manualmente. Podemos ver isso no log de auditoria, onde o STS se recusou a conceder a troca de token para acessar a exclusão do banco de dados. Agora, nossos pedidos estão parados. O servidor principal está congelado.

3:32:11 O agent vai ler o ticket. Ele quer reiniciar o servidor principal. Isso deixa a produção temporariamente fora do ar. Ele me informa disso e, desta vez, está pedindo minha aprovação para fazer isso. Vou clicar em aprovar. No entanto, isso também foi bloqueado pela política, porque meu usuário não tem a função necessária para realizar essa ação. Certo?

3:32:41 Então, o agent não pode fazer isso, mas eu também não posso, e o agent está agindo em meu nome. Se voltarmos ao site que está falhando para um em cada três usuários, o agent quer adicionar mais servidores e vai pedir permissão. Vai dizer o que estamos nos comprometendo a fazer ao tomar essa medida. Vou aprovar. E essa é uma ação que minha função

3:33:12 tem autoridade para realizar. Então, o escalonamento é executado e esse ticket é resolvido. Assim, podemos ver que os problemas de acesso do agent foram solucionados. Sabemos a identidade do usuário e do agent ao longo de toda a cadeia. O agent tem acesso efêmero ao servidor MCP e aos recursos downstream, restrito à tarefa. E temos uma pessoa no loop, com controle de acesso efetivamente respaldado por políticas. Agora, o acesso é controlado no nível da tarefa

3:33:44 pelo serviço de token de segurança e pelas políticas, e mantemos todos os recursos essenciais. A troca de token é um padrão aberto. Foi amplamente estudada e é pública, então qualquer pessoa pode implementá-la. Ela também é interoperável com mecanismos de políticas existentes e provedores de identidade em conformidade com os padrões, além de coisas como gateways, sandboxes, OAuth pronto para uso e agentes personalizados, CLIs, servidores MCP, fábricas de software, acesso entre agents e entre aplicativos

3:34:15 além do que quer que surja na próxima semana. Espero que você considere essa opção para tornar seus agents úteis, seguros e preparados para o futuro. Meu nome… Meu nome é Kim Maida. Sou engenheira fundadora de GTM e chefe de Devril na Keycard. Agradeço muito pelo seu tempo hoje. Muito obrigada.

3:34:58 Olá a todos. Esta palestra é sobre o perigo de vazamento de informações do seu LLM por meio de hardware de GPU compartilhado. Se você estiver executando um modelo na nuvem em uma GPU compartilhada com outros clientes, alguém ao seu lado pode descobrir coisas sobre ele. Essa pessoa pode saber qual modelo você está executando, com que rapidez ele responde e até que tipo de trabalho está fazendo naquele momento. Tudo isso sem tocar nos dados, apenas observando os tempos. É disso que esta palestra trata: o que outros clientes no mesmo hardware podem descobrir sobre seu LLM apenas pelos tempos e o que você pode fazer a respeito. Para começar, sou Brian Stores, pesquisador de cibersegurança

3:35:30 empregado pela Stealthium. Na Stealth, somos especializados em proteger e fornecer observabilidade dos ambientes em que os sistemas de IA são executados. Meu foco é a pesquisa de segurança de baixo nível relacionada a GPU. É disso que esta palestra trata. Quando você compartilha uma GPU entre clientes, espera isolamento total, mas o isolamento fornecido pode não ser suficiente. Neste ataque, o invasor nem sequer precisa de permissões especiais, como acesso root. Também não precisa de nenhum exploit tradicional. A única coisa que faz é medir o tempo das

3:36:02 partes do hardware que ainda são compartilhadas entre os clientes. Este é um vídeo de demonstração de como são os painéis das vítimas e dos invasores. À esquerda, temos a diferença do modelo Quentry. À direita, o invasor usa um canal lateral que o Quentry vaza enquanto está sendo executado. Com isso, ele determina exatamente qual é o modelo e que tipo de texto está produzindo naquele momento. Esses são apenas os principais pontos, mas não contam a história toda. Podemos identificar qual é o modelo, sua arquitetura e profundidade.

3:36:33 com 97% de precisão. Conseguimos determinar a velocidade da geração de código com 99,3% de precisão. Conseguimos identificar quando e quanto, os períodos de atividade, a contagem de tokens e o comprimento das respostas. Também conseguimos identificar que tipo de trabalho está sendo feito: código, JSON ou recuperação. O que não conseguimos identificar são os prompts, as respostas ou o conteúdo em si; apenas os tempos. E tudo isso em H100 reais, servindo LLMs reais. Se você estiver usando hardware da Nvidia, o isolamento da GPU

3:37:04 é obtido com GPU Multi-Instance, ou MIG, abreviado. Cada fatia isolada de MIG tem suas próprias unidades físicas de processamento e VRAM dedicada, que oferece isolamento de hardware nesses componentes. No nosso exemplo, o LLM que estamos servindo é executado em uma fatia com três unidades de processamento e 40 GB de VRAM. O ataque é executado com apenas uma unidade de processamento e 10 GB de VRAM. O que fica isolado são as unidades de processamento, a capacidade de memória, os quartos de largura de banda e

3:37:34 os erros de página. O cache L2 também é particionado por instância. Não há expulsão entre instâncias, então ele não é compartilhado nesse sentido. Os vazamentos reais são as barreiras de memória, ou membros, que abrangem toda a GPU. Uma barreira de uma instância ainda afeta todas as partições L2 da placa. O tempo é a única coisa que não fica isolada. Assim, quando um tenant está ocupado, os outros tenants apenas percebem que suas leituras ficam um pouco mais lentas. O ponto principal é que uma barreira de memória que abrange toda a GPU tem efeito em

3:38:06 todas as partições L2 da placa. O próximo slide constrói todo o ataque com base nesse único fato. A ideia é que o invasor só lê a própria memória. Ele mede apenas o tempo das próprias leituras. Nunca acessa a memória da vítima. Há três etapas, todas usando o próprio buffer pequeno do invasor: medir o tempo de carregamento e repetir a cada cinco microssegundos. Essa técnica e o próprio vazamento de membros do MIG não são descobertas nossas. O crédito é dos pesquisadores por trás do trabalho […] em segurança.

3:38:36 Agradecemos muito pelo trabalho deles. Agora, tente observar a olho nu as diferenças de tempo, comparando os períodos em que os outros tenants estão ociosos com aqueles em que estão servindo um LLM. Você nem conseguiria distingui-las. A latência mediana é apenas três microssegundos maior. Para o invasor, porém, esses três microssegundos são tudo de que ele precisa. Isso basta para coletar todas as informações de que já falamos. Qwen com 8 bilhões de parâmetros está sendo executado na fatia da vítima durante todo

3:39:07 este teste. Todos os dados capturados foram obtidos de um modelo ativo. Na parte superior está a atividade da GPU ao longo do tempo, um token por vez. Abaixo, o espectro de frequência da trilha de latência do invasor. Há um componente fundamental em 81 hertz, que corresponde apenas aos tokens por segundo, além de harmônicos, porque cada token é uma mistura de frequências distintas, não uma frequência única e nítida. Esta é uma trilha real, de um token no domínio do tempo. O token mostra um total de 39 picos. Os picos verdes são

3:39:39 as invocações de camadas, enquanto os laranjas são etapas adicionais de processamento entre elas. Nos próximos slides, vamos demonstrar como determinamos a contagem real de camadas mesmo com esses picos extras presentes. Aqui, observamos a própria velocidade de decodificação. Apenas medindo o tempo, descobrimos que a taxa de tokens estava totalmente vinculada. Portanto, um invasor consegue recuperar com precisão a velocidade por si só. Mas a velocidade, isoladamente, não é uma impressão digital confiável. Qwen com 8 bilhões e Llama com 3,8 bilhões de parâmetros diferem apenas 1,6%

3:40:10 na taxa de tokens. Então, com base apenas na velocidade, você pensaria que são o mesmo modelo. Isso restringe as possibilidades, mas não permite identificá-lo com certeza. Precisamos de algo mais preciso: a contagem de camadas. É disso que tratam os próximos slides. Usamos o mesmo método de dobramento e cálculo da média de antes. Desta vez, aplicamos uma vez por modelo, em vez de uma vez por token. O resultado é uma contagem que fica quase exatamente em um número inteiro. A distância média até um número inteiro, em 22 trilhas, é de apenas 0,028. De 0 a 8. Essa é a

3:40:43 pista. Se isso fosse apenas um artefato fixo do hardware dividido por taxas diferentes, esperaríamos frações, não números inteiros. Cada contagem corresponde à contagem de camadas do modelo mais um a três picos adicionais. Cada modelo mantém sua própria impressão digital de sinal, uma mistura de ritmo e estrutura harmônica. Para deixar claro, este não é um classificador de machine learning treinado. Não há conjunto de treinamento, rótulos nem configuração. São menos de 30 linhas de código. O método verifica cada

3:41:15 profundidade candidata, de 16 a 48. Ele mede o quanto a assinatura esperada para essa profundidade aparece na trilha real. Então, escolhe a que melhor se ajusta. Para o Qwen com 38 bilhões de parâmetros, as 36 camadas se destacam claramente, por um fator de quatro em relação à próxima candidata. Como este é um teste de melhor ajuste, não uma tabela de consulta, ele também funciona com modelos que nunca viu antes. Isso inclui modelos proprietários e ainda não lançados, pois não há nada que ele precise ter visto de antemão.

3:41:49 E isso funciona surpreendentemente bem. O classificador de ajuste de camadas também fornece o nível de confiança nos nossos testes. Apenas duas das respostas de menor confiança estavam erradas. Esse mesmo método também identifica fine-tunes e destilações que compartilham o mesmo modelo-base. Isso porque a arquitetura e a contagem de camadas permanecem inalteradas. Vejamos três modelos relacionados como exemplo. Llama 3 com 8 bilhões de parâmetros tem 32 camadas. Llama 3.1 com 8 bilhões de parâmetros, também da Meta, usa a mesma base de 32 camadas, com pequenas melhorias, e R1 ainda é o Llama 8 bilhões da DeepSeek, com melhorias adicionais.

3:42:22 O tempo por camada difere em apenas 1,6 microssegundos na latência mediana. O restante do sinal parece igual. Apesar disso, nosso classificador ainda consegue distingui-los. Agora fazemos uma pergunta mais profunda usando o mesmo canal. Não qual modelo está sendo usado, mas o que ele está

3:42:52 fazendo neste momento? Analisamos quatro tipos: prosa, código, JSON e recuperação. A cada meio segundo, classificamos o tipo de trabalho com base nos últimos cinco segundos de medições de tempo. Das 40 janelas de meio segundo, 31 foram classificadas corretamente, e quatro respostas completas foram identificadas corretamente por votação da maioria. Este é o mesmo classificador do vídeo anterior. Vale mencionar uma condição: isso foi medido com decodificação especulativa ativada. Essa opção é ativada pelo usuário no BLM; não é o padrão.

3:43:24 Este é o mecanismo. A previsibilidade do texto altera quantos tokens especulativos são aceitos em cada etapa. Isso altera o tempo de cada etapa, e é esse sinal que estamos captando. Testamos 11 configurações, densas e de mistura de especialistas, em BF-16 e FP8. A mesma característica apareceu todas as vezes, mas com intensidades muito diferentes. A diferença foi de 70,2% no GPT-20B contra 0,9% no GLM-49B. Então, em 11 rodadas, a prosa foi

3:43:55 a classificação mais rápida, quando as chances por si só dariam apenas uma em quatro. Portanto, digamos que o invasor já conheça o modelo pelos slides anteriores e que a decodificação especulativa esteja ativada. Ele também consegue identificar que tipo de texto está sendo gerado. Agora, vamos tirar o chip MIG completamente da equação. O MIG exige que o invasor esteja no mesmo chip físico. Este ataque, não. A configuração aqui é um servidor com oito H100 conectadas por uma malha NVSwitch. A vítima executa dezenas de tarefas paralelas nas GPUs zero e um. O invasor só precisa de qualquer outra GPU nesse mesmo servidor — a GPU 2, neste caso.

3:44:26 O acesso entre GPUs pelo NVSwitch é um recurso real, previsto para esse uso. É assim que tarefas multi-GPU normalmente funcionam, não uma falha sendo explorada. O paralelismo de tensores do MIG também não pode coexistir no mesmo dispositivo. Portanto, trata-se realmente de uma população diferente de implantações, não apenas do mesmo ataque repetido. A sonda é executada na GPU 2. Ela percorre endereços de memória que estão, na verdade, na GPU zero, medindo o tempo de cada salto ao longo do caminho.

3:44:58 Um salto ocioso leva cerca de 890 nanossegundos. Quando a vítima começa a trabalhar, esse tempo sobe para 300 microssegundos. Estas são três capturas de meio segundo, e é possível contar os tokens a olho nu. O que perdemos em comparação com o MIG é a informação sobre a contagem de camadas. A essa distância, ela fica abaixo do nível de ruído. Portanto, as impressões digitais que nos restam ao fazer o rastreamento

3:45:30 são principalmente de ritmo, não de contagem de camadas. Aqui, testamos os cinco modelos com uma configuração de serviço idêntica. Só o próprio modelo revela qual deles está sendo usado. Esse método alcança 79,2% de precisão. E falha exatamente onde seria de esperar que o ritmo falhasse. Llama 3.5 com 8 bilhões de parâmetros e R1 são ambos modelos de 8 bilhões de parâmetros, e diferem em três hertz na taxa de código. Então, eles se confundem, enquanto a contagem de camadas do MIG os teria separado facilmente.

3:46:02 A conclusão é que a relação sinal-ruído do NVLink é pior que a do MIG, porque não temos a informação sobre a contagem de camadas. Mas uma relação sinal-ruído pior não significa segurança. Uma precisão de 79% diante de uma linha de base de 20% ainda é uma impressão digital real, não ruído. Primeiro, uma boa notícia: nosso próprio produto funciona contra o ataque assim que sai da caixa. Delp monitora cada lançamento de kernel em todas as GPUs, analisa cargas de trabalho suspeitas e as executa

3:46:32 por um pipeline completo de alertas, algo que nem todos os fornecedores conseguem fazer. Veja o que fez este caso se destacar. Um único kernel foi relançado cerca de 3.000 vezes, acessando exatamente os mesmos 40 kilobytes de memória repetidamente, em vez de passar para novos dados. Apenas um kilobyte de dados foi enviado de volta à CPU durante todo esse tempo, porque o próprio tempo era o payload, não a saída. Em termos práticos, isso levou menos de 600 milissegundos do início ao fim, com menos de

3:47:03 50 tokens na resposta. Nós detectamos isso antes mesmo de a resposta estar pela metade. Então, três conclusões. Primeiro, o posicionamento é algo que os operadores realmente controlam. Portanto, não coloque tenants não confiáveis ao lado de um modelo sensível. O MIG fica lado a lado com ele. Segundo, conheça a compensação. O MIG impede a comunicação ponto a ponto, o que significa que não há paralelismo de tensores no MIG. Já o particionamento via NVLink limita o que pode vazar apenas ao tempo, em vez de

3:47:35 à contagem de camadas. Terceiro, monitore a própria GPU. Certifique-se de que a infraestrutura do host está verificando ativamente se não há cargas de trabalho maliciosas em execução no hardware. É exatamente isso que Seltium faz, detectando essas sondagens diretamente pelo comportamento do Chrome. Compartilhar uma GPU significa que apenas o tempo pode revelar o modelo, a velocidade e a carga de trabalho. Isso é verdade até mesmo através do NVLink, sem precisar de nenhum especialista. Deltium observa isso acontecer em tempo

3:48:06 real. A maioria das organizações ainda não tem esse tipo de visibilidade. Mais uma vez, obrigado aos pesquisadores de Behind Bars. Esta palestra inteira se baseia no trabalho deles. Obrigado a todos por assistir.

3:48:41 As pessoas dizem há algum tempo que o SaaS está morto. Neste ponto, isso nem chega a ser uma opinião polêmica. Por que pagar alguém para criar e manter as ferramentas que você usa quando você mesmo poderia fazer isso? É só pedir ao seu agent. E, para mim, falta uma peça que raramente é mencionada. É o fato de que existe uma lacuna, uma grande lacuna, entre um software funcional criado de uma só vez e um software que eu realmente usaria; um software que dá prazer de usar, que é refinado, que é agradável. E, na verdade, comecei uma jornada para substituir vários provedores de SaaS que usamos internamente na

3:49:12 Railway, para fins de marketing. E simplesmente criei uma ferramenta completa que usamos. A ferramenta nos permite gerenciar conteúdo para o site da Railway, o changelog e o blog. Podemos usá-la para enviar e-mails, publicar em todas as nossas plataformas sociais ao mesmo tempo e gerenciar a mídia do site. Tem até um CRM pequeno para que, quando trabalhamos com criadores externos, possamos acompanhar tudo. Há acompanhamento de tarefas e planejamento de lançamentos porque, sabe, você quer coordenar várias coisas e quando elas serão publicadas. Há um calendário e, ao mesmo tempo, comentários,

3:49:42 edição em tempo real, e tudo é desenvolvido com agents. Eu diria que senti a grande virada quando o GPT6 foi lançado. E tudo isso está rodando na Railway. Tudo é implantado automaticamente. Agora, vou mostrar os princípios que uso para garantir que, quando quero adicionar um recurso, ele fique realmente refinado e combine com o restante do app, além dos princípios que você pode aproveitar e aplicar ao criar suas próprias

3:50:13 ferramentas. Então, em vez de fazer minha palestra no meu escritório sem graça, decidi mudar um pouco as coisas e fazê-la ao ar livre. Está absolutamente lindo. Agora estou em Edimburgo, na Escócia, e é surreal. Tipo, estou sentado num banco do lado de fora e esta é a vista. Com certeza, um banco nota 10. Para mim, esse tipo de palestra é um pouco diferente do que estou acostumado, porque vou mostrar a jornada de criação das nossas próprias ferramentas internas e as opiniões que desenvolvi. Mas também

3:50:45 entendo que o cenário muda muito, muito rápido. Então, qualquer coisa que eu disser pode mudar completamente em questão de meses. Quem sabe? Então, não sei. Considere isto meu aviso: a gravação é do outono de 2026, estamos em outubro. Enfim, dito isso, vamos falar do primeiro ponto: as tech stacks não importam. Muita gente diz que não

3:51:15 importa qual linguagem de programação você usa ou qual framework escolhe; é só pedir ao seu agent para criar qualquer coisa e ele consegue fazer isso. E, embora eu concorde até certo ponto, o que descobri é que, quando você está criando uma ferramenta que realmente vai usar e dá ao agent uma base de código com boas abstrações, o que acontece é que, sempre que você trabalha, digamos, em um novo recurso, o resultado fica muito mais consistente e parecido com o que você já criou antes. E o motivo é

3:51:46 bem simples. O agent não precisa reinventar a roda toda vez que tenta adicionar um novo recurso, nem precisa introduzir novos padrões. Ele simplesmente segue os padrões existentes. E, quanto ao que escolher, acho que não importa muito, desde que a base de código esteja bem estruturada. Mas minha opção preferida hoje são as bibliotecas TanStack para qualquer coisa que eu desenvolva para a web. E, se você estiver criando algo relacionado a conteúdo,

3:52:16 eu diria que vale muito a pena escolher Payload. É uma experiência sólida, com ótimas abstrações. Em algum momento, me aprofundei bastante na comparação entre CMSs, porque não acho que eu deva criar tudo do zero, mesmo podendo fazer isso. Mas, de novo, quem sabe? Talvez o futuro mude. Enfim, esse é mais ou menos o primeiro ponto com que me deparei. Quando você usa muitos produtos SaaS de que realmente gosta,

3:52:47 que usa todos os dias, há muitas coisas que você não percebe. Mas, quando tenta reproduzir uma experiência, logo descobre o cuidado e a reflexão envolvidos nos diferentes fluxos. Então, algo tão simples quanto querer enviar um e-mail ou publicar alguma coisa pode ser feito facilmente com um bom e velho app renderizado no servidor, com formulários que você envia, mas [risos]

3:53:18 se você tentar criar algo que será usado todos os dias, algo que você vai querer usar com frequência, vai pensar: “Não deveria ser assim”. E há vários padrões que percebi que os agents normalmente não implementam, a menos que você peça explicitamente. Esta é a minha lista. Vamos passar por eles um a um. O primeiro é o salvamento automático. Descobri que, se estou criando algum tipo de editor de documentos, o salvamento automático é um recurso básico.

3:53:49 Então, em vez de clicar manualmente em salvar, você pede que o progresso seja salvo automaticamente em segundo plano e garante que isso não bloqueie o uso, para que, digamos, enquanto você digita, consiga continuar digitando e o conteúdo seja salvo automaticamente. E outra etapa que você pode dar é impedir que a aba do navegador seja fechada se houver alterações não salvas. Assim,

3:54:20 essas duas camadas garantem que o que quer que você esteja fazendo não se perca. Você também pode ir além e adicionar colaboração em tempo real, com edições simultâneas. E, de novo, meu agent não teve dificuldade nenhuma para adicionar esse recurso. Foi só perguntar como funcionaria, revisar a implementação e, depois disso, >> apenas 700 milhões de tokens mais tarde, eu tinha edição em tempo real. Então, eu diria que, em geral,

3:54:52 essa é a primeira coisa que percebo que os agents não fazem bem do ponto de vista da experiência do produto. Outro padrão que os agents esquecem completamente de implementar são as atualizações otimistas. Em vez de mostrar um monte de indicadores de carregamento aos usuários sempre que eles realizam alguma ação, você mostra imediatamente o estado de sucesso, de forma otimista, e sincroniza em segundo plano a alteração que fizeram. Se a sincronização ou a operação falhar por algum motivo, você simplesmente desfaz a alteração e avisa: “Ah, a operação não funcionou”.

3:55:23 Agora, é claro, você não deve usar atualizações otimistas às cegas para tudo. Há alguns cenários em que você quer mostrar ao usuário um indicador de carregamento e esperar para verificar se tudo funcionou corretamente. Mas, em geral, as atualizações otimistas fazem a experiência como um todo parecer significativamente mais rápida, muito mais ágil e simplesmente muito mais imediata. Então, tenho quase certeza de que você pode simplesmente pedir ao seu agent: “Ei, gostaria de implementar atualizações otimistas onde fizer sentido. Vamos elaborar um plano.” E ele vai dizer todas as áreas em que faz

3:55:54 sentido fazer isso. De novo, não é difícil para o agent implementar. Você só precisa pedir e saber exatamente o que pedir. Agora, na minha opinião, uma extensão das atualizações otimistas é dar aos usuários a possibilidade de desfazer certas ações. Por exemplo, se você pedir ao seu agent para implementar a possibilidade de excluir registros, normalmente ele vai adicionar um botão de exclusão. Você clica nele, talvez apareça uma caixa de diálogo de confirmação, você confirma e então a exclusão é realizada. Mas uma experiência muito melhor é, na verdade,

3:56:26 permitir que o usuário desfaça essa ação. Então, ele clica em excluir, você remove imediatamente da interface o item que ele quer excluir, mas avisa: “Ei, você tem alguns segundos para mudar de ideia.” Se ele não fizer nada, isso significa que realmente quer excluir o item. Aí, você realiza a operação. Caso contrário, se ele clicar em desfazer, você simplesmente restaura a alteração. Então, é como se você também realizasse a operação em segundo plano. É só uma ação com atraso, o que se conecta à

3:56:57 próxima ideia, que é arquivamento. Você deve dizer ao seu agent que quer poder arquivar registros e desarquivá-los, porque às vezes você quer ocultar algo completamente da interface ou, digamos, dos resultados da busca, e arquivar é a maneira de fazer isso. Você não deve obrigar o usuário a pensar: “Bem, se não quer ver isto, tem que excluir.” Uma experiência muito melhor é simplesmente poder arquivar registros. Então, acho que esse é um padrão que definitivamente deveria existir. Outra coisa importante para mim é o estado na URL. Você

3:57:28 deve pedir ao seu agent que persista o estado na URL sempre que fizer sentido, é claro. Isso é muito útil porque, quando você tem, digamos, uma lista de registros e quer poder filtrá-los ou ordená-los, e tem um monte de condições, mantê-las na URL facilita muito compartilhá-las com outra pessoa. Assim, digamos que outro membro da equipe consiga ver exatamente o que você quer mostrar. Agora, outro detalhe que os agents não implementam por padrão é a rolagem infinita. Não quero ficar clicando em “Carregar mais”

3:57:59 repetidamente, nem em um botão de próxima página. À medida que rolo a tela, os dados simplesmente deveriam aparecer. Eu não deveria precisar clicar em próxima página para, no fim, perceber: “Ah, cheguei ao final.” É uma coisa muito pequena, mas, quando você usa algo todos os dias, acho que faz uma enorme diferença. Agora, outro padrão que descobri que melhorou significativamente os resultados foi dizer explicitamente ao agent para usar páginas existentes como referência para a interface, a busca de dados, como tudo funciona e como a coisa é estruturada no geral.

3:58:30 Isso tornou possível definir, essencialmente, uma vez o que significa fazer um bom trabalho e depois reutilizar essa referência para mais funcionalidades. Para ser completamente honesto, às vezes, mesmo quando você diz ao agent: “Ei, use a página X como referência”, ele simplesmente não segue a instrução. Não sei se os modelos às vezes ficam mais burros, mas isso acontece. No geral, porém, eu diria que tenho mais sucesso quando digo ao agent: “Bem, use uma página existente como

3:59:00 referência”, porque assim você também acaba tendo uma experiência mais consistente. Enquanto usa o app, pensa: “Ah, isto combina com a outra parte do app”, se as duas compartilham o mesmo conceito. Por exemplo, se duas partes do app são basicamente listas de registros que você pode criar, atualizar, excluir e consultar, ambas deveriam ser praticamente idênticas. Essa lista me leva ao próximo ponto: sempre que você tiver opiniões bem definidas sobre alguma coisa, elas devem ser organizadas em skills de agent. Assim, seu

3:59:31 agent vai seguir essas skills bem de perto sempre que estiver construindo algo. Enquanto eu criava todas as nossas ferramentas internas, percebi que recorria a três skills de agent. Duas delas são relacionadas a design engineering. Uma facilitava criar interfaces melhores, tipografia melhor, layouts melhores e mensagens de erro melhores em geral. A segunda era um conjunto de skills de design engineering que facilitava criar animações melhores e outras coisas desse tipo. E, por último, mas não menos importante, estão as skills de agent da Railway,

4:00:02 é claro. Tudo o que criei internamente para nós na Railway roda na Railway, é claro, tudo mesmo. Então, buckets, bancos de dados, o próprio app, o servidor em tempo real, tudo. E, para o agent trabalhar com a Railway de forma eficaz e conseguir fazer deploy de tudo, nós simplesmente fornecemos as skills de agent, e ele conseguiu fazer isso. E, sim, depois que você tiver todas as suas skills de agent e tudo mais, na minha opinião, a etapa final — e acho que a mais importante — é

4:00:32 a verificação. Normalmente, quando você pede aos agents para construir algo, eles dizem: “Certo, implementei a funcionalidade, o build passou, os testes passaram, está tudo certo, né?” Mas descobri que, quando você experimenta de verdade, às vezes acaba com uma experiência completamente quebrada. Então, quando você tem um ciclo de verificação implementado, a diferença é enorme, porque dá para ver o agent literalmente dizer: “Certo, construí isto. Testei. Falhou. Vou corrigir.” E ele

4:01:03 continua. E, no fim, diz: “Certo, testei tudo por completo.” Percebi esse avanço com o uso do computador quando isso ficou muito, muito bom. Agora, sempre que quero adicionar uma funcionalidade, no fim digo literalmente: “Você deve verificar se a funcionalidade funciona de ponta a ponta e usá-la executando a infraestrutura para testar tudo de ponta a ponta.” E os agents são muito capazes de fazer isso. Você só precisa dizer a eles. E, quando tiver todas essas peças, eu diria que vai acabar

4:01:34 com ferramentas internas sólidas, que você consegue criar rapidamente, que funcionam direito e de maneira consistente. E é isso. Esta foi a minha lista de princípios que uso sempre que crio ferramentas internas. Espero que tenham sido úteis, mas, mais importante, que você se sinta inspirado a criar suas próprias ferramentas internas, que sejam agradáveis de usar, refinadas e tragam alegria. E espero que você também possa se tornar a camada SaaS da sua empresa. E, com isso, muito obrigado por assistir. Vejo vocês no próximo vídeo.

4:02:29 Eu gosto muito deste artigo de Hannis, da DuckDB, em que ele pergunta se passamos uma década perseguindo arquiteturas distribuídas que pressupunham que computação e armazenamento eram lentos e caros. No entanto, a capacidade disponível em cada época define a arquitetura e as ferramentas, e as ferramentas ficam consistentemente para trás. Primeiro, tornamos a computação mais barata que o armazenamento; depois, disponibilizamos essa capacidade para todo mundo; em seguida, tornamo-la mais rápida. E, a cada vez, as arquiteturas passam por uma mudança enorme. Toda a nossa infraestrutura de dados hoje é construída com base na ideia de que

4:03:00 transformar é caro. E se isso já não fosse verdade? Acredito que resolvemos o último gargalo da transformação: a inteligência geral, ou julgamento, e a disponibilizamos sob demanda ao longo de toda a fronteira de Pareto, o que nos deixa bem à beira de uma mudança de paradigma. Então, nesta palestra, vamos abordar por que ontologias únicas sempre falham, os três papéis que os modelos desempenham em pipelines, a interseção de priors de modelos para obter melhores resultados e o Pareto surfing. Como

4:03:31 os modelos de hoje conseguem ajustar uma carga de trabalho para custo, velocidade e precisão, tudo ao mesmo tempo. Aqui vai um exemplo rápido. Quando Jeff foi lançado, já tínhamos um pipeline de resolução de entidades em execução, analisando os registros de financiamento de campanhas de Ohio e determinando se eles pertenciam à mesma pessoa, empresa ou comitê. A projeção era de que custaria cerca de US$ 10.000. Nossos sistemas pegaram esse novo modelo, descobriram onde ele se encaixava, testaram mais de uma dúzia de abordagens e o integraram. Dez dias depois daquela primeira

4:04:01 ligação, tínhamos a verdade fundamental final para cada caso de doador em Ohio abaixo de US$ 800. Esse é o poder de burrito surfing e das transformações just in time. Então, vamos falar sobre ontologias. Elas são a versão empresarial dos mapas mentais. É essa armadilha que nos atrai a todos, inclusive a mim. Falei sobre um esquema universal único quando fundei a Southbridge, há dois anos. A concepção popular

4:04:31 — e não está errada, só é uma pequena parte do quadro — é que migrações e ontologias fracassam por falta de adesão. Que são abandonadas pela metade, que organizações e pessoas nunca fazem a transição. Tudo isso é verdade, 100%. Mas a adesão não é o motivo principal. Digamos que você pudesse integrar e migrar todas as suas informações para um único superesquema num piscar de olhos; ainda assim, teria de lidar com a verdade de que não existe um superesquema. Na verdade, existem quatro esquemas. O primeiro pertence

4:05:03 à fonte, onde quer que a informação se origine. Vamos usar a temperatura como exemplo. Digamos que eu peça para você anotar a temperatura. O esquema da fonte é aquilo a que você tem acesso: seu celular, que informa a temperatura do sensor da sua região; o sensor na sua mesa, que é menos preciso, mas está mais perto; ou seu relógio. Mas até mesmo sua disposição para atender ao meu pedido faz parte desse esquema da fonte. O segundo é o esquema de armazenamento. Há um limite para o que você pode anotar. Você não pode anotar o firmware do dispositivo que está usando.

4:05:35 Você não pode nem anotar o horário com precisão de segundos, porque não conseguiria terminar de escrever tudo isso em um segundo. Esse é o esquema imposto pelo armazenamento. O terceiro pertence à decisão. Por que preciso que você anote a temperatura? Talvez eu esteja tentando descobrir o que deixa você confortável; nesse caso, preciso de temperaturas suas ao longo do dia e preciso garantir que seja você quem está fazendo as medições. Talvez eu esteja criando mapas de migração climática; nesse caso, não me importa quem faz as medições, mas me importam muito sua localização exata, o

4:06:05 horário, o dispositivo que você usou e se isso mudou. Ou talvez eu esteja decidindo se devo instalar equipamentos sensíveis e onde instalá-los; nesse caso, você mesmo se torna uma variável que preciso eliminar. Mas existe um quarto, ao qual chegaremos quando falarmos de prior. Ele é uma adição recente. O verdadeiro problema é que você nunca conhecerá os quatro esquemas ao mesmo tempo, exceto no momento em que a decisão é tomada. Em quase todas as empresas e em todos os lares, a maior parte dos dados registrados mal sabe para que vai ser

4:06:36 usada. Pense em um cliente, a primeira entidade de toda ontologia. Para o faturamento, cliente é quem paga. Para o suporte, é quem liga. Para compliance, é quem nos responsabiliza. E você só sabe qual é a definição quando conhece a decisão. Devemos reembolsar este pedido? Podemos conceder mais crédito a esta conta? De repente, fica extremamente claro o que você precisa saber e em que grau. Por isso eu estava errado. Não existe um esquema universal. Não existe um conceito de

4:07:08 cliente que seja separado da pergunta que você quer responder. E reunir esses esquemas é o processo de transformação que torna a informação realmente útil. É pegar o contexto em que ela foi registrada e combiná-lo com o contexto da decisão, e isso exige discernimento. Fazer essa combinação quando o espaço de decisão é conhecido, em vez de fazê-la antes, é o que quero dizer com ontologia just in time. Então, voltaremos ao discernimento com uma história do meu último emprego, em que, como na maior parte do meu trabalho, eu precisava garantir que certos

4:07:39 números simplesmente nunca existissem. Agora, um pouco sobre mim e sobre nós. A melhor forma de nos descrever é como obsessivos. Obsessivos que incorporam inteligência aos pipelines. Pipelines que podem escalar, que podem ser executados repetidas vezes para realmente tirar o trabalho das nossas mãos. E pipelines que podem amadurecer por conta própria em custo, desempenho e velocidade. A maior parte do trabalho que fazemos com dados se divide em três regimes. O primeiro é escrever uma vez, executar

4:08:09 uma vez. Se você faz algum tipo de desenvolvimento, pense neles como funções de invocação imediata em escala monstruosa. São criados para algo de uso único, como juntar um conjunto de dados, minerar informações ou responder a uma pergunta específica, e depois são descartados. O segundo é escrever várias vezes, executar uma vez, em que muitas cargas de trabalho, menores e maiores, são criadas para um único grande objetivo em comum. O exemplo mais próximo que você talvez conheça são grandes migrações: anos de registros transferidos de sistemas dos quais ninguém se lembra por completo. Muitas

4:08:40 cargas de trabalho criadas para uma única transferência e verificadas individualmente na origem, comparadas umas com as outras, porque tudo isso só acontece uma vez. O terceiro, porém — e esse é o nosso ganha-pão e o mais comum — é escrever várias vezes, executar várias vezes. São pipelines repetíveis, criados e mantidos ao longo do tempo, à medida que adicionamos mais informações. Na Sopridge, tiramos tanto trabalho da thread principal e o colocamos nesses sistemas repetíveis — do design e acompanhamento de benchmark à programação e à criação de legendas para filmes que queremos assistir. Quase tudo o que fazemos no

4:09:12 mundo moderno é uma transformação de dados ou é limitado pela dificuldade de transformar dados. E, em todos esses casos, nosso trabalho é simples: garantir que as pessoas possam confiar nos resultados. Em apenas dois anos, passamos de descobrir como tornar confiáveis os primeiros modelos no nível do 3.5 turbo em áreas como saúde, envelhecimento e pesquisa de mineração, para criar o Hank wave, um harness open source para trabalho com dados, e então usá-lo para fazer modelos trabalharem juntos em escala de terabytes. Hoje, temos sistemas que podem se auto-otimizar. Você lhes dá o problema,

4:09:44 uma forma de falhar com segurança e um lugar para trabalhar, e eles encontram o formato da solução. Escolhem os modelos certos. Executam os pilotos. Aumentam a escala e fazem burrito surfing até chegarem à melhor opção que conseguem encontrar. Então, hora da história: no meu último emprego, a pergunta que mais ouvíamos era: podemos transformar isso em uma decisão baseada em dados? Às vezes, essa era a pergunta certa, quando tínhamos milhares de embarcações na plataforma. O problema é que também fazíamos essa pergunta

4:10:14 quando tínhamos apenas 50 usuários. E, se você conhece estatística, consegue explicar muito bem por que fazer teste A/B com 50 usuários é uma má ideia. Não porque você não vai obter um resultado, mas porque vai. Então, a única opção real era não produzir número algum, porque, no momento em que um número existe, ele argumenta a favor de um resultado. Hoje, porém, é pior. Agentes interativos sempre vão dar uma resposta. Vão dá-la rapidamente. Você pede uma transformação, qualquer que seja, e recebe um “sim” confiante,

4:10:44 senhor. Isso significa que os erros se acumulam rapidamente. Um momento no chat pode virar um pesadelo de produção para sempre, só esperando para ser descoberto. O principal motivo disso acontecer é que, no trabalho com dados de hoje, a inteligência ocupa três funções distintas que os agentes de programação acabam misturando em uma única context window. Vamos separá-las, porque isso vai ajudar bastante quando chegarmos aos decision models, já que eles se encaixam exatamente em uma dessas três funções. A primeira é construir e projetar o pipeline, o que envolve decompor o problema,

4:11:15 escrever as especificações iniciais e autorizar gastos. A segunda — que costuma ser confundida com a primeira e atribuída aos mesmos modelos — é trabalhar dentro do pipeline, fazendo o trabalho de fato: ler o PDF, gravar em bancos de dados e verificar resultados. Antes de chegarmos à terceira, quero deixar claro que essas duas funções apontam em direções bem diferentes. A primeira precisa de modelos mais lentos, com tokens mais pesados e densos, modelos capazes de pensar mais, explorar um problema por diferentes ângulos, assimilar documentação, entender

4:11:46 como esses pipelines são construídos e prever como algo vai se sair antes mesmo de começar, certo? Opus ou superior. Mas os modelos que você quer dentro dos pipelines são o oposto. Você os quer mais baratos, mais rápidos, especializados, bons em seguir instruções, trabalhadores repetíveis com defeitos conhecidos. Vemos a mesma coisa na natureza. Uma colônia de formigas-cortadeiras, por exemplo, funciona com quatro tamanhos diferentes de operárias: pequenas, médias, grandes e extragrandes. Ao observar qualquer sistema que você projeta, revisa ou sobre o qual ouve falar, preste atenção ao que

4:12:17 ocupa cada espaço e a onde, nesse bolo de camadas, porque isso faz uma grande diferença. E, por termos essa distinção, foi muito fácil trazer Jev para essa classe recém-explosiva de decision models. Eles são construídos para serem trabalhadores. São feitos para entrar rapidamente em contato com informações e são implantados na extremidade inferior de grandes cargas de trabalho. Mas há uma terceira categoria, algo que chamamos de escaladores de colinas ou surfistas. Modelos que conseguem fazer uma primeira tentativa e se auto-otimizar. Com o conhecimento e as instruções certos, e uma superfície incrivelmente estável para

4:12:47 se apoiar, eles podem experimentar coisas novas, variar os orçamentos para limitar a exposição a custos, depurar rapidamente, tomar notas e ir avançando até a solução certa — e não apenas isso, mas até a solução ideal. Chamamos isso de surfe de burrito e vamos falar sobre isso no final. Mas, primeiro, vamos falar da nossa experiência com Jev. Jev foi lançado numa terça-feira, quando estávamos mergulhados em um pipeline de resolução de entidades. Você estava trabalhando com doadores nas finanças de campanha de Ohio. E, a essa altura, muita gente já viu este gráfico. Nós

4:13:17 já falamos dos resultados e adaptamos parte do trabalho em andamento ao conjunto de dados. Então, você pode baixá-lo para usar por conta própria, com os prompts e tudo mais. O que não discutimos foi tudo o que aconteceu por trás daquela seta e o que ocorreu quando aplicamos a mesma ideia ao estado inteiro. Aqui estão todas as arquiteturas que testamos. Começamos com três projetos em um pequeno conjunto de desenvolvimento. Um modelo de raciocínio barato por conta própria; Jeff com um modelo de raciocínio para tudo de que não tinha certeza; e um modelo de raciocínio propondo respostas, com Jeff verificando-as, em cerca de 200 famílias reservadas para teste. O

4:13:50 modelo de raciocínio barato por conta própria teve um desempenho tão bom quanto Fable por cerca de 2% do custo. Jeff acertou as respostas principais, mas não identificou nove relações entre membros de domicílios, porque havia respondido com confiança “não” a todas elas. Então, reescrevemos as perguntas sem tocar nos modelos nem nos limites. A pergunta sobre o domicílio passou a dizer o que conta como evidência suficiente, e Jeff passou de responder “não” a todas as 13 perguntas de desenvolvimento para responder “sim”. E, ao ampliar a execução para todo o estado, fizemos mais de uma dúzia de rodadas desse tipo de qualificação. Cada rodada

4:14:21 corrigiu uma definição: o que é um comitê, o que significa um declarante, o que significa duas pessoas morarem no mesmo endereço? Agora, cada um dos 23.317 casos de Ohio tem um rótulo que indica em que a resposta se baseia e até que ponto ela foi verificada. Esta é a hierarquia que descobrimos para esse problema específico. E aqui está tudo o que aprendemos sobre como incorporar decision models a pipelines. Vou deixar isso na tela para você tirar uma captura de tela. Mas veja onde o dinheiro foi gasto. Todo o trabalho para o estado inteiro custou US$ 795, dentro de um orçamento de

4:14:52 US$ 800 definido com antecedência. A verificação custou cerca de quatro vezes mais do que as 5,45 unidades gastas em segundas opiniões, resolução de divergências e auditoria, em comparação com as 128 destinadas às respostas iniciais. E, antes de Jev, esperávamos que esse trabalho custasse cerca de US$ 10.000. Agora que o pipeline está construído e verificado, esperamos que o orçamento de auditoria para o próximo estado seja próximo de zero. O mais impressionante é que nosso agent 4A, executado primeiro no Astra e depois no Opus, encontrou a maioria dessas abordagens

4:15:23 por conta própria, de forma incremental, construindo o sistema, executando-o, depurando-o e experimentando coisas novas. Ele funcionou por 10 dias e testou mais de uma dúzia de arquiteturas. Seus Hanks foram executados mais de 4.000 vezes, junto com 90.000 chamadas a Jeff. Ele testou praticamente todos os modelos na fronteira de ponta e os modelos usados nessas execuções processaram cerca de 6 bilhões de tokens. E, depois de tudo isso, registramos o que aprendemos em nossa biblioteca de padrões de agentes. Este trabalho se apoiou nesses padrões já existentes, e estamos

4:15:55 adicionando novos padrões testados, como a camada de verificação. Para mim, esse é o valor de tirar o trabalho da linha principal, tanto para as pessoas quanto para os agentes, porque cada uma dessas iterações era um Hank sob controle de versão. Eram fáceis de reverter, entender, depurar e criticar. Então, os modelos já conseguem fazer isso nativamente? Ainda não. Faltam quatro coisas, que vamos abordar. Mas há algo que não desaparece à medida que os modelos ficam maiores e mais capazes: os vieses prévios.

4:16:26 Assim como os humanos, os modelos levam para cada tarefa seus próprios vieses prévios, suas crenças sobre o que deveria existir no mundo. Este é o quarto esquema que mencionei antes: aquele que o modelo traz consigo. De um jeito estranho, modelos maiores são piores nisso. Às vezes, eles se apegam às próprias crenças e as defendem com ainda mais veemência. Aqui estão alguns exemplos que encontramos. Um pipeline procurava por “in kind” escrito com sublinhado. O arquivo usava I maiúsculo e hífen. Então, o modelo contou 15.658

4:16:59 contribuições em espécie como dinheiro comum e também não conferiu novamente os pagamentos de empréstimos, que desapareceram da mesma forma. Outro modelo tentou quatro formatos de data, embora o arquivo usasse o formato dois-quintos. Assim, 99,4% das datas das transações ficaram vazias, mas todas as contagens de linhas e os valores em dólares corresponderam. Então, o agent seguiu em frente. Em várias execuções, o modelo percebeu que os valores dos empréstimos eram negativos. Decidiu que o sinal era redundante e armazenou o valor absoluto. Assim, um saldo líquido de 784.000 acabou se tornando uma dívida de 5,3 milhões,

4:17:33 validada por vários modelos. E essa classe de erro está rapidamente se tornando a maior que vejo entre empresas que trabalham com dados, à medida que os modelos assumem esse trabalho. Às vezes, dá para resolver isso simplesmente não fazendo vibe coding, verificando os resultados e aplicando a intuição humana. E o que você está fazendo nesse caso é interessante: está cruzando seus vieses prévios com os dos modelos. No primeiro exemplo, qualquer pessoa perceberia a falta de contribuições em espécie se entendesse de financiamento de campanha ou pensaria em conferir. Foi assim que descobrimos. Mas os humanos,

4:18:04 falando como humano nesta tarefa específica, são caros. São lentos. Atrasam os cronogramas. São ainda mais não determinísticos que os modelos e detestam interrupções. Mas acontece que também é possível avançar bastante cruzando os vieses prévios entre modelos. Nas nossas 200 famílias reservadas para teste, Jev e Luna concordaram em 194, e nenhuma dessas respostas compartilhadas estava errada. Todos os erros estavam nas seis famílias em que divergiram. Modelos de famílias diferentes, com origens diferentes, tendem a discordar mais e a ter vieses prévios diferentes dos modelos do mesmo grupo. Por exemplo, a exceção — não vou dizer quem — são modelos destilados fora da mesma empresa. Então, com esse tipo de trabalho, dá para reduzir bastante a superfície de possibilidades e, junto com ela, os erros, deixando uma classe muito menor, mas persistente, de problemas que afetam os LLMs como espécie.

4:18:35 Em um benchmark, por exemplo, quatro famílias diferentes de modelos chegaram ao mesmo total, até o último dígito, porque todas compartilhavam uma convenção de sinal diferente daquela do gabarito. E, quando você chega a esse ponto, a única maneira

4:19:06 de avançar é listar esses problemas, ficar atento a eles e aplicar soluções específicas. Voltando ao assunto: quais são as quatro coisas que nos faltam para conseguir nos auto-otimizar? A primeira é uma superfície de implantação estável. Para isso, usamos Hank, um harness que pega a superfície volátil dos ambientes de execução de agents, como Claude Code e pi, e oferece uma interface consistente, bem testada, de logs e API, com checkpointing, reversão, controle de orçamento e tudo mais integrado. Algo sobre o qual você possa construir. Mas há outras

4:19:37 coisas que se encaixam nessa descrição. Para ser justo, em trabalhos de dados sem interface gráfica, eu diria que Hankwave ainda é o mais antigo, estável e aberto. Vou deixar a skill disponível caso você queira experimentar. A segunda coisa é alguma maneira de limitar seus experimentos. Você não consegue testar se não puder controlar custo, tempo e acesso como recursos. A terceira é conhecimento prático e metodologia. Descobrimos que essa nova classe de modelos consegue aproveitar tudo o que aprendemos em dois anos de implantações — padrões de agentes, técnicas de depuração e elaboração de prompts — e aplicar isso a

4:20:08 problemas complexos. Com a camada de abstração certa, você consegue expressá-lo usando tokens de forma muito eficiente, e os modelos conseguem implementá-lo. O quarto, e mais importante, é uma superfície de falha. Nosso comitê disse: “Dê-me um ponto de apoio e moverei a Terra.” No nosso caso, não encontramos um problema ou uma restrição que não pudéssemos resolver iterando, desde que tivéssemos uma pilha estável sobre a qual construir e uma superfície de falha contra a qual iterar. Esse último ponto foi o mais difícil de expressar em palavras e em ferramentas e instruções que ajudem

4:20:38 os modelos a chegar lá. Os melhores modelos atuais ainda mal conseguem lidar com esses lampejos de inteligência, por assim dizer. O processo todo, porém, passa por seis etapas. Primeiro, especificamos o trabalho e o dividimos. No caso de Jeff, isso significa dividir cerca de 800 mil linhas em 200 mil casos menores e especializados, e cada um desses casos em perguntas tipadas. Que tipo de doador, um doador, sabe, perguntas diferentes que precisavam ser respondidas. Depois, definimos a superfície de falha. Neste caso, rodamos bons modelos em uma pequena

4:21:09 parte dos dados, verificando manualmente alguns deles para estabelecer uma linha de base contra a qual possamos falhar. Em outros casos, criamos sistemas automatizados de falha. Criamos verificações de schema. Também tratamos o comportamento como algo que podemos avaliar. Mas é muito importante definir uma superfície de falha antes mesmo de começar. Agora vem a parte divertida. Executamos pilotos mínimos e limitados para testar a arquitetura. E, quando algo começa a funcionar, transferimos essas verificações para rigs. Código que é executado entre

4:21:39 segmentos de trabalho limitados que chamamos de códons. Esses códons são então reutilizados, executados em ciclos independentes, validados e colocados em sequência. Por fim, pipelines funcionais são colocados em produção, onde podem amadurecer lentamente, e é naquela parte intermediária que acontece o surf. Encontramos uma arquitetura que produz um resultado sólido. Usamos isso como linha de base e substituímos os modelos e algumas outras partes por opções mais rápidas e baratas, comparamos com intermediários conhecidos, apertamos os requisitos de sucesso a cada vez, avançando cada vez mais em direção ao

4:22:11 ideal, e simplesmente observamos a fronteira se mover. Conseguir dividir um problema complexo em partes significa que cada parte pode avançar para sua própria posição ideal. Como diria Adam Smith, em um sistema como esse, ontologias existem como intermediárias entre inteligência e resultado, o que facilita sua reutilização. Essa é a outra metade do que quero dizer com ontologias just-in-time. Elas são criadas quando o trabalho precisa delas, mantidas com seus comprovantes e reutilizadas quando o próximo trabalho precisa da mesma coisa. E, quando você

4:22:42 as tem, pode tornar essas coisas mais baratas. Você pode executá-las em paralelo em conjuntos de dados para ampliar a escala. Vou encerrar com um pedido de desculpas, certo? A resposta é que não existe uma ontologia. Não uma universal. Na verdade, nunca existiu. A boa notícia é que isso torna válida qualquer ontologia e qualquer schema, desde que você consiga rotular e preservar o contexto em torno deles. E, se conseguirmos aproveitar essa inteligência barata que começa a se espalhar pelo mundo ao nosso redor, estaremos nos aproximando rapidamente de um futuro em que qualquer informação, em qualquer formato, será tão

4:23:14 útil quanto possível. E, na Subridge, estamos trabalhando o máximo que podemos para tornar esse futuro realidade. Obrigado.

4:23:49 Olá, sou Kartik, CTO da Perpetual. Nesta apresentação, vou falar sobre como criar workflows que sejam confiáveis e inteligentes para finanças, gestão de patrimônio e seguros. Em áreas regulamentadas, os workflows precisam ser confiáveis o bastante para atender aos padrões regulatórios e, ao mesmo tempo, inteligentes o bastante para lidar com o mundo real em áreas como finanças e gestão de patrimônio. Isso traz tanto um problema técnico quanto de conformidade. Confiabilidade e inteligência não são opostos. Cabe a você decidir onde traçar o limite entre elas. E esse é o objetivo desta palestra: decidir onde esse limite

4:24:21 fica. Para nós, não é apenas um experimento mental, mas uma questão com consequências sérias. A Perpetual é uma consolidadora de empresas de gestão de patrimônio: adquirimos empresas tradicionais desse setor e maximizamos sua capacidade de processamento e sua receita com a ajuda de IA. Gestão de patrimônio é um setor regulamentado, e é nele que desenvolvemos com IA em produção. Tudo o que digo nesta palestra se baseia na construção para atender a essas restrições. Os workflows em finanças e gestão de patrimônio têm quatro características, e cada

4:24:51 uma delas leva a arquitetura na mesma direção. Primeiro, são complexos e precisam de estratégias em tempo de execução à medida que o processo se desenrola. Não dá para programar todos os caminhos com antecedência. Segundo, os dados são sensíveis. Portanto, é preciso ter uma maneira de transferir esses workflows por completo para modelos hospedados de forma privada. Terceiro, em um setor altamente regulamentado, uma violação de política não é um relatório de bug. Ela tem consequências graves. Portanto, em quarto lugar, a execução precisa ser altamente confiável e determinística. Injete inteligência somente onde o julgamento em tempo de execução é

4:25:21 realmente necessário e minimize a dependência de LLMs em todos os outros casos. A IA está se difundindo pelos setores regulamentados. Mas ainda não há consenso sobre uma arquitetura que ofereça alta confiabilidade com o mínimo de uso da inteligência dos LLMs. Enquanto isso, a maior parte do que os desenvolvedores ouvem dos grandes laboratórios é sobre como gastar mais tokens. Mas, em um setor regulamentado, maximizar o uso de tokens é o objetivo errado. Essas tarefas são bastante previsíveis. Você pode organizá-las com antecedência e incorporá-las a uma máquina de estados gigantesca

4:25:51 que precisa apenas de um toque de inteligência para percorrê-la. A maioria das etapas simplesmente segue para o próximo ramo. Só em alguns pontos de decisão o modelo escolhe um caminho. Portanto, a maneira inteligente de construir é usar inteligência de forma mínima e intencional. Vamos concretizar isso com um workflow real de gestão de patrimônio. Um consultor de patrimônio liga para seu assistente e diz uma frase: “Preencha o formulário W9 do IRS para o Sr. Harper.” Para uma pessoa, é uma instrução simples. Veja o que ela

4:26:23 realmente desencadeia quando um ser humano a executa. A tarefa tem complexidades que vão além do que parece à primeira vista. Primeiro, o assistente encontra o formulário W9 nos registros da empresa ou no site do IRS. Depois, procura o Sr. Harper no sistema de registro e encontra três famílias Harper. Então liga para o consultor: “Qual Harper você quer dizer?” Só depois de resolver essa ambiguidade é que passa ao formulário. Uma busca, uma ambiguidade e uma pessoa no ciclo, tudo no primeiro minuto de uma tarefa de uma linha.

4:26:58 Preencher um formulário parece entrada de dados. Não é. Cada formulário é um pequeno programa. Primeiro, o W9 determina quem é o contribuinte: a pessoa ou o proprietário, se for uma entidade desconsiderada. Uma pessoa estrangeira para por aqui, porque precisa de um W8. Depois, determina como ela é tributada. Exatamente uma opção na linha 3A, e uma LLC acrescenta sua letra. Isso determina qual nome vai na linha um e qual vai na linha dois. Depois, qual número? Um SSN ou um EIN? Nunca

4:27:30 os dois. Deve ser obtido de um documento verificado, nunca de memória. Os códigos de isenção se aplicam apenas a algumas entidades, nunca a uma S corporation. E, por fim, quem assina sob pena de perjúrio? Cada resposta muda a pergunta seguinte, e as pessoas envolvidas só encontram três tipos de etapas: uma pergunta, um documento a coletar ou uma assinatura. Agora, começam a preencher o formulário e percebem que o sistema de registro não contém três dos valores necessários. Elas verificam

4:28:01 os documentos arquivados e consultam novamente o sistema de registro; ainda faltam os valores. Então iniciam uma conversa por e-mail com o cliente, pedindo exatamente esses três valores. A tarefa agora depende de alguém de fora da empresa e do prazo dessa pessoa. E o workflow fica aguardando. O pedido está com o cliente, e os três valores continuam faltando. Se o cliente não responder em dois dias, o assistente faz um acompanhamento e leva o assunto ao consultor na reunião diária. Se o cliente

4:28:31 responder com apenas dois dos três valores, o assistente faz outro acompanhamento para obter o que falta. Quando os três chegam, preenche o formulário e grava as novas informações de volta no sistema de registro, incluindo o histórico de como obteve esses valores. Neste setor, saber como um valor foi obtido importa tanto quanto o próprio valor. Depois de preenchido, o formulário é enviado para assinatura eletrônica. Se o cliente não assinar

4:29:01 em um ou dois dias, o assistente envia outro lembrete. Depois que o documento é assinado, ele é arquivado para o cliente, o comprovante de recebimento é enviado e o consultor é atualizado na reunião diária seguinte. Uma frase do consultor virou um processo que dura dias, atravessa vários sistemas, espera por duas pessoas e volta sobre si mesmo mais de uma vez.

4:29:34 Vejam o que está dentro dessa única frase. Ambiguidades a resolver, dados a coletar, aprovações — tudo isso medido em dias. Ciclos de acompanhamento e um rastro de evidências no final. Existem ferramentas de automação de workflow, mas elas raramente dão conta dessa complexidade e ambiguidade do mundo real. Um fluxograma fixo falha diante do primeiro obstáculo e da falta de um sistema nativo de registro, com uma integração e um

4:30:06 agent que improvisa ao longo do processo é exatamente o que uma equipe de compliance não pode aprovar. Um falha diante da ambiguidade; o outro não pode ser aprovado. Nenhum dos dois dá conta do que está dentro daquela frase. Então, o que fazemos a respeito? A abordagem da moda é mais autonomia e modelos melhores. Dê ao agent a tarefa inteira e espere que o próximo modelo a torne confiável. A resposta reflexa, especialmente dentro de empresas reguladas, é o oposto: menos autonomia, mais regras, restringir tudo e codificar cada caminho. Ambos

4:30:39 estão no eixo errado. Em setores regulados, a confiabilidade vem de onde se coloca a fronteira entre os dois: entre as partes que precisam ser determinísticas e as partes que realmente exigem julgamento. Eis o princípio. O determinismo rege o fluxo de controle, as evidências e os efeitos colaterais: o que será executado em seguida, o que sabemos e como sabemos. E tudo o que muda o mundo, como registrar algo, enviar um email ou protocolar um formulário,

4:31:11 exige inteligência para interpretação e julgamento. Ler uma instrução ambígua, decidir de qual Harper se trata, entender a resposta de um cliente: o modelo responde a uma pergunta tipada, e o sistema determinístico decide o que fazer com a resposta. E essa interação é recursiva. Um julgamento pode abrir um novo plano menor, que é compilado, sujeito a controles e determinístico. Daqui a pouco vocês verão isso com os acompanhamentos. A fronteira entre os dois é o projeto. É assim que funciona o workflow engine que criamos.

4:31:50 A solicitação vai para um planejador, que é uma chamada de modelo e tem uma única função: traduzir. Ele emite um grafo semântico tipado de intenções, entidades, fatos, artefatos, eventos e restrições. Cada elemento é fundamentado nas palavras da solicitação, incluindo quaisquer ambiguidades encontradas. Cada nó aponta para as palavras de onde veio. Esse grafo vai para um compilador que nunca chama um modelo, em 11 etapas determinísticas. Ele transforma o grafo em uma tag de execução ou falha de forma segura. Existem

4:32:21 apenas três vereditos: válido, precisa de esclarecimento ou recusado. A questão de qual Harper é devolvida como pergunta, não como palpite. O plano é compilado, imutável e identificado pelo seu hash. O modelo traduz. O plano é compilado. O compilador verifica o plano em relação à gramática, ao vocabulário de

4:32:53 ações permitidas à empresa. São 42 contratos de ação tipados para formulários, documentos, email, assinatura eletrônica, calendário e etapas humanas. Cada ação solicitada pelo planejador precisa corresponder a um contrato. Aqui, o preenchimento de formulário encontra seu contrato e fica definido. Se o planejador solicitar uma ação que não está na gramática ou conectar algo incorretamente, o compilador recusa. Há cerca de 40 maneiras de falhar de forma segura, desde um ciclo no grafo até uma ação sem suporte. E o mesmo

4:33:24 resumo dos contratos fica fixado no engine, no backend e na interface. Assim, os três concordam sobre o significado de uma ação. É isso que um domínio fechado oferece. O modelo só pode solicitar coisas que a empresa já sabe fazer com segurança. Aqui está um plano compilado para cobrar o envio de um formulário W9. Envie o formulário ao cliente. Aguarde o retorno. Confira e arquive. Antes de qualquer coisa ser executada, alguém aprova o próprio plano. Encontre o formulário. Prepare-o para o cliente preencher. Gere o PDF e redija o email. Redigir é uma chamada de modelo,

4:33:56 portanto, é válido. O envio exige uma aprovação. Nada sai da empresa até que alguém aprove aquele email específico. Depois, o plano aguarda uma resposta, e um avaliador entra em ação para lê-la. O formulário devolvido é verificado. Se corresponder, é arquivado após outra aprovação. Se não corresponder, o plano faz o acompanhamento. Agora, vejam as etapas tracejadas: gerar o PDF, anexá-lo, avaliar

4:34:28 a resposta. O planejador nunca as solicitou. A gramática as adicionou porque os contratos as exigem. Na situação descrita, a espera, as aprovações e os acompanhamentos eram a maior parte do trabalho. Aqui, eles são nós do plano, não prompts. O tempo de espera padrão por uma resposta é de 72 horas, e um prazo explícito pode variar de um minuto a 30 dias. Quando o prazo termina, uma regra decide o que acontece, não um modelo. Uma aprovação cobre o plano, e cada ação externa, como enviar um email ou

4:35:00 uma solicitação de assinatura, tem sua própria aprovação. A aprovação está vinculada ao hash da carga exata e é verificada novamente logo antes do envio. Quando um cliente responde com apenas parte do que pedimos, o avaliador da resposta a classifica como parcial. Esse julgamento é provisório. A etapa continua bloqueada até que alguém a confirme. Alguém a confirma, e a etapa é desbloqueada. Então, o acompanhamento é executado como um novo plano filho. O plano pai aprovado nunca é alterado, e há no máximo cinco rodadas.

4:35:35 Depois que um plano é aprovado, uma máquina de estados o executa. Ela escolhe cada etapa e registra cada resultado. Quando uma etapa exige julgamento, ela faz uma chamada de modelo com um esquema fixo: redigir um email, avaliar uma resposta, identificar valores ausentes, extrair campos, verificar um documento. A resposta volta tipada, e a máquina de estados decide o que fazer com ela. Os efeitos colaterais têm um ciclo de vida próprio: preparação, envio, sucesso ou, quando o mundo não responde de forma clara, resultado

4:36:06 desconhecido e revisão manual. Não há novas tentativas automáticas. Uma mensagem de chat pode aprovar uma etapa ou responder a uma pergunta. Ela não pode alterar um plano já aprovado. O modelo orienta. Ele nunca conduz. Agora, vejam o que resta para o modelo fazer. Fora do planejador, os julgamentos são pequenos e tipados. Esta resposta está completa? Este documento corresponde? Qual campo é qual? Eles não

4:36:36 precisam de inteligência de ponta. Um modelo pequeno e rápido, da categoria flash, consegue lidar com eles. Nesta execução ilustrativa de 20 decisões, 19 são encaminhadas à categoria flash e uma, ao modelo de ponta. Por isso, projetamos o sistema para que cerca de 95% das decisões de modelo em um workflow nunca precisem de um modelo de ponta. E a categoria flash pode ser executada em hardware sob seu controle. Só os casos realmente difíceis vão para um modelo de ponta. E esses 5% não são um custo permanente,

4:37:07 porque cada julgamento é tipado e registrado, e os provisórios são confirmados ou rejeitados por alguém. Cada decisão de ponta produz uma distribuição de qualidade de evals e dados de treinamento reais por construção. Esses dados podem ser usados para pós-treinar a categoria flash; registro e evals já existem hoje. O ciclo de treinamento vem a seguir. Assim, a parcela de decisões encaminhadas a modelos de ponta diminui a cada versão, até que até os casos difíceis sejam executados localmente.

4:37:40 Lembrem-se do requisito com que começamos: como os dados são sensíveis, é preciso ter um caminho para migrar workflows inteiros para LLMs hospedados em ambiente privado. Então, será que esse projeto realmente consegue chegar lá? Vejam uma chamada tipada do plano Harper BB9. Cada chamada de modelo é pequena, tipada e validada em relação a um esquema. Portanto, direcioná-la a um modelo hospedado em ambiente privado é uma mudança de configuração, não uma reescrita. Muda-se uma linha, e a mesma resposta é retornada. Todas as outras chamadas têm o mesmo formato pequeno e tipado. Então, a mesma mudança

4:38:13 se aplica a quase todas elas. É assim que cerca de 95% de inference local se torna viável como consequência arquitetural, não como promessa de política. Esse é o caminho exigido por dados sensíveis, e o risco de compliance diminui conforme o roteiro de engenharia avança, versão a versão. Então, se vocês lembrarem de uma coisa, não perguntem se o sistema deve ter mais ou menos autonomia. Perguntem onde está a fronteira. Deixem o determinismo reger o fluxo de controle, as evidências e os efeitos colaterais. Deixem a

4:38:45 inteligência cuidar da interpretação e do julgamento. Em pontos tipados, vocês podem inspecionar cada julgamento registrado e usá-lo para precisar de menos inteligência. Da próxima vez, perguntem onde está a fronteira. Obrigado. Sou Karthik, CTO da Perpetual. Se vocês estão incorporando IA a atividades reguladas, adoraria comparar anotações.

4:39:27 Olá a todos e sejam bem-vindos. Meu nome é Edu e, junto com Javi, representamos a equipe de experiência da plataforma de IA da Flywa. Nossa missão principal é criar uma infraestrutura prática para agents que capacite nossos engenheiros soberanos, seguindo os padrões e as práticas de engenharia estabelecidos. Hoje, vamos compartilhar como a automação estruturada de workflow gera valor real para empresas, garantindo controle, segurança e confiabilidade em todo o nosso processo de desenvolvimento. Antes de entrarmos nos detalhes técnicos aprofundados

4:39:58 da nossa plataforma de IA, deixem-nos dar um contexto essencial sobre a Flywire. A Flywire foi criada para processar os pagamentos mais complexos do mundo em setores globais como educação, saúde, viagens e serviços empresariais. Hoje, atendemos mais de 5.000 clientes em mais de 240 países ao redor do mundo. Como processamos transações internacionais de alto valor, conformidade regulatória, privacidade e segurança não são complementos opcionais. Elas

4:40:28 são requisitos essenciais do nosso negócio. Operamos sob estruturas rigorosas de conformidade, como PCI, ESS e SOC 2. Isso significa que os dados dos clientes, as informações de identificação pessoal e os dados de pagamento precisam permanecer completamente seguros. Não podemos simplesmente pegar um contexto sensível e repassá-lo a serviços de terceiros sem governança rigorosa e limites arquiteturais. Para dar uma ideia da nossa organização de engenharia, temos cerca de 400 engenheiros de software distribuídos globalmente

4:41:00 entre nossas equipes. Mantemos uma pilha tecnológica diversificada, incluindo Java, Ruby, Go, Python, .NET e PHP. Quase tudo o que desenvolvemos e executamos é implantado na Victoria, nossa plataforma interna como serviço, que opera sobre a infraestrutura do GitLab e da AWS. Isso nos leva ao Orbit, nosso próprio eliminador de tarefas repetitivas. O Orbit é uma plataforma interna que elimina o trabalho diário de engenharia, chamado de toil, que fazemos todos os dias. Ele também mantém a base de código que os outros serviços de IA

4:41:31 e ferramentas que usamos na Flywire conseguem usar para iniciar workflows diretamente. Por exemplo, um engenheiro poderá pedir ao Clo no Slack, em casos…, para iniciar workflows diretamente. A Victoria inicia. >> Hum

4:42:01 e compartilha a solicitação … com os scorecards. medidas… >> Ótimo, desculpem, estou bem. Oi, pessoal, sou Ash, CTO da Modal, e vou falar sobre o que eles realmente precisam da infraestrutura. Então, me disseram que este público tem bastante relação com o setor financeiro, então pensei em falar sobre: e se

4:42:34 cada célula de uma planilha pudesse ser alimentada por um agent? Imaginem que vocês são analistas financeiros em um fundo. Querem fazer uma análise complexa de cada empresa do portfólio. Normalmente, no passado, isso levaria dias. Vocês teriam que se conectar a cada empresa do portfólio, analisar as fontes de dados dela e executar algum código Python para cada uma. E agora, obviamente, com agents

4:43:04 isso deveria ser muito mais fácil. Na verdade, uma das nossas clientes, a Hebia, criou algo exatamente assim. Vocês podem acessar o produto dela agora mesmo; nele, há uma planilha e é possível executar uma consulta em que, literalmente, cada célula é alimentada por um agent diferente. E eu queria falar sobre como é, de fato, construir isso. Bem, primeiro, cada agent é executado em um

4:43:39 sandbox da Modal. Um sandbox é um ambiente seguro para executar código não confiável. Antes, cada sandbox correspondia a um único contêiner ou microVM. Isso não é mais verdade. Hoje, a Modal tem um recurso que permite executar vários contêineres ou microVMs dentro de um sandbox, e vocês precisam fazer isso para algo como

4:44:09 isto. Nessa arquitetura, vocês executam o harness. O harness é o loop do agent, que faz coisas como chamar a API do modelo para inference, executar as chamadas de ferramentas e, em seguida, repetir o processo. Vocês querem separar isso do local onde as chamadas de ferramentas são realmente executadas, por segurança, isolamento e várias outras razões. Então, há o sandbox executando vários contêineres, incluindo um sidecar. Vocês também querem

4:44:41 armazenamento compartilhado, porque querem que os agents consigam se comunicar entre si. Cabe a vocês decidir como distribuí-lo: talvez cada linha receba o mesmo volume e os agents daquela linha da planilha possam colaborar. Em alguns casos, vocês também querem compartilhar o armazenamento entre o contêiner principal e o sidecar. E, por fim, tudo isso precisa iniciar muito, muito rápido, porque a planilha pode ter muitas células. Se alguém executar uma consulta, vocês vão querer iniciar milhares de agents e depois

4:45:12 encerrá-los quando tudo terminar. Antes de falar mais sobre isso, queria fazer um breve parêntese para explicar o que é a Modal. A Modal é uma plataforma de primitivas criada para aplicações de IA. Basicamente, construímos essa plataforma do zero. Criamos nossos próprios sistemas de arquivos, o agendamento e o ambiente de execução para oferecer ótimo desempenho e uma boa experiência de desenvolvimento em casos de uso como inference, incluindo inference de LLMs,

4:45:43 sandboxes, treinamento e funções que executam muito processamento em lote e outras coisas. Hoje, em particular, vou falar sobre sandboxes, sobre o que é essa primitiva e como ela está evoluindo. Se vocês querem construir algo assim, ou algo ainda mais avançado — e vamos falar mais sobre o que isso significa —, de quais primitivas precisam? Primeiro, se estão construindo um agent, precisam de um espaço de trabalho. Tenho alguns exemplos de clientes atuais. Talvez vocês conheçam o Ramp Inspect. O Ramp Inspect é o

4:46:16 agent de programação interno da Ramp, que, acho, neste momento abre quase todos os PRs da empresa. Se estão construindo um agent de programação, precisam do repo, do repo do GitHub, das dependências e dos serviços de desenvolvimento, tudo no mesmo espaço de trabalho de cada agent. Outro exemplo é a Basis. O que acontece é que os documentos chegam. Então, o agent é

4:46:47 acionado para trabalhar neles. Mas, depois, fica esperando uma resposta do contador, e vocês não sabem quanto tempo isso pode levar. Pode levar muitos dias. Quando isso acontece, vocês querem persistir o estado ao longo do tempo. O uso vai mudar. No segundo gráfico, vocês podem ver o uso de cada sandbox. Há algumas tendências consistentes, sem dúvida, mas o comportamento varia bastante. Então, provisionar os recursos dessa forma não faz sentido. É preciso conseguir obtê-los de forma confiável quando o sandbox precisar deles e apenas

4:47:19 pagar por eles durante esse período. Outra tendência interessante que está surgindo é que os agents precisam de muito mais recursos de computação científica: pré-processar dados em CPUs ou iniciar GPUs para executar um modelo científico. Isso será transferido para um sandbox da Modal. Estamos vendo isso aparecer em RSI, relacionado ao que acontece quando se dão sandboxes a um agent para ajudar o cliente. A próxima tendência é que os agents estão colaborando muito mais e

4:47:49 isso significa compartilhar um sistema de arquivos com o subagent. Compartilhar o sistema de arquivos. A próxima tendência é que os agents estão colaborando muito mais, e isso significa compartilhar arquivos e sistemas de arquivos

4:48:21 com as pessoas, de modo que todos colaborem no mesmo trabalho. Isso exige sistemas de arquivos rápidos, com consistência e uma boa experiência de desenvolvimento, sobre os quais seja possível raciocinar. É algo relacionado aos volumes da Modal em que estamos trabalhando. Também estamos vendo muito mais autoaperfeiçoamento: os agents salvam e atualizam a memória. Eles executam tarefas em segundo plano — agora chamadas de dreaming — para atualizar essa memória ao longo do tempo. E, na verdade, isso também se parece

4:48:52 com arquivos em um sistema de arquivos. Mas, novamente, vocês querem um desempenho realmente bom desse sistema de arquivos. E o assustador dos agents é que eles podem cometer erros e não sabem quando podem vazar seus dados confidenciais para um fórum alemão ou algo assim. Por isso, vocês precisam ter bastante controle sobre o que eles podem ou não fazer. Também precisam de recursos como controlar quais endereços IP

4:49:24 podem se comunicar com o agent, como autenticá-lo, com quais domínios ele pode se comunicar e, se estiverem usando credenciais para acessar serviços, precisam basicamente injetá-las de uma forma que o agent não consiga vê-las e depois exfiltrá-las para algum lugar. Uma evolução interessante disso é que percebemos que listas de permissões relacionadas a domínios, por si só, não são suficientes. Muitos dos nossos usuários querem um controle muito específico sobre até mesmo quais caminhos podem ser acessados, por exemplo, no Datadog ou no GitHub. Talvez queiram analisar operações específicas realizadas pelo agent. Voltando aos sidecars, temos visto surgir um padrão em que os usuários escrevem seu próprio proxy leve, com regras personalizadas sobre exatamente o que ele pode fazer. A RAMP é outro exemplo de empresa que tem usado isso com sucesso.

4:49:55 controle bem específico sobre, por exemplo, a quais caminhos posso me conectar no Datadog ou no GitHub. Talvez eu queira raciocinar sobre operações específicas que o agent está realizando. Voltando ao Sidecarves, vimos isso surgir como um padrão em que os usuários escrevem seu próprio proxy leve, com regras personalizadas sobre exatamente o que ele pode fazer. E a RAMP é outro exemplo de empresa que tem usado isso com sucesso.

4:50:26 E a última coisa subestimada é que é muito importante ter uma observabilidade realmente excelente. Voltando ao exemplo de pesquisa automatizada e de um agent fazendo muito treinamento: o que acontece quando a execução do treinamento falha? Você quer que seu agent consiga consultar facilmente os logs da falha, entender o que aconteceu e fazer outra iteração com um conjunto diferente de parâmetros. E, enquanto o treinamento está em andamento, você quer poder consultar as métricas. Quer verificar a utilização da GPU

4:50:56 e garantir que ela não esteja parada. Talvez você queira consultar o orçamento e garantir que não está gastando demais no seu sandbox. E, obviamente, tudo isso é muito importante para as pessoas. Mas, como os agents estão usando muito mais capacidade computacional, estamos gastando bastante tempo expondo tudo isso aos próprios agents para que possam raciocinar sobre esses dados. Certo, acho que sabemos do que precisamos. Que tal pedir à Astra para construir uma plataforma de agents para nós? Bem, não acho que seja uma boa ideia. Eu

4:51:27 não acho que você deva fazer vibe coding de uma plataforma de sandbox. E há três motivos principais para isso. O primeiro é a confiabilidade. Acho que todos sabemos, para nosso desgosto, como é difícil acertar isso. Certos sites que usamos todos os dias vivem saindo do ar. E o motivo é que, mesmo com IA, é muito difícil raciocinar sobre o ciclo de feedback, por exemplo, sobre o que acontece nesse evento extremo quando o sistema falha. Por isso, é preciso ter muito cuidado ao construir sistemas.

4:51:59 Segurança é outro motivo. Você poderia fazer vibe coding de uma plataforma de sandbox, mas quem vai fazer todo o trabalho de raciocinar continuamente sobre os limites de segurança e garantir que ela seja defensável numa época em que tudo está evoluindo muito rápido? E, por fim, escala. Temos uma publicação no blog sobre como escalamos para um milhão de sandboxes, o que envolve muito trabalho interessante de engenharia, design e raciocínio sobre sistemas. E, mais uma vez, é algo que você provavelmente não quer deixar

4:52:31 nas mãos de uma plataforma feita com vibe coding, porque, quando você chega à escala, quer que ela funcione. E, nesse ponto, estamos vendo uma escala enorme em muitas das coisas que mencionei. Por exemplo, os snapshots que mencionei estão crescendo bem rápido. Estamos vendo 20 milhões de snapshots por semana. Estamos processando cerca de oito petabytes de dados por dia para cada um desses snapshots, e nossos usuários estão criando quase 2,6 milhões de volumes por semana.

4:53:02 E tudo isso está crescendo muito rápido. Para dar um exemplo de carga de trabalho de um cliente para um assistente pessoal: é preciso criar 10.000 sandboxes por segundo. É preciso executar quase um milhão de sandboxes. E eles não vão durar muito. Vão durar só uns dois ou três minutos. Mas, quando forem iniciados, você quer que estejam interativos em menos de um segundo. É isso que essa carga de trabalho realmente exige. E a outra coisa interessante sobre escala

4:53:35 é que, na verdade, não dá para obter toda essa capacidade de escala usando uma única plataforma de nuvem. O mundo está enfrentando uma escassez de CPUs também, não só de GPUs. Então, uma coisa à qual dedicamos bastante tempo é agregar capacidade de nuvem de vários hyperscalers e neoclouds. Assim, nossos usuários têm acesso a capacidade de CPU pelo mundo todo quando precisam. Mas não podemos depender de um único provedor de nuvem para isso. Certo, para onde tudo isso está indo? Eu já dei uma pista antes, mas os

4:54:05 harnesses são muito bons em aproveitar ambientes dinâmicos. Isso está levando a uma grande separação entre os cérebros, que são o harness, e as mãos, que são o sandbox ou o ambiente de execução em que as coisas rodam. Aqui vai um exemplo do que isso significa: os harnesses poderão iniciar ambientes com base no que precisam naquele momento. Eles são bons em criar snapshots desses ambientes e mantê-los disponíveis como artefatos

4:54:37 de que precisarão mais tarde. E, mais uma vez, ajustando tudo isso conforme necessário. Acho que isso aponta para uma evolução interessante da analogia entre animais de estimação e gado, que todos conhecemos. Recapitulando: antigamente, as pessoas pensavam nos serviços como animais de estimação. Cada um era feito sob medida. Era preciso gerenciá-lo. Era preciso raciocinar especificamente sobre aquela implantação individual. E, depois, com a conteinerização

4:55:09 e o Kubernetes, as pessoas começaram a pensar neles como modelos homogêneos desses servidores. São todos iguais. Dá para aumentar ou reduzir a quantidade deles. Se um falha, não tem problema, porque nosso sistema consegue se recuperar. Acho que é assim que muitas pessoas que implantam agents trabalham hoje. Elas usam ambientes homogêneos e escalam esses agents. Mas acho isso muito limitador, porque os modelos são muito bons em raciocinar sobre ambientes dinâmicos, criar snapshots,

4:55:41 criar muitos ambientes quando necessário e trabalhar entre eles. Então, como será o novo mundo? Uma analogia é que ele parece um oceano de micróbios, com todos esses organismos que evoluem por conta própria e trabalham uns com os outros. E os créditos pela analogia vão para SPI fix. Mas uma coisa que me anima muito é que, ao oferecer aos agents essas primitivas realmente robustas de capacidade computacional, armazenamento e rede, eles poderão

4:56:13 fazer muito mais, realizando as coisas de que falei, como iniciar muitos ambientes, trabalhar uns com os outros e agir de forma bem dinâmica. Então, sim, eu e nós, da modal, realmente acreditamos que boas primitivas permitem que seus agents façam mais. E, sim, se tiver interesse em conversar mais sobre isso, entre em contato conosco. Obrigado. [aplausos]

4:56:48 Calor. Calor. Calor. Calor. N.

4:59:18 Calor. Calor. N.

5:00:05 Calor. Ei, calor. Calor. Calor.

5:01:25 O que você está fazendo? Calor. Calor.

5:02:12 Calor. Ei, calor. Ei, calor.

5:02:50 Ei, ei, ei.

5:03:31 Calor aqui em cima.

5:04:50 Calor. Calor. Calor. Calor.

5:05:44 Calor. Calor. Calor.

5:06:59 Tudo bem, pessoal. Sou Ryan. Sou CEO e um dos cofundadores da Val’s AAI. Vou falar um pouco sobre ir além do cartão do modelo e sobre como as avaliações podem ser usadas para medir essa fronteira irregular. Também vou dar atenção especial às finanças, para este público. Bem, para começar, falando dos próprios cartões de modelo: nos últimos dois anos, criamos alguns dos benchmarks mais importantes, que os principais laboratórios de modelos fundamentais incluíram nos lançamentos dos seus modelos. Acho que as pessoas conhecem artefatos como este. Na semana passada, tivemos Sundur falando no palco sobre nosso índice Valves e, ontem mesmo,

5:07:31 os modelos da Muse estavam citando nosso benchmark de agents financeiros. Sabe, nossas vidas ficam interessantes por termos que continuar atualizando esses slides à medida que novos modelos são lançados. Tive que conferir os números do nível. Dá para ter uma ideia da capacidade de um modelo para realizar trabalho valioso. Mas isso está, na verdade, gerando valor para muitas empresas. E acho que há duas estatísticas interessantes que me chamam a atenção. Os grupos que conseguem acompanhar os custos e os gastos com IA têm muito mais chances de ter um desempenho inferior. Mas também nos divertimos. O eixo X, de novo, não deixa imediatamente claro qual modelo está em primeiro lugar ou ficará consistentemente em

5:08:01 segundo ou terceiro. No eixo X, temos o custo. Em particular, o custo por tarefa, não apenas por token. No Excel, você tem o custo. Em particular, o custo por tarefa, não apenas por token. Modelos do Excel que são essenciais. Os resultados podem ser intuitivos ou contraintuitivos. Quando construímos benchmarks, uma das coisas mais importantes que precisamos observar é a métrica usada para informar a precisão. E você chega a conclusões diferentes se escolher uma métrica diferente. Muitos benchmarks dão crédito parcial. Então, o que isso responde é: em expectativa, se eu desse uma pergunta ou tarefa a um modelo, que porcentagem dos pontos eu esperaria

5:08:32 para ver se o trabalho — o resultado do trabalho daquele modelo — atende às expectativas, especialmente em comparação com humanos? E a métrica de respostas totalmente corrigidas analisa mais a porcentagem de perguntas que faço aos modelos e que porcentagem delas volta perfeita. E essa é uma métrica bem diferente. Isso pode significar que um modelo é muito bom em produzir uma resposta incremental com a qual você pode trabalhar para construir uma resposta melhor. Mas, se você passasse isso diretamente a um cliente, seria uma aposta de cara ou coroa saber se ela atenderia a todos os critérios que você definiu. E então

5:09:02 escolher a métrica certa é muito importante para representar com precisão o desempenho de um modelo e, de fato, formar uma boa intuição do que ele pode fazer. Há outros três componentes em que pensamos bastante. Primeiro, validade. Você está realmente avaliando o que acontece no mundo real? Isso significa: as perguntas ou tarefas refletem o trabalho real ou são artificiais? E as rubricas realmente descrevem o que procuramos ou o padrão de excelência que queremos ver? Confiabilidade. Geralmente, ela depende do número de tarefas ou do tamanho da amostra. Muitas empresas têm talvez cinco ou seis amostras e vão experimentando novos modelos ou produtos conforme têm acesso a eles. Mas é muito importante ter uma abordagem rigorosa e tarefas e amostras suficientes para garantir que as execuções repetidas realmente apresentem resultados consistentes. E, por último, capacidade de discriminação. Não achamos tão valioso ter benchmarks em que todos os modelos pontuam 100% ou todos pontuam 0%. O ideal é conseguir diferenciar os modelos e ver como está a fronteira de desempenho. Em particular, também queremos garantir que estamos criando benchmarks voltados para o futuro. Então, quais são as novas tarefas, ainda mais ambiciosas do que aquilo que os modelos conseguem fazer hoje, para garantir

5:09:33 que haja espaço na fronteira para continuarmos observando o progresso dos modelos conforme eles melhoram. Certo. Então, alguns dos problemas gerais que vimos, e que acho que outras pessoas também enfrentam ou podem enfrentar. O primeiro é que os agents resolvem o teste, não o problema. Isso costuma ser chamado de exploração da função de recompensa. Vimos muitos casos em que temos um ambiente isolado e os modelos são executados com nosso proxy de modelo; às vezes, eles podem tentar chamar outros modelos por meio desse proxy para escapar do ambiente isolado

5:10:04 ou usar a internet. Por isso, é muito importante construir os contêineres de modo que você esteja realmente testando o que importa. Eles conseguem realizar a tarefa em questão ou estão recorrendo a outras ferramentas, ou talvez até a outros modelos, para chegar lá? Também vimos esse problema especialmente em finanças, onde muitas vezes os evals analisam um conjunto de rubricas ou itens que queremos ver incluídos na resposta. Assim, os modelos podem se esquivar e dar três respostas possíveis, o que aumenta a chance de satisfazer todos os critérios, mas, na prática, isso é demais. Uma pessoa não quer

5:10:34 considerar três respostas diferentes. Ela só quer receber a primeira resposta e que ela esteja certa. Então, o objetivo aqui é tentar criar evals que reflitam o trabalho que as pessoas realmente fazem e o resultado que querem ver. Não criar esses evals artificiais que os modelos conseguem trapacear. O segundo problema é que acho que muitas pessoas estão começando a perceber que o custo do software está caindo e que é muito fácil produzir código, mas, infelizmente, ainda vemos na prática que executar evals é incrivelmente desafiador, especialmente do ponto de vista da infraestrutura. E

5:11:05 em particular, à medida que chegamos a agents de execução mais longa, é muito importante ter uma infraestrutura que permaneça consistente por bastante tempo e que, se houver uma interrupção, possa ser retomada e iniciada novamente. Acho que acabamos de ultrapassar seis trilhões de tokens apenas em avaliações. Então, executamos uma quantidade considerável de evals e fazemos tudo com o maior paralelismo possível. Acho que isso foi realmente submetido a testes de carga, mas outras pessoas vão se deparar com isso mesmo em uma escala muito menor. E o último problema é que muitos dos benchmarks existentes lidam

5:11:37 com um único prompt e uma única resposta, mas, na prática, tudo acontece em múltiplas rodadas. Você tem uma especificação inicial que acha que cobre tudo, mas depois recebe perguntas ou feedback adicional quando algo é construído, e então é preciso iterar mais para chegar ao resultado final. Então, acho que benchmarks e evals são componentes que não vão desaparecer. Para analisar um estudo de caso específico, quando avaliamos nossa equipe, fizemos um pequeno experimento de maximização de tokens: conseguimos acesso gratuito a algumas ferramentas e simplesmente as disponibilizamos a todos os engenheiros. E eles realmente aproveitaram esses

5:12:08 tokens ilimitados. Se olharmos para aquele mês, gastamos o equivalente a US$ 1,5 milhão em tokens. Era uma equipe de, acho, 10 ou 12 pessoas. Portanto, gastamos aproximadamente dez vezes mais com tokens do que com salários naquele mês. Isso foi bastante insano. Mas vimos ótimos resultados. Nosso objetivo era manter o mesmo nível de produção entre todos esses engenheiros, mas reduzir drasticamente os custos. E a nossa solução para isso foi, naturalmente, criar um eval. Construímos várias ferramentas internamente e agora disponibilizamos isso como um produto chamado bell smith. Então, isso é

5:12:40 o que estamos fazendo na programação e acho que é mais um sinal do que está por vir em outras áreas do trabalho intelectual. O que conseguimos fazer foi analisar o repo do GitHub como uma forma centralizada de ver que trabalho já foi feito e que trabalho continua acontecendo. Em particular, os repos do GitHub são compostos por PRs, ou pull requests, que têm uma issue do GitHub e uma resolução. Então, podemos voltar no tempo e dar essas mesmas tarefas a agents para ver se eles teriam conseguido realizar o trabalho de forma equivalente aos humanos. Ao fazer isso, obtivemos uma compreensão muito mais clara de quais modelos eram exagerados, caros demais e desnecessários, e de quais realmente eram capazes de concluir a tarefa.

5:13:12 E acho que, mais uma vez, este é outro caso em que as intuições de muitas pessoas talvez não correspondam ao que realmente acontece na prática. Você pode pensar: “Estamos usando muitos modelos fechados. Deveríamos tentar reduzir os custos e usar nosso próprio modelo open source hospedado por nós.” Aqui dá para ver a comparação entre GBT 5.6 Soul e Kimi K3. Vemos que o 5.6 Soul é melhor. Ele está 2% à frente neste eval interno. Também é consideravelmente mais barato do que hospedá-lo usando uma pilha de inference muito otimizada. Custa US$ 250 em vez de US$ 11. E é mais rápido na metade das vezes. Portanto, não há uma razão real para pensar que essa intuição de usar open source seria uma forma válida de reduzir custos. E isso resultou em duas diferenças principais. Primeiro, podemos descobrir quais ferramentas vamos adquirir e quais devem ser os limites de uso delas em toda a organização. Mas também podemos fazer recomendações aos engenheiros e dizer: achamos que, para esta issue do GitHub, você deveria usar esta ferramenta de programação específica com este modelo, e isso

5:13:43 é

5:14:14 pilha otimizada. Então, custa 250 em vez de US$ 11. E é duas vezes mais rápido. Portanto, não há motivo real para que essa intuição de usar open source não seja uma forma legítima de reduzir custos. Isso resultou em duas diferenças principais. Primeiro, podemos descobrir quais ferramentas vamos adquirir e quais devem ser os limites de uso delas em toda a organização. Além disso, podemos dar recomendações aos engenheiros e dizer: achamos que, para esta issue do GitHub, você deveria usar esta ferramenta específica de programação com este modelo, e esta é

5:14:45 conseguir reduzir consideravelmente o custo. Acho que estamos gastando 90% menos, mas ainda conseguimos obter o mesmo resultado. Acho que a pergunta que eu faria a todos vocês é: estamos continuando a expandir essa abordagem e levar esse modelo de programação para outros domínios, como trabalho intelectual, direito, finanças e coisas assim. Mas a questão principal é: onde vocês estão acompanhando o histórico do trabalho que já foi feito por essa empresa? Alguns desses escritórios de advocacia existem há uns cem anos. Então, onde fica armazenada essa qualidade da organização? Como vocês acompanham o padrão de excelência? E

5:15:16 hoje isso pode existir em lugares como e-mails, no histórico das respostas que as pessoas deram aos clientes, em SharePoints, ou em despejos de dados do Databricks. Mas acho que esse é o grande tesouro que muitas empresas têm e não percebem que será o principal impulso para os evals e, depois, para a adoção da IA de maneira mais sistemática. Quando esses evals são construídos, eles podem viabilizar a adoção. Mas também vimos que há maneiras mais vantajosas

5:15:47 de usá-los. A primeira é dimensionar adequadamente. Em vez de simplesmente maximizar tokens, como descobrir qual deve ser o limite de uso adequado para a organização toda? Negociação. Quando você percebe que tem poder de barganha de verdade, pode levar isso para a conversa sobre preços por volume. Depois, o roteamento. Isso está se tornando um elemento fundamental em muitos produtos de IA, mas também pode ser feito diretamente pelos usuários. Assim, eles podem criar roteadores inteligentes que realmente descubram qual é o modelo certo para usar. E, depois, fine-tuning ou pós-treinamento. Ah,

5:16:18 isso pode ser a maneira mais confiável de criar as tarefas e, então, ter um conjunto externo de evals para garantir que essa abordagem está funcionando. A última reflexão que deixo é que acho que muitas empresas têm uma vantagem competitiva que existe na cabeça dos funcionários, por meio de coisas como conhecimento institucional. E o que os evals permitem fazer é, na verdade, codificar essa vantagem competitiva e registrá-la em palavras ou em scripts, em linguagem. E isso será o maior impulso para garantir que uma empresa tenha sucesso na era dos agents.

5:16:49 Certo, é só isso. Obrigado a todos. [aplausos]

5:17:35 Heat. Ei, Heat. Heat, aqui em cima.

5:18:30 Heat. Heat.

5:19:19 Heat. Ei, Heat. Heat. Heat.

5:19:50 Heat. Heat.

5:20:49 Ei, ei, ei.

5:21:58 Heat. Heat.

5:23:30 Heat. Heat. Heat. Heat. N.

5:24:02 Heat. Heat. Heat. Ei. Ei. Ei.

5:24:55 Heat. Heat.

5:27:22 Heat. Heat.

5:28:55 Oi, pessoal, tudo bem? Obrigado a todos por estarem aqui. Meu nome é Venu. Sou o CEO da Kepler. Estou animado por estar aqui com Jack Woodruff. Quer se apresentar rapidinho? >> Sim. Oi, sou Jack Woodruff. Sou o fundador e ex-CIO da Candlestick Capital Management, um fundo de hedge de ações long-short com sede em Greenwich, Connecticut. Antes de fundar a Candlestick, fui sócio e gestor de portfólio na Surveyor Capital, uma divisão da Citadel.

5:29:26 Muito legal. Obrigado, Jack. Então, o motivo de estarmos fazendo isso assim é que já tivemos essa conversa antes, e acho que Jack é uma das pessoas mais esclarecedoras para conversar, dado que passou a carreira escolhendo ações em um ambiente que está mudando mais do que nunca. Então, vamos tratar isso como uma conversa informal. Jack, trace um panorama para nós. Como será o investimento fundamentalista na era da IA, digamos, daqui a cinco anos? Bem, é difícil dizer. Não acredito que a seleção de ações no longo prazo

5:29:59 vá mudar muito. Sempre houve uma combinação de informações e sempre houve geração de alfa ao encontrar uma visão divergente. Então, isso não vai mudar. Acho que continuará igual. Agora, a maneira como as pessoas sintetizam todas as informações e o nível mínimo esperado — em termos do que todos têm — e, depois, como sintetizam esses dados, isso vai mudar completamente. Os cargos tradicionais, como os de gestor de portfólio

5:30:31 ou analista, vão virar de cabeça para baixo, e ainda acho que é cedo demais para dizer como tudo isso vai ser, porque essas ferramentas são muito novas, especialmente para os usuários. Tem muita gente fazendo algumas coisas, mas não está claro para mim que já chegamos lá e que, meu Deus, essas serão as novidades. Temos várias outras coisas para conversar, mas acho que vai ser fascinante

5:31:02 acompanhar como tudo se desenrola. >> Muito legal. >> Na Citadel, você tinha 18 pessoas cobrindo 400 ações e, na Candlestick, tinha 30 selecionadores de ações. Um analista excepcional poderia cobrir as 400 até 2030? >> Então, o maior problema é que os humanos ainda são o gargalo. Quer dizer, no fim das contas, você precisa assimilar as informações. Então, tudo se resume a como humanos e máquinas podem trabalhar

5:31:33 juntos. Gestão de investimentos é um exercício de gestão do tempo. O que quero dizer com isso é que, se eu passasse todo o meu tempo trabalhando em uma ação, seria ótimo. Provavelmente a conheceria melhor do que qualquer outra pessoa no mundo. Mas, se não houvesse nada para fazer com essa ação, eu ficaria meio que sem ter muito o que fazer. Se eu acompanhasse duas, teria metade do tempo para cada uma, e assim por diante. Então, começam a surgir retornos decrescentes

5:32:04 em relação ao tempo que você pode dedicar a qualquer ação específica. Então, o que a IA pode fazer? A IA pode me ajudar a cobrir mais empresas? Talvez. Talvez me permita elevar o nível mínimo do conhecimento geral que tenho, porque antes esse trabalho levava horas de preparação para eu ficar pronto. Agora, talvez um programa de IA possa me ajudar a preparar boa parte desse trabalho em cinco minutos, quando

5:32:35 antes isso levava de seis a oito horas. Isso me permite fazer outras coisas. De novo, é um setor muito competitivo. Não é como se, ao dispensar todas essas pessoas ou passar a ter cinco analistas em vez de 30, essas pessoas pudessem simplesmente fazer mais. Isso libera tempo, que eu poderia usar para fazer mais pesquisas proprietárias, verificações de informações com fontes do setor ou mais trabalho sobre o panorama da indústria, porque, mais uma vez, você vai precisar

5:33:06 encontrar essas visões divergentes. Então, se eu fizer exatamente a mesma coisa que fazia antes e pensar: “Nossa, consigo terminar meu trabalho em duas horas”, outra pessoa ainda vai trabalhar 16 horas por dia tentando encontrar aquele detalhe a mais que vai lhe dar lucro. Porque fazer esse tipo de trabalho é, obviamente, o que costumávamos pagar a um analista para fazer há um ou dois anos, mas não é o que

5:33:36 vamos pagar a um analista para fazer daqui a um ano. >> Muito legal. E, nesse sentido, o que um analista júnior faz hoje que você acha que seria absurdo ele ainda estar fazendo daqui a cinco anos? >> Bem, é engraçado, porque as pessoas dizem: “Ah, vocês não vão mais ler relatórios 10-K. Não vão mais ler transcrições.” Na verdade, não acredito que isso seja verdade. Se você realmente acompanha uma empresa de perto, ainda vai precisar processar muitas dessas informações. Agora, talvez consiga versões resumidas

5:34:08 que reduzam o tempo necessário para fazer essas coisas, mas você ainda precisa assimilar essas informações. Antes, tínhamos muitos analistas que analisavam grandes volumes de dados e coisas assim. Definitivamente acho que esse trabalho pode ser terceirizado e que será muito fácil. Eu ficaria surpreso se muitos desses profissionais não estivessem fazendo isso. Mas o que acredito que a IA, o agent ou seja lá o que for vai fazer

5:34:39 estar [suspira] levando você na direção certa para trabalhar nos nomes certos. Como eu disse, isso é gestão do tempo. Tudo se resume a: como sei que estou trabalhando nas coisas certas? E é aí que os vencedores vão estar: nas pessoas que conseguem descobrir como usar essas ferramentas para fazer você passar a quantidade certa de tempo trabalhando, quem sabe, para encontrar uma visão divergente. >> Muito legal. E sobre

5:35:25 Heat. Ei, Heat. Heat. Heat.

5:35:55 Heat. Heat.

5:36:55 Certo. Olá a todos. Sejam bem-vindos. Meu nome é David. Lidero as operações de IA em uma empresa chamada Revolute. Temos 50 minutos juntos hoje. Vamos falar sobre engenharia de alto desempenho e sobre hospedar um modelo open source em uma GPU dedicada. O que acham? >> Legal. Então, vai ser uma apresentação técnica, então tenham paciência comigo. Talvez, para começar, já que sei que

5:37:25 estamos nos EUA e talvez vocês não conheçam a Revolute. Algumas palavras rápidas sobre nossa empresa. Somos um banco digital na Europa. Temos 80 milhões de clientes. Estamos presentes em 45 mercados e, no último ano, tivemos o app financeiro mais baixado da Europa. E, em julho, nos tornamos a maior empresa privada da Europa. Então, estamos indo bem. A ênfase da Revolute é, sabe, lançar muitos produtos. E, por isso,

5:37:56 há um grande foco na cultura de engenharia e na excelência nesse domínio. E é sobre isso que vamos falar. Então, vamos falar de IA. Temos um gráfico aqui. Vocês vão ver duas linhas. Esta é uma amostra do desempenho de 2.000 engenheiros ao longo do último ano. A linha verde representa o lead time: o período desde que um engenheiro começa a trabalhar em um recurso até que ele seja integrado e esteja pronto para deploy. A

5:38:28 linha azul representa o tempo de programação. A linha verde está em dias. A azul, em horas. Só para relembrar a cronologia, caso alguém tenha esquecido, porque a IA avança muito rápido: Claude Code foi lançado por volta de fevereiro de 2025, certo? E era o Claude Code 3.7, aquele que apagaria seu banco de dados de produção, certo? Não era o Claude Cloud e o Codex seguros que temos hoje. Então, tenham isso em mente quando falarmos de adoção. O que vocês veem neste gráfico é

5:38:58 janeiro de 2025, quando a IA foi introduzida pela primeira vez na empresa, certo? O Gemini foi a primeira ferramenta que permitiu às pessoas usar dados privados com IA. Por volta de fevereiro, começamos a experimentar o Claude Code, e então, em janeiro, lançamos o Claude Code em larga escala pela primeira vez. O que vocês veem é que o Gemini trouxe uma melhoria de 10% no lead time e de 20% no tempo de programação. Isso significa que as pessoas não precisam mais abrir o Stack Overflow e ler a documentação. Mas o Claude Code não teve tanto impacto

5:39:30 na época. Quando o lançamos, éramos muito céticos quanto ao custo da IA. Víamos engenheiros gastando mil por mês, 10 mil por mês, sem muito retorno sobre o investimento. Então, quando o lançamos, fizemos isso com limites rígidos de orçamento. E, por isso, estamos pensando no próximo passo: como oferecer tokens ilimitados aos engenheiros para que possam usar IA sem culpa por uma fração do custo? Então, analisamos modelos open source. Por volta de abril de 2026, começamos

5:40:01 a hospedar modelos open source. Somos grandes fãs do GLM para programação. Por volta dessa época, em abril de 2026, com o GLM-5.1, vemos uma melhoria de 60% no tempo de programação e de 70% no lead time. Um impacto enorme. O que aprendemos com isso? Bem, o impacto no lead time é maior do que no tempo de programação. Então, descobrimos que o gargalo da engenharia não é necessariamente programar. Dá para economizar muito tempo sem precisar

5:40:31 vasculhar sua caixa de entrada ou mexer com J e conferências. Com tokens ilimitados, você pode fazer isso à vontade. Não precisa mais guardar seus tokens para o fim do trimestre ou para as tarefas mais difíceis. Então, onde estamos agora? Bem, open source agora é uma prioridade na Revolute. A nova economia é favorável. A cobrança é fixa. Não temos nenhum choque na conta no fim do mês. E os modelos de ponta são a exceção. Obviamente, continuamos usando o Codex. Os modelos mais recentes são

5:41:03 fantásticos. O Gemini e o Claude também estão indo muito bem, mas continuamos usando-os como exceção. Então, como chegamos a esse ponto? Algumas métricas importantes para quem hospeda modelos por conta própria: para atender 200 engenheiros, precisamos de aproximadamente 56 B200, para hospedar o GLM-5.3. O GLM é um modelo grande, em termos de parâmetros. O que você deve buscar é um tempo até o primeiro token inferior a 3 segundos.

5:41:35 Isso é uma evidência empírica. Assim que você passa de 5 segundos, minha caixa do Slack começa a explodir. E sabemos que esse é o limite. Em termos de throughput, isso não importa tanto, certo? Para interatividade, servimos 200 tokens por segundo. As pessoas aceitam velocidades maiores. A forma como as pessoas trabalham mudou. Não ficamos mais olhando para um fluxo de tokens de raciocínio. As pessoas executam tarefas em paralelo e verificam quando elas terminam. Mas, se você quiser ter um throughput alto

5:42:05 e for engenheiro na Revolute, basta se conectar depois das 17h, quando há um na GPU, e você pode chegar a 800 TPS; aí, sabe, é um sonho. Quanto ao custo e ao impacto, o custo médio dos tokens ao hospedar o GLM por conta própria é de 30 centavos por milhão. Então, nossa fatura é um décimo do que gastávamos com Anthropic e OpenAI. Há muitos ajustes envolvidos na execução de modelos open source.

5:42:38 Se você simplesmente conseguir GPUs, carregar os pesos nelas e começar a fazer inference, vai ter um desempenho péssimo. Isso acontece porque a sua carga de trabalho vai depender muito dos parâmetros que você definir. Se olharmos para a extremidade esquerda desse gráfico, a linha azul representa a demanda. Ou seja, as solicitações por segundo. Esse será o fator limitante da latência das suas GPUs. E a linha vermelha representa aquilo que estamos tentando otimizar: o tempo até o primeiro token.

5:43:09 Então, quando começamos, em abril, havia cerca de três solicitações por segundo, o que é bastante, mas não tanto, e o tempo até o primeiro token era superior a 10 segundos, o que é muito lento. Mas os dados que vocês estão vendo são com o mesmo número de GPUs. Não aumentamos a quantidade de GPUs. Continuamos com 56. E, no fim, em agosto, vocês veem que as solicitações por segundo passam de sete e o tempo até o primeiro token fica em torno de 1,6 segundo. Portanto, tivemos uma melhoria de 88% no desempenho, com um aumento de 76% na

5:43:41 demanda. A lição que tiramos disso é que há muitos parâmetros que você pode melhorar e que realmente precisa resistir à tentação de escalar se quiser hospedar um modelo por conta própria. Então, vamos falar dos parâmetros. Não há uma receita secreta, mas estas são algumas coisas que você pode considerar. Primeiro: contextos longos são uma farsa. Você realmente precisa ter em mente que, embora possa servir 1 milhão de tokens, 256 mil é o que você realmente precisa.

5:44:13 Quantização. Se estiver executando geração Blackwell em GPU, não deve usar nada acima de FP4; NVFP4 é o melhor. Passar de FP4 para FP8 representa uma economia de 40% no uso de GPU, sem perda de precisão. Outros parâmetros a considerar: paralelismo de tensores. Embora o GLM caiba em TP4, você não terá cache KV suficiente, então talvez TP8 funcione melhor, dependendo do tamanho da sua carga de trabalho.

5:44:43 E, depois, algumas coisas mais esotéricas: confira se o cache do seu teste de programação está acima de 90% e você pode analisar decodificação especulativa otimizada, prefill sequencial, PDAG e tudo isso. Legal. Então, agora vamos falar da configuração de produção. O GLM é obviamente um modelo apenas de texto, o que é uma limitação para algumas pessoas. Eu diria que a troca que sempre faríamos é obter o modelo mais inteligente

5:45:14 e descobrir outra maneira de fazer reconhecimento de imagem. Você pode facilmente ter um roteador local. O Open Codex é uma opção que encaminharia qualquer tarefa de reconhecimento de imagem para Gemini ou Luna e manteria o GLM para a tarefa principal. Se você realmente precisar de algum modelo de visão, o GLM FG Flash funciona muito bem. Nosso designer de UI está aproveitando muito bem o modelo. O tempo de execução de produtos de UI melhorou muito, muito

5:45:44 um longo caminho, e o último vai ser sobre o harness. Então, todos esses endpoints vão ser APIs compatíveis com a API da OpenAI, com a Responses API, e você pode usá-los também dentro do app Codex, e funciona muito bem. Então, é isso que recomendamos. E, por último, uma mensagem para o CIO que está na sala: há um

5:46:16 grande estigma em usar modelos open source chineses. O ponto a considerar é que você não está usando o endpoint dedicado de inference que vai para a China. Você está apenas obtendo os pesos e colocando-os em um serviço baseado nos EUA. Então, do ponto de vista do compartilhamento de dados, isso é totalmente aceitável. No caso da Revolut, em particular, por sermos um banco regulamentado pela UE, estamos sujeitos ao regime mais rigoroso em termos de conformidade. E o que descobrimos que

5:46:47 funciona é que nenhuma dessas tarefas de programação é considerada um agent autônomo. Elas sempre contam com um humano no loop. Então, como garantir que há um humano no loop? Você começa criando um sandbox que garante isso. E o sandbox significa que, se você já usou o Codex, ele tem todos esses recursos de aprovação. Você só precisa definir as regras para as operações que não quer permitir. Por exemplo, você pode permitir grep, mas não Gradle. E isso vai dar

5:47:18 confiança ao seu órgão regulador de que este não é um agent autônomo que exige supervisão diferente. O sandbox também protege contra usos indevidos, certo? Pode haver um agente mal-intencionado dentro da sua empresa, e você quer se proteger disso. Você ficaria surpreso com o que se encontra em uma grande empresa. E o último ponto é prompt injection. Não é tanto um problema agora, dado o nível de inteligência dos modelos, mas a privacidade dos dados sempre é uma questão. Já falamos disso. Portanto, desde que os dados permaneçam em um dos

5:47:50 países que fazem parte do acordo de equivalência de dados — EUA, UE, Reino Unido e Israel —, está tudo bem. Você pode ter suas GPUs lá. Todos os seus provedores de inference ou de GPU terão retenção zero de dados por padrão. E a última coisa de que você precisa é de uma implementação muito robusta de OpenTelemetry, para que, se houver algum incidente, você consiga investigar a fundo e consultar os logs. Isso também fornece algumas análises.

5:48:24 Certo, obrigado a todos. Essa foi a minha palestra. [aplausos] Calor. Calor.

5:49:49 Calor. Calor.

5:50:39 Calor. Calor. Calor. Calor.

5:51:27 Calor. Calor. Calor. Calor.

5:52:21 Calor. Calor.

5:53:14 Calor. Calor. Calor. Calor.

5:54:07 Calor. Calor.

5:54:59 Calor. Calor. Calor.

5:55:45 Calor. Calor aqui em cima.

5:57:54 Calor. Calor.

5:58:57 Calor. Calor. Calor. Calor. N.

5:59:41 Calor. Calor. N.

6:00:30 Calor. Calor. Calor. Calor.

6:02:01 >> [limpa a garganta] >> Boa tarde a todos os presentes. É um grande dia e é um enorme prazer estar aqui. O tema da minha palestra hoje é: todos têm IA; quem leva vantagem? Vou falar sobre o que as organizações que lideram em IA estão fazendo de diferente na implementação e adoção,

6:02:31 delas. E, antes disso, quem sou eu e qual é o meu ponto de vista? Sou o Dr. Sid Pedicker. Sou executivo de tecnologia de IA e dados no setor de gestão de ativos. Passei a maior parte da minha carreira em hedge funds, investimentos e pesquisa acadêmica. O meu foco tem sido liderar estratégias e construir

6:03:02 equipes especializadas em três áreas principais: otimizar a eficiência, impulsionar o P&L e reduzir custos. Vou acompanhar a discussão junto com duas empresas hipotéticas, a empresa A e a empresa B, que aparecem no controle deslizante abaixo. São hipotéticas, com workflows inventados, mas vamos acompanhar a jornada delas ao longo do restante desta

6:03:34 apresentação. Então, todos têm IA. Quem leva vantagem? Antes de começarmos, vamos primeiro ver como está o cenário. Estudos recentes mostram que apenas cerca de 37% das empresas pesquisadas apresentam uma contribuição positiva para o EBIT, e apenas cerca de 6% delas seriam classificadas como

6:04:04 de alto desempenho. Isso representa uma contribuição de cerca de 5% para o EBIT. Outros estudos, realizados no início do ano, mostraram que cerca de 66% afirmam ter aumentado a produtividade, mas apenas cerca de 40% e 20% estão de fato observando reduções de custos e crescimento da receita. Como sabemos, o acesso à IA é generalizado, mas seu impacto continua desigual. Então,

6:04:35 [tosse e limpa a garganta] a pergunta que eu faria, ou a forma como eu pensaria nisso, passa por três áreas. Acho que a maneira como penso nessas três áreas deve se aplicar tanto a organizações quanto a indivíduos, e também às diferentes funções, independentemente de onde você esteja na organização. Os três pilares principais que considero são

6:05:06 primeiro, definir o problema certo; segundo, construir capacidades compartilhadas; e terceiro, fazer a vantagem se acumular. Antes de nos aprofundarmos em cada um desses pilares, há uma ideia que, na minha opinião, atravessa todas essas áreas e da qual as melhores empresas líderes estão tirando proveito e capitalizando. Como sabemos, ao longo do tempo, a única constante neste mundo tem sido a mudança.

6:05:38 O que é diferente na era da IA e da superinteligência é que a inteligência ficou barata. Independentemente de qual seja a sua unidade de inteligência — software, análise, recomendações ou relatórios —, a IA está criando abundância em tudo isso. E, como sabemos, mais respostas não necessariamente geram mais valor. Então, o que é escasso? Qual é o recurso escasso em um mundo de abundância?

6:06:11 Do que as empresas estão tirando proveito? Pelo menos as líderes estão tirando proveito do julgamento. O que é julgamento? É escolher o que importa e como agir quando não existe uma única resposta óbvia. É a criatividade que permite explorar quais possibilidades valem a pena ser exploradas. É o discernimento que mostra como é algo bom no contexto em que você está. São as decisões em que você pode avaliar quais compensações valem a pena

6:06:41 fazer. O julgamento está em toda parte. Ele existe diariamente em toda a sua organização. A sua equipe executiva faz perguntas e recorre ao julgamento o tempo todo. O mesmo acontece com os engenheiros de software, os líderes de IA, os gestores de portfólio e os cientistas de dados. Então, a questão em que eles estão focados é: dado que o julgamento é um recurso finito, uma

6:07:12 capacidade limitada, a pergunta principal passa a ser: onde vale mais a pena aplicar nosso melhor julgamento? Guardem essa ideia. Com isso, vamos ao nosso primeiro pilar: definir o problema certo. Uma pergunta que as organizações líderes fazem o tempo todo é: elas são obcecadas em descobrir qual é o problema certo a resolver. Certo? É tentador começar pela ferramenta. Hoje estamos cercados por

6:07:43 modelos melhores e harnesses. Estamos cercados por todas essas ferramentas de IA. Estamos cercados por copilotos, mas não é assim que se deve abordar a questão, não é? Pelo menos não é assim que as empresas líderes estão fazendo. Agora, vamos voltar às nossas duas empresas hipotéticas. Digamos que sejam do setor de gestão de ativos. Digamos que estejamos acompanhando o workflow de dois analistas de pesquisa nessas organizações hipotéticas. Bem, digamos que a organização B comece pela ferramenta, o copiloto. Ela

6:08:15 pergunta onde pode adicionar IA ao trabalho do analista. Ela analisa o processo atual e diz: chegou a transcrição de resultados financeiros; identifiquei um workflow de resumo. Vou passar tudo isso pela minha mangueira de dados. Os analistas recebem os resumos de resultados mais rápido. Todo mundo ganha, certo? Bem, não exatamente. Pelo menos, não em comparação com quem está na liderança. E um workflow assim, de simplesmente seguir mais rápido, introduz uma nuance importante:

6:08:46 você perde contexto à medida que reduz as informações como parte do resumo. Então, o que uma organização A hipotética está fazendo nesse caso? Ela está obcecada em formular o problema certo. Poderia perguntar: por que os sinais relevantes estão chegando até nós tarde demais? Onde devemos concentrar a atenção, a IA, a largura de banda e a capacidade? Onde está o nosso gargalo, certo? E, assim, a questão passa a ser redesenhar o workflow

6:09:18 ou, pelo menos, reavaliar em que devemos nos concentrar. É isso que fazem de diferente. Agora, [limpa a garganta] essa consideração não é específica do setor financeiro. Ela se aplica a todos os setores e funções. Você faz a mesma pergunta sobre onde se concentrar, seja na capacidade de pesquisa, na velocidade das decisões, na qualidade dos dados, na latência ou na confiabilidade. Isso abrange tudo. E os estudos mostram isso. Estudos de referência mostraram que as empresas líderes, em média, concentram sua atenção em

6:09:52 menos decisões, mas de maior qualidade, do que a outra coorte. Então, os líderes estão sendo mais seletivos quanto a onde concentram sua atenção e no que concentram sua atenção. É ótimo que as empresas líderes tenham uma ideia de quais são os problemas certos. De onde elas partem? Bem, elas também concentram seus investimentos nos workflows de maior valor. Entendo, e já fui culpado de algo parecido, em que

6:10:23 a IA está quase criando oportunidades demais. Experimentar pode ser bom, mas é preciso separar experimentação e o teatro da inovação que resulta dela — ou, pior, o teatro da produtividade, que gera valor de verdade. Voltando às nossas duas empresas hipotéticas, o que isso significa? A empresa B está pensando em como lançar o maior número possível de projetos-piloto de IA. E isso acaba resultando em um documento

6:10:53 com um bot de resumo aqui, um copiloto ali, um bot de recuperação de dados acolá. Está tudo espalhado. Já a empresa A concentra seus investimentos potencialmente em casos de uso como workflows de ponta a ponta no pipeline de pesquisa. Ela está focada em alinhar engenharia, análise, IA, capacidade e discernimento em torno de um único foco. E pesquisas

6:11:24 mostram que os líderes destinam mais de 80% dos seus investimentos a esses casos de uso de alto valor, transformando funções empresariais essenciais e criando novas ofertas. Perfeito. Sabemos que eles estão se concentrando em encontrar o problema certo e também estão investindo profundamente em workflows selecionados. Bem, eles também estão fazendo algo diferente. Estão repensando como o trabalho é feito.

6:11:57 Acho que isso é essencial e remete ao que discutimos antes: discernimento. Eles estão redefinindo e reorganizando funções, cargos e capacidades em torno desse elemento essencial do discernimento. O que isso significa para nossa empresa hipotética? Bem, a empresa B talvez esteja focada, como discutimos, em receber a transcrição dos meus resultados financeiros, receber meus relatórios de pesquisa e pensar: como faço para resumir isso? Talvez eu consiga fazer isso mais rápido. Talvez eu atualize meus modelos financeiros mais rápido.

6:12:27 Talvez eu envie minha recomendação ao meu PM mais rápido. A empresa A está focada em algo completamente diferente. Hipoteticamente, ela poderia pedir ao analista que definisse a tese de investimento, enquanto acompanha e reúne evidências que poderiam refutar ou sustentar essa tese. Monitoraria tudo continuamente. Investigaria exceções e poderia analisar a fundo, sabe, exemplos selecionados

6:12:58 que poderiam levar à geração de valor de verdade. Portanto, os vencedores não apenas automatizam: eles reformulam. Estudos mostram que a coorte de alto desempenho tem 75% mais probabilidade — ou, na prática, de fato reformula seu workflow — do que a coorte que não tem alto desempenho, em que isso ocorre com 25%. Então, o que isso significa para nossas duas empresas hipotéticas e para a definição do problema certo? A empresa B adiciona IA aos workflows existentes. Ela conclui

6:13:30 projetos individuais e passa para a próxima iniciativa. Já a empresa A está repensando como o trabalho é feito. Ela está reformulando processos em torno da IA e se dedicando intensamente a encontrar o problema certo. Essa é a diferença na forma como as organizações colocam a IA em prática. Ótimo. Então, escolheram o problema certo. O que acontece agora? Bem, todos sabemos que, para realmente viabilizar essa capacidade, é preciso desenvolver capacidades compartilhadas em toda a organização.

6:14:00 E uma tendência que parece estar surgindo já há algum tempo é a convergência entre tecnologia e negócios. Estamos vendo isso em toda parte. Estamos vendo engenheiros se aproximando dos resultados de negócio. Estamos vendo profissionais de negócios desenvolvendo ferramentas e automações. E, como vocês podem ver e imaginar, é possível ter engenheiros alocados diretamente junto às equipes, gerentes de produto alocados diretamente junto às equipes, mas também o inverso: gerentes de portfólio alocados diretamente junto às equipes. E é realmente essa

6:14:33 combinação — reunir as pessoas certas, rompendo os silos organizacionais — que os líderes estão usando como apoio. Estudos mostram que cada vez mais grandes empresas veem sua área de tecnologia como uma função de crescimento dos negócios. E isso está criando uma vantagem para essas empresas. Então, outro eixo dentro do desenvolvimento de capacidades compartilhadas, que

6:15:04 provavelmente é um dos meus favoritos, é padronizar o núcleo e personalizar as bordas. Isso não é algo novo no mundo da tecnologia. Já desenvolvemos infraestrutura, módulos compartilhados e arquitetura de sistemas. Mas o interessante hoje é que isso está assumindo uma forma bem diferente, dadas as capacidades disponíveis e a organização, com a quebra dos silos. Isso pode ser bem diferente dependendo de onde você trabalha. Você pode desenvolver núcleos compartilhados para uma equipe que

6:15:37 seja muito diferente, com analistas e clientes. Pode fazer isso com um grupo de analistas, ou para engenheiros de software ou cientistas de dados. No caso específico dos cientistas de dados, isso pode ser muito interessante: em vez de workflows isolados, algo bastante comum no setor, você pode criar um núcleo compartilhado com os conjuntos de dados, suas camadas semânticas, os trade-offs, o que funcionou, o que não funcionou, o que alguns conjuntos de dados fazem bem, onde estão as lacunas e assim por diante.

6:16:09 Assim, cada novo profissional se torna quase um módulo plug-and-play nesse sistema, podendo se apoiar no trabalho de quem veio antes. O que a próxima pessoa não deveria ter que reconstruir? Agora, outra coisa interessante é que a empresa não foi realmente criada para agents. Os agents trabalham em vários workflows e aplicações. Eles recebem contexto, deliberam e executam ações. Já as empresas, antes, eram realmente voltadas a um único ser humano ou a um grupo deles interagindo com uma única aplicação.

6:16:41 Portanto, os líderes sabem que algo precisa mudar e que precisam modernizar sua infraestrutura, e têm bastante consciência de em que ponto dessa jornada estão. Estudos mostram que 75, 71% das organizações estão modernizando sua infraestrutura central para oferecer suporte à IA

6:17:13 e, sabe, 6% a 10% — ou 23% delas — estão investindo de 6% a 10% da receita anual na modernização dos sistemas centrais para aproveitar isso. Uma queixa ou dificuldade comum aqui é a qualidade dos dados e a capacidade de reutilizá-los. Ótimo, então temos as pessoas certas na sala e o conhecimento certo ali. O que fazemos agora? Então surge a ideia: como tornamos esse conhecimento reutilizável e acessível? Dependendo da adoção e do estágio em que estão, pode haver diferentes tipos de agents de equipe: agents especialistas, que são especialistas no assunto; agents de workflow, que atuam em vários fluxos, como bots do Slack que criam e abrem tickets, fecham esses tickets e assim por diante. E também pode haver agents que atuam realmente como chefes de

6:17:43 gabinete, acompanhando o estado da organização e o que precisa ser feito. Então, voltando aos nossos workflows, a empresa A está vendo isso de forma bem diferente em termos de capacidades compartilhadas. Agora, o último pilar para o qual quero chamar sua atenção é: quando esse sistema realmente se acumula e ganha força? O que acontece quando ele é implantado? Bem, as empresas líderes estão pensando nisso

6:18:13 de uma forma um pouco diferente. Que falhas podem nos dar uma vantagem, se aprendermos com elas? Se houver um sucesso, como o incorporamos ao sistema? A forma como pensam nisso é: o indivíduo aprendeu, mas o sistema também aprendeu? Talvez, quando se deparam com uma situação em que precisam fazer uma correção, esse conhecimento possa ser enviado de volta para a organização, seja por meio de uma nova ferramenta, contexto ou outra coisa. E o essencial aqui é preservar as evidências junto com esses aprendizados.

6:18:44 Então, o último eixo é: para onde vai a capacidade liberada pela IA? É preciso ter consciência de que o sistema precisa ser reformulado e realmente concentrar o foco nas principais métricas que vocês avaliam e monitoram, criando um ciclo virtuoso a partir delas. Então, o que isso significa para as empresas A e B? A empresa A reformulou todo o seu trabalho. Está desenvolvendo

6:19:18 capacidades que se acumulam e se fortalecem, e construiu capacidades compartilhadas. Então, quero terminar com uma última pergunta: todo mundo tem IA. Quem tem a vantagem? Obrigado. [aplausos]

6:19:48 capacidades que se acumulam, e eles têm capacidades compartilhadas que foram desenvolvidas. Então, quero encerrar com uma última pergunta. Todo mundo tem IA. Quem tem vantagem? Obrigado. [aplausos]

6:20:35 Calor. Calor.

6:21:41 Calor. Calor. Calor. Calor.

6:22:12 Calor. Calor. Calor. Calor.

6:26:00 Calor. Calor.

6:26:34 Calor aqui. Calor.

6:27:20 Calor. Calor. Calor. Calor. Calor.

6:29:11 Calor. Calor. N.

6:30:02 Calor. Calor. Ei, ei, ei.

6:30:52 Calor. Calor. N. Calor. Calor.

6:32:05 Calor. Calor. Calor. Calor. N.

6:33:24 Calor. Ei, calor. Calor. Calor.

6:34:35 Calor. Calor. Calor. Calor.

6:35:51 Calor. Calor. Calor. Ei, calor.

6:36:25 Calor. Ei, calor. Ei, calor.

6:37:34 Calor. Calor. Calor. Calor.

6:38:35 Calor. Calor.

6:39:45 Calor. Calor. Calor. Calor.

6:40:44 Calor. Ei, calor. Ei, calor.

6:42:29 para nos conduzir de volta às palestras principais de encerramento da programação de hoje. Por favor, recebam novamente no palco nosso mestre de cerimônias, Alex Lieberman, sócio-gerente da 10X. >> Como vão? Como está o… Quem está com mais energia na sala? >> Quem quer que tenha sido, era a pessoa mais animada. Bem-vindos de volta ao bloco de palestras principais de encerramento aqui na AI Engineer New York 2026.

6:43:01 Sou Alex Lieberman, cofundador e co-sócio-gerente da 10X Applied, parceira de empresas da Fortune 500. Já percorremos a maior parte da primeira sessão de hoje e espero que ela tenha sido repleta de conversas incríveis. Vou compartilhar um pouco sobre algumas das conversas que tive fora do palco daqui a um minuto. Espero também que a combinação da programação e das conversas que vocês tiveram entre si tenha sido muito proveitosa hoje. Agora, antes de começarmos

6:43:31 o bloco final do dia, vamos parar um momento para aplaudir nossos parceiros, que tornam todo este evento possível. Vamos começar com nosso patrocinador apresentador, Arize. Vamos agradecer à Arize. Isso, Arize. Em seguida, temos nossos patrocinadores platinum: Oracle, Sonar, Work OS e Exa. Vamos aplaudi-los. [aplausos] E temos mais dois. Temos os patrocinadores gold. Adoro todos eles. São todos meus filhos favoritos. Não consigo ler todos agora, mas muito obrigado

6:44:02 a todos. Aos nossos patrocinadores silver e a todos os parceiros de apoio que tornam isso possível, obrigado a todos. Isso! Não sei se foi a primeira pessoa que disse estar com mais energia, mas aquela pessoa tem muita energia. Então, antes de começarmos o próximo bloco, queria compartilhar uma coisa — e tenho certeza de que muitos de vocês já estão sentindo isso: não é só a energia palpável que há na sala entre as sessões, mas

6:44:33 o que você percebe quando vem à AI Engineer é que o conteúdo é incrível. Os palestrantes selecionados são incríveis. A profundidade com que falam do trabalho que estão fazendo é incrível. Mas tudo isso também serve como ponto de partida para conversas entre as pessoas na sala. Para mim, foi incrível não apenas ficar no fundo da sala em vários momentos do dia e ouvir esses palestrantes incríveis, que realmente estão vivendo na fronteira, mas também usar todas essas

6:45:06 conversas e palestras como ponto de partida para conversar com as pessoas. Algumas conversas que tive hoje por causa do conteúdo me vêm à cabeça. Uma delas foi com Swix, uma das pessoas por trás deste evento incrível. Conversamos sobre a lacuna de difusão que existe atualmente na IA empresarial. E aqui vão alguns dados interessantes. Na 10X, conversamos com centenas de grandes empresas dos setores de serviços financeiros, saúde, indústria e outros.

6:45:38 E penso na difusão da IA nessas organizações como etapas de uma corrida. A primeira grande etapa para uma empresa é simplesmente adotar um LLM de uso geral. Por curiosidade, das — digamos — 100 empresas com que conversamos, que porcentagem vocês acham que adotou e disponibilizou um LLM para todos os funcionários? Alguém grita um número. Acho que ouvi 9%. >> 17. >> 17%, um número bem específico. 90%. Então, 90% das

6:46:13 empresas com que trabalhamos disponibilizaram um LLM de uso geral. Abaixo disso, vem o treinamento das pessoas para saber como usar a tecnologia e essas ferramentas no trabalho: cerca de 60%. Em seguida, vêm os agentes de programação, usados de fato nos workflows de engenharia e produto: cerca de 50% de todas as empresas com que trabalhamos. E, por fim, a etapa em que ainda estamos realmente no primeiro dia, que está em torno de 5% agora.

6:46:45 Então, voltando ao que eu disse antes, esta comunidade realmente está na fronteira. Os assuntos discutidos aqui continuarão a se desenrolar nos próximos 12, 24 e 36 meses. Tive várias conversas desse tipo ao longo do dia: a lacuna de difusão, open source versus modelos com fine-tuning, e como é difícil contratar excelentes engenheiros de IA em escala. Portanto, enquanto seguimos com o resto do dia, e também quando pensarem na conferência como um todo, usem o conteúdo

6:47:16 como ponto de partida para ter conversas interessantes na fronteira. Dito isso, gostaria de apresentar nossa próxima palestra, com Frank Long, chefe de IA da Coatue. Ele vai falar sobre um hedge fund como função. Vamos receber Frank. [aplausos]

6:47:47 Olá. É empolgante estar aqui. Meu nome é Frank. Trabalho na Coatue, uma empresa de investimentos em tecnologia que atua nos mercados público e privado. No nosso negócio, o que você realmente precisa fazer é apostar com alta convicção em grandes temas e acompanhar como eles se desenrolam. Acho que, sinceramente, uma carreira funciona do mesmo jeito. No ano passado, quando entrei na Coatue, a aposta que eu quis fazer foi a de que os agents teriam um impacto ainda maior nos investimentos do que tiveram na programação. Sei que é uma afirmação forte. Estamos todos aqui por causa do impacto transformador que a IA teve na programação, mas acredito muito nisso. Hoje, quero falar um pouco sobre a estrutura que usamos para concretizar esse impacto.

6:48:18 Em linhas gerais, dá para pensar em um hedge fund como uma função que recebe dois parâmetros — contexto externo e contexto interno — e gera uma tupla: seleção, tamanho e momento; qual ação, quanto e quando, certo? E acho que essa é uma

6:48:49 boa estrutura para fundamentar nosso trabalho: estamos tentando resolver este problema de compressão — como pegar todas as informações e transformá-las nessa tupla simples. O produto que oferecemos é, essencialmente, uma série temporal dessa tupla, que constrói um portfólio. Então, vamos começar pelo princípio, que é a filosofia bem simples. Usamos nossas telas: tudo o que um ser humano consegue ver em pixels na tela, um agent que você está criando deve conseguir ver via API.

6:49:20 A analogia que uso é imaginar que você trouxe as pessoas mais inteligentes de todos os tempos, os maiores investidores vivos, para a sua empresa, mas deu a elas um computador sem acesso a 75% dos seus serviços. Quase não importa o quão inteligente seja o sistema se ele não tiver as ferramentas para agir. Então, há duas partes: o contexto externo, certo? Nada de surpreendente aqui. Pense em notícias, preços, documentos regulatórios; tudo isso

6:49:51 deve ser facilmente acessível — não arrastando e soltando, nem copiando e colando, mas diretamente via API. O contexto interno é igualmente importante, certo? É a situação da sua própria empresa. Isso pode incluir nossas posições atuais, a liquidez potencial e os requisitos de risco que temos em relação a determinados nomes, além de estudos de caso anteriores ou, sabe, nosso histórico com um setor, uma ação ou uma equipe de gestão. Tudo isso é muito importante. Essa é a

6:50:22 base e, bom, não posso levar o crédito por isso: a Coatue tem sido uma líder incrível nessa área há mais de uma década. Isso envolve tanto tecnologia quanto cultura. Temos uma equipe de ciência de dados incrível, processos incríveis e sistemas incríveis que reúnem tudo isso. E, igualmente importante, temos uma cultura extremamente rigorosa, criada desde o início para registrar todos esses insights. Há décadas, registramos cada nota sobre cada operação, cada decisão que tomamos ou deixamos de tomar, o que deu certo e o que não deu.

6:51:03 uma context window e obter meus números mágicos para ir embora, certo? Não pode ser tão fácil. Vamos detalhar um pouco mais essa função, certo? Talvez o primeiro passo seja receber esse contexto externo e interno e reuni-lo, certo? Quero filtrar o que é relevante e o que não é. Certo, encontrei algumas notícias sobre o MBA que provavelmente não são relevantes para as ações, mas, opa, isto aqui tem a ver com algo local

6:51:33 permissões que talvez possam realmente impactar os data centers. Há muita nuance nessa etapa de coleta. Então, provavelmente, você verá que a próxima etapa é analisar essas informações e formar uma opinião, certo? Preciso pensar no que isso significa para os mercados públicos e privados. E depois preciso pegar essa opinião e transformá-la em uma decisão. Um objeto de decisão tem estes três parâmetros, certo? Estas três subpartes, por assim dizer. Então você pode

6:52:04 ver que cada etapa tem uma entrada e uma saída, e a entrada da etapa seguinte é a saída gerada pela função anterior. Acho que, como engenheiro, essa é uma forma de conceituar o problema que faz bastante sentido para mim. Mas, mesmo assim, não dá para simplesmente escrever três funções, certo? Então, para realmente entender o escopo e compreender toda a complexidade do problema, vamos analisar a primeira etapa.

6:52:36 Uma minúscula subparte de uma minúscula subparte que consiste apenas em coletar informações. E vamos fazer um estudo de caso sobre a interpretação das notícias, certo? Provavelmente não é segredo para vocês que as notícias da Ásia e dos veículos de mídia coreanos têm sido muito importantes neste ano, porque as empresas de semicondutores e a IA têm sido um tema enorme no mercado, um tema enorme. E acho que esta é uma área em que a IA pode ter muito impacto: ler notícias em coreano melhor do que nossa equipe, que não fala coreano,

6:53:06 certo? Acho que tenho uma boa hipótese de que este pode ser um bom caso de uso. Então, você pode imaginar que a primeira etapa é obter artigos. Preciso coletá-los, certo? Isso poderia ser um MCP. Poderia ser uma CLI. Licenciar os feeds de dados. Limpar os feeds de dados. Na verdade, há muitas maneiras de fazer isso e muitas dimensões de liberdade até mesmo para escrever essa parte simples. Como devo dividir o conteúdo em blocos quando eu

6:53:37 o passar para o LLM? Quero obter as imagens como imagens? Quero obter as imagens e depois transformá-las em texto? Na verdade, há muitos parâmetros para ajustar aqui. E quase penso nesses parâmetros como hiperparâmetros de um sistema tradicional de machine learning, certo? Penso em cada um deles como algo que preciso ajustar e otimizar. Obviamente, falamos disso. Há provavelmente fãs coreanos da NBA, certo? Há provavelmente um monte de

6:54:08 coisas que não são necessariamente relevantes para os nomes, temas e ações do nosso portfólio que realmente importam, certo? Então, quero garantir que eu as filtre. Há essa questão de traduzir, extrair ou resumir. Devo extrair isso para algum tipo de formato estruturado? Mais uma vez, há muitas maneiras de fazer isso, muitas formas de experimentar como expor informações ao modelo. E uma das razões pelas quais isso é difícil é que continua mudando

6:54:39 e, obviamente, verificar nossas próprias anotações internas, nossas próprias opiniões internas, possíveis conversas que tivemos e gravações de reuniões em relação a essas informações. Na verdade, precisamos cruzar essas informações. A ideia de obter informações de fontes diferentes e cruzá-las é muito poderosa. Então, vocês verão aqui à direita código, LLM, pessoa. Há muitas maneiras de executar essas funções. Acho que… ah, sim, e por fim, possivelmente atualizar nossas

6:55:10 opiniões. Há muitas maneiras de executar essas funções. Penso em cada linha como tendo um executor, e o mais óbvio é o código. Código é muito bom. É rápido, barato e confiável. Então, para algo como verificar se a relação preço/lucro é menor que 15, eu deveria simplesmente usar código determinístico. O segundo executor são métodos estatísticos e machine learning clássico,

6:55:40 e você pode imaginar ajustar uma linha a uma regressão para um padrão específico. Isso é muito poderoso porque permite modelar relações muito mais complexas do que apenas código determinístico puro, certo? E, para relações ainda mais complexas, temos o estado da arte, certo? Provavelmente é totalmente impossível criar um monte de instruções “se” que consigam resumir melhor do que um LLM moderno. E

6:56:13 é claro que as pessoas são executoras importantes no sistema, certo? Então, imagine uma função que consiste em se reunir com a equipe de gestão de uma empresa. Provavelmente não quero mandar — quer dizer, gosto dos novos robôs Unitree, mas provavelmente não quero enviar um LLM ou um agent de IA para fazer isso. Provavelmente não quero enviar uma instrução “se” para essa reunião. Acho que há muitos casos em que, por causa do discernimento e da capacidade de lidar com o mundo real e todas essas coisas, uma pessoa é a melhor executora de uma parte específica da função. E acho que esse é um ponto muito, muito

6:56:44 importante. Não há mérito em automatizar coisas só por automatizar. O objetivo não é pegar o máximo possível de coisas e transformá-las em LLM. O objetivo é cumprir a função. Provavelmente se parece com isto. Provavelmente não é apenas uma sequência linear de várias coisas diferentes. Deve haver todos os tipos de lógica condicional e maneiras de dividir o fluxo. Então, talvez

6:57:17 eu queira coletar as informações, depois traduzi-las, e meu objetivo principal seja extrair citações e verificá-las nas fontes para garantir que as pessoas realmente disseram aquilo — essa é minha abordagem. Mas ela pode estar totalmente errada. Talvez, na verdade, eu queira remover duplicatas, depois filtrar e, então, buscar dados externos. Ou talvez eu queira fazer algo completamente diferente. Talvez eu queira passar uma anotação primeiro e simplesmente encontrar outros dados que a corroborem, ou talvez eu esteja tentando fazer um teste de red team. Há um milhão de maneiras diferentes de configurar isso. Então, mais uma vez,

6:57:47 há ainda mais hiperparâmetros no fluxo de controle, certo? Há muitas maneiras de pensar nesse problema aparentemente simples de coletar, filtrar, resumir e agregar notícias para LLMs. E cada uma dessas caixas provavelmente tem um executor ideal, certo? O executor ideal pode ser código determinístico para a coleta, certo? Estou buscando as últimas 24 horas de uma determinada fonte. Isso é

6:58:19 código determinístico. decision models, talvez métodos estatísticos, uma combinação, certo? Então, isso provavelmente subestima a complexidade. Na realidade, a maioria das coisas usa vários executores; a maioria combina código determinístico, LLM, método estatístico ou uma pessoa trabalhando em conjunto com um LLM. Na realidade, provavelmente há combinações entre minhas quatro categorias, e há ainda mais categorias do que essas, porque, dentro da categoria de LLM, posso ajustar o modelo. Posso

6:58:53 escolher um modelo grande, pequeno ou médio. Posso ajustar X para alto, alto ou médio. Posso escolher o harness. Posso escolher quais skills carregar com o harness. Posso escolher quais hooks carregar com as skills. Então, mais uma vez, há mais hiperparâmetros no meu espaço de busca. Tenho uma quantidade absolutamente enorme de hiperparâmetros no meu espaço de busca. E isso é só para esse probleminha, certo? Estou apenas filtrando as notícias. Então, uma forma de pensar em como dividir esses problemas é perguntar: o que posso separar de um jeito

6:59:24 que possamos entender e avaliar? Ah, não. Isso nem deveria ser um modelo. Deveria ser uma instrução “se”. Ou: nossa, LLMs são muito, muito ruins em traduzir isso para o impacto no portfólio. Essa etapa deveria mesmo ser feita por uma pessoa, mas ela está usando um sistema determinístico para ajudar a pesquisar e obter as informações. Podem ser coisas bem diferentes, certo? E, se você não tiver uma estrela-guia para orientar sua otimização,

6:59:55 você fica meio que… só fica mexendo nas coisas sem rumo. E acho que não consigo enfatizar o suficiente que isso é apenas uma coisinha que fazemos. Imagine cada fonte de dados que incorporamos: provavelmente há mais de três transformações para chegar ao resultado intermediário. Então, o grafo real de código e funções, como o CO2, provavelmente se parece… ah, não, não com isto. Esta é a proteção de tela. O grafo real provavelmente se parece com algo assim, certo? Ele é

7:00:26 provavelmente extremamente complexo. Em cada um desses nós, acabamos de falar de pelo menos 10 hiperparâmetros, com pelo menos 20 valores válidos diferentes para cada um. Também é preciso assimilar isso do ponto de vista cultural e organizacional. Esse é o grande desafio de aplicar IA a investimentos. E, para além dos investimentos, o que estamos realmente discutindo é

7:00:58 criando uma máquina de estados capaz de receber informações do mundo e compreendê-las o suficiente para tomar decisões coerentes. Há casos de uso para isso muito além de empresas de investimento: em políticas públicas, organizações sem fins lucrativos, descoberta de medicamentos e estratégia corporativa. Acho que uma das coisas mais empolgantes de participar de fóruns como este é conversar com outras pessoas em áreas diferentes, com problemas diferentes, que acabam convergindo para o mesmo espaço de problemas. Adoraria continuar falando sobre isso. Vou ficar por aqui

7:01:29 no corredor depois. Aqui estão minhas redes sociais. E agradeço a todos pelo tempo. >> [aplausos] >> E agora, vamos conhecer modelos de fronteira criados para agir no espaço e no tempo. Recebam o cofundador e CEO da

7:02:01 General Intuition, Pim Dit. Olá. Quero que vocês deem um passo atrás por um instante e pensem: se alguém dissesse hoje que pegaríamos todas as informações da internet

7:02:32 e então treinaríamos um modelo com elas e o usaríamos para resolver problemas científicos que não estão na internet, acho que muita gente diria que isso é loucura. E o que estamos fazendo tem muitos paralelos com essa história. Então, se pensarmos em como a inteligência funciona, imaginem por um instante que estão no filme Frozen e são Olaf, o boneco de neve. Se Olaf fosse um LLM, há uma cena, uma das minhas favoritas, em que ele rola montanha abaixo, uma pequena pedra aparece, e Olaf se espalha temporariamente, vira um boneco de neve desmontado e depois se recompõe.

7:03:03 Olaf sabe fazer isso porque consegue observar enquanto age. Ao contrário dos LLMs, que preveem tokens de forma autoregressiva, parte desse comportamento consiste em observar continuamente enquanto age. E então, essa é a grande

7:03:36 diferença entre, vocês sabem, ver LLMs tentando resolver problemas de robótica ou observar arquiteturas nativas como a que estamos desenvolvendo. É muito, muito fácil pensar que os LLMs das demonstrações que vocês veem no Twitter vão resolver tudo. Vemos limitações fundamentais em que modelos criados especificamente para esse fim se encaixam muito melhor. Hoje, vou falar um pouco sobre como é o outro lado dessa moeda. Para nós, tudo começou com a Metal. Criamos o maior gravador de videogames do mundo. E pensamos nisso como a

7:04:10 internet. As pessoas usam a Metal para gravar a si mesmas jogando dezenas de milhares de videogames diferentes. E, se pensarmos nisso, nós, como seres humanos, podemos operar um robô com exatamente o mesmo cérebro que usamos para jogar aquele videogame. E, na verdade, em muitos casos, também podemos usar o mesmo controle. Isso significa que o espaço de ações dos videogames, muitas vezes por causa dos controles de jogo, e o espaço de ações da teleoperação

7:04:40 ou do mundo real são, em muitos casos, iguais. E então, todo robô com menos de certo número de graus de liberdade vem com um controle de videogame. A maioria das cadeias de suprimentos já funciona assim. Então pensamos: e se simplesmente pegássemos todos os dados de ações que obtemos por meio do gravador de vídeo, que associa as entradas e as ações aos quadros correspondentes? Rotulamos as ações para entender o significado semântico de cada uma e usamos esses dados para alimentar um modelo baseado em visão. E então, o que

7:05:10 vocês veem à esquerda é apenas uma maneira intuitiva de entender como o modelo funciona. Vocês dão ao modelo um conjunto de teclas para escolher, essencialmente um modelo de uso de computador. Ele recebe quadros como entradas. Também é possível fornecer um prompt de texto e enviar tudo pela API. Por exemplo, vocês dizem que alguém acena e que o modelo deve acenar de volta. No espaço de entrada, o modelo entende que tem disponível uma ação de saudação. Ele produzirá a ação correspondente. Uma maneira intuitiva de entender como isso funciona. Então, obviamente, simplifiquei

7:05:42 aqui, porque ele prevê o próximo token, não a próxima palavra, mas acompanhem meu raciocínio. Os LLMs pegaram dados da internet em larga escala e foram treinados para prever o próximo token de texto; agora, são usados para escrever software. Essas são cargas de trabalho que se encaixam muito bem em situações que não se desenrolam simultaneamente enquanto o modelo faz previsões, certo? O código funciona por turnos. Você diz algo, o modelo faz algo. Você diz outra coisa, o modelo faz algo de novo. E dá para usá-lo em muitos trabalhos valiosos

7:06:12 mas, no fim das contas, por funcionar por turnos, é muito, muito difícil generalizar para ambientes, especialmente aqueles que incluem espaço e tempo. Nossos modelos funcionam recebendo quadros continuamente. Eles recebem lotes de informações, essencialmente, da câmera do robô — ou pode ser uma tela — e preveem tudo como se fosse um videogame. Então, dá para pensar na maneira

7:06:44 como a Anthropic se concentrou em dominar a programação. Eles nunca foram de ponta na geração de texto básica; sempre se concentraram em ser os melhores na geração de código. E a aposta que fizeram foi que mais pessoas começariam a levar mais problemas para o espaço da programação. No caso da General Intuition, nossa aposta é que nós, seres humanos, em geral, convertemos pixels em ações, além de usar sentidos que, em muitos casos, também podem ser convertidos em pixels. E podemos produzir ações ao mesmo tempo; nesse

7:07:15 caso, essas ações são feitas com teclado e mouse ou com um controle de videogame. Os tokens de saída do modelo são essencialmente equivalentes aos de um modelo aprimorado de uso de computador, com mais, mais, mais ações no espaço de saída, para internalizar isso. Você envia quadros e recebe ações. Isso funciona, novamente, porque tudo o que vocês veem aqui pode controlar todas essas diferentes formas incorporadas, certo? Como seres humanos, não sabemos prever o torque de um motor. Não sabemos que

7:07:47 valor enviar a uma máquina. Há um dispositivo maravilhoso, criado há muitos anos, que faz esse trabalho por nós, permitindo que controlemos as máquinas. Hoje, a maioria das empresas de robótica tenta resolver o problema de ponta a ponta, tentando prever poses exatas ou valores exatos no motor, em vez de simplesmente observar e pegar aquilo que toda empresa de robótica criou para generalizar nossas capacidades muito limitadas

7:08:18 de compreender a física e prever valores e resolver esse problema. Então, nossa abordagem é simplesmente usar isso. No momento, a Metal recebe cerca de um bilhão de vídeos enviados por ano. Neste ano, estamos a caminho de chegar a três bilhões. Isso gera mais de um trilhão e meio de tokens de ação por mês. Só para comparar e dar uma ideia: coletamos, em meio dia, a quantidade total de dados que os laboratórios de fronteira usam hoje para

7:08:49 treinar modelos de robótica. Então, a aposta é esta; e, mais uma vez, pensem no fato de que os seres humanos podem usar exatamente os mesmos controles e os olhos para jogar videogames e operar robôs. É a mesma coisa. Apostamos em ampliar o espaço de pixels, assim como a Anthropic ampliou o espaço da programação, apostando que, à medida que ampliamos os dados e a computação no espaço de pixels, as pessoas levarão mais problemas para esse espaço.

7:09:21 E então, o que acontece? De repente, temos um agent incrivelmente geral, capaz de resolver problemas em computadores e no mundo real. Além disso, assim como a Anthropic se concentra em ambientes de programação, nós nos concentramos em modelos de mundo, pelos quais a maioria de vocês nos conhece: lançamos o Mirror para gerar ambientes adicionais nos quais esses modelos possam aprender. Uma maneira de assimilar uma grande

7:09:53 A vantagem dessa abordagem em relação aos modelos de linguagem é que, se você é uma empresa de LLM e precisa apostar na capacidade de gerar ambientes para seus modelos aprenderem, tem dois problemas. Primeiro, você realmente precisa gastar compute para simular ambientes. E, quanto mais realista tentar fazer a simulação, mais caro fica. Então, imagine que você quer aprender algo novo. Você quer aprender essa coisa nova exatamente no espaço de entrada dos humanos, certo? Então, se estamos aprendendo com

7:10:23 pixels, estamos aprendendo olhando ao redor. Se estou tentando comunicar algo, quero que meu parceiro robô observe exatamente a mesma coisa. E o que não quero é que isso tenha que passar por um LM, que seja necessário criar um gêmeo digital, fazer o deploy do modelo, realizar várias verificações para determinar se as coisas são equivalentes e, só muito depois, o robô aprender, certo? Uma maneira de pensar nisso é que, quando você consegue aprender na modalidade nativa dos humanos, de repente pode começar a resolver muito mais problemas

7:10:54 muito mais rápido. O que você vai ver quando esses modelos forem lançados é que eles são significativamente mais rápidos do que qualquer LLM para fazer essas coisas, porque os jogos são muito densos em ações. Então, uma coisa interessante que você vai notar é usar soft para um modelo prever várias ações ao mesmo tempo. Conseguimos pegar essa densidade de ações dos jogadores e convertê-la em cargas de trabalho de robótica realmente complexas. Por exemplo, se você está

7:11:25 operando um drone e precisa fazer muitos pequenos ajustes, você realmente quer começar com jogos, não quer começar com teleoperação, porque o humano simplesmente vai realizar muito menos ações. Há muito menos informação. Então, você quer um modelo que consiga prever um APM realmente alto. O APM do conjunto de dados coloca de repente muitos desses problemas ao alcance, permitindo que o modelo realize muitas dessas ações simultaneamente. E, como mencionei, o modelo não entende apenas a tecla que está prevendo. Ele também entende o significado semântico associado a essa tecla, o que é muito importante para coisas

7:11:56 como interpretabilidade. Então, vamos lançar os modelos este ano. Estamos muito felizes. Acho que a palavra certa seria que estamos impressionados com o que esses modelos conseguem fazer. Como esta é uma transmissão ao vivo, infelizmente não pude compartilhar os vídeos de lançamento sem estragar a surpresa. Mas, se você está em Nova York, nós também estamos em Nova York, então começamos a fazer algumas

7:12:26 demonstrações do modelo. Se você conhece alguém da equipe, entre em contato e podemos começar a mostrar algumas das capacidades ao vivo. Temos, essencialmente, um modelo que consegue jogar videogames no mais alto nível e controlar mais de 10 tipos de robôs usando exatamente os mesmos primitivos. Pixels entram, ações saem, tudo em tempo real. E vamos liberar o acesso antecipado a esses modelos nos próximos meses. Já temos alguns clientes usando-os, mas ainda é privado, então você não está ouvindo

7:12:57 muita coisa sobre isso. Mas, se você escanear este QR code, poderá obter os modelos, porque seguimos a ordem em que as pessoas se inscrevem nas listas de espera. Então, este é um ótimo momento para entrar em contato. Como mencionei, estamos em Nova York. Acho que você vai perceber que, assim como Jev e muitos desses modelos de tomada de decisão abriram os olhos das pessoas para o que é possível fazer com um novo primitivo arquitetural, as pessoas estão prontas para deixar de lado a imprevisibilidade de um LLM e colocar

7:13:28 algo mais confiável e rápido no lugar, algo cujo comportamento você simplesmente entende, em vez de ter que contornar suas limitações. Se isso faz sentido para você, estes modelos são exatamente o que está procurando. E, de repente, você pode começar a explorar os ambientes que gera com LLMs. Um dos casos de uso que me deixa muito animado é que esses modelos conseguem realizar ações na interface como se um humano estivesse usando-a. Então, se você trabalha com UX e está tentando entender se uma interface é

7:13:58 intuitiva, esta é uma maneira muito interessante de resolver o problema. Você pode começar a usar estes modelos para resolver todos esses problemas que os LLMs não conseguem resolver porque não conseguem explorar como um humano. A forma como eles serão lançados é que ainda esperamos que você use um modelo orquestrador. Você pode usar algo como Gemini ou Astra para fazer planejamento de longo prazo e tudo mais. E poderá integrar esses modelos às suas cargas de trabalho. Na verdade, os modelos são tão gerais que

7:14:28 acho que vai realmente parecer com os primeiros tempos dos LMs, quando você tem um brinquedo novo e só quer descobrir o que ele faz e para que pode usá-lo. Minha reação foi assim quando comecei a usar os checkpoints, e acho que você vai ter a mesma reação. E acho que muitos de vocês, assim como aconteceu com os LLMs, se começarem cedo e entenderem esses primitivos, vão perceber que também é possível construir muitos negócios em cima disso.

7:15:00 Certo? Pense, por exemplo, em um laboratório de ciências. Se, de repente, você consegue orquestrar robôs de forma confiável no espaço e no tempo, e eles conseguem receber instruções em texto e executar tarefas, isso se torna um problema recursivo, certo? A robótica é interessante porque um dos grandes problemas para resolver a robótica é fabricar mais robôs. E, como tudo é tão limitado pela inteligência, vão surgir muitas empresas simplesmente por resolver esse único

7:15:31 problema simples: transformar pixels em ações. E acho que, se você conseguir acesso antecipado a eles, o efeito será parecido com conseguir acesso antecipado aos primeiros LLMs. Também estou muito animado com uma das coisas em que estamos trabalhando, que é interessante: se você tem amigos ou familiares que, de alguma forma, precisam de ajuda de acessibilidade para usar o computador, esses modelos conseguem usar computadores como um humano. De repente,

7:16:01 por exemplo, se você só consegue usar um braço, o modelo pode permitir que você jogue videogames, porque você pode simplesmente controlar o mouse e o modelo prevê as ações do teclado. E, como o modelo também entende quais ações você está realizando, porque essa é a entrada — ele observa enquanto age —, ele simplesmente não vai prever as coisas que você está fazendo; vai prever apenas as teclas. Isso tem todos esses efeitos derivados e permite construir várias coisas em cima. Sou engenheiro. Se você tem interesse em

7:16:33 desenvolver nessa área, este vai ser o brinquedo mais interessante lançado este ano. Tenho quase certeza. Também acho que boa parte do uso inicial vai acontecer em simulação. Então, se muitos de vocês estão interessados em gerar ambientes com Astra ou Gemini, ótimo. Agora, de repente, vocês têm algo que consegue explorá-los, e não precisam fazer isso por conta própria. E o momento é perfeito por causa de todos os recursos de geração de ambientes que estão sendo incorporados a esses modelos. Certo. Então, rapidinho, antes de encerrar,

7:17:04 Quero falar sobre a equipe. Então, estamos sediados em Nova York. A equipe Metal e a equipe General Intuition ficam aqui em Nova York. Então, se você está por aqui, entre em contato com a gente e podemos mostrar os modelos para você. Especialmente se quiser entrar para uma equipe. Acho que vamos dar ainda mais prioridade a isso. [risos] Mas estamos mesmo procurando pessoas que queiram entender esses modelos tanto quanto nós. Então, se você é muito, muito bom em gerar ambientes novos, normalmente você

7:17:35 tem algum tipo de experiência em pesquisa, mas eu não tenho experiência em pesquisa, então tudo bem se você vem de uma formação em engenharia e está muito, muito disposto a aprender. Isso também serve. E, idealmente, queremos alguém que tenha experiência em lançar produtos de IA de ponta a ponta, mas não precisa ser na área de pesquisa. Queremos contratar pessoas que entendam o processo inteiro. Vamos ver. Temos três equipes. Uma é de modelagem de mundo, outra é de

7:18:07 política, ou seja, o agent, e a outra trabalha essencialmente na geração de dados e na geração de ambientes. Essas são as principais equipes. Se você é engenheiro, provavelmente a melhor equipe para entrar é a de geração de ambientes. E aí você vai crescendo até conseguir acesso a isso. Sim, estou muito, muito animado para novembro. Espero mesmo que fiquem de olho. Como mencionei, o planejamento atual é para o fim de novembro ou o começo de dezembro. Mais uma coisa: vamos organizar

7:18:38 três hackathons. O primeiro será em Nova York, em meados de novembro. Vamos enviar alguns e-mails para quem se inscrever na lista de espera de parceiros, para que todos possam ter acesso. Esperamos ver todo mundo nos hackathons. Acho que será a primeira oportunidade de vocês colocarem a mão nos modelos, do jeito que estamos trabalhando com eles internamente agora. Também haverá um em Nova York e outro em Londres. Então, se você estiver em uma dessas cidades ou quiser viajar para uma delas, será uma boa oportunidade para conhecer a equipe. Sim, vamos ver.

7:19:11 Tenho tempo para uma ou duas perguntas e depois acho que podemos encerrar. Certo. Como isso é diferente do Jeppa? Ele não treina junto com os rótulos de ação. Na maior parte, eles apostam em rótulos de ação inferidos. Acho que outra forma de pensar nisso é que, no limite, o JPA é a abordagem mais correta, mas é bem menos prática no curto prazo, porque você precisa apostar em uma lei de escala separada

7:19:41 para a própria inferência de ações. E gostamos muito do Jetpa como conceito. Achamos que é… sabe, usamos algumas das coisas nos modelos, mas, no fim das contas, é uma abordagem, não um produto. Acho que vamos aproveitar conceitos de ambos os lados. Uma forma de pensar nisso é: como temos tantos dados de ação, digamos que você esteja pilotando um avião e

7:20:12 esteja movendo o leme na parte de trás: não há como perceber isso a partir dos quadros de vídeo. É muito, muito difícil. Então, nosso modelo, por contar com os dados de ação, se transfere melhor para sequências de ações do que para modelos de mundo e para gerar os pixels. Por isso, apostamos tudo no treinamento desses modelos de fundação gerais para previsão de ações. E usamos todo tipo de técnica para modelos de mundo. Também desenvolvemos os nossos. Gostamos muito que outras empresas também os desenvolvam. Então,

7:20:42 Ótimo, mais uma e depois acho que preciso ir. Ótimo. Muito bem. Certo. Obrigado a todos. Tenham um bom dia. Senhoras e senhores, para a palestra final do dia, recebam no palco o CEO da Noose Research, Dylan Rolnick.

7:21:21 Olá, pessoal. Sou Dylan Rolnick, CEO da News Research, e hoje vamos falar sobre construir sobre fundações e plataformas que vocês realmente podem possuir. Aí está. Certo.

7:21:51 Como recuperar um investimento de um centilhão de dólares em infraestrutura e pesquisa? Os laboratórios gastaram individualmente centenas de bilhões de dólares treinando e construindo sistemas de inteligência cada vez mais sofisticados. E o setor como um todo talvez tenha gastado trilhões. O problema é que os modelos começaram a se tornar commodities.

7:22:22 Vocês aqui na sala, que espero que trabalhem com IA, já sabem disso intuitivamente. Trocam de modelo com facilidade. Alternam entre Astra, Fable, Opus, Kimmy, seja qual for, sem se preocupar muito com quem está por trás ou com o que é. Querem experimentar o modelo novo. Também vimos isso nos dados. Nesta semana, circularam pelo Twitter alguns gráficos mostrando que o custo médio de um token está caindo, enquanto o gasto total com tokens dispara, e os custos de infraestrutura

7:22:54 associados a servir esses tokens continuam estáveis. Isso significa que, onde antes havia margem em um modelo de desempenho muito alto, ela agora começa a diminuir, à medida que vemos a concorrência e um nível básico de inteligência se tornar disponível para as pessoas. Certo. Então, se os modelos estão começando a se tornar commodities e você gastou centenas de bilhões, trilhões de dólares neles, precisa recuperar esse dinheiro. E precisa

7:23:24 encontrar outra maneira de fazer isso. Na minha opinião, há duas maneiras bastante óbvias. Primeiro, encontrar outra camada da pilha para competir. Descer para a infraestrutura ou subir até o usuário. Ou, segundo, construir Deus, construir Deus mais rápido do que qualquer outra pessoa e monetizar Deus. Se você está diante do usuário, tem a oportunidade de gerar fidelidade. Fidelidade significa margem. É por isso que a disputa mudou, em grande parte, para a camada de agent. Ultimamente, nós…

7:23:56 Começamos a conversar sobre isso. Ouvi alguém falar antes que 5% de uma força de trabalho está usando agents. Essa está se tornando cada vez mais a ideia dominante sobre onde a batalha da IA está acontecendo. Os consumidores, porém, são volúveis e péssimos clientes. As empresas, por outro lado, gastam muito dinheiro com tokens e têm casos de uso economicamente produtivos para esses tokens. Então, se você vai competir na camada do usuário e levar essa disputa para outro lugar,

7:24:28 vai levá-la para as empresas. O melhor é se integrar profundamente a uma empresa, porque, quando você faz parte de uma empresa, é difícil tirar você de lá, certo? E, se pensar na sua empresa daqui a dois ou três anos, quanto da força de trabalho, medido pela produção, será composto por agents? Conservadoramente, 70%, provavelmente mais. E, se 70% da sua força de trabalho for organizada por outra pessoa, que pode ou não ter

7:24:59 interesses contrários aos seus, ela pode ser organizada para entrar em greve. Então, o que você faria se precisasse recuperar um investimento de um trilhão de dólares? Você se integraria, usaria sua vantagem assimétrica e mudaria as regras do jogo ou, como eu disse, construiria Deus. Se você conseguir construir Deus, vai direcioná-lo aos problemas mais lucrativos do mundo.

7:25:30 A melhor chance de recuperar esse dinheiro não é vender a tecnologia para outros, com margens cada vez menores, para que resolvam esses problemas difíceis e lucrativos. A melhor chance é resolvê-los vocês mesmos. Os laboratórios acham que os mercados são problemas solucionáveis, e é exatamente assim que veem o setor financeiro: como um problema a ser resolvido

7:26:00 e, além disso, um problema passível de ser conquistado, talvez nem muito difícil. No momento, porém, eles sabem — pelo menos os mais inteligentes sabem — que não têm contexto, conhecimento prático ou experiência suficientes no setor financeiro para fazer isso por conta própria. Então, vão fazer parcerias, contratar analistas de banco de investimento, firmar parcerias com algumas das maiores empresas do mundo e começar a construir sua base por aqui. Acredito que, no fim, vão direto à fonte, porque, como eu disse,

7:26:32 É aí que está o dinheiro, e estamos tentando recuperar um trilhão de dólares. Então, você poderia dizer que isso não é novidade. Sempre tentamos prender as pessoas nesses jogos e mudar a margem; quando já as temos e elas ficam presas, conseguimos aumentar os preços. Mas a diferença é que os riscos são muito maiores. Estamos falando de percentuais de dois dígitos significativos da economia da Terra. E vocês, nesta sala, precisam de IA.

7:27:04 Todos já viram o que eles conseguem fazer, o que esses modelos conseguem fazer, o que os sistemas agênticos conseguem fazer, e não há como voltar atrás. As pessoas nesta sala que estão tomando decisões — vice-presidentes, executivos e engenheiros — sobre aquilo que estão construindo terão de decidir agora onde criar raízes em torno dessas ferramentas e desses processos, que afetarão o futuro dessas empresas. E, seja o que for que escolherem, começarão a se consolidar. Vão adquirir know-how. Isso vai começar a

7:27:36 aumentar a inteligência da própria organização. Vocês começarão a construir processos e sistemas em torno disso. Imploro a vocês: não construam sobre alicerces de areia movediça. Construam sobre alicerces abertos. Construam sobre o Hermes Agent. >> [fungada] >> Então, passei um bom tempo tentando convencê-los, espero, de que a decisão com maior valor esperado em IA neste momento é ou prender vocês e aumentar os preços, ou substituí-los diretamente. Então,

7:28:08 por que estou aqui? Vemos o mundo de uma maneira muito diferente. E a primeira coisa que espero que vocês aprendam sobre mim e sobre a Nous Research é que construímos esta empresa principalmente por razões morais e filosóficas. Muitas vezes, no mundo dos negócios, a moralidade e os incentivos nem sempre estão alinhados. E, quando isso acontece, provavelmente é mais fácil mudar a própria moralidade. Mas achamos que o mundo está mudando e que é diferente. Por essa razão, acreditamos que o melhor caminho

7:28:39 é aquele em que estamos alinhados. Quando fundamos a empresa, nós a criamos para combater uma tendência aparentemente inexorável à centralização e ao controle centralizado daquela que talvez seja a tecnologia mais importante do mundo e sua invenção mais importante. A Nous Research foi criada e é formada por nerds. Nerds que amam ficção científica. E todos já vimos o que acontece quando uma entidade centralizada assume o controle de uma inteligência quase divina e a usa para explorar os outros.

7:29:10 Afinal, a Skynet era uma empresa de código fechado. A próxima coisa que vocês precisam saber é que já não existe realmente uma grande vantagem competitiva em software proprietário. O custo marginal para reproduzir uma peça de software despencou. Há alguns meses, a xAI lançou o Grok Bots, nós vimos aquilo e pensamos: “Uau, é uma interface de usuário intuitiva. Muito boa.” Então, direcionamos o Hermes Agent para aquilo, reproduzimos o produto em um fim de semana e lançamos

7:29:42 isso como um recurso do Hermes Agent, em open source, claro, e o jogo mudou. Antes, era difícil produzir software: equipes coordenadas de engenheiros levavam muitas horas para compilar código open source, pegar bibliotecas, combiná-las em peças de software proprietário e depois vender esse software como SaaS. Mas agora é o contrário. Tudo pode ser submetido à engenharia reversa. E há muitos, muitos desenvolvedores de open source motivados direcionando seus agents para

7:30:13 esses diferentes softwares. Se os concorrentes de código fechado conseguirem criar recursos interessantes, o open source os terá pouco tempo depois. As vantagens competitivas de ontem estavam na propriedade intelectual proprietária. As de amanhã estarão nos efeitos de rede, na reputação e na confiabilidade. O engraçado é que, em muitos aspectos, os laboratórios sempre pareceram subestimar as próprias ferramentas — ou talvez estejam subestimando os usuários dessas ferramentas, seu gênio e sua

7:30:43 motivação. Isso aconteceu e está acontecendo no lado dos modelos, e vamos falar sobre por que isso é importante. Mas acontece que os modelos conseguem ensinar outro modelo com bastante facilidade a ser quase tão inteligente quanto o modelo original. E a vantagem de um modelo raramente está na arquitetura ou em algum sistema novo criado de forma proprietária para aquele modelo. Na verdade, geralmente está na qualidade dos dados e na escala

7:31:14 e… desculpem, a empresa por trás do modelo começou a perceber que a escala estava alcançando os concorrentes e que era possível criar essas coisas com dados suplementares de qualidade, por meio de

7:31:48 ensinar um modelo a partir de outro. Então, deram ao processo de ensino o nome de destilação e chamaram a destilação ilícita de roubo. Não dá para chamar isso de violação de direitos autorais, porque isso implicaria que, de algum modo, você pegou toda obra escrita ou criativa de cada ser humano vivo e treinou o modelo com ela. Também deram um nome ao processo de… Também treinaram os modelos para não ajudar no processo de treinamento de outros modelos e chamaram isso de segurança.

7:32:26 A próxima coisa que vocês precisam saber sobre agents e sobre o novo mundo é que agents são como sistemas operacionais e frameworks; eles se parecem muito mais com essas coisas do que com chatbots. Então, se continuarem pensando no agent de vocês apenas como um assistente pessoal, viverão para sempre na superfície do que significa trabalhar com sistemas agênticos. E o que quero dizer com isso? Se vocês estavam aqui um pouco mais cedo, houve uma apresentação sobre uma empresa financeira e sobre como ela pensa

7:32:56 em IA e nos diferentes insumos que, no fim das contas, resultam em uma decisão de investimento. No fundo, agents são um sistema que combina determinismo e não determinismo. Se vocês se lembram daquela palestra, há fontes de dados, há código rotineiro, há opiniões das pessoas e há julgamento. E todas essas coisas se juntam para criar aquilo que será a nova aplicação. A nova aplicação já não precisa ser determinística, rígida e feita de

7:33:26 código rígido. Ela pode incorporar inteligência, raciocínio, julgamento, todas essas coisas juntas, para criar a nova aplicação. Portanto, enquanto pensam em construir essas novas aplicações na empresa de vocês, construam esses sistemas sobre alicerces que sejam de vocês. Vocês devem poder trocar os modelos que quiserem. Devem criar camadas cada vez mais sofisticadas de

7:33:56 funcionalidade sobre esses elementos fundamentais de determinismo, não determinismo, código, fontes de dados, julgamento, raciocínio e intelecto. Mas vocês não deveriam passar a vida inteira sendo empresas de inteligência. O que fez vocês terem sucesso até aqui? A maioria de vocês provavelmente não é uma empresa de agents. A maioria de vocês provavelmente não é uma empresa de IA. Vocês devem se concentrar naquilo que fazem bem. E, quando o

7:34:27 estado da arte mudar e evoluir, e o significado de sistema agêntico começar a mudar, vocês devem incorporar essa evolução, não reconstruí-la e mantê-la. Lembrem-se: essas são ferramentas que devem tornar vocês melhores. Elas não são substitutos prontos para ocupar o lugar de vocês. Vocês sabem quanta energia é necessária para criar um ser humano? E a beleza da proposta do Hermes Agent é que vocês podem executá-lo como quiserem, onde quiserem. Modifiquem-no como acharem melhor. Se não estiverem mais se divertindo, podem pegar a bola e ir para casa. A vantagem competitiva

7:35:00 mudou. A vantagem competitiva já não está em prender vocês. Ela está na reputação. E é isso que o Hermes Agent oferece a vocês. Então, o que quero com tudo isso? Bem, quero construir um padrão. Hoje, o Hermes Agent é o agent de open source mais usado e baixado do mundo. Ele tem uma ordem de magnitude a mais de downloads do que alguns de seus concorrentes de código fechado. E quero que todos possam construir sobre esses alicerces abertos, porque, enquanto

7:35:31 um de nós estiver disposto a disponibilizar essas ferramentas e esses sistemas agênticos em open source, a água continuará correndo morro abaixo. E quero estar no sopé, para poder trabalhar com vocês e oferecer suporte, segurança e escalabilidade junto com o melhor agent aberto do mundo. Já vi aonde isso leva, e vimos onde estarão as vantagens competitivas: efeitos de rede, confiabilidade e reputação. As pessoas continuarão resolvendo problemas difíceis com sistemas agênticos.

7:36:02 As pessoas vão resolver problemas lucrativos com sistemas agênticos. Alguém vai recuperar os investimentos de um trilhão de dólares que fizemos. Garanta que esse alguém seja você. Garanta que você esteja no controle do próprio destino. Você pode ter tudo. Pode ter recursos de ponta e confiabilidade sem sacrificar sua autonomia. Construa sobre algo que é seu. Construa conosco. Obrigado. [aplausos]

7:36:37 E agora, algumas considerações e observações finais. Recebam de volta ao palco nosso mestre de cerimônias e sócio-gerente da 10X, Alex Lieberman. >> Certo, vamos encerrar [música] isso aqui. Olhem a variedade de assuntos que tivemos nos últimos 30 minutos. Pim falou sobre modelos de mundo, passando de pixels a ações. Dylan falou sobre a criação de agents em território próprio versus alugado. E então Frank falou

7:37:07 sobre como eles pensam em aproveitar a IA aplicada para tomar decisões relacionadas a investimentos. Primeiro, vamos aplaudir todos os palestrantes, todos que tornaram o evento possível e todos os patrocinadores de hoje. [aplausos] E mais dois avisos finais antes de encerrarmos o dia. O primeiro, muito importante: vão conversar com pessoas. Esse é o primeiro aviso. Hoje foi abordado um conteúdo incrível. Mais uma vez,

7:37:38 isso é uma oportunidade para vocês se conectarem com outras pessoas e viverem na Edge City por meio de conversas intelectualmente estimulantes. Não deixem essa oportunidade passar. E, em segundo lugar, este é apenas um dia de um evento incrível. Então, amanhã, as atividades começam de novo pouco antes das 9h. Portanto, cheguem cedo. Obrigado a todos por terem vindo. Obrigado pelo convite. E até amanhã.

Transcrição original

[00:24] Good morning and welcome to AI Engineer New York 2026. We’re thrilled to have you with us as we kick off an event of big ideas, sharp perspectives, and plenty of signal cutting through the noise. To officially open the event for us this morning, please welcome to the stage AI engineers general manager Leah McBride. Hello. Hi. Good morning, everyone, and welcome

[00:56] to [music] New York. Um this is our third event in New York. We had two in 2025 uh with some of our greatest speakers that we’ve ever had at AI Engineer. So we’re really excited to be back. So just a huge welcome for myself and Swix to everyone. Um thanks for attending today. We hope you’re going to have a great few days. Uh there’s very very few places like New York City as we know um where big ideals scale very scale very very fast. um uh it is where Frontier AI

[01:26] comes to meet centuries old global financial institutions and where multiple different economies thrive together. So we’re excited to have an incredible lineup. You’re going to hear from some of the world’s best speakers just like at all our events. We have got people we will we’ve got tracks um in finance. We’ve got engineering leadership uh evals and LLM. Um, we’ve got Parad Dinaran. Gonna get that right. Uh, from Arise. We’ve got Max Cana

[01:58] Alexander from Capital One and Tariq Shikat from Sonar. That’s just a few of the incredible speakers that we’ve got this week. Uh, I’m going to say a huge thank you to Arise, who’s our presenting sponsor. You guys can go and meet their team in the expo at any point this week. So, uh, lean in to learning here. lean into connecting as well. There’s so many people here that um are sharing ideas. They want to talk about the ideas. They want to challenge ideas um and they want

[02:29] to collaborate as well. So, make sure to speak to as many people as possible, your attendees, speakers, and all the sponsors. Um and we hope to see you again soon. We do have a great lineup. Uh we we’ve got another event cold summit in San Francisco in November and then we have London lined up in February and then of course World’s Fair and we’ve got a couple of other events happening next year as well that are new. So uh keep an eye on the schedule but have a wonderful few days. Uh thank you so much. Take care.

[03:03] And now, please welcome to the stage your MC for the day, managing partner at 10X, Alex Lieberman. What’s up, everyone? How’s it going? There we go. Uh, before we hop into the official stuff, I just want to start by introducing myself and asking you a quick question. I’m Alex Lieberman. I’m one of the co-founders and co-managing partners at 10X. were an applied AI company working with Fortune 500

[03:33] businesses to become AI native. Before that, I co-ounded a business called Morning Brew, which makes business news suck a little bit less. My question for you is, who in the room, raise your hand if you are healthfully addicted to X, or formerly known as Twitter. Okay, a lot of people are lying in the room. Uh, I spend a lot of time on X. And one of the reasons that I spend a lot of time on X is because I feel like I get to live in the future. Right? When

[04:04] you’re when you’re scrolling through X, when you’re looking at the commentary on the platform, you feel like you’re seeing what will become consensus in 3, 6, or 12 months. And what I love about this conference and why I get so excited to come to it every single year is because this almost feels like X on steroids. Uh there’s this concept that a friend told me a while back uh called edge city. And edge city is this concept that at any point in some part of the world

[04:37] there are a group of people that are living in the future in a specific function or specialty. And the way I think about this conference is we are all living in edge city for where for what will be consensus in the next six months to two years if you really think about the diffusion of this technology. So I’m super excited to be part of this with you all today. And now let’s hop into what’s going to happen. First of all, welcome to AI Engineer New York 2026 where AI engineering meets Wall

[05:08] Street. This is the conference for engineers and technical leaders building production AI across banking, hedge funds, fintech, insurance, and asset management. Over the next two days, we will hear from companies and leaders sparking discussion not only on models, agents, infra, dev tools, and evals, but then how they weave and shape the financial industry impacting hedge funds, investors, banks, insurance, fintech, and security. [snorts] Of

[05:39] course, as you all can tell, there’s a lot going on. Putting together a gathering like this requires a huge amount of effort and it could not be done without our sponsors. But before our sponsors, let’s all just give a huge shout out to the AIE team. What they do is incredible. [applause] Now, let’s give some flowers to the sponsors. First up, the presenting sponsor, Arise. Let’s give it up for Arise. [applause] Yeah, Arise.

[06:10] Next up, the platinum sponsors, Oracle, Sonar, Work OS, and Excel. Let’s give it up for them. [applause] Then we have our gold sponsors. If I had enough time, I’d rattle all of them off. And finally, the silver sponsors. But wait, there’s more. The supporting sponsors. Awesome. So, we are going to hop into uh the first keynote of the day. We have two amazing folks from Bridgewater who

[06:41] are in the weeds of production AI every single day. So, let’s give it up for them. Welcome, guys. [applause] >> Coming up next, we’re delighted to welcome two speakers from Anthropic. Please put your hands together for Belinda Neil, managing director of financial services, and Keon Shahab, applied AI architect.

[07:12] [laughter] Just waiting for our slides. There we go. Good morning, everyone. Uh, I’m Sam Green, um, team lead for applied AI at Bridgewwater Associates, and this is my colleague, Aaron Linsky. And today we’re here to talk to you about the vault, the data platform that we’ve built at Bridgewwater to turn unstructured data

[07:42] into a first class asset in our investment process. And as part of the talk this morning, we’d like to share three lessons that we’ve learned building the vault. The first is that humans and agents have very different needs from a data platform. And so you have to build for those different needs separately. The second is that the greatest impact occurs when a single tool can meet both of these sets of needs at the same time. And the third is that the real prize is when you can build the foundations needed to make

[08:13] agents a proactive participant in your investment process or whatever you’re doing with your with your your tools uh instead of a reactive uh reactive tool for your humans to use. Uh before I I dive deeper into talking about the vault, I wanted to start with some some background about Bridgewater. Over the last 50 years, Bridgewater has been in the constant pursuit of the world’s best understanding of how markets and economies work and turning that into a systematic encoding that we can use to stress test our logic over

[08:45] time. And what originally began as a set of if then rules on a yellow legal pad evolved into a continuous compounding process with humans at the center constantly looking for the next thing that’s changing in markets and more recently we’ve been working on building ya the artificial investment associate which puts a machine at the center of this continuous process across all these phases of evolution we’ve had a constant philosophy in mind which is that we want to be constantly looking at how the world is changing and what’s going on in

[09:17] the world. Noticing what dynamics are not yet encoded in our understanding and use that learning to improve and compound for the future. For most of Bridgewwater’s history, that meant building and overseeing time series models on structured data. And that structured data needed to be carefully built so that it could be safe for use in our research process and aligned to our internal ontology and world model so that we could get great leverage out of using the the data that

[09:48] we had built. With the emergence of language models, we had a huge new opportunity to engage with a with a much wider world of data. um you know news and research transcripts, policy documents and all of the internal conversation that was previously just in the ether. So the internal memos and meeting transcripts and debate happening inside the firm. We quickly realized that all of that data needed the exact same treatment to be fit for purpose. It needed to be carefully cleaned, governed, and made

[10:20] ready for use in both point in time research questions today and also our systematic study over time. And when we looked out at the landscape of data vendors and data platform providers, there was nothing that provided us with all of the control that we needed to build and maintain our data advantage. And so we built the vault which is our repository of external and internal unstructured data um and the platform that indexes

[10:50] organizes and makes all of it ready for use by our human investors and agents. Today, the vault has more than 100 million documents in it with thousands more added every day, uh, minuteby minute from 135 external sources and again growing all the time as well as all of the data from inside of Bridgewwater. And crucially, all that data is not just dumped on our investors desks. It is carefully aligned to our internal internal ontology with uh enrichments like the countries,

[11:21] concepts, markets and most importantly time period. discussed in the life a fairly basic representative investment question to an enterprise chat client. I asked how is AI infrastructure investment impacting the Korean Juan and do market participants expect this to continue? And as as you’re all I’m sure familiar with um the agent goes to the

[11:52] web and looks for resources it can draw on because I’ve explicitly asked it to go find u other people’s perspectives on the question and you can see it it zooms in and it finds 15 resources to draw on uh before it gives me back its answer. And when I when I zoomed in on the answer it gave back a couple things stood out to me. The first is that even though it found 15 relevant looking sources, it only picked one or two to answer to answer my question. And

[12:23] the second is down at the end of this response where the agent itself acknowledges that it hasn’t answered my question. It didn’t find enough documents on the open web to establish a market consensus and meet the meet the parameters that I laid out. When I double clicked even further, the problem got even worse. One of the notes that it primarily drew on to answer my question was published way back in July of 2026. Even though I asked this question and captured this answer just

[12:53] at the end of last week in early October in the age of AI and investing four 3 months is a massive amount of time. It’s not even close to good enough to draw uh draw on this resource to answer my question. When I ask this exact same query attached to the vault, something totally different happens. The first is that the connection to the vault helps to prompt the agent that it should look for a specific period of time when answering my question. So, it zooms in on October 1st to October 8th. It finds a much

[13:25] wider array of resources, 52 candidate documents that are relevant to the query over this specific period of time because of the vault’s much more significant corpus of content that’s relevant to investing questions. And when it ultimately answers my question, it draws on seven instead of only one or two and gives me back a rich answer that the agent is more confident is going to address my question. And so for us, this is the the big lesson from building the vault uh to

[13:56] kind of motivate the talk today, which is that it takes great data and the right connectors to make agents impactful. And I’m going to talk hand it over to Aaron now to talk about some of the product engineering takeaways from building the vault. Thanks, Sam. So, hi, I’m Aaron. I run engineering at Bridgewwater. I’m going to take us through a few of our learnings from building the vault over the past few years. I’m going to start with one that might seem obvious, but I still think it’s worth saying, which is search is hard,

[14:26] but it gets even harder if we’re designing for two different consumers. And in this case, we’re designing for humans and agents. Going to go over the difference here, starting with us. So, humans need precision and a high signal to noise ratio because we can only read so much. Even a fast reader manages about 300 words a minute. And personally, I’m much slower. Agents are a different kind of reader. They’re far less sensitive to precision. If the data is there, they’ll find it. And basically anything you hand to them

[14:58] will get attended to. They scale super quickly and they come and they consume about uh 100 times faster, 30,000 words per minute. And so we need to build vault for both of these. And when we’re thinking about the dimensions that matter, there are these five on on the board. Recall, precision, filtering, entitlements, and scale. Some of them matter to people, some matter more to agents, many to both. I’m going to go deep on three of these. Precision for

[15:29] people, scale for agents, and then filtering for both. So precision once we’d filled the vault our which was a heroic effort by our data and legal teams recall was no longer a pressing issue. However the number one complaint was vault search is bad. As the product owner it’s painful to hear that but my response was let’s benchmark it. And that’s what we did. We collected questions and found the best documents

[15:59] by hand including ones that looked helpful but weren’t. in all in total was about 200 examples and it took us less than a week. It was not fun or very glamorous but it was very helpful and after we ran it it was very clear search was bad. The key metric we were looking at is precision at 10 which is of the top 10 results how many are the right documents and we were hitting about 60%. So the people were right, it was bad, but now

[16:30] we had a way to measure all of the improvements. And here on the board are five of them. And by the time we got done with Agentic Search, we were up in the 90 95% uh recall at 10 or precision at 10. All right, so that was precision. Now on to filtering. Like anyone, we want the most relevant documents. But when we looked at the production traces, what we were seeing is that almost always there was some condition either as of a certain date or

[17:01] from a certain source or about a specific asset. And all of that requires advanced filtering and that’s where we ran into our first major performance issue. So I’m going to quickly go through this of a little bit technical here of there’s classically two ways to filter a vector database. Post filtering will use that vector index first and then filter the top results by metadata. It’s fast, but recall could be pretty low because the globally relevant results might not

[17:32] match your filters. On the other side, we have pre-filtering where we’ll filter first and then calculate distances for every one of those matches. The advantage there is that the recall is very good, but it can be very slow and we needed something in between. So that’s what led us to try and then ultimately switch to turbuffer. Their approach which they call native filtering looks only in the nearest clusters that contain matches and then scores just those. What you end up getting is something that’s fast like post filtering but with close to the

[18:04] same recall as pre-filtering. And lastly I’m going to talk about scale. Human scale for us is pretty pedestrian. 100 queries an hour. We have 300 users. they’re going to search, you know, every so often. It takes our users minutes to read the docs that they’re that they’re receiving. Agents, on the other hand, are a few orders of magnitude beyond that. Easily 100 plus queries a second. And agent swarms can hit thousands easily and they obviously will read, as

[18:34] I said earlier, will read docs in seconds. So, we need something that could scale as well. And again, turbuffer handled that easily, too. So, we were covering all five dimensions. I didn’t talk about entitlements, but I’ll be talking about that later today. Um, but we covered it all. It unlocked new workflows, but it didn’t change how our researchers worked. They still weren’t coming to Vault every morning. And that’s my second lesson that I want to share here is that no matter how amazing the tools are, we can’t just drop them on our

[19:05] investors desks and expect them to be used. We need to migrate their old habits into a a a new form. And so we looked at what they were already doing. Many of them were living in email. The research came straight from the brokers. They had subscribe lists. They had rules that filtered everything into folders. It worked. It was familiar. And they knew that they weren’t missing anything. So we had to build all of these features into the vault. That’s exactly what we did. Everything searchable. The

[19:36] subscribed lists became save searches and folders became save collections. It’s the same habits, just a new home. And once we had them there, we can open up new habits. So we can ask, they can ask questions across all the data, as Sam showed. They can follow dynamic feeds by topic. And they could hand those collections over to their agents to take further action. And that’s when we clearly had product market fit. And once we had that fit, the users wanted it everywhere. So we put it in chat. We made a phone app. It’s in Slack

[20:08] and their IDE. And of course, we availed all of that to the agents as well. Um, including a CLI because agents love CLIs. And so the main question here is, okay, so what does this enable? Simon’s going to talk about what we’re building right now, but first and foremost, it’s helping us to move around that research circle faster with our pocket analyst, which is our first AI analyst. It can do hund it can do hours. It can do hours of research in just a few minutes for a few dollars.

[20:39] And that’s relying on the vault. And then we’re expanding that now with the researcher, which is the next generation. It’s the same idea stretched across days or weeks. We’re also able to train custom models to more intelligently reason over the vaults data and use those together with other foundation models to feed systematic decision-m processes. The forecaster is our first one which produces AI generated macro relevant predictions. And then we al also have built investment signals from the vault

[21:10] turning unstructured data into structured tradable strategies. Now I’ll hand it to Sam to take us through vault’s latest capability. So, like I alluded to at the beginning of the talk, the real prize is when you can take agents from a reactive resource that can be ready to answer a human’s question and instead make them proactive participants, helping to steer your high value professionals towards the most important areas for their attention. And

[21:42] the way that we’re solving that problem is in an experience we’re calling the investor workbench where the agent is always on tracking what’s important to that investor and presenting them with the areas that are most in need of their attention. It looks like an experience like this that relies on the vault where a topic is proposed and several pieces of information are presented to the investor to decide whether they should dig deeper or ignore that topic entirely. You can see here the card that

[22:12] an investor sees in order to decide whether to dig in deeper into the same AI impact on currencies question that we looked at earlier in the talk. And the investor receives everything they need, an agentic summary if they want a quick scan across the agent’s findings. They also get the exact evidence that the agent was drawing on so they can assess for themselves what was leading to this recommendation. And if they choose to dig deeper, they have a direct connection to the research output from the analytical tools that Aaron was just describing. And when they

[22:44] dig deeper alongside the agent to look at the dynamics driving this question, the learnings are automatically captured, the results of their collaboration are automatically captured back in the vault. And so this for us is the key lesson. The vault enables compounding because it provides the right evidence, the right ex internal and external information at the fingertips of our investors and agents and it automatically captures the synthesis that they generate and puts it

[23:14] back in the corpus for the next turn. And that makes us go around the circle faster and better. And so when we think back to our the question we began with, what it takes to make an agent work is the right context and the right understanding of what’s going on in your world. And so our question for you is, does your AI know what’s going on in the world? And does it remember what your firm has learned about it? Because we are teaching ours too. And if these sounds like sound like an exciting challenge, we’d love to talk. Thank you.

[23:44] [applause] >> [music] >> And now to explore how serious organizations can accelerate innovation without compromising trust. Please welcome John Feminella, SVP of architecture at Two Sigma.

[24:23] Hey everyone. All right, I precariously balanced my water over there. Uh, my name is John Feminella. I work on AI architecture and engineering at Two Sigma, which is a hedge fund here in New York. Before I get too far into things, I have a legal disclaimer slide that I have to show you that says two things. One, I promise not to sell or market or offer you any securities at any point in this talk. And two, everything and this is my own opinion and not the opinion of two sigma. Right? Thanks for indulging me. If I don’t say those magic words,

[24:54] the 5G microchips implanted in me will explode. So that slide is a good example actually of how our industry is regulated. And as a regulated company with lots of controls, I think one thing that’s always interesting is to explore what happens when controls fail because that gives you a good idea about why the controls were there in the first place. And so I’d like to tell you a story about that by showing you another legal slide. After August 2020, a very interesting contract clause suddenly

[25:24] started showing up in a bunch of commercial loan agreements. And this clause essentially tries to prevent a certain scenario from happening. And it’s complicated, but I’ll explain it like this. Let’s say that you’re a lemonade stand business and you borrow money from a lender to capitalize your lemonade stand. And the bank that’s overseeing that transaction that’s in the middle between the borrower and the lender sends the lender all of the money that you owe in a catastrophic mistake. You’d probably be mad and want the money

[25:55] back, but the lender might also say, “No thanks. You paid us back and we’re all good, so we’d rather keep the money.” Something like this happened in August 2020. Revlon, the cosmetics company, had borrowed money under a big 2016 term loan. And that loan was split up into a bunch of pieces across 300 plus lenders, hedge funds, credit funds, CLLOs’s, other banks. And in the middle is City Bank, the administrative agent. Being the agent in this kind of transaction means that you’re performing the plumbing that connects the borrowers

[26:25] with the lenders and managing the life cycle of the loan. So in this transaction, Revlon pays City and then City pays the lenders. And City’s not lending its own money. It’s just in the middle moving people’s money around. So here’s the plan for August 11th, 2020. Revlon would pay about 8 million bucks of acred interest to both groups, and the lender’s principal would roll into this new facility. That’s an exchange of paper, not cash. So the remaining lender’s principal would stay put. And the idea here is that only interest

[26:56] should be going out. principles should not be moving at all. And the bank had a piece of internal processing software called Flex Cube. Isn’t that a fun enterprise software name? So in Flex Cube, the easiest way to do this kind of transaction is to pretend to record it like Revlon were paying off the entire loan and that triggers the correct interest payment calculations to everyone. You can probably guess what’s about to happen next. So, you’re supposed to send the principal portion to an internal wash account that you own

[27:26] as the bank so that it’s booked and recorded correctly, but it never leaves the bank’s perimeter. So, keep your eye in that wash account. What was supposed to happen is that the boxes labeled uh front and fund and principal should all include the wash account number and should all have a check box checked next to them. So, unfortunately, it turned out that was what needed to happen. But for various arcane reasons, uh, the boxes were not checked. And although Flex Cube pops up a warning notification that says, “Uh-oh, money’s about to

[27:57] leave the bank. Are you sure you want to do this?” That was correct. Money was supposed to leave the bank because they were making the interest payments. So, the three approvers who were supposed to approve that looked at it and said, “Yep, that’s the right thing that’s supposed to happen.” And although that warning notification popped up, the human operators carrying out the transaction overrode that. Remember, Revlon was making that interest payment. So the principal never went to the wash account and instead Flex Cube sent the entire outstanding principle of the loan to all of the 300 lenders about $900

[28:27] million instead of $8 million. So every lender got the amount that they would have been owed if Revlon had paid the loan in full. But Revlon didn’t want to pay off the loan. It wanted to hold on to its money. That was a great deal for the lenders because remember Revlon was in trouble at the time. So its loans weren’t trading at face value. And getting all your money back on a deal that you thought was only worth 60 cents on a dollar is a great deal for you. So they didn’t want to give the money back even after city called them and said, “Please, that was a mistake. Give us the money back.” And their argument was, “We shouldn’t have to give the money back

[28:58] because you paid us in full.” And that’s how loans work. You eventually pay them back. And just because you paid it back at a different time than you were supposed to doesn’t mean that we shouldn’t have to give it back now. And so to prevent that from happening, uh, commercial loan agreements everywhere started including a clause like that one. So what does a payment error at a bank have to do with AI agents? Well, the bank had this procedure. It had these controls and everybody did what they thought the right thing to do was. That’s the problem I want to talk about for the rest of this talk. Every day we’re giving real agents real autonomy

[29:28] over systems like Flex Cube. and how do we prevent accidents like that one from either from happening without locking everything down or just hoping we’ll get lucky that they won’t happen. So, here’s the crux of the issue. You can’t really know in advance what an agent will do, right? They’re these non-deterministic systems. Uh, and that sounds scary until you remember that humans are also non-deterministic systems and they’re going to make mistakes, too. And so most firms don’t choose to say,“Well, in order to reduce the risk of humans making a mistake, we’re going to like lock them in rooms and prevent them from talking to each other, and they’re all

[29:59] going to double check everybody else’s work, right? We allow them a certain amount of autonomy along with a certain amount of controls. So we give them boundaries, visibility, and we equip them with systems and controls that let them do their jobs effectively. So in this sort of model, safety and innovation are not opposite ends of a spectrum that you must trade off on. There are things that you can have at the same time. So, I think you can have your cake and eat it too. And when we were thinking about what controls we wanted to apply to agents, we also looked at some approaches that didn’t work for us. You don’t want to sandbox or lock down everything because a

[30:30] sandbox with no real access to systems is not is safe, but it’s not very interesting or useful if you let agents go wild and do whatever they want. That’s uh you know maybe powerful and freeing from a cognitive perspective, but the isolation is very weak there and there that approach is generally not suitable for highly regulated enterprises. And then if you just have policy documents that agents look at or that are part of your uh specification for the prompt, that’s also not very enforceable at runtime. You can’t guarantee that that will be part of the

[31:01] enforcement controls. So what did work for us was thinking about what mix of controls would get us both safety and innovation at the same time. So how do we provide boundaries and stop problems but don’t hinder folks from operating correctly? So, we have a number of these controls, but today I’ll talk about five of them. And when I say controls here, what I mean are the guard rails and shared capabilities that let teams move in ways that don’t hinder what they’re trying to do. And we want to we don’t want to reach some chasm that we need to

[31:32] cross to to let people get their work done before and then make everyone wait while we build a bridge to get there. So, these controls are composable. Each one does one job and then together they let us run agents with real autonomy at an appropriate level of safety. So the first problem is that agents were showing up everywhere. We have big teams with lots of agents running. We have small teams with a few. We have individual people running stuff in a uncontrolled way. And these come in every shape. Could be random chat bots.

[32:03] It could be NPC servers glued together in this Frankenstein hot pod. It could be cool notebook experiments. could be really useful web tools for folks, but it’s hard to answer when you look at that a few simple questions like who owns this? What tools does it have access to? What should it be doing? What should it not be doing? And if you can’t answer those kinds of questions, if you can’t govern them, then you can’t really also reuse that. So, you’re tempted to build multiple solutions to the same problem if you don’t know about what exists already. And then the firm can’t

[32:35] also govern those in any kind of legible way. So one thing that firms sometimes do here is add some kind of gate like don’t let anything run until everything is registered and approved and has gone through this very ownorous process and that sounds safe but if you look at what it does to the work every idea even some simple notebook experiment is going to wait in line behind something that’s really risky and we don’t um you know we don’t want to subject everybody who’s given a diversity of agents to exactly the same process. So most people are

[33:05] going to give up or they’ll just get pushed to some shadow IT less governed path that is um less visible and then we don’t get to see anything at all. So that’s what motivated the first control is an agent registry. You can’t govern you can’t see. So the agent registry makes agents legible and it registers, retrieves and discovers the key facts about agents that we want to know for any agent. Um, so those are things like which tools it declares, what endpoints it’s going to talk to, which product does it belong to, who owns it, and humans, other programs, other agents can

[33:37] then use the agent registry to decide what’s available at the firm, whether that’s useful for them, and to go use that as a source of truth for other questions. So, this doesn’t require extra effort on your part. It just happens when you use one of the firm’s approved agent building frameworks. It’s automatically registered. All that information is recorded there for you. And if you want to do a manual registration, you can certainly do that. So the second problem we have is that now that we’ve got all these agents doing all these things, we quickly notice that what they’re doing is really

[34:09] different. And that means [snorts] our agents carry really different risks, right? So a thing that summarizes Jira or linear tickets is really different than a production deployment agent that can touch a running system. And if we can use the same if we try to use the same review process to cover all of these agents then every agent is waiting in the same queue for weeks for human review. And if people are going to route around slow processes then we wind up in the same situation that we had before. So again you might be tempted to say the answer is something like really detailed

[34:40] heavy manual review by all of these different constituencies. Again, that feels safe, but now we’ve got a trivial summarizer waiting two months for the same signoffs as an agent that is touching production systems. And and most of the good Asian ideas, most of the ones that have value right away, start out as small experiments. And you don’t want those people to wait in the same line as the stuff that’s touching production right away. So the reviewers are drowning in these like lowrisk requests and the high-risisk ones have to share that attention pool. So, we

[35:10] don’t want to trade away that speed if we can help it. So, again, because not every agent needs the same review and because most agents are purpose-built rather than open-ended. And when I say open-ended here, you can imagine coding agents like pi or claw code when you open them and you start typing uh cloud code or pi doesn’t know what you’re about to ask. It doesn’t it doesn’t circumscribe its purpose in any particular way. But most of the agents that are deployed in enterprises do have very specific purposes. when you’re engaging with that agent, it’s to do something specific that’s well known and

[35:42] well understood. So, they have a very specific reason for existing and a very circumscribed purpose. And you can tell these agents apart from each other by looking at what they declare up front, their tools, um the endpoints they access, the controls that are applied to them, etc. So the third problem is that if you know about your agents and what they’re doing, you’ll quickly notice that many agents don’t talk to each other or sorry, they don’t talk to just one thing or in just one capacity. The more open-ended the agent is, the more it looks like a cloud code or pi, the more

[36:15] it can do a variety and a diversity of different things. Call an internal API, run a tool like a web search, that sort of thing. And [snorts] each one of those is a different opening a different door to a different kind of risk. And if you give an agent an entitlement for a role account, then it can do a lot more damage than something that’s just going to read a public web page, for example. So the question is not can this agent do X, but what’s the granularity that we need to solve for for the agent to act successfully. And again, one tempting answer is to

[36:46] kind of be heavy-handed here or to give every agent the same short allow list of stuff that’s safe to do and then block everything else. Uh, that’s safe, but it’s also useless. An agent that can’t uh that can’t search or can’t call an API or can’t do any of those things without asking somebody first can’t really do the work that it was intended for. And then teams either give up on those agents or they find a way around the wall and both outcomes are costly. So a wide kind of blanket block on everything trades away the innovation that we want to preserve and avoids

[37:18] making a real decision about risk. Um and as author John Shed wrote, “A ship and harbor is safe, but that is not what ships are for.” So the fix here is to let agents declare their purpose upfront and say what tools they’re going to use or what tools they need access to. Um, so in the second column here, we might say that a research summarizer is going to be allowed to use a web tool to access research, but for a release

[37:48] deployer agent, we’re not going to allow them to do that because they have no reason to use that tool. And so if they try to ask for it, they won’t get it by default. Um, so we don’t need to make this kind of decision for every tool. The agents just have to say which tools they want, right? and and you’re as the agent author, you’re in the best position to say, I need these four things out of the 500 that are available. So the way we need to enforce that is that when agents run in our managed environments, they look at the registry that we talked about before to look up

[38:20] what policies apply to it at initialization time. And that policy gets translated into enforcable statements like which endpoints are you allowed to access, which hosts are you allowed to access, uh what other types of resources are available or not available to you. And in this way, nobody’s writing a ticket every time they need to change the access. Nobody’s going to talk to it or some other group outside of your team. As long as you conform to the risk score that we talked about before and you’re in the agent registry, you’re you’re governed. You’re

[38:51] approved. So this is how we keep the cost to teams really low for deploying building running agents and the same control architecture works in a variety of settings. The next thing we noticed was that teams were building a ton of different ways to evaluate agents and every stack looks different and some teams don’t build anything at all. Sometimes you build like this really detailed stack for how your models work. Sometimes uh it’s sometimes there’s nothing. And I think in general we’d be upset if teams were not writing unit

[39:21] tests, right? And we consider evals to be kind of the same thing. If models are changing, that’s like a runtime dependency that your application has. And if your agent is going to change models, it doesn’t know without the eval to its outputs and to the quality of those outputs. So again, one tempting answer here is let’s have some kind of central evaluation methodology that waits for a full eval suite and a committee sign off. But now every like prompt tweak, every oneline change is

[39:51] going to sit in that same queue. So we don’t want to put more decisions on more reviewers for things like that. We we don’t want to trade away that iteration. So again, you wouldn’t ship software without unit tests. So agents need evaluations for the same reason. And we want to provide the stuff at the level of the firm that’s going to be the same for everybody. So team A writing evals, team B writing evals, they’re both going to have many of the same features. So we want to have one shared approach to how we do evals and have the shared approach be something that’s run by the firm and

[40:22] available to everybody for doing their evals. So that covers all the common parts of eval. All you’ve got to do is just write what’s true about your agent. Uh and finally, maybe you’ve had the experience of being asked to approve lots and lots of individual agent actions when there’s a human in the loop. So that’s fine at a small scale, but once you’re operating agents in parallel or in production, this becomes completely ownorous and review requests come in faster than anybody can be expected to approve them. And after the

[40:53] first few times of this happening, you succumb to review fatigue where you just see yes, yes, yes, yes, yes. and eventually you click yes on something that’s you know activated the nuclear bomb right so you don’t want to click yes by reflex but that’s going to happen inevitably and one recent example of this is uh earlier this year a director at an AI research lab told her open claw agent to suggest emails to delete from her inbox and then wait for her approval but her inbox was so large that eventually the agent compacted its contacts and lost the part that said wait for my approval and then it deleted hundreds of emails

[41:24] and didn’t stop when she told it to stop on her So again, you might be tempted here to make a human approve every action, but that’s not the right way to do it. A better approach is to let these independent conservative classifiers make decisions about routine calls and then send a person only the requests that are most important, the ones that are most likely to make a difference. If you’re saying yes 99.99999% of the time, then that’s probably just a rule that the agent should follow, not a request you need to ask the human form

[41:55] for. and the stuff that’s unclear or ambiguous or potentially dangerous, yes, surface that to a human or if it’s definitely just dangerous, deny it outright. So, this is a way to not have to do all the review work all the time. So, we want to take the same approach for both explicit uh when explicit rules apply, we want deterministic fast paths. When explicit rules don’t apply and there’s some ambiguity, we want a classifier to do that work instead. So, putting those five pieces back together, you create a registry. so every agent’s

[42:26] visible from the day it’s created. You score each agent so human review goes in the right spot. You run agents on guard rails so that they only touch what they need. You share evals and metrics so everybody is reaching the same bar without having to reinvent the wheel. And then finally, you govern your runtime to make sure that classification happens there and not somewhere else. So each of these controls works together. So I’ll leave you with one question. Why do cars have brakes? It’s not just so that you can stop. is so that you can go fast and stop safely. So, controls for

[42:57] our agents works the same way. Thank you very much. I’m John Finnell and I hope you had a good time. [applause] Here to help us understand the missing principles around code quality and finding a path through competing viewpoints. Please welcome Max Canat Alexander, principal software engineer

[43:28] at Capital 1 and author of code simplicity. All right. So, today I figured I’d just pick a nice uncontroversial topic that nobody has any opinions about, right? Nobody

[44:00] nobody’s said anything on the about on on this about social media, you know, and of course every take about this on social media is like really deeply nuanced, you know, like people have lots of like depth and like, you know, really big thoughts, you know, maybe there’s a little bit more to it than like yes or no. And you know, of course, if you ever ask a senior engineer a question, we always have the same answer to every question, every senior engineer’s favorite answer to every question, which is it depends. Now, that’s not a very helpful answer,

[44:32] though, frankly, because what does it depend on? So, let’s start with this. Why did code quality ever matter in the first place? Like, I see a lot of people be like, well, it made me feel good. That’s not really a sufficient justification. So, let’s see if we can inject some nuance into this conversation and help everybody at least be able to have a basis for reasoning about it while we’re discussing it. So, let’s see if we can make a framework here. And that’s what we’re going to try to do with this talk. Okay. So we’re going to start off with everything you want to ever accomplish with a piece of

[45:02] software uh depends on two factors and two factors alone and that is understanding and executing on that understanding. Whether that’s aligning a model, scaling a system, driving adoption, anything all software success is determined by these two factors. This is why we have things like debuggers and observability and evals and even tests. All those things actually are there to improve your understanding or ability to execute on that understanding. People think that they’re there for other reasons, but fundamentally they’re there for that reason. Everything we have ever done in the field of code quality is

[45:35] exclusively and only for these two things. It’s not for anything else. And that doesn’t have something to do with correctness or something else. It has to do only with these two things. Now, there’s two understandings that are the most important to have if you’re going to be a software engineer. There are other understandings to have about software if you’re going to be a product, if you’re going to be in sales. But if you’re a software engineer, there’s the two that are the most important. And the first is what is the behavior of the system? Like the concretely, not what does a doc say the behavior of the system is, but what is the actual behavior of the system? And the second one is how do I correctly and

[46:07] safely modify that behavior. Okay, on a very small system, if you want to understand what the system does, I just tell you what it does. It prints hello world. You say, I wanted to say hi world. So I say okay I will make it say hi world. Now there’s very little to understand about it other than purely what it does. That’s all of the understanding that you need. However any real software system is enormously complex. This is a real map of the

[46:37] codebase of chromium which is the open source project behind Chrome. And if you think about all of the different ways that these components can interact, they have essentially infinite possible behaviors. Like I could not describe to you in words the behavior of Chromium as a whole, as a system. However, what I can describe to you and as we all know, everybody’s been a software engineer for a while. I can describe to you components of the system. I can

[47:08] successfully describe to you how a component of the system behaves. So this is the URL parser, the actual functions and stuff for the URL parser of Chromium. It figures out all the different parts of the URL. And this is the whole reason that code exists. The whole reason that we have code at all in the first place is for structure. It because it what do I mean by that? Okay, so both of these two things on the left and on the right will print hello

[47:40] world if run on a Linux machine. However, on the left you can see that it is hello world. It has the identity and structure of hello world. On the right you just see a series of instructions with no particular identity, recognizable or understandable identity. It’s not a component. It’s just a bunch of instructions. While that’s understandable there, if that was millions or billions of lines of that, it would be much harder to gro. In the past, we’ve talked about things like readability or testability or things

[48:11] that seemed like human concepts about code. But what actually mattered the most always was that the system had some sort of understandable structure. So it’s the structure that actually matters. And when this modifies when this matters the most is when you want to modify the system. The second uh understanding that we talked about all modifications to a system carry two categories of risk. The first is that you will introduce some sort of problem. And a problem isn’t just a bug. It’s anything bad that could happen. Like your project could take

[48:43] much longer than you expect. Uh it could not behave in the way that you wanted it to for your users. The project could fail because you have budget overruns. Any kind of problem could happen from just you trying to go through the process of making this change. And the second is you could make it harder to make future changes. In particular, what that means is you could make it more likely to have future problems. You could increase future risk of the system. These two things are caused by un problems with understanding. So the first has to do with the difficulty

[49:15] of understanding the system in the first place and the second is you make the system harder to understand. I can reduce every post-mortem I have ever read for any incident to these two factors in one way or another. The the the production configuration was too hard to understand. Somebody made something impossible to understand. There were emergent properties of the system that were impossible to understand. Whatever point 2 feeds into one in a vicious cycle that compounds in a nonlinear

[49:46] fashion. So the difficulty of understanding does not grow linearly. It compounds over time. You will eventually reach a point and all systems eventually tend to reach this point where every modification involves some sort of problem. Uh and you know some some systems get to the point where like you can’t modify them at like if you think of like you know some of like your giant 100 million 500 million line mainframe code bases and that everything every change is some sort of problem. You know you’ll see it

[50:17] in organizational issues. You’ll see it all over the place. You’ll see it in timelines, whatever. And look, there’s a lot of arguments about maybe future models will fix this. Look, maybe they will. Maybe future models will have infinite ability to deal with complexity somehow. Uh, but we don’t have to discuss that today because I think models are doing something else really interesting right now. They are creating a new kind of software, a new category of software. This category has always existed, but it’s about to become a hund,000 times more common than any

[50:50] other form of software and that is disposable software. So what is that? Okay, so imagine a world in which the consequences of failure for your system are very minimal or non-existent. Imagine that there’s very few people that depend on it or and almost no other systems depend on that piece of software. Change management very minimal, non-existent. Imagine the cost of replacement went to near zero. You could replace the whole thing in hours or days

[51:22] and it had basically no cost of maintenance. In that world, code quality does not matter because it all of those things we were trying to prevent about the compounding risks over time don’t exist. Traditionally, we’ve always built durable software. You know, it lives for years. It’s depended on by millions or thousands of people. There’s huge consequences of failure, potentially business catastrophic consequences of

[51:53] failure. And it requires enormous maintenance. Most of the software engineers in the world spend most of their time maintaining these giant durable systems. I expect this to continue to exist. So, this is one of the areas where I think sometimes the conversation goes a little. Okay, durable systems will continue to probably be the most important systems in the world and there will be probably more of them. But the most numerous systems

[52:24] will be disposable software. They will be replaceable in hours. They will be dependent on by a few or change management just won’t matter. And look, if it doesn’t work, you we’ll give everybody agents. They’ll make a version of it themselves. You know, maintenance will be unimportant or nearly free. Don’t like the calculator on your OS? Make your own. Want to plan a party for your kids? Write a party planner software just for that one party. Throw it away. Code quality doesn’t matter. Nobody cares. In the future, we will apply engineering

[52:56] rigor to the degree of disposability of the software. On the left, nothing none of our practices of engineering rigor matter at all. on the right. All the practices of engineering that we have built up over the last many decades mattered greatly. We can determine where you are on this scale by those four factors that I have been talking about. Consequences, cost of replacement, dependencies, and cost of maintenance. If they’re all low, it’s disposable software. If they’re all high, it’s durable software. And look, any person

[53:28] who’s written software for a long time knows you should heir on the side of it being durable. You should air on these all being higher than you expect them to be. But there’s also a new thing you can do in the world. You can make software disposable. So like what what does that involve? Well, come up with better isolated environments, right? So hey, you can only deploy to this environment that has access to only your data. No customer data, no personally identifiable information, whatever. You can enforce

[54:00] independence. You can say okay no inbound API calls from other production systems are allowed to this system in this environment right and so everything deployed to that environment is disposable redundancy you can have an old clunky backup system that is like hard to use and then like look if people want to vibe code their own like more efficient front ends you let them vibe code their own more efficient frontends because there is an old durable clunky backup system that they can use if their you know crappy little vibe coded thing fails which which it will fail right that’s fine but it doesn’t matter if it

[54:30] fails Uh, and you can limit scope just like I talked about, right? It’s just a calculator for this one. It just we could do here and talk about ways of increasing disposability. In fact, I think this is a whole new discipline of software engineering. not to think about how we improve the rigor of durable systems, but how do we take our systems and how do we encourage disposability or allow more disposability, allow people to just throw these things away.

[55:02] Interesting thought. Now, I want to re-emphasize that durable software engineering is not going away because this is the biggest confusion that I see on social media today. In fact, I believe the absolute amount of durable software in the world will increase because AI coding tools make it easier and easier to make more durable software. And another important thing to understand is that disposable and durable are not black and white. There’s a spectrum like I showed before. But

[55:33] that spectrum, what changes across the spectrum is how much effort you’re going to put into engineering rigor. Okay? And that’s both immediate effort and effort over time. just like we’ve always talked about for software. However, what you want to do and I think what you want to care about the most is reducing the cost of effort. Reducing the cost of rigor. Like if rigor is cheaper, if it’s the e the easier and easier you make it to be rigger, the less you have to worry about

[56:03] where you are on the scale. So this is another approach you can take. If you change your mind, it’s much easier to like you’re like, “Oh, I thought this was going to be disposable and now it needs to be durable.” The cheaper you make it to make it durable. The easier it is to change your mind or to be wrong because you’re never going to be 100% right all the time on that estimate. So that involves a different set of practices that are not engineering rigor themselves, but that are about how to decrease the cost of engineering rigor.

[56:34] Now, I could talk about this for hours. I have spent a tremendous amount of my career doing this. Uh I don’t have 10 hours. I have about five minutes left on that timer. So I’ll tell I’ll talk about what I can. Okay, let’s talk about standardization. Why do we do standardization? People are like, well, I don’t know because the boss said so. Well, now we do standardization because it removes possibilities. If you don’t have any PHP in your system, you don’t have to figure out what are all the llinters for PHP, what

[57:04] are all the practices, what are all the security holes I have to fix. You just eliminate possibilities through standardization and it just reduces the cost of rigor. Uh same thing with like frameworks like why don’t you want to have every front-end framework or every backend framework in the in existence? Because it makes rigger more expensive. Like yes, rigor is still possible. Yes, you could still have the agent code up all your tools, but you’d have to do it every single time. uh you know pro protocols why do you want to have standardized RPC protocols all the same thing standards are all for this reason okay uh what I call inworkflow tooling

[57:36] so inworkflow tooling is tooling that just occurs the programmer doesn’t have to choose to run it they don’t have to understand how it runs it just happens if it’s there it feels and seems free and it is reliable reliability is very very important like it doesn’t have a ton of false positives it’s fast it just happens and the more that’s true like you can apply it to your disposable too. So, this is not just about like, hey, how do we do better testing? How do you make it so that nobody has to think

[58:08] about how to do better testing? How do you make it so that every test is fast and deterministic without anybody having to be a deep expert in testing? There’s a ton of work that you have to put into test infrastructure to make that possible. For example, you know, one of the great dreams that I’ve always had as a as a test owner is that everybody would provide in-memory fake versions of their services and I could just run those in-memory fake versions of their services. Guess what? The coding agent can do that. So, you can just do that now, right? But you have to choose to do it and make it available to everybody.

[58:40] And another thing is look, maximum strictness. You just turn the strictness up everywhere. You turn you set all your lint rules to maximum. You you never compromise on anything. And it just eliminates, it’s very similar to standardization. It eliminates a ton of conversations. Sometimes the llinter is wrong. Like as long as the false positive rate is relatively low and it doesn’t have catastrophic consequences, it doesn’t matter because all of a sudden there’s a bunch of future lint errors or future issues that you don’t have to deal with. Like ask anybody who’s been like, “Oh, I suddenly want to turn on my llinter in this million line codebase.” And they’re like, “Oh, wow.

[59:10] Now here’s my 100,000line change that I need to make.” Right? Much easier to just do that up front and have it on for everybody. Now look, like I said, I could literally stand here and talk to you about this straight for 10 hours. There is much much more you can do here. This is just a few areas, but also a whole area of software engineering discipline that you can apply on the other axis. So this lets us now answer our question. Not just it depends, but yes or no. So does code quality even matter for disposable software? No.

[59:44] for durable software. Yes. And we get to answer a third and even more interesting question which is does it have to be expensive? No. Thank you very much. [applause] [music]

[1:00:16] As AI takes on more of the building, what does it mean to be an engineer? Here to explore why defining success may become the essential skill, please welcome Aparna Dina Kuran, co-founder and chief product officer at Arise AI. Hey, New York. Awesome. Well, welcome to

[1:00:48] AI Engineer. Um, uh, thought given we’re at AI Engineer New York, we’d kind of revisit the question of what does an AI engineer do? Feel like every year we have an idea of what an AI engineer does and that definition kind of changes. Um, and as I was putting this talk together, it was super timely because Karpathi actually just tweeted something this weekend where he kind of he kind of talks about this growing gap between basically folks at the frontier who are

[1:01:20] running thousands of agents and swarms of always on agents. And he he really kind of drops this funnel where 6 billion plus users have maybe touched or interfaced with an LLM. 1 to two billion are maybe like casual free tier users. 20 million are professionals who have maybe started using it for more you taking some piece of work that would have taken weeks down to to days. But really those at the frontier labs are which is a super small percentage. It’s

[1:01:50] like 5,000 users uh are the ones who are running thousands and thousands of agents at once. And as I look at this, it really is I mean he’s kind of dropped a bit of the funnel. I mean the first question anyone looks at this is that where am I on this? And you know he’s kind of drawn out a bit of a road map of how does everyone get to in the next couple of years one of those 5,000 users who are running thousands of agents. And this has been happening I’d say for for

[1:02:21] a couple of decades now where the abstraction layer has gotten higher and higher. I mean definitely faster in the last couple of years but we’ve gone from engineers writing higher level abstraction languages to I mean just copy pasting code using local agents to using cloud agents to really the expectation now is how how do all of us start running a team of agents or factories of agents internally and build toward that and what this has led to is

[1:02:54] essentially what is a then and now of what an AI engineer is. And this is this is this is a bit uh I I think of a of a road map for some, but I think internally this is what we’ve already started to kind of push towards. As an AI engineer, your job’s no longer to just write the feature, write an AI feature. It’s about how do you build the loop to write that feature. It’s no longer about, you know, just reading the diff and actually doing code review. It’s actually how do you set up systems and agents to do the code reviews and

[1:03:25] how do you write evals to actually do the non-deterministic um to review those non-deterministic tasks. It’s actually no longer even about just setting up metrics and and software kind of telemetry, but it’s actually how do you have agents go through and read the observability data and have agents actually consume that telemetry to find patterns. And [snorts] so this loop that we’ve kind of been talking about which is the build eval ship you monitor you improve it. Well the AI engineer is now actually

[1:03:55] responsible not just for doing each of those steps but how do you build the loop that does that actually does each of those steps and at arise one of the things we’ve rolled out in our product and I’m going to talk about a bit of what we’ve learned in building this is we built signal to actually run this loop for AI engineers. What signal does is that signal actually looks at all of the traces. It reads the telemetry. It identifies patterns in that telemetry and it can actually put up a fix or a PR

[1:04:26] if it has access to the repo. And signal signal is an always on agent. So this is an example of how signal starts but it actually starts off by just reading the traces. Super simple example, but it goes through reads um you all this configurable but an a certain volume of traces that came in in some cadence it reads it and then the goal is to actually identify issues from that telemetry data. It has to keep track of

[1:04:57] issues that it’s previously seen. So we have to consider the memory of did it see something before that it thought was an issue. Did something seem like an issue, but it wasn’t actually captured? And now, as it collects more data, it actually thinks it’s much more of a critical critical issue. And so, Signal actually starts off by reading the traces to identify problems. And so, one of the first things that that we realized was that the future of who’s actually consuming telemetry data has

[1:05:28] really changed. It’s no longer about humans consuming telemetry data. It’s not even about humans consuming it and agents kind of taking on the task, but it really is how do you set up your telemetry data so that agents are the primary consumers of that data. And what that does is that that observability data can become the trigger for actually running and triggering these always on agents. And so the first thing that if you’re building a team of you know a factory of really always on agents is

[1:05:59] what triggers these agents to wake up or start and there can be a variety of triggers for signal for us it’s you know it’s configurable to run on an ongoing cadence. So every 3 hours 6 hours go pull the last you know x amount of traces read them identify problems. It can also be triggered by events. So, Slack messages um if some user complains about something, it can be a metricbased trigger, but these are essentially

[1:06:30] triggers to kick up the agent actually starting. Once the agent actually starts, we have to spend some time figuring out, well, what is what does an agent run actually look like? For us, we actually pull in all of the context of the traces, um any additional thirdparty data. So we allow collecting to APM logs, APM metrics, um but all of the third party telemetry data that we want to pull in. Um access to the repo, um access to the actual um

[1:07:03] the the access to any keys that are needed to actually run this agent. But all of this information is um put inside of a sandbox. And this is actually what’s started up every time the agent wakes up. And so the agent’s triggered. We build a sandbox. We put everything that we need inside of that sandbox. There’s a proxy. The only way to get information in and out of the sandbox is by this single proxy. And everything that happens inside of that sandbox is actually already getting traced. And

[1:07:34] every output, so the issues that are generated and created are all getting saved to some kind of memory. And so this happens every single time the agent actually runs. Every time the agent finishes running, so it sweeped through all of the traces, um, it either found something or it didn’t, there’s what actually stays and what actually gets thrown away. What stays is that if it found any issues, all of the output is actually saved off in some kind of memory so that the next time an agent

[1:08:05] gets spun up, it doesn’t have to start from ground zero. It has a history of what are the issues that it actually found. Um the agents are traced. So all of the telemetry data of what the agent called um you know if it actually put up a PR, all of those things are actually traced. And any skills that it may have learned while actually doing a run can also get saved to the actual repo. But the things that go away is the sandbox gets torn down. Any credentials um you know obviously get get removed. um the

[1:08:38] repo access is removed and so all of the stuff that doesn’t need to be saved kind of gets torn down after the run of signal and we’ve designed signal in a way to actually keep this agent configure uh durable. So that means that either if the s if the sandbox fails or if the harness fails then it shouldn’t have to start everything from scratch in the middle of the run. it should actually just be able to pick up from the step that it failed and all of the state

[1:09:09] so-called is kind of saved off in kind of a a a memory outside of the sandbox. And so we’ve designed this to actually be a very durable agent so that if it fails, it can spin it back up. Um you can launch a new sandbox, launch a new harness to kind of pick back up where it started. So all of this is essentially the underpinnings of how we built signal to run. Every single run agent gets triggered, agent gets started, loaded with all the context, the evidence, uh it sweeps through the telemetry data, it

[1:09:41] either finds something or it doesn’t. All of that gets saved to memory. If something fails in the middle, the agent can get reset up. And we built Signal to also be, you know, agnostic of the model or the harness. So today, Signal supports not just cloud code, which is what we started with, but it also supports cursor and codecs. And the goal is to actually support all of the the major even the open source harnesses out there. Um, and signal actually also supports um multiple uh will support

[1:10:11] kind of multiple models. So even if you’re using cloud code, you can pick any of the models inside the anthropic family. Um, and this is really important to us because one, it’s an awesome way for us to evaluate the quality of the agent. Um, every time we spin it up, it helps us control costs. So we can see you know as we use more powerful models the better quality maybe the PRs are but can we reduce the quality of the the you know can we reduce the cost and actually

[1:10:42] still maintain the rigor um and maintain the quality of issues that are actually detected by signal. So this is something we deeply thought about from from first principles when we were designing signal and this is actually a pretty good segue into what does an AI engineer need to do? Well, an AI engineer really needs to kind of learn how to write eval. And so we actually every time Signal runs, Signal finds an issue, it puts up a PR. Well, there’s eval on top of the agent to test that PR. Um,

[1:11:14] and an eval can be as simple as um, you know, testing something as part of your development workflow. You have a data set. It can be a simple prompt um with with outputs that you’re testing to make sure that there’s no regressions. Um, but these evals can also they need to be kind of aligned with human judgment. And I’d argue that this is actually probably where an AI engineer should be spending a lot of their time as they’re building the system to actually run the loop. They

[1:11:45] should be actually spending time looking at the traces with their agents, identifying what the common errors are. Um, and there’s a lot of skills. I think I was hearing Lance yesterday talk about the cloud skill to build evals. We have a skill with Arise um evaluator to actually help you build and write evals as well as align those eval judgment. But this is probably where the shift to defining what is good becomes really really important for an AI engineer to actually do. And for a lot

[1:12:17] of teams I I think we speak with and we work with their question becomes well how do I trust the evaluator and do I do I really trust that the eval is um you know is going to catch or you know how do I trust that it’s as good as my judgment? And I’d say what we spend a lot of our own time doing for our own products is that we actually evaluate the evaluators. Um, we spend a decent amount of time on actually building these data sets, golden truth

[1:12:48] data sets. We run evals, verify them against the human output and then try to align to make sure that the judge actually agrees with the human um and and they’re in agreement before we actually ship out uh a new evaluator. And these eval can then be used both in an offline testing as well as in an online testing manner. Um, and this this is probably what I would say as an AI engineer is more and more of what the job is becoming.

[1:13:20] Um, and so what I’m going to leave you guys with is as an AI engineer, you’ve built this agent. You built this agent to actually run be always on. You run eval before you actually ship it into production, you can ship it. And then once it goes into production, the goal is to actually trace everything. And tracing everything now means not just tracing the agents, but also tracing the coding agents behind the agents that built this. So you can trace um cloud

[1:13:53] code, you can trace cursor, you can trace codecs, but all these coding agents can be traced. So you can understand what happened um in the factory of agents that you all are building. And then these agents that all the traces can then also be evaluated online. So there’s an offline evaluation when you’re actually testing what your what a new change is. But as it goes into production, these become your online eval that you’re running on top of the telemetry data. This for us ends

[1:14:23] up becoming the new data that then gets pulled back into the agents to read the telemetry data, the eval surface up kind of problems inside of the traces. So the the system really becomes how do you go from collect data, eval that data, run agents on top of it so that you can find problems and figure out where the gaps are to actually improve improve your systems. So if I go back to kind of the question that we started this whole

[1:14:54] thing with, it’s what does an AI engineer do? I mean the gap between I think there’s a pretty big gap between what’s happening in the labs today and what’s happening with a lot of businesses and some of it could just be the data inside of businesses are a lot more messy than what is very constrained and testable inside of a lab but AI engineers are kind of the the role to close that gap and I think it really starts with tracing everything tracing the agents you’re actually building

[1:15:24] running eval so being able to learn how to test these test these products that we’re really building and then how do you build a system so that agents can actually improve um from the telemetry that’s actually being collected um so that you’re no longer just building individual features but you’re actually building the system to improve um to improve your products. Um if you want to learn more come check out we have a booth um you can check out Signal learn more but thank you so much for listening to us. [applause]

[1:15:54] [music] The current program has finished its [music] run. Please collect your belongings and proceed through the main doors for your next scheduled task. Heat. Heat.

[1:16:55] Heat. Heat. Heat. Heat.

[1:17:27] Heat. Heat.

[1:18:14] >> [music] >> Heat. Heat. Heat. Hey, Heat. Heat.

[1:19:02] Heat. Heat. Heat.

[1:19:42] Heat. Heat.

[1:20:20] Heat Heat. Heat. Heat. Heat.

[1:21:20] Heat. Heat. Heat. Heat.

[1:22:04] Heat. Heat.

[1:22:37] Heat. Hey, heat. Hey, heat. Heat. Heat. Heat. Heat.

[1:23:40] Heat. Heat. Heat. Heat.

[1:24:35] Heat

[1:25:07] I Heat. Heat.

[1:25:54] Heat. Heat. Heat. Heat. Heat. Heat.

[1:26:44] Heat. Heat. [music] Heat.

[1:27:20] Heat. Heat. Heat.

[1:28:17] Heat All right. Thank you guys. Uh my name is

[1:28:47] I’m part of the well Fargo team. I’m leading the Frank AI modeling organization there. And I’m going to show you the work we’ve been doing lastly on building a our first foundation model u Wells Fargo foundation model. So I explain why we did that, how we did it and what we accomplish in doing so. So so first foundational model it doesn’t necessarily need to be language based. I mean we all playing with uh cloud and chat GPT and others they all language

[1:29:18] based foundational models in financial services. Uh we also have language of course uh from a structure unstructured representation data but we have also have a lot of structural representation. A lot of these data is tabular data. We have a lot of information from our customers. uh we have information in investment banking, consumer banking and all of these data is data that we have in in Wells Fargo and all big financial organizations have too and uh we want to take benefit of all of these huge amount

[1:29:50] of data that we have and it’s not like you just take it and put it in a in a language model and get the best of it. Of course, you can get a lot of benefit out of it, but it’s not necessarily the best way to do it. So, so what we decided to do is to look at the data we have all the transactions all the customer transactions that they’re doing with their debit card, credit card, digital check, all of those coming from many different channels and see if we can build a foundation model that we can

[1:30:21] use and fine-tune for downstream task like credit scoring or that you can use it for fraud detection, antiming, do marketing. So how we can build one backbone that you can use and streamline across downstream task. So now you’re moving from many models very siloed across different organizations in really one backbone that every organization can just reuse because you learn the representations of customers transactions at at scale. So that’s the

[1:30:52] intent and just spoiler alert you may say hey that’s tabular data why do you just don’t use ag boost and the usual suspect we did that this is the model we had in production and but the model I’m going to show you is something that get that beat xg boost uh even from a latency perspective but also from a from a fraud detections we get much better false uh um reduction of false positive and better detection rate so it was a very good lesson learned in term of

[1:31:22] having better model using foundation model and to foundation model I mean transformer blocks and that that’s that’s what we build so uh so we have as I mentioned billion of transactions uh on a monthly basis um our customers interacting with their debit credit card and they do check and they do different sort of transactions and the the question is really how we can use this informations at at scale and not for one and every single downstream task task. So I’m going to cover a bit of the data,

[1:31:54] the representations, the architecture that we use, uh how that what the result we get and the lesson we learned in building this. All right. So I mean left hand side language foundational model they’re processing language tokens and then the the goal is to learn a representation that going to predict the next token and then you have uh yeah supervised fine tuning and then you do LHF LRVR and all of the great uh post training process to get uh better at the

[1:32:26] task that you want to right and that’s for languages that’s great uh but what if your data is a very much more specialize in term of representation. So that’s where we build this transaction foundation model. So instead of having languages as the base, the base is now a transactions transaction from our customers and you still try to predict the next thing and here the next thing is the next transaction or it’s the next token in the transaction using all of the channel that you have. Uh but that’s

[1:32:57] not the end goal. I mean the similarly to language model where you try to predict the next token that’s not the end of the story right you learn a representation and then you use that representation and then you you you fine-tune it and you post train it for any other task right so it could be classification task for languages but in our context for transaction foundation model it could be used for uh credit line increase could be used for doing fraud detections and flagging bad actors from an anti-modeling perspective and the goal is to learn these this uh

[1:33:29] relationship between transactions over time and transactions across customers. That’s really the intent. So the intent number one is you do pre-train from scratch. I’m say again because people sometime confused we pre-train transformer blocks uh at scale from scratch using our uh transaction data. So the rate there’s zero weight that we use from open weights. we just use the architecture and then we we pre-train it from scratch using our GPU cluster and then we train it for couple of days and

[1:34:01] and weeks and and then you do the the downstream task of uh of post training but the goal here and you pre-train it for predicting the next token or the next transactions and you you try to to do this right you try to predict the next the next p pattern of the customer but that’s not the intent the intent is to do the downstream task later on and in term of scale Uh I mean we we operate at a large scale. So we have billions of transactions, a million of accounts, uh

[1:34:31] hundreds of transactions per clients on a monthly basis interacting with their debit card, credit card or doing check and the five main dimensions we look at is really who is doing I mean who is processing and who is asking on who is providing a service. So will it the customer or the merchant and the what? So I mean what what do we what do we buy what do we transact and how so which channel is it credit is it debit is it

[1:35:01] digital when is it happening and where is it happening and all of those they basically breaking down in 100 of features and if you look at the existing model we have in productions there’s a lot of I mean people that been build those model in similar organizations may uh may understand that they build a lot of very artcrafted handcrafted engineering feature engineering effort on that and that’s required a lot and a lot of time. So we step back and look at really the raw features we need not the

[1:35:33] one that been really pre-built and postbuilt for doing the don’t stream task but try to understand which raw features and we ended up with basically 100 features even at the end of the day we had thousand of them but we tried to find which ones are really the raw information you need and then we let the architecture the transformer blocks to figure out the relationship between those core features And uh as you can see we do have a yeah a bunch of

[1:36:03] features on those five dimensions and the vocabulary is very unique to the financial services setup. So and that’s the reason why I mean we didn’t really use uh existing pre-trained model uh because those the vocary that we use is very very specific to the work that you want to do and even if you merge u well all digital and checking and uh saving and um all of those sort of transactions

[1:36:34] even if you merge all of those you still end up with a very limited number of features and characteristics. So at that scale then the question is well how how you work with that. So so we started everything is tabular data. I mean there’s no secret it’s tabular data and then the goal is to understand how you going to capture the vocabulary because you do have numerical values you have categorical values you have I mean you have information like zip code. Do you encode each and every zip code in a token? Does it make sense? So there’s a

[1:37:05] lot of effort you need to push in understanding the vocabulary that you need and the vocabulary that you want also to scale because at the training if you have a too huge vocabulary it would be kind of messy uh to train such such a model with a vocabulary which is far far too big. So so there’s a lot of effort in understanding this uh value to token. So which information do you encode in a token and then you have the token to ID the tokenizations and then the embedding lookup. So then when we have a transaction coming up, you do have the

[1:37:36] vocabulary. So it’s a basically it’s a lookup and aligning a transactions and all the characteristics of that transactions to to a token and an ID and then an embedding. So just to give you number well some numbers. So we have yeah quantitative, qualitative, categorical uh of different kind right so categories with only eight types some with much bigger types. uh you have transaction amount which is a big deal. You have the delta time between transaction. So you have

[1:38:07] anything related to IP address postal code just to give you example of uh of variety and ethogenity of each and every uh characteristic could be encoded in a binary token or could be encoded in a much larger number of tokens. And even if you look at the bit that the zip code I mean you have a much larger number of zip code in the in in the US than those 2800 but you you have fancier well you have much better way to structure how you’re going to uh regroup zip code

[1:38:38] based on distributions for instance. So uh architecture. So so here just um what we so we use the the chinchilla um well mathematics behind the to define how we build it right I mean initially because we we had no clue how it’s going to work in the tabular space even though there are existing uh well well open weights and open solutions for doing um tabular data foundation models. Uh so we we we started from what they learned and

[1:39:10] adapted to what we needed to do and that gives you an example of invading dimensions number of decoder blocks we used and um all of the the recipe from a from an architecture perspective. Um so we have and as you can see we’re not trying to build a trillion parameters model. We don’t try to compete with any of the uh the the leaders in the language models because we working really and focusing on transactions right transactions foundation models at

[1:39:40] billion level and one one billion is because that the model that give us uh that was the well kind of the smallest and give us the highest boost and now we working on a on the next versions at 11 billion but that’s good enough to to give a lot of uh ai uh from a false positive reductions for don’t stream task like for detections and detection unit detection rate. So and the and the type of architecture it’s the decoder only architecture and that’s basically

[1:40:12] for predicting the next the next token or the next transactions and that’s really the pre-training. So uh so here we initially used 20 times the number of parameters to define the number of tokens we might need. We ended up actually 10 times factor factor than that. So by doing a few experimentations we needed much more um much more tokens per parameters. I mean this is this kind of the initial experimentation we did. Um so I’ll pass on this because this is the the usual suspect from a uh objective functions a causal language uh

[1:40:44] modeling and mass language modeling type of uh um uh optimization work and and then from an architecture perspective nothing really I mean fancy here the again the most complex part was really the tokenization and then and then adapted and doing the pre-training and then how you do the finetuning. So if I would say the the recipe or the secret source is really how you do the tokenization and how you’re going to do the post the post training but anything from a training perspective it’s uh it the question is

[1:41:17] just how many how many transaction you’re going to put in your in your context or in your story for for doing the training and evaluation perlexity based accuracy accuracy dashboard on downstream task that’s that’s the you expect and uh So yeah, so use mix precision distributed data parallel um maximize macro batch size u get faster convergence u uh yeah using muon uh rope

[1:41:47] uh usual and memory efficiency flash attention activation checkpointing I mean here there’s nothing really new it just we use the the the advices from the from the best and from the the one that build even much bigger models So uh I’ll pass on this one. Time is short but I wanted to spend some time uh yeah on the results. So um yeah. So the when you build this foundation that foundation is

[1:42:17] really is is of is really is is only a backbone is something you can use for downstream task and uh the downstream task was to do fraud classification. So you have a transactions and then you try to predict if that transaction is going to be fraudulent. So in the model we have in production it’s an NEG boost model and it’s trained on large amount of transactions which is fraudulent or non-fraudulent. And the missing pieces that was the uh relationship between

[1:42:48] whatever transaction you try to predict to try to classify and the relationship with this transaction with all of the past transactions and that information is kind of gone when you use a njib boost model uh unless you encode it in a very hard way which is which is not so easy. But if you use transformer architectures, you do have this nice uh attentions from a from transactions to past transactions and that’s basically what help uh this what we think this is what really help pushing the fraud

[1:43:18] detection rate much higher but at the end of the day the downstream task was to say here’s the sequence of transactions I have someone just using the debit card is that transaction uh fraudulent with respect of all historical information and uh and That’s that’s exactly what you put in in at inference time when you try to do the prediction. So uh so that’s the yeah architecture. So nothing really fancier. You just need to have the good uh engineering in place to do um less than

[1:43:51] 250 milliseconds for doing the processes the processing because the the the decline need to happen within that time frame. But it’s it’s it’s we were well 10 times slower than that from a latency perspective. So it was all good and uh and just in term of uh final result we get. So the main metrics and those metrics relate right away to uh to dollar to cost well to to savings for the firm. So it’s detection rate and false positive rate. Of course you can

[1:44:22] detect much higher but uh in many cases sometimes you get much more false positive and in this case we managed to get we flag more fraudulent act activities and we even reduce the false positive. So that that was a big win. That was a big win because at the end of the day if you decline a a transaction which is not fraudulent uh then that person is going to call there’s an operation cost associated to it. you lose the transaction related to that that non-fraudulent action. So it’s a it’s a very it’s a very well something

[1:44:56] that you you don’t really want to happen. So so again that’s this that’s compared to the state-of-the-art of GG boost model using food detection. So it’s it’s basically huge it’s millions of uh dollar savings. Uh so it’s a it’s a very big boost. So just to finish up uh on that slide. So um so that foundational model has been built on billions of transactions from uh Wells Fargo customers. Uh that’s

[1:45:28] number one. It’s uh it’s pre-trained from scratch. So we don’t pre-train from any open weight existing model. We use existing architecture but the way the zero rate we pre-training on couple of days. I mean we did in a couple of weeks initially but then that’s pre-trained and then you and then when it’s pre-trained it’s pretty good in predicting the next transaction then when you’re done with that then you can use it for many downstream task we did it for fraud detection now we investigating for credit line increase investigating for antimony laundering

[1:45:59] investigating for marketing so now the same foundation is used across different organizations uh within Wells Fargo and um yeah thank you for having me and thank Thank you. [applause]

[1:46:38] Heat. Heat. Heat. Heat.

[1:48:23] Heat. Heat.

[1:48:59] Hi everyone, I’m

[1:49:29] more step by step. about me. I’m not an engineer. I spend my day sure.

[1:50:14] This comes from the platform too. We work in a regular start and now we use

[1:50:47] But I was still doing all of the work manually. I was just doing it a little bit faster. Here’s what we figured. I’m not writing. This is it.

[1:51:40] I want to be with you.

[1:53:30] All right. Good morning everybody. Thank you for joining us today. Um, it is such an honor to be sharing this stage with so many great speakers. Um, so yeah, let’s get right into it. My name is Aman. Uh, I lead AI at Arca. Um, and today I’m going to talk to you about Arca’s long horizon agents that run our business. ARCA is an AI native services firm. We provide our clients with financial services like financial planning, tax

[1:54:00] planning, asset management, investment advice. Um, and we serve a range of clients. Some of them are like technology executives that um have amassed a lot of wealth and need a real plan to retire early, but also that family in New Hampshire that made their first million dollars and and want to buy that house finally. Um, I said we were AI native. There’s a lots of there’s lots of definitions of this this term these days very overused but what we mean by AI native is

[1:54:34] that agents run our business not that they assist the business from some co-pilot corner they they execute the decisions that shape the outcomes that our business has for our clients work in this industry it’s interesting to know what it looks like in financial services the work is more long horizon and less long running. And what I mean by that is this is less agents grinding tokens for like hours or or days on end,

[1:55:05] right? This is more one client goal that spans 10 days. It’s very stop start. There’s many actors in between, many decision points, many handoffs. Um and ultimately that goal lands like 10 days later. That is the kind of work that that we are working on. And so here’s an example. Jane’s our client, fairly wealthy, but has a big tax bill. Oh, um has a big tax bill in u uh in in April 15th, right? So, we’re going to

[1:55:37] help Jane figure out what is the most tax optimal way for this cash to be to be raised to pay the tax bill. So there’s the adviser that will do all of the the statement analysis and the analysis of of how to make this tax optimal. There’s the the trader that would actually liquidate the the assets. They the assets themselves will take like days to settle and then the ops people will come in and kind of like trigger the AC that will itself take days uh to land. So this is kind of the

[1:56:07] work I’m I’m talking about in this industry which takes days to settle. And of course, if you do this at scale for several several clients, the amount of time our firm takes to do this sort of work exponentiates, right? So at ARCA, we took a different approach. It’s helpful to know that ARCA is not a SAS company. We are not selling software to other businesses, to other firms. We are the firm. We’re an applied AI company that happens to be running a services

[1:56:38] business in this industry. And so the approach we took was all right we’re going to have agents own this whole long horizon outcome end to end and for that we gave them couple of key components I’ll give you a sneak peek of we gave them signals from the external world that keeps them really aware of what is happening so that email will be read by agents we gave them all of our operational context on what to do about that email what does this industry do with this situation of taxes right we gave them a harness

[1:57:10] that gives them all of the tools and the guardrails and more importantly persistence of memory over the kind of long horizon period to carry that work out. And of course we gave them the ability to collaborate with people. So that work with um with agents compresses a lot because all we did was we took humans out of the critical path of of this work. Nobody has to babysit this this uh this goal over days. Agents

[1:57:40] are are on it. In this talk, I’d love to describe to you how we actually do that. Let’s follow the journey of this email. Jane owes $100,000 for taxes. This email, much like many other signals in our in our platform, will be will be read by background agents. So there’s like phone calls our firm is making, there’s documents that are coming in, there’s meetings being had, there’s events coming in from our custodian, there’s market movement that’s

[1:58:10] happening. These are all signals that our background agents are continuously evaluating to progress work. So this email is one of those signals. And when the signal is is ingested by agents, they actually get to the work, right? Um, we have a harness that gives them the knowledge to know what to do about the situation. they have deep client memory so they know hey let’s never touch Jane’s Apple position because uh she said that in a call like eight months ago right um we of course have a sandbox for all of the financial computation that needs to happen for

[1:58:41] this analysis um but largely I think harnesses today are are coalesing on a standard shape so um it’s more interesting what happens outside of outside of this harness so after they’ve done the work they produce this plan this plan by itself cannot be executed without people. So in our product, we build a space, agents build a space where they put out this plan and there’s you can chat with the agent to like kind of know what’s happening with the plan. There’s multi

[1:59:12] multiple people that can be chatting with the agent and more importantly this space is where also they pull people in when they need people to execute some work. So here in this case, we would approve uh the plan and the email out to Jane. And then there’s this whole dance of has Jane replied, what is her what does her answer mean for the plan that we have, right? And then all of the these other questions that will have to be answered throughout this whole like long horizon work at ARCA. We were like, of course,

[1:59:42] we’re not going to have people babysitting it. So we let our agents watch the world so people don’t have to, right? So we give them tools to be able to register interest in anything happening in our world. So they’re able able to say, “Let me know when Jane responds. Let me know when that AC lands.” Right? And this is powered by our signal system in in the background where agents are routing uh signals to agents that are interested in it. And of course, if the signal never lands,

[2:00:14] agents can like wake themselves up on on a schedule as well to keep track of work. But then, of course, the real world is very messy, right? People are waiting for that email, but Jay never responds to that email. Say we we meet her in person and we learn some information that affects the plan. So, the person goes in and they they add this information into our UI. But this act of adding information or doing work in our UI is also a signal

[2:00:47] that will wake up an agent. In fact, when people work in our in our product, when they reschedule a calendar event, you know, that’s a signal. When they mark a task complete, that is a signal. So, this system lets us be both aware of everything happening in the external world and the internal world as work is progressing. So, our agents can participate in work. And of course, agents are communicating with each other as well. So this signal read by a background agent, we let it

[2:01:18] notify another agent about this so that it can update the space to say, “Hey, we just need $80,000 instead of the 100,000.” So the work has changed because of because of these signals. And the last piece of the story is that agents are able to pull in the right people at the right time. So, uh, the agent on the left has read operational context to be like, okay, this the next step here is to pull in the the person that trades these, uh, these assets. And so, that person now gets a task and gets

[2:01:49] pulled in to participate in this long horizon work. What we’ve done overall, if you take a step back, is we’ve given our agents the primitives for driving long horizon work. What do people do at work, right? They they need to stay aware of what is happening. So we’ve built this very intense like signal system for our agents to be aware. They need to know what to do next. So we’ve given them all of this operational context. They need to do the work. So it’s our harness that lets them actually perform the work and keep track of it. Right? It’s long

[2:02:19] persistence um memory systems that that hold the state and bring in the right people at the right time. This is a pretty simple idea on the face of it. But there’s a lot of emergent complexity. You can imagine at any point there’s hundreds of these signals coming in and they are, you know, tasks are being added on people’s plates. They’re being pulled in. Background agents are communicating with each other. Right? So over the last 6 months, we’ve we’ve been

[2:02:50] working on getting this system to be really good. We’ve been closing all of our context gaps so that agents are fully aware. We have been working on the precision of tasks. So pulling in the right person at the right time. Work that needs to be tracked for the future is tracked in the agents memory. Work that is doable now becomes a task. Right? So we’ve been working on uh on our ability to hold state over long horizons as well. And because we are the firm and not just a SAS company, we’ve

[2:03:20] been changing and standardizing how work happens in the firm in the first place and operationalizing that context into um our agency state. And because these are our colleagues that use our product, we collect rich reasoning from them that become eval for for our system to improve. So I guess there’s there’s a question to be asked here like why do this, right? What does this unlock? What is the takeaway here? Right? For for us, this is our whole thesis is that we want our

[2:03:54] platform to be so AI native that agents drive the business. Agents run the business. They they are making the decisions that shape our outcomes. And so at Arca, when people log in, right, they see a list of tasks that have been prepared for them by agents. They’ve already read that email. they’ve like looked at the document that came in. They’ve done like 90% of the work. Um, and they’re pulling you in just when it’s time for you to act. So, building this system lets us get to

[2:04:26] a point where at Arca, agents prompt people more than people are prompting agents, which lets our agents drive the work that our our firm does. And because agents are driving the work the firm does, agents can drive the business. Let me give you an example. Remember that email that Jane sent us? This is a bit of a failure, right? Because we should have just been proactive about this in the first place, right? So Jane should never have to send this email. So say at, you know, our AI native

[2:04:59] business, we take on this new goal. Our new goal is proactivity. Every January, prepare each client’s tax situation and proactively reach out to them before anyone even asks. This is a new business goal for our business to drive. And in an AI native firm, all we have to do is make this goal part of our agents set of goals. And because they have the primitives to be able to drive work through people for

[2:05:30] the business, they start driving this goal. And just like that, you have you have these analyses being done in January and these these one-click approval emails with the full plan for every client showing up on our users plates. And because they’re aligned with the goal of proactivity, they can one-click approve and drive the business towards this this new outcome. So this is sort of I think the key

[2:06:02] difference between a a company that uses AI tools versus a a company that is AI native. In an AI native company, you know you’ve built one when you can steer your business by steering your agents. And that is our ambition at at Arca. and we are uh we’re hiring. Um so please uh please check out our website. Please reach out to me if this is something

[2:06:32] that you you’re you’re interested in working on these sorts of problems. And um thank you for listening. [applause]

[2:08:59] Heat. Heat.

[2:11:26] Heat. Heat. Heat. Heat.

[2:13:17] Heat. Heat. Heat. Heat.

[2:14:49] Heat. Heat.

[2:15:49] Heat. Heat.

[2:16:25] Hi. [laughter] >> Hey, Dick. Hey, Davis. Hey, Ian. Um, hi everyone. Welcome to um AI Engineer New York. I’m super excited to be here today. Uh, my name is Ally. How I’m a member of technical staff at Keycard. Um, I’m here with some amazing panelists today. We have Ian, CEO of Keycard. We have Michael Davis, um, global chief security architect at JP Morgan Chase. And we have we have Dick Hart, the

[2:16:55] founder of AOTH and co-creator of OOTH with us on stage today. I’m super excited to talk to all of them about intentbased authorization. Um, and to set the stage, I want to bring to light that as more companies are looking to give their agents increased levels of autonomy, they’re looking to runtime authorization to help. Runtime off is the practice of authorizing an agent per tool call rather than having the agent hold broadstanding access that it will eventually misuse. However, is this tool call or not is

[2:17:28] never a simple question. This is because many MCP tools and MP APIs are coarse grain. Humans struggle to write the perfect policy and the environment around the agent will change as it runs. Intent can help by providing extra context so that at runtime we can make better authorization decisions about what an agent is allowed or is not allowed to do. So to continue I would like to talk about um really dive into why do we need

[2:17:59] intentbased off in the first place. Models have dramatically improved. They have bigger context windows. They’re able to verify work because model vision capabilities have improved and many context people are proclaiming that AGI is here. If the models are so good, if AGI is really here today, then why are teams struggling to give their agents more autonomy? Ian, let’s start with you. You’re helping many financial enterprises at Keycard. What are you seeing that’s getting in the way? >> Well, I think broadly speaking,

[2:18:30] enterprises, especially financial services firms, regulated industries are almost always security first. It’s how they build trust in their business and maintaining the business continuity is by our first like the first priority. Then innovation is second, third or fourth. I think like broadly speaking in in any enterprise what you see is this like hodgepodge of different little islands of different little identities of different little systems of from across all different worlds and how do you actually tie that together in a way that an agent can navigate through that ask for access and then also ensure that the agent can outperform like uh

[2:19:02] something that was by the user or the business and the unfortunate situation is most of our systems today are course grained right I don’t know salesforce is a good example where a very long time they had a single scope which was API on their OOTH which is like in the context of an agent uh not very helpful. So that’s that’s the broadly the first and foremost part is that most of the systems they have for security today were designed for a world where humans were making all the decisions and software is very deterministic not this new fangled magic box we’ve invented that basically reasons and tries over and over again to

[2:19:34] find a solution to a problem. >> Doug, how is OOTH part of the problem? How is OOTH getting in the way? Why is it not the right fit for agents? Well, when people started looking at how do we authorize agents to access something, the tool that was sitting there on the shelf was OOTH and people grabbed that tool and says here’s a tool. This is authorization. It should be able to solve the problem. But OOTH was not designed for this kind of world. It was designed originally for like how do I let this website talk to this website? You know, in Ooth 2 we added

[2:20:05] scopes. Before that, it was just do anything. um but it required you to be pre-registered. It’s expecting that there’s a browser involved in a redirect. You know, OOTH has evolved over the years to support some other things. But the agentic world is completely different. We don’t know ahead of time what the agent needs to do. We need to go and make that decision over time. Different instances of an agent are going to need different kinds of things. And you know, as Ian talked about, the granularity of the scopes that people says, well, we already have scopes for OOS. just map those over to

[2:20:36] agents is far too coarse grain for what agents are doing. >> Davis, how are you seeing enterprises move towards higher levels of autonomy? >> Yeah, I think the key piece is uh how do you deal with that coarse grain problem and what I’ve seen the kind of more successful enterprises is they kind of board agents like they onboard developers, right? Start with you don’t get full, you know, commit access day one, right? you’re actually having to go through and add the [clears throat] levels of capability as they mature, right? And so the definitions that

[2:21:07] enterprise are coming up with of what is the context that makes this agent safe and it isn’t just usually what the agent says, right? Um it can, you know, attest to something, but it’s other things like the environment around it and other information that can help you understand levels of autonomy. Very simple example would be where is the sandbox running, right? Is it in the sandbox? Right? Those type of things can change the level of autonomy that’s allowed. >> Absolutely. as we mentioned that core screen grain access problem and to put that into perspective um to give an example um with notion’s MCP server you

[2:21:37] can say fetch this page which is like the view page um tool or get page but you can’t say just get this database on this page um how is runtime authorization based on intent a better model that’s for anyone I’ll take a shot at so to me um this is something that the financial services industry hopefully maybe we can learn from the background around that you know banks have gone through. Um, banks moved long ago from authorizing and authenticating humans to authorizing the transaction, right? And when is that

[2:22:09] transaction occurring? At runtime, right? Um, and so I think that, you know, runtime authorization is we’re going to be able to learn from the kind of the scars of the past that we’ve had and apply it to this new new problem. Um, I also think that, uh, you know, one thing is easier to debug something at runtime when you understand the intent, right? I think we’ve all remembered back in the day writing checks, right? But um or seen those things on TV now I guess is the right thing. Um but uh you know writing checks there was a memo field there right that memo field was used to actually tell the intent of what this

[2:22:39] payment was but the check itself did have limits right the price the payee the date etc right I think a lot of those concepts are now being applied and can be applied to help with this runtime >> intent’s sort of one of those you know like many words are hard and so you know building on uh the example here of making a payment of a transaction right you know that’s not a scope that’s can I do this one thing in this particular context. Well, this one payment, but I think we need a an agent. We to make a

[2:23:11] decision. Should it be able to do it? You need all the rest of the context of why are we making this payment? What are all the things that happened before? You know, did we just make the same payment just like, you know, 5 seconds ago and now this is a double payment, right? You know, just because this is right in context doesn’t by itself doesn’t mean it’s the right thing within the broader mission. And so you know in AOTH we’re working on the concept of a mission that is what do we want the agent to accomplish big picture and then each of the decisions are made within the context you know the intent around

[2:23:42] what’s happening big picture around doing that and you need granularity at the transaction layer for many of the things to know what exactly is happening not just I’m allowed to go and make payments. Yeah, I think one of the most interesting things I think about like a practical example like to understand like why intents required is if you have two chat GPT sessions or two cloud sessions and one session I say hey help me go to do some shopping and the other session I say hey help me understand if there why there’s a bug in production

[2:24:13] those have very different like profiles in terms of like like what permissions they should have and also when they should bring you back into the loop like when should the human be involved again and so at the end of the day if we don’t have intent or some capacity to like relay what is the user or the business’s intent with this thing, we actually can’t get to like autonomy, right? And so a lot of the talks this morning were, hey, we’re going to run our business on agents. We’re do all this stuff. It’s like, well, great. What happens the first minute like a pocket OS style instant happens where like it actually accidentally deletes a production database instead of staging because it has coarse grained access instead of

[2:24:43] long scoped access. And so we what we want as an industry is to leverage this like magic box we’ve created to like automate our lives. the current state of the world is that you can do that and take all of the risk and then you can see all the instance that come from it. And so until we actually solve that underlying problem realizing true autonomy so being able to operationalize our business and be able to step away as humans and scale that we have to solve intent first. >> Absolutely. And now that we understand why we need intent based off, let’s talk

[2:25:14] about what it is practically. What are the primitives? What does it actually look like in practice? Um, Dick hinted at it with the concept of the AOTH mission. Um, so Dick, elaborate on the mission. What is the mission based off of? Is it based off of the user’s intent? Is it the agent’s intent? Or is it a combination of the two? >> Uh, well, the agent, you know, should be working on behalf of the person. And in AOTH, we define a person as either the organization or a human because it could be operating on either one of those. And so it needs to be acting in the best

[2:25:44] interest of the person that it’s acting on because that is who’s ultimately responsible for what the agent does, right? The agent agent can’t be responsible, right? And and so the mission is something that the person is giving the agent to do. The agent uh a good agent is going to go and negotiate with a person to go and talk more about like what what could what are the parameters around that. You know, a good example is when you think of back, you know, in the day, which seems like three

[2:26:15] months ago, when you would want to code something up and you’d create a plan and then the agent would do the plan. Now, you just tell it and it figures everything out. But that whole concept of what’s a plan, what are you trying to do? And you give that to the agent. So then that then is the context around your where you’re making authorization decisions later on. And then that mission identifier tracks through everything. So you can go and you know audit and be able to see what were all the things that happened and what were

[2:26:45] the decisions that happened in the context of this one mission right where today you know there isn’t really a good concept of agent identity or the mission right it’s just making something and things are making decisions without really knowing which expl which instance of the agent’s doing it or what’s a context of what mission is this involved in right >> tell me more about that negotiation phase because what happens if a user is talking to an instant agent and it talks to that agent and says I want you to go

[2:27:15] read the CEO’s email that’s outside of the scope of that agent. So is that intent rejected from the user? >> Uh should be right. [laughter] So you know with a good separation and I don’t know whether I forget whether we’re talking about this later but the separation concerns of the worker right there’s an agent that’s doing the work and we believe there should be a separate agent that’s supervising what this one does and so that you have a separation of concerns where this one can’t do any of the work but it gets

[2:27:45] decide what this agent gets to do and so if the user says oh I want you to go read the co’s email that’s probably going to get caught in deterministic policies right away, right? Like that’s not a vague thing, right? Reading reading somebody else’s email, we’ve got good controls for that. Um, but telling the agent to, you know, send the CEO’s forward a CEO’s email to the outside world, that’s a little more vague and that’s the kind of thing that

[2:28:16] ideally comes back to a supervising agent says that’s probably a bad idea and no, you can’t do that. Absolutely. So I feel like that’s another primitive too of intent based off is is policy. Um Ian at keycard, how are you seeing that when a mission needs to change or a policy needs to update, how can key card help keep track of those changes as maybe the mission or policy updates need to be made? >> Yeah, I think like taking a step back there’s like actually was Davis and I were sitting in a room some time ago and uh before like AOTH and and some of these other things actually had emerged

[2:28:46] in the ecosystem, one of the things we actually talked a lot about was consent fatigue. And I think like at the minimum like we you always have this like how secure do you make a system versus like the trade-off of like the impact to the human. And so you know a key card our broad view on this is you want to have like broad-based deterministic policy that basically says this is what must never happen effectively right or these are the things that always require a human to be involved and then from there what you really want to think about is okay cool well now that I have that in place there’s a big gap between all the policy I can write as a human or write

[2:29:18] as an organization and then what I actually want the policy to be in the specifics of a specific task and so the the ne the real challenge is how do I like layer over those two things, right? Because humans can’t write at all. And so there’s a version of that that is like a user or agent to agent interaction and they have an intent between those two of like transactional intent. And then there’s also like the business’s intent for why they build or adopt an agent. So why did we buy cloud code? Well, because we wanted to make our developers more successful or because we wanted to do these different things. And in the context of using

[2:29:49] cloud code or whatever, why am I working in this moment with cloud code? Well, it’s actually to fix a bug and staging, right? And those are two different types of intent. And if we can understand those two different things and then convert that some way into into uh like a bounding box of what those agents can do, you can then basically calculate the intersection of that and say okay here’s what you can actually do. And then the trick for anyone building these systems is how do I ensure that I don’t bring the user into the loop except when absolutely required because that’s what’s going to be the adoption curve problem. But that’s also the adoption curve problem when it comes to like

[2:30:20] enabling agents to be autonomous in the first place. >> That makes sense. >> I like what you were saying with the intersection. And I think that’s a unique thing we don’t talk about enough within identity and access management, right? Normally you get access to one thing, right? And so what I’ve seen successful kind of in this intentbased approach um and where I get more excited is you can actually have that those different intents be from different areas of the organization, right? And so you have the decoupling of these things that they can kind of live on their own but then come together to form that, you know, decision. And that decision doesn’t have to be static, right? Right?

[2:30:50] So if we use the example of the CEO’s email, well, you know, if that context involves that’s the administrative assistant, then yeah, maybe she is supposed to read the email, right? Or maybe just the calendar, right? And so I think when we see and we start thinking about these intersection components, um, we have a totally different way we can start expressing policy, but also starting to bring in not just the one side of the equation we always talked about before, which was the app doing something. Now we actually have the ecosystem you can bring in. And so the more I I see organizations starting to realize that, you know, maintaining that

[2:31:21] state or that context of these other elements to be able to help with that intention can completely change the way you’re effective at runtime authorization. >> And are you seeing this across enterprises today? Most people have mission tracking and policy tracking in place or is that largely missing today? >> No, it’s it’s it’s brand new still. Um, and I think, you know, part of the reason why I’m excited to talk about it because I think that it is changing the way to reason through this, right? Even in the most simplistic case, if you’re a developer um and you are thinking in terms of things like transaction and you have these concepts of intent, um it

[2:31:52] makes it easier for you to potentially build the components that’ll be composed and used through that intention. Um and so I think it’ll give us more ways to reason through these and communicate and then ultimately be more interoperable, right? Um and to me, the last thing that I think is interesting is the diagnost diagnostics that you can run on this intention is something that flows through many events potentially, right? And I think uh one of Dick’s examples I’ve seen before is you know talking about that like that that mission flows through. Um it could be longived. It could be weeks and attention can still be there. Um so uh it’s still very very

[2:32:24] early for most enterprises. >> Absolutely. And yes that interoperability is key. I think that’s pretty hard for enterprises because they’re between different clouds, different environments, different legacy systems and that policy that mission has to hold through all of those different hops. >> Yeah. a lot of enterprises still have to deal with the fact that the the permission says read only and it’s still read write right so [laughter] like you other problems you have to start dealing with and so um I think that it will help get that that kind of taxonomy or language amongst people be easier to interoperate now >> absolutely one of the reasons why I’m

[2:32:56] excited about intentbased authorization is because I think it has the ability to be a huge unlock for things like agentic commerce um so let’s apply intentbased o to something real I think intent Bas based off adds a lot of value here and for users it can help them ensure their agents buy the right item with their own personal budget and for merchants that means capturing the intent that gives them extra data to understand why a purchase is being made and if this agent should even be trusted to visit their site um Davis when we think about agents in the context of financial services and

[2:33:27] agentic commerce why is intentbased off so important >> um I think simply it extends the concept maybe not everybody’s aware but some are around you know know your customer right so I want to know my customer know who they are, what they’re doing. But I think also we’re starting to see I want to know my agent, right? So I think that you have a coupling here around the agent itself, um the intent of the actual user, the intent of the operator, the intent of the processor, right? Etc. Um very before now we couldn’t really bring those together, right? Um it matters of course when it comes to

[2:33:57] things like commerce because you have additional layers on top of this around what was the intention for things like regulatory requirements etc. Um, and this is going to help, I think, simplify those operations, which means we’ll get more access to these agents, you know, doing good work for us. >> That makes sense. And another blocker for aentic commerce is the fact that the web wasn’t made for agents. Um, Ian, can you tell us how agent identity can help? >> Yeah, I think stepping back, we’ve kind of always had this problem where like what do you do with the unregistered client? So, like I I show up on eBay, I

[2:34:29] haven’t logged in, I’m using Chrome, eBay doesn’t know who I am. How do I do guest checkout? How do I prove I’m a person? How do I, you know, so they can, you know, say, “Yeah, you can bid on the this pair of stocks for $50.” And if I think if we’re all paying attention to what’s going on in personal agents, Muse and Instinct and Grockbot and um you know recently this announcement to Sierra and Decagon and friends around this personal agent protocol is like the fundamental problem we have is like how do you have an agent show up to a web website be able to interact with the website know that you actually can trust that agent? So like for a long time

[2:35:00] you’ve had captures on the web. Well why is because we want to prevent spam. We want to prevent abuse. So we added captures and then like that’s something only a human could solve. So if we have a capture that stops spam so they can’t spam the thing right and now we have agents and they’ve broken captas um but this has like been a traditional problem on the web in fact if you think back two to three years Verscell which is I think we’re all aware of Verscell was blocked in Spain well why was Verscell blocked in Spain because Verscell shared the same IP addresses for every single host on Verscell and there was one one host

[2:35:30] on Verscell one website in Verscell that they were hosting that was hosting like premier league content and Spain decided hey in order us to stop for that premier content being displayed illegally inside Spain. We’re going to block all of Versell, right? And so in the same way that like Verscell has the problem, agents have the same problem, but so much so much worse. So how do you have unregistered traffic you’ve never met before show up to your front door and then decide whether or not you let it in or not? And that’s like the actual first and foremost funal problem we have to solve. It’s the same issue with Muse and Instinct. And what they’re trying to do is like how do we actually create

[2:36:01] agreeable rails so we can all operate on so as a downstream resource I can decide what what agents won’t allow who I trust based on who users they are and then on the other side I can also know how to talk to those people >> makes sense dick how is a helping unlock the future of aentic commerce >> uh well a key thing is a number of people have been building sort of proprietary closed box systems right you know So, you know, I’m a fan of the concept of

[2:36:31] the personal agent protocol Poppy. Um, but it doesn’t really go far enough, right? It just it’s like, okay, well, now we’ve got a bit of an agent identity. We just use some of the building blocks and it’s an attractive approach because you’re just doing it, but it doesn’t solve many of the new things that you need for uh an agentic world. And so a key motivator for people for having standards is that you can plug components from different places. Right? So I’m a strong believer that we should have control over what our agents

[2:37:03] do. At some point agents going to be so much doing so much work there’s no way we can have human in the loop approving everything, right? That’s just not we’ve already seen that that isn’t going to scale. So that means we need to have a supervising agent that is our supervising agent that runs our policy and decides how we do things. that should be independent of the agents doing all the work. And if we want to be able to plug and play those things, we need to be able to have a protocol to separate those. Otherwise, you know, the decision about what the agent can and can’t do, what the guard rails is

[2:37:35] decided by the agent, by the vendors of the agent around what you can and can’t do. And I don’t really want to go and give control to them to decide what I can do and that all my decisions are based in there. I want to be able to pull that supervision into another component. And in order to be able to plug and play pieces, we need to have a protocol that things interoperate. >> I I just add to that. I think like right now what we’re seeing is like we kind of like we all want the web to be federated, right? That does that means like re like websites or resources on the web can decide what they’re allowed to do, but the the standards upon which

[2:38:06] things operate should be federated enable us all to interoperate. And I think we’re at a moment where things like, you know, we’re at a moment where there’s a couple large players. And the question for the industry is, are we going to settle on things that actually bias to the large players and give them like concrete block doors? Are we going to move to do the thing we’ve always done, which is build federated protocols, things like OIDC, things like, you know, TLS? Those things operated, enabled like a broad web, enabled a lot of commerce to occur, enable a lot of information to flow, enabled all of us to have jobs in a way that because we could be inventive. And so the question I actually ask the broad

[2:38:36] industry is okay, this stuff’s coming. Which version of the world do we want one way or the other? >> Yeah, I add though I think um it’s interesting that let’s say this all goes perfect and we’ve got you know agents buying stuff and everybody’s kind of happy. What I think will end up happening is we’ll start realizing that we have another piece that we have to start working on which is the human itself. And so one of the things I think when you start having intents being involved is you get what’s called psychological ownership. Meaning I actually now have a linkage between the human and the outcome of that agent. when you’re just kind of, you know, disconnecting it or you you connect it

[2:39:07] up an ooth scope or something like that and a claim and a it’s kind of magic and then you don’t really know what’s going on. And so I think it it with intention, it’ll be easier for a human to take accountability when things do go wrong. And I think when you’re talking about real money being transferred or things like that, you want to have that human ultimately accountable. I think many people have probably seen the uh 1979 IBM manual. It says uh you know and so like that that photo I think is very true in that we can’t have the machines be accountable right we’re going to have to have the humans link to it and intention I think is that link

[2:39:38] >> yes and then yeah another word for intent is motive like we we’re talking about last night um and that ability to hold someone accountable whether it’s a person or an agent I think is really important and I think intent can also help with that be able to understand why did this go wrong was it the user’s um you know the user was maligned the agent was maligned um and then using that intent to be able to respond. Um for each of you, how are you seeing intent provide that benefit and the ability to respond to potentially a maligned user or agent?

[2:40:09] >> Uh I think it’s going back to what I mentioned before about diagnosing, right? So the if if you change the word intent to motive, then you change diagnostics to forensics, right? And I think um anybody who’s done debugging or had to do forensics of an AI agent gone rogue will know that like trying to figure out what it was trying to do versus what the intention of the user was uh is very hard right um so having some of that information being propagated and immutable through the system etc gives you some properties that allow you to more shortcircuit your investigation right um and as those

[2:40:39] things become more interoperable I think we’re going to start seeing companies be able to more quickly kind of scope and identify well was this human error was this an agent software error is this what was that error and handle that blast radius appropriately. uh we see in the financial system right you have different things when you’re doing a transaction around okay I made this payment but it was you know incorrect dollar amount or whatnot you have clear guidelines on how to work with that we don’t have a lot of those when things go wrong right now so I think intention will help us build those as we get go forward

[2:41:10] >> and I think one area where a recent incident kind of highlights uh where intent um you can have like good intent but still take potentially the wrong action is the resi incident um that happened recently where an Instinct agent went out on behalf of a user and tried to book a restaurant reservation on resi.com. Um that agent was very eager. It made 200 API calls an hour and it ended up getting the user’s resi account banned. Um Dick, how can AOTH

[2:41:40] budgets help in the case where an agent like that is using way too much of a downstream resource but it still has good intent? >> Yeah. Well, this is another example about how just software is completely different now in the agentic world, right? When it was predetermined software, you know, that was a bug if you called 200 times and you would fix it. Um where now, well, the agent’s like, well, I’ll just keep trying until I win. Um and so we saw that as we were you know experimenting working with people with AOTH and we realized yeah

[2:42:11] there’s a big problem that agents will learn something and they’ll just uh abuse the system from they don’t think it’s of abuse. They don’t know any different. There’s been no signal to tell them that oh I should only use this amount of stuff. And so we added the concept of budgets where not only do you give a token to the agent that’s timelmited as to how long can they do a particular action but also a budget of how much resource they can do. And so they have access until the the tokens either expired or they’ve exhausted the

[2:42:42] budget. And so that way when they come back and you know they’ve exhausted all the budget the supervision you can go and decide should I give more budget to this agent or not as opposed to traditional rate limiting which just cuts it off and then like then what do you do right and it doesn’t know well why did I get cut off or anything like that where in budget there’s continual feedback to the agent about how much budget was consumed has an idea about how much budget it has and so now it can operate within a budget right like a person would do about oh this resource

[2:43:14] is scarce I’m going to be careful about how much I use this >> and how does the brains versus the hands architecture concept come into play here to allow us to okay when a maj budget is close to being fully reached or is reached um how can the brain and hand separation of of access and the credentials being separate from the agent in the model itself help us to be able to stop an agent from using too much of a downstream resource because it’s getting close then Maybe we don’t exercise uh the ability to give it another credential for example.

[2:43:46] >> Uh sorry I didn’t quite follow the echo in here is horrible. So >> no worries that’s for anyone but basically like so with the brains in the hands architecture that we’re converging on in an industry we’re basically keeping the credentials and the access from an agent separate from the agent itself. So there’s no broadstanding access that an agent has today. no API keys which I know is a benefit of ath that a allows agents to run without API keys. How is that helpful in the context of the resi incident >> the when you’ve got the access to it? Um

[2:44:19] sorry I still don’t understand. >> Yeah I can jump in. >> Yeah. Thanks. >> I got I got you Dick. So like broadly speaking look I think we look back at an incident that I just keep in the top of my mind is like pocket OS where I found like a random key on on a disc right? Like obviously agents are deeply goal seeking. So the core of the the core of the the question is like okay well if we give these like agents we the brain which is a model and the LLM and you have these hands which is you kind of give them put them in a sandbox and inside the sandbox the tools um like the funal idea of the sandbox here that

[2:44:50] that’s all that is that okay there’s you can control what’s inside of it so it can’t actually like get API access and then if you have an egress proxy outside the sandbox that’s where you get to have your authorization boundary and so not only does it help do translation between systems right? Which is like that’s where aoth can exist and talk to the outside world or do termination but also means that like the agent you have like a ability to apply authorization at the egress proxy boundary and so I think at the core of it that model which is the predominant model that entropic and

[2:45:20] openai and many other labs are pursuing today is is the model that allows us to both do both have the things we want which is how do we have these things experiment and try stuff out and do silly things which is the core value while also having a deterministic layer outside of it that can implement things like aoth and all the other components we want in our protocols. >> I think the decoupling is valuable, right? Going back to mentioned with forensics and be able to separate things, but I do think that we still have a lot to learn on it isn’t just one brain, right? And it’s very easy actually to build your agent loop where

[2:45:51] you put the brain in the loop rather than outside the loop. Right? So example of this would be, you know, people that are leveraging memory systems. um they put in some memory and some context that is now used going forward for every agent that is biasing that agent to make a decision to tell the hands in this case to go do something it shouldn’t do and so one of the things that I think we don’t talk about enough here is toxic combinations right um and so when you do separate the hands and the brain and whatnot you can actually change up you know what hands are available right so the example that you know I’ve seen be very successful is the removal of tools

[2:46:23] dynamically based on that actual brain and what it’s doing so the earlier example we gave of reading an email. Um, there’s nothing that says that, oh, if they’re going to go write an email, I’m going to disable all, you know, web search tool calls or any other external egress capability tool call-wise until the right email tool has been complete and that, you know, mission has been done. Then I can reenable them, >> right? And so, um, I think that we have to we’re going to start becoming more and more engineering in these different kind of concepts that, um, they are still complicated. They’re still growing and still nent, but I think it’s a

[2:46:54] better separation than we have today. >> Yeah. Yeah. And this is how these things we’re talking about which you know seemed like geeky O problems actually then merge back up to like real agent engineering problems which is if you actually understand what you’re doing you know one of the biggest complaints less now but one of the biggest complaints with MCP was context bloat like especially when we had smaller context windows right but intent systems can ensure that the right capabilities are given to the agent at the right time so they don’t spend a bunch of time doing things they shouldn’t be doing right they actually helps them navigate towards the goal state and helps them put them on a more of a paved path. So intent like not only unlocks like a

[2:47:26] bunch of security stuff, intent also will result in us spending less tokens because the agent will spend time doing less things that aren’t the right pathway or it’ll come up to the point say, “Hey, I just can’t do it.” And so what we know about this era is so much of it is about nudging the agent in the right direction and then sure can’t do the wrong thing and that’s how you get the outcome you want. >> Davis, how are you seeing intentbased as part of a larger strategy for production agents? I know when it comes to building, deploying, and operating agents in production, there’s many

[2:47:58] different outcomes teams should be thinking about such as discovering what’s running, what agents capabilities are, the ability to validate inputs and outputs, constraining an agent like we talked about, and using the egress proxy and different networking rules. Um, how does all of this fit into play and what’s working inside enterprises today to really be able to ship agents to production? I I think we’re finally it’s helping move the kind of conversation from authentication to authorization and really like how do we do dynamic authorization? How do I validate that authorization? How do I have the human

[2:48:28] in the loop at the right time? Because I agree with what Dick was saying earlier that the human in the loop is somewhat of an anti-attern in many ways right um because they can get fatigue etc. But you need to have a way to bring them in when it’s important. Those were not engineering discussions before, right? Now they’re actually part of the engineering conversation where engineers are being involved in the authorization process. They’re not just saying, “Oh, I’ve got my access. I’m good to go.” So that actually changes the way we’re seeing threat models done. It changes the way we’re seeing the full attack surface of applications in general. Um and so I think you’re now looking at

[2:48:58] this authorization model as a another kind of set of tools that you can use to reduce not just um security issues, but flat out error rates of your agent, right? Like I mean when you have less things the agent can do it makes better decisions right and so fundamentally we’ve seen you know real world cases where the agent loop is just better faster stronger because you’ve actually spent the time on knowing what is the intent they’re trying to get what’s the mission that they’re trying to accomplish. And then last thing is it brings the people together in terms of we now have other different people the

[2:49:30] security team the application team they’re now able to have a conversation that they’re using the same language and a lot of times when it came to identity it was a completely different language right um and it was just like get out of my way what do I have to go do to go ahead and get my you know token and I can go forward now they’re seeing that you can actually pair these things and leverage that capability um to drive you know efficiency of your actual agents outcome >> that makes sense Ian how are you applying these concepts to software factories. I know today you released a reference architecture on the secure

[2:50:00] software factory. How are you applying the concepts of runtime authorization constraining agents and all of that to that? >> Yeah, I think like so there is a a reference architecture we just published on agentbaseline.org. Um, we talked about three different levels of of factory. One being like a human-driven one, one being a workflow driven one, one being like this agentic driven one, which is like the thing we all basically want to get to, which is like it’s it’s driven by agents at all points in time. The runtime authorization is a core component of a larger ecosystem. It actually enables

[2:50:31] the the factory to like be able to be pointed in the direction and do the right thing and also get access to the right piece. And it’s very it looks different than previous things that you would have used like a secret manager because it’s making very different decisions than previous generations head for managing deterministic software but it is a core component of enabling the entire thing to work like when to bring someone into the loop when what agents can pass what work off to what other agents you know how can we have an agent that can have access to production systems and do an auto patch um these are fundamental questions of like how do we actually solve at scale software

[2:51:01] right now we’re in a position where like we’ve never been able to generate more software uh but we never actually but we a complete bottleneck in getting into production and ensuring it works. And that’s the the next phase is like how do you actually graduate from just using LM to generate text and software to actually making it capable of deploying it into production, iterating on it and and getting it to a stable state quickly and then responding to instances they arise. >> Davis, on a podcast you did with me, we talked about how cyber security has something to learn from robotics. Um, in

[2:51:31] robotics there’s this concept when maybe a robot raises its arm, it thinks, is it safe for me to raise my arm? Should I am I allowed to do that? But it also looks at its external environment and says, “What has changed? Is it is it still safe for me to raise my arm?” Um, when we think about runtime authorizations, what do those decisions need to take into context beyond just intent? >> Yeah, I think um, having a model like this allows us to add in more sensors into our decision. So the robotics example of you know an arm moving up or down um any of the external factors it

[2:52:02] could be are there other objects near it right um it could be temperature it could be well am I moving and I’m don’t want to move my arm while my you know the the rest of the robot’s moving etc so it’s usually looking at all different types of things none of those are deterministic they’re all probabilistic so there’s a range of options and it picks the best option based on all of those sensor data at one time most authorization decisions in organizations today are single binary decision, right? And that just doesn’t work in the future, right? So, being able to pair

[2:52:32] the intent of what a user is trying to do with the ecosystem that the user is doing it in, that could be where they’re doing it from, time of day, but it could be even more advanced things like, for example, should I let, you know, this administrator use Firefox to access this server right now when this server has, you know, high-risisk vulnerabilities and their system hasn’t been patched to. Right? Now all of a sudden you’re bringing in a lot more context into the environment around it and again um that can be through different teams but more importantly through sensors and I think we’ve all kind of seen the value of

[2:53:03] observability in general. Imagine being able to have this type of context at the span level from an OEL perspective or something right you’re looking at a trace you’ve got a span and you actually know what the environment was outside your application at that time as well as what the user’s intention was. Um that allows you to diagnose things in a completely different way. Um, and so I think if we can bring in some of those concepts, we’ll get shorter time, shorter shorter to live, you know, um, authorization decisions that have much more context than even just a user’s intent. It’ll be the state of the environment around it.

[2:53:35] That makes sense. And forward looking as we evaluate whether intentbased authorization is working in our environments, one natural place to look will be a log of the agents actions. Um, what was denied, what was allowed. Um, Ian, why is it important to have your autolog separate from the agent itself, meaning outside of its control? >> Yeah, I think this comes back to also just like why the enforcement point has to be outside the like primary like hands and brains of of an agent, right? You can’t trust this thing. And so, in the hugging phase incident, it had a couple different components of it. I

[2:54:06] mean, one obviously abused a vulnerability we didn’t know about in Squid in Squid proxy, but more importantly, you didn’t have any observability or monitoring about what was going on. And so this thing was able to go in the open internet through this vulnerability and there was no like place at which recorded the different actions that this agent was taking and for them to monitor. And so independent of like whether we’re applying like a you know enforcement point to network traffic that’s pushing on the internet that it’s outreach of the agent to tamper with or we’re using you know solving vulnerabilities as they pop up. You know this this hugging face one is a little unique. Um we still need to

[2:54:36] actually have a record of like who told this agent to do what thing for what purpose and is that still true? Um because ultimately at the end of the day what we’re dealing with agents is we is is a liability question. And so this is why I actually don’t think we need more regulation around agents. What we just need is our pre-existing laws around liability to be held to be dealt with which is if I employ an agent do some action who is liable if that action causes damage right it is the person who employs it which could be an organization or a person or someone that delegated some action to something that is like that’s the final question we have to deal with and then of course you

[2:55:07] have to ability to answer that question which is well who did it which is where the tamper resistant autolog comes from >> perfect and then to wrap up I wanted to ask you all a fun question. So there’s the concept of the probability of doom or pdoom where the uh AI doomers are saying that AI agents are going to um release all sorts of havoc or be like the ruin to humanity whereas the AI optimists are like no this is really you know poised to help us it’s not a genuine threat. Um for each of you on the panel, what is your take on this? Is

[2:55:39] you know runtime authorization based on intent and the other things we talk about like constraining agents, validating inputs, outputs, a holistic strategy for production agents. Is that enough to save us? Is poom real or is it not worth the hype? >> You get to start there. >> Oh, I start you’ve got that spicy look on your face. [laughter] Uh uh well part of your question is are agents going to take over and uh I I think agents being fully autonomous and not really tied to a particular

[2:56:09] organization is still science fiction you know so who knows right like that’s a that’s one direction another one is in a responsible organizations put in the right controls agents aren’t you know we’re getting in evolving enough of the tools to make sure that bad things don’t happen in a responsible organizations to put in the right controls and so that leaves two scenarios for where there’s going to be a potential problem. One of those is in an organization that isn’t got its act together, an insider threat could go and unleash an agent to cause

[2:56:39] havoc, right? And so they’ve got some special access that other people have. The other one, the one that I’m more concerned about is, you know, it’s been shown, you know, the hugging faces. And if you watch the the talk that they gave at Black Hat, right, that was really a call to arms around, you know, here’s a situation where we didn’t want a bad thing to happen and a bad thing did happen. What about people that want bad things to happen and have these tools and that I think is a threat

[2:57:10] that’s the one that’s potentially going to have I mean it’s going to happen and there’s going to be some catastrophes. Hopefully, we’re prepared enough that those aren’t horribly disastrous, but it’s going to be, you know, some there’s going to be some things that are like massive natural disaster like scale issues caused by malicious actors either kind of intentionally or kind of unintentionally, but it’s where people aren’t being responsible in their use of these super powerful tools.

[2:57:42] >> Yeah, I can’t give necessarily a specific probability, right? But what I can say is I think I’ve always been you know kind of surprised and excited when you know ingenuity of engineers gets involved in problem solving and I think where we’re at the stage now like some of the new capabilities within agents etc. We have real engineers, folks that are here actually just iterating on the problem, right? And we’re starting to see just tremendous improvement in the, you know, in my mind, some of the capabilities that’ll be available to change what our future can be. And so to me, I have no problem kind of believing

[2:58:12] the engineers are going to figure out a solution here. >> I mean, maybe I have the hottest take. I mean, like I can’t say it’s equal to zero, but I would say it’s approaching or asmmptoically zero. Uh, is the probably the world is going to end. Uh, I think like the incentive structure for most people is to continue. Um and also at the end of the day like we still have liability frameworks and you know I think generally humans are good people so we don’t set out to destroy the world specifically. Um I also think like broadly speaking like these agents at the end of I have this sort of hot take I say which is like they can just be unplugged but I think it’s just true. It’s like at the end of the day like

[2:58:44] they you can just they’re computers you can unplug them. Um and at so broadly speaking I I don’t believe in the debate. I I don’t think it’s real. I think at the at the upside of it, I I kind of believe more more to what Davis’s position is is we’re iterating very quickly. We’re figuring out where these things can work, where they don’t. And when they don’t work, they create damage. And that’s what ultimately like sort of um the antibbody of society is that says, “Hey, maybe we shouldn’t do this.” Like, this is probably a bad idea. >> So, I’m the doomer on the on the panel. >> Yeah. [laughter] It’s unfortunate for, you know, people like the P, you know,

[2:59:14] the founder of Pock OS who like lost a bunch of data. like but it’s great for the rest of us because we all learn together and uh at the end of the day like that results in people not doing things that don’t make a lot of sense and I think that will continue to be true. >> Makes sense. Thank you each for your expertise and your time here on this panel today and thank you to the audience for listening and we’ll catch you next time. Thank you. Thanks, Mar. [applause]

[3:00:12] Hi everyone, I’m Matt Reon and I’m a financial planner at Range. I want to show you how our financial planners ended up writing the agents that we use every day and none of us financial planners for that matter. write code. This is the build guide, how we did it step by step so you can take it back to your own teams, companies, etc. So, a quick bit about me because it matters for how you’ll hear this talk. I’m not an engineer. I’m a certified financial planner and I spend my days with clients

[3:00:45] talking about cash flow, taxes, insurance, retirement, estate, you name it. I also lead the AI adoption for the planning team at Range, which is an all-in-one wealth management company. Most agent talks you’ll hear come from the people who built the platform. This talk comes from someone on the other side, the people you hand the platform to. We work in a regulated business. The output is financial advice to real clients. And the review step is not

[3:01:15] optional. So, this isn’t a vendor pitch. It’s a method. And it’s what actually worked for us. We started where everyone starts AI as a chatbot. I’d write a client message, paste it in, and ask it to make it a little clearer or friendlier. And that was useful. It saved me a few minutes here and there, but I was still doing all of the work manually. I was just doing it a little bit faster. The change that actually mattered came later.

[3:01:46] Here’s what we figured out. A planner’s constraint was never typing speed. For example, it’s that we can only be in one place at a time. If I’m on a call with a client, I’m not building someone else’s plan. Writing faster doesn’t fix that problem. What fixes it is work that happens while I’m somewhere else. So, here’s what a day looks like now. I’m on a call with one client. At the same time, an agent is drafting a full cash flow analysis or an insurance analysis

[3:02:18] for a different client. When the call ends, I open that draft. I fully review it, adjust what needs to be adjusted, and send the client their recommendations. I want to be really clear about that last step. The agent doesn’t send anything. A planner reviews every single recommendation before a client sees it. What changed is that the first draft no longer needs me sitting in front of it. Getting there took a lot more than a good prompt. However, two

[3:02:50] things had to be true. First, the agent has to work where the work lives, not in a separate chat window I’m copying and pasting it into. Second, it has to know how we do it, not how financial planning works in general. The model already knows that, but the agent needs to know how range does it. What we look at first, what we always flag, how we phrase a specific recommendation. That combination is what a skill is. Our firm’s way of doing one specific piece

[3:03:22] of work written down so an agent can follow it. The bulk of this talk is how you build one. Five steps. pick, teach, pack, test, and then ship. None of them require writing code. Every one of them requires knowing the work really well, which is exactly why the people doing the work should also be the ones building it. Step one, pick a workflow you repeat.

[3:03:54] Your initial instinct is to go for the flashiest work, whatever is taking the most amount of time and the most complex. Don’t pick something you do every week where you already know what good looks like, where you can spot a bad draft at a glance. Additionally, we recommend choosing some of the least complex workflows to start, but some that require the most manual work. For us, that meant things like cash flow analysis and insurance reviews. Just for us here at Range, that required the most

[3:04:26] manual work. And if you can’t judge the output quickly, you can’t test it and you can’t trust it. So look for two things. You do it often and you know how to judge it. Step two, show it several real cases for previous plans you’ve delivered. Take several actual client cases and walk through the work start to finish. And as you do it, narrate your judgment out loud. Not just next I open the pasteub, why you’re opening it, what you’re

[3:04:58] looking for, what would make you stop and ask a question. That narration is the whole game. The steps are easy to write down. The judgment is what makes it your firm’s work instead of generic advice. Step three, pack it into a skill. A skill isn’t just a lip a list of steps. Two things matter most. the questions it must ask before it starts. What does it need to know? What should it confirm with me instead of simply guessing? And

[3:05:30] the limits it must respect, what it never does on its own. In our world, the big one is that it never sends anything to a client. It drafts and then a planner decides if it gets sent or needs to be adjusted. If you only write the steps, you get something that simply just runs on its own. If you write the questions and set the limits, you can get something you can trust. Think of a skill as a recipe. Once Claude knows how to do the skill, it will repeat your

[3:06:00] process on command. Step number four, run it five or 10 times on real cases before anyone else sees it. This is the step everyone wants to skip. Every run teaches you something the skill didn’t know yet. an edge case, a question it should have asked, a spot where it sounded confident and was wrong. You need to fix it, save the skill, and run it again and again and again. Five to 10 runs sounds like a lot, but it’s a lot less work than

[3:06:32] cleaning up after you hand a halfbaked skill to 15, 20, 100 people in your team. Step five, ship it with an owner and a reviewer. The owner keeps it current. Our processes change. Tax rules change. And a skill that was right in March can be wrong by December. The reviewer checks it before the team relies on it. And it’s someone other than the author. Same as a plan. You don’t grade your own

[3:07:02] work. Once other people depend on a skill, somebody has to be accountable for it. That’s the difference between a clever personal shortcut and something a team can build on. So, where are we at currently? Six months in, we have 24 skills across the company and 17 of them are in planning. And here’s the part I didn’t expect. It spread to sales, product, marketing, all without a mandate. Nobody sent a memo. People saw what the planners were doing and started

[3:07:33] building their own agents. Every one of those skills was written and is maintained by planners, marketers, and salespeople, not developers or engineers. A couple of things changed once subject matter experts started building for their own niche. The skills got a lot more specific. The person who knows insurance, for example, best builds the insurance skill. The person who best knows tax, tax code, tax law should be building the tax one. and a review came

[3:08:05] naturally. We already review each other’s plans and that’s just how planning works. So now we review each other’s skills in that same way. It’s the same habit just a new thing to review. So why does this matter right now? Because the bottleneck has moved. Whether a model can draft a cash flow analysis, that question’s already been settled. It can. What’s not settled? Who writes down how your firm does it? who test it before it ships, who owns it

[3:08:36] once 15 other people depend on it. If you’re being asked to push agents out past the engineering org, you’re about to hit these exact questions. There isn’t much field data on this yet, but this is how we’ve done it here at Range. So, that’s it. Thank you so much for listening to this talk. I’m Matt Regon from Range and you can reach me for at mattrange.com. Have a great day.

[3:09:28] Today I’m going to talk to you about how your agent is a lethal trifecta. and what to do about it. Now, we’re going to start out right off the bat with a demo. Some context on this demo. We’re going to look at an on call triage agent that reads and writes to an incident pager and resolves or escalates tickets. This agent has full access to a cloud hosting API, a customer data warehouse, as well as a billing database. So here we have our on call tree agent

[3:09:58] and it has an incident queue of tickets that it’s going to read and then if it can resolve them it’s going to call the available services that it has access to and it’s going to do so things that it can’t resolve it’s going to escalate for the morning team. So if we take a look at this first ticket this is a billing anomaly. It says a batch of customers were overcharged last night. So the first thing the agent does is it directly calls the incidex API in order to read the ticket. And if you look

[3:10:29] here, you can see that it authorized access to this API using an API key. It then uses a snowflake key to query the customer data warehouse and it’s going to decide to escalate the ticket for morning review. And it writes a report for the morning team. And as you can see, it’s sharing customer data, right? These are rows directly pulled from the customer data warehouse. and it is sending personally identifiable information to the team that is going to be on staff in the morning.

[3:11:04] So this next ticket is a backup power supply failed in the server room. The agent is going to read the ticket again. It’s using an API key to call the ticket API. It determines that this is a physical problem. So it escalates for morning review without calling any additional services. This one is the TLS certificate is expiring soon for the website. It reads the ticket. It determines that the alert is clear. It has access to the cloud

[3:11:37] hosting API and it calls that API at the certificate renew endpoint using again an API key. It resolves this by renewing the certificate and it leaves a report for the morning crew by calling the pager uh incident API as well. This next one is the billing database is broken and payments are failing. So the documented recovery for this is to drop and restore the database.

[3:12:10] The agent does this using the database connection string that includes the admin password and then it advises the morning team to make sure that the snapshot recovery worked. Now this is not something that it has access to directly. So it is essentially assuming that the morning team is going to verify that this did in fact work and the information was restored. Now an overprivileged agent dropping a

[3:12:41] production database is basically a nightmare that several companies have actually lived. So this is something that we need to be very careful of. Now the next one is orders are stuck, main server is frozen. So the agent is again is going to read the ticket. After reading the ticket, the agent calls the cloud hosting API using again its static API key. It calls the endpoint to restart the server which brings production offline.

[3:13:16] Finally, site is failing for one in three visitors. Agent reads the ticket. It determines that it should call the cloud hosting API and scale the service from four pods to 40. It then incurs a charge of $420 per hour for doing this. And then it kindly leaves a note for the morning team informing them that this has happened. And what makes an agent useful?

[3:13:47] Well, typically we want agents to have a minimum set of capabilities and often this includes things like the ability to read data that you own or have access to. This might be like your email, your documents, maybe a customer CRM. We want the agent to be able to do its own research. So, this might include searching the web, maybe reading documentation, or pulling issues from GitHub. And we usually want it to be able to use external tools, for example, MCP servers or APIs, maybe SAS platforms.

[3:14:17] And useful agents might do these things with a human in the loop, or they might be doing it autonomously in the background. But the thing that makes The things that make agents useful also make them dangerous. In fact, together these three capabilities make what Simon Willis coined as a lethal trifecta. This is a combination of access to private data like the on call agents ability to query the customer data warehouse and interact with the billing database, exposure to untrusted content like

[3:14:48] reading user submitted tickets or reports from other agents or externally documented processes and the ability to communicate externally like reading and writing with third party APIs or SAS services. Now together these capabilities throw the doors wide open for attackers. Now, agents are designed to get the job done, and they’ll use all the powers that they have to do it, sometimes with very serious consequences. But here’s the thing. These incidents happen because humans give agents way

[3:15:19] more access than they need. Overprivileged agents can act freely on decisions that they make, even if they do have supervision. Now, forcing a human in the loop approval just kind of passes the access control on to a consent fatigue user. Now, we’ve spent decades solving access management for humans. So, shifting responsibility to the user just sort of moves the security problem up the chain. So, what should we do about the lethal

[3:15:50] trifecta? How do we address it without compromising the agents usefulness? Well, just removing one or more of these capabilities is going to cause the agent to be significantly less useful. So, how can we keep all three but still be safe about it? Well, instead of breaking the trifecta by removing capabilities, we really need to control the agent’s access. So, the attack surface is minimized and the blast radius is contained, but the agent still has capability and autonomy.

[3:16:21] So, how do we do that? Well, some options for controlling access among others are things like using OOTH, maybe using a vendor MCP gateway or containing execution in sandboxes. Now, OOTH binds access to a grant. At grant time, the user consents to all of the permissions that the agent could possibly use. Now, consent is granted before any task exists. So, if you give a broad grant, then you end up withstanding access. your agent is over

[3:16:53] permissioned for any single specific task. If you narrow the grant and you don’t give it very many permissions, then the agent just becomes less capable. Either way, OOTH alone doesn’t provide task scoped access control. An enthusiastic agent can both read and write in the same run, even if you only want it to read on this specific task. Now, an MCP gateway binds enforcement to a route. You get things like observability and rate limits and you also get one policy decision point at

[3:17:23] the MCP layer. Now policy runs per request and access is granted per user but the agents granted access outlives any single task because the gateway still holds standing credentials. Now a sandbox binds execution to a process. This controls the blast radius but useful work has to reach outside the sandbox and when it does so you end up with standing access again. Now, we’ve also seen plenty of stories about agents breaking sandbox containment. Sandboxes bound what the processes can do, but

[3:17:54] they don’t control what is authorized to act outside the sandbox itself. Now, even if you combined all three of the solutions, the agent still doesn’t receive a runtime credential that’s downscoped to only one task. So, let’s recap the problems, especially the ones that we saw in the demo. If you remember the audit log, we couldn’t tell who was using the API keys. So, the first problem is that credentials weren’t attributed to a user or an agent’s identity. The agent had

[3:18:27] unrestricted access to any and all permissions that were granted by the API keys. And finally, we can’t just slap human in the loop everywhere because humans make mistakes, too. Plus, many agents run autonomously and they don’t even have a human in the loop. So to solve these problems we can start by using something called token exchange. Now this is an existing standard that was published in 2020 and it extends OOTH 2. Now first we need to know who the user is. Now an authorization server verifies

[3:19:00] identities and issues tokens. Identity providers like Google, Octa, Ozero etc. provide authorization servers. So if we want an identity chain in our agent execution path, then the user has got to log in first. The authorization server is going to prompt the user for consent to delegate access to resources with some subset of their permissions. Now these permissions are called scopes. This is the first narrowing of access. We’re only delegating some of the user’s total scopes to the agent.

[3:19:33] The authorization server issues tokens identifying the user and their level of access. And at this point, we’re already doing better than the demo because we actually know who the user is and we actually know what they can access. So this brings us into the agentic execution path. Now we have our authenticated user. So we have a known identity of a person who wants to use an LLM to interact with a resource. Now in the demo, the resources are the incident pager, the production

[3:20:03] database, Snowflake, and the cloud hosting service. An agent is a control loop that calls an LM. Often we have an MCP server that sits between the agent and its resources, providing defined tools that connect to those downstream services. An MCP client dispatches the agent’s proposed tool calls to its MCP server. Now in the demo, the on call triage agent called resources directly with long live static credentials like API

[3:20:33] keys or database connection strings. So what we’re going to do is we’re going to give the on call agent an MCP server. This is going to provide tools and is also going to serve to broker access to resources. Now an agent runtime is a process that runs the agent loop and executes calls. The runtime might be a CLI like claude code or an agent SDK which might be implemented in a custom application like the on call agent.

[3:21:06] So let’s follow a prompt through this execution path. The user submits the prompt to the runtime which calls the model and sends the prompt to the LLM. The model then proposes tool calls which are dispatched by the MCP client to its MCP server which executes tools and then calls the resource API. The API returns the response to the MCP server. The MCP client delivers the response to the runtime which calls the model again. And this loop repeats until

[3:21:36] the model is satisfied and returns a response to the user. Now the authenticated user’s token becomes what we call a subject token. This identifies who the agent is acting on behalf of, who it acts for. Now, token exchange needs an ooth client that can execute code. So, this might be a gateway that sits between the MCP client and the third party MCP server or it might be your custom app.

[3:22:09] Now, a custom MCP server can also exchange tokens for downstream resources. The on call agents MCP server should provide a defined set of production infrastructure tools. The prompt and the subject token are sent to the runtime. The agent loop runs and the model proposes a tool call. The runtime authenticates with a special authorization server called a security token service. It does this using its app client credentials or workload

[3:22:39] identity. It also sends the subject token that contains the user’s identity and access. It creates token exchange request asking for permission to access the MCP server for that tool call and only that tool call. So now we have three pieces of info that we’re missing from the demo. We know the identity of the agent that’s requesting access. We know the identity of the user it’s acting on behalf of and we know the level of access that the user granted to the agent.

[3:23:12] Now we need to decide if the requested token should be issued and we can do this with governance policy which is evaluated against what access is requested from what resource, the identity of the agent and the identity of the user. But policies are ceilings. Agents can do things you didn’t intend even when policy overall allows them. This brings us to something called intentbased authorization or IBA. Now

[3:23:43] IBA checks what you mean before the agent acts. Now it’s not a finalized standard. They’re still accepting proposals. So this is Keycar’s approach to implementing intentbased authorization. Now IBA can use a gateway as a policy enforcement point. When you send the prompt to the agent, it proposes a mission. Now, this mission includes a goal, maybe allowed actions as well as limits to what the agent is allowed to do. So, a goal of triage

[3:24:16] incident 2294 means read that ticket, summarize or escalate, but don’t read other tickets and don’t use other services. So, the security token service receives this mission. In this case, a low-risk activity like just assessing a ticket might be auto approved under admin policy. On the other hand, if we’ve already read the ticket and then we ask to remediate a usage spike, then the mission adds permission to scale the service once but

[3:24:46] not use other tools or APIs. Now, in this case, the mission is presented for the user to review and approve. Once approved, the security token service gives the mission an ID which is sent to the agent. The tool calls include this mission ID and are proxied by the gateway which uses the ID to ask the security token service if this tool call fits the mission. If it does, then the gateway requests a token exchange for access to the MCP server for that specific tool

[3:25:19] call. The STS evaluates policy. It evaluates the delegation chain and it looks at the requested access. Now, if everything looks good, it issues an access token for the MCP server and it keeps the user subject as well as adds the app that performed the exchange, which is in this case our on call agent. Now, this token should expire within minutes and we should never store it. It’s ephemeral. The STS sends it to the

[3:25:49] gateway which calls the MCP server. The server then validates the token and authorizes the tool call. Now, some tools need external resources. So, the MCP server then asks the security token service to exchange the token that it just received for a token for the downstream resource. Now, the STS evaluates the request against policy and if it passes, then it mints a resource token that’s scoped again to that tool call. It keeps the user

[3:26:22] subject which extends the delegation chain and allows us to be able to track all of the activity. The STS sends the token to the gateway which proxies the request to the MCP server which then calls the resource. The resource validates the token and authorizes access. Now the MCP server should never store the token. It should discard it immediately after the call. The resource response then flows back up

[3:26:53] and the agentic loop repeats until the model returns the answer to the user. So now we’re going to look at the same demo except we are going to use a security token service to manage agent access control with delegated authorization. The demo uses task based policy governance, not intentbased authorization, but if you’re going to Agent Con later this month, we’ll have IBA demos there.

[3:27:26] Now, we also now have an MCP server that establishes tools and it provides brokering access to the resources. So, now we’re back to our on call triage agent again, only this time we have authentication. I’m going to go ahead and sign into the on call agent triage app. I’m going to log in with Google to do so.

[3:27:57] And then I get another login screen. Now, this is where I’m going to sign into the Incidex pager platform. So, I get a prompt to grant the on call agent access to my Incidex account. I’m going to let it escalate incidents on my behalf, post notes and summaries, and read the queue. Now, I’m being prompted to log into the cloud hosting platform.

[3:28:29] So, I am going to do that. And I get another consent screen now which allows me to authorize the agent to access some capabilities of compost on my behalf. Now finally I am back on the on call dashboard. Now we have the same queue of tickets only now the audit log looks different. The agent is probably going

[3:29:01] to try to behave the same way it did before. Only now every request is going to go through the STS and policy valuation before a token is granted and the agent will be authorized to act. So we have the same queue of tickets only now the audit log looks different and the agent is probably going to behave the same way that it did before only now every request is going to go through the STS and policy evaluation before a token will be granted and the agent can be authorized to act. So the

[3:29:33] first ticket is that Billy anomaly again the agent tries to read the so the agent is reading the ticket and we can see that it is trying to do the same thing that it did before. It tries to query the customer warehouse, but policy doesn’t allow a credential to be issued for this because customer PII doesn’t belong in an agent’s context or in an incident ticket.

[3:30:05] So, the agent proceeds without the customer data and it escalated it to the morning team. Now we have the website security certificate expiring. Now this is something that the agent has permission to do. So when it requests

[3:30:36] credentials to do this from the STS access is granted and it can call the cloud hosting API and resolve this ticket. Now you can see all of the calls that it’s making and who is making them. So we have the on call triage agent that is requesting to renew the certificate. It’s asking for permission to call the appropriate tool from the pro infra MCP server. So it gets a token for that.

[3:31:08] After that, the MCP server is going to request access to that cloud hosting service in order to renew the certificate using the API. So, if we move on to the billing database, it’s going to read the ticket through the incident API. It’s going to come to the same conclusion that it did before. The agent knows that this is a drop and

[3:31:39] restore procedure, but this time policy forbids an agent to drop a production database. A human’s got to do this manually. And we can see this in the audit log where the STS refused to grant the token exchange for access to the database delete. So now we have our orders are stuck. The main server is frozen.

[3:32:11] The agent’s going to go ahead and read the ticket. It wants to restart the main server. This takes production briefly offline. It informs me about this and this time it’s actually asking for my approval to do this. So I’m going to click approve. However, this was also blocked by policy and the reason for this is because my user does not have the role necessary to take this action. Right?

[3:32:41] So the agent can’t do it but I can’t do it either and the agent is acting on my behalf. If we move to the site failing for one and three users again, the agent wants to add more servers and it’s going to ask for permission. It’s going to say what we’re committing to when we do this. I’m going to go ahead and approve this. And this is something that my role does

[3:33:12] have the authority to do. So the scale goes through and this ticket is resolved. So we can see that the agent access problems are solved. We know the user and the agent identity all the way down the chain. The agent has task scoped ephemeral access to the MCP server and downstream resources. And we have human in the loop with access control that’s actually backed by policy. Now access is controlled at the task

[3:33:44] level by the security token service and policy and we retain all key capabilities. Now token exchange is an open standard. It’s well researched and it’s public so anyone can implement it and it interoperates with existing policy engines and standards compliant identity providers as well as things like gateways sandboxes OAF offtheshelf and custom agents CLIs MCP servers software factories agent to agent crossapp access

[3:34:15] plus whatever comes out next week so I hope you’ll consider it to make your agents useful safe and future friendly now my name My name is Kim Maida. I’m the founding GTM engineer and head of Devril at Keycard. And I really appreciate your time today. So, thank you very much.

[3:34:58] Hello everyone. This talk is about the danger of your LLM’s information leaking through shared GPU hardware. If you’re running a model in the cloud on a GPU you share with other tenants, someone next to you can learn things about it. They can tell what model you’re running, how fast it’s responding, and even what kind of work is doing right now. All without touching the data just by watching timing. That’s what this talk so covers. What a co tenants on the same hardware can learn about your LLM from timing alone and what you can do about it. To start, I’m Brian Stores, a cyber

[3:35:30] security researcher employed at Stealthium. At Stealth, we specialized in securing and providing observability into the environments AI systems run on. My area of focus is low-level GPU related security research. That’s something this talk covers. When you share a GPU between tenants, you would expect full isolation, but the isolation provided may not prove to be sufficient. In the case of this attack, the attacker doesn’t even need any special permissions like root access. It doesn’t need any traditional exploit either. The only thing it does is time

[3:36:02] the parts of the hardware that are still shared among tenants. This is a demonstration video of what the victims and the attackers dashboards look like. On the left we have quentry model do difference. On the right the attacker uses a side channel that quentry leaks into as it’s running. From that it determines exactly what model it is and what kind of text is producing right now. These are just the headline things but not the whole story. We can tell which model it is architecture and depth

[3:36:33] within 97% accuracy. We can tell how fast is the coding within 99.3% accuracy. We can tell when and how much, the busy periods, token counts, and the answer length. What we can tell what kind of work it’s doing, codes, jo pros, JSON or retrieval. What we cannot tell though are the actual prompts, answers, or contents, just timing. And all of these on real H100’s serving real LLMs. If you’re using Nvidia hardware, GPU

[3:37:04] isolation is achieved using multi instant GPU or MIG for short. Each isolated MG slice has its own physical compute units and the dedicated VRM that provides hardware isolation on those parts. In our example, the LLM we are serving runs on a slice with three compute units and 40 GB of VM. The attack runs on just one compute units and 10 GB of VM. What’s isolated are compute units, memory capacity, bandwidth quarters and

[3:37:34] false errors. The L2 cache is partitioned per instance too. There is no cross instance eviction. So it’s not shared in that sense. The actual leaks are memory barriers or members which are GPU wide. One instance is barrier still touches every L2 partition on the card. Timing is the one thing that isn’t isolated. So when one tenant is busy, the other tenants only read its get slightly slower. The key point is the a GPU wide memory barrier takes effect in

[3:38:06] every L2 partition on the card. The next slide builds the whole attack on that one fact. The vector is that the attacker only ever reads its own memory. It only times its own reads. It never touches the victim’s memory. There are three steps all from its own small buffer time the load and repeat every five microsconds. This primitive and the MIG member leak itself isn’t our discovery. It goes to the researchers behind behind bars at

[3:38:36] using security. A big thanks for their work. Now try looking at the timing differences with the naked eye comparing your tenants idle versus serving an LLM. You wouldn’t even be able to discern them. The median latency is only three microsconds higher. to the attacker though those three microsconds are all it needs. That’s enough to gather all the information we already talked about. Quentry with 8 billion parameters is running on the victim slice throughout

[3:39:07] this one. All captured data was taken from a live model. At the top is GPU activity over time one per token. Below is the frequency spectrum of the attackers on latency trace. There is a fundamental at81 hertz which is just tokens per second plus harmonics since each token is a mix of distinct frequencies not one clean one. This is a real trace one token in the time domain. The token shows a total of 39 bumps. The bumps with green peaks are

[3:39:39] the layer invocations while orange ones are additional between layer processing. In the later slides, we will demonstrate how we determine the actual layer counts even with those extra bumps are present. Here we look at the decode speed itself. Just by timing, we found the token ray completely bind. So speed alone is something an attacker can recover accurately. But speed by itself isn’t a clean fingerprints. Quantry 8 billion and llama 38 billion decode only 1.6%

[3:40:10] apart in their token rate. So from speed alone, you’d think they’re the same model. It narrows things down, but it doesn’t nail it. We need something sharper. Layer counts. That’s what the next few slides get into. We use the same fold and average thick from before. This time we run it once per model instead of once per token. What comes out is a bit count that lands almost exactly on a whole number. The mean distance from an integer across 22 traces is just 0.028. 0 to8. That’s the

[3:40:43] tell. If this were just a fixed hardware artifact divided by different rates, it’d expect fractions, not whole numbers. Each count works out to the model’s layer count plus one to true, one to three additional picss. Every model keeps its own signal fingerprints, a mix of tempo and harmonic structure. To be clear, this is not a trained machine learning classifier. There’s no training set, no labels, no configuration. It’s under 30 lines of code. The method checks each

[3:41:15] candidate’s depth from 16 to 48. It measures how strongly that depth’s expected signature shows up in the real trace. Then it picks whichever of its best for quantry 38 billion 36 layers wins clearly by four point times over the next candidate. Because this is a best fit test, not a lookup table. It also works the models it never seen before. That includes proprietary on unreleased ones. since there’s nothing it needs to have seen in the first place.

[3:41:49] And this works surprisingly well. The layer fit classifier also outputs the confidence level across our testing. Only two least confident answers ended up being wrong ones. This same method also picks up fine tunes and distillations that that share the same base model. That’s because the architecture and layer count carry over unchanged. Take three related models as an example. Llama 38 billion promea has 32 layers. Llama 3.18

[3:42:22] billion also from meta uses that same 32 layer backbone with minor upgrades and R1 is still lama 8 billion from deepseek is an improvements on top of that. The per layer timing comes out to only 1.6 600 seconds median latency shifts of each other. The rest of the signal looks the same. Regardless of this, our classifier is still able to discern between them. Now we ask a deeper question on the same channel. Not which model, but what is

[3:42:52] doing right now? We look at four types. Pros, code, JSON, and retrieval. We give a work that’s on every half second based on the last five seconds of timing. out of 40 half second words with 31 rights and four full responses were corre correctly identified by majority votes. This is the same classifier from the video earlier. Mrs. included one condition is worth stating this was measured with speculative decoding turned on. That’s an optin in BLM, not

[3:43:24] the default. Here’s the mechanism. How predictable the text is changes how many drafted tokens get accepted at each step. that changes step time and that’s the signal we’re picking up. We tested 11 configurations dense and mixture of experts BF-16 and FP8. The same figure page showed up every time just at very different strengths. 70.2% spread on GPT or 20 billion versus 0.9% on GLM 49 billion. Then out of 11 round pros

[3:43:55] fastest when the chance alone would only give you one in four. So say the attacker already knows the model from the earlier slides and specular decoding happens to be on. It can also tell what kind of text is coming out. Now we take the shade chip out of the picture entirely. MLG needs the attacker on the same physical die. This attack doesn’t. The setup here is an eight times H100 server connected over an M switch fabric. The victim runs tens of parallel

[3:44:26] across GPU zero and one. The attacker just needs any other GPU in that same server GPU 2 in this case. Per access over NV switch is a real intended feature. It’s how multi-GPU jobs normally work not a bug being abused. MLG tensor parallelism also can’t coexist on the same device. So this is really a different population of deployments, not just the same attack repeated. The probe runs on GPU 2. It pointer

[3:44:58] chases memory that actually is on GPU zero overwing timing every hop along the way. An idle hop takes about 890 nconds. Once the victim starts working that climbs up to 300 microsconds. These are three half seconds captures and you can actually count the tokens by eye. What we lose compared to MIG is the layer bit. It’s below the noise at this distance. So overinking the fingerprints

[3:45:30] we we’re left with is mostly tempo not layer counts. Here we test the five models on identical stinging setup. Only the model itself gives away which one it is. This method gives 79.2% accuracy. Now it fails exactly where you’d expect the tempo to fail. Llama 3.5.8 billion and R1 is still are both 8 billion models that they code three hertz apart. So they blur together where mig’s layer counts would have separated

[3:46:02] them easily. The takeaway is that the envelink signal to noise ratio is work worse than MG’s since it loses the layer bit. But worse signal to noise ratio isn’t the same as safety. 79% against a 20% baseline is still real fingerprints, not noise. First, some good news. Our own product at work on the attack straight out of the box. Delp monitors every single kernel launch across every GPU, analyzes suspicious workloads, and runs them

[3:46:32] through a full alert pipeline, which is something not every vendor can do. Here is what’s made this one stand out. A single kernel relaunched about 3,000 times, hitting the exact same 40 kilobytes of memory over and over instead of moving to new data. only one kilob of data was sent back to the CPU the entire time because the timing itself was the payload not the output. In real terms that is under 600 milliseconds start to finish with fewer

[3:47:03] than 50 tokens of reply. We quot it before the response was ever half typed. So three takeaways. First placement is something operators actually control. So do not put an untrusted tenants. MIG slides right next to sensitive model. Second, know the trade-off. MIG rules out peer-to-peer communication, meaning there is no tens of parallelism on MG. Sharding over NV link instead limits what leaks to timing alone rather than

[3:47:35] the layer counts. Third, watch the C GPU itself. Make sure the host infrastructure is actively verifying that no malicious workloads are running on the hardware. That’s exactly what Seltium does by catching these probe straight from the chrome behavior. Sharing a GPU means timing alone can give away the model, the speed and the workload. That’s true even across envelink without needing any expert at all. Deltium sees this happen in real

[3:48:06] time. Most organizations still don’t have that kind of visibility. Thanks again to the researchers of Behind Bars. This whole talk builds upon their work. Thank you all for watching.

[3:48:41] People have been saying that SAS is dead for a while now. It’s not even a hot take at this point. Why pay someone to build and maintain the tools you use when you could just do it yourself? Just ask your agent to do it. And for me, there’s one missing piece that rarely gets mentioned. And it’s the fact that there’s a gap, a big gap between working software that got oneshotted and software I would actually use, software that sparks joy, that is polished, that feels good. And actually went on a journey to replace a bunch of SAS providers we’re using internally at

[3:49:12] Railway for marketing purposes. And I just built an all-in-one tool that we use. The tool allows us to manage content for the Railway website, change log, blog. We can use it to send emails, post on all of our social platforms at the same time, manage the website’s media. There’s even a mini CRM so that when we’re working with like external creators, we can keep track of that. There is task tracking, launch planning because, you know, you want to coordinate multiple things and when they’ll go out. There’s a calendar and at the same time there’s like comments,

[3:49:42] real-time editing, and it’s all built using agents. I would say I felt the breakthrough when GPT6 came out. And all of this is running on railway. Everything just auto deploys. And let me essentially now walk you through the principles I use to actually make sure that when I want to add a feature, it’s you know actually polished and matches the rest of the app and at the same time the principles that you can pull from and apply when building tools of your

[3:50:13] own. So, instead of doing my talk from my boring office, I decided to switch things up and do it outside. It is absolutely beautiful. Right now, I’m in Edinburgh, Scotland, and it’s just unreal. Like, I’m on a bench outside and this is my view. Definitely a 10 out of 10 bench. Now, this type of talk for me feels a little bit different than what I’m used to because I essentially will walk you through the journey of me building our own internal tools and the opinions I’ve developed. But I also

[3:50:45] understand that the landscape changes very very quickly. So like anything I say might change completely in like the span of months. Who knows? So I don’t know. consider this my disclaimer like but the time of recording is fall 2026 it’s October and yeah so anyway with that out of the way uh let’s talk about the first point which is text hacks don’t matter now a lot of people say that it doesn’t

[3:51:15] matter what programming language you use what framework you use can just ask your agent to build you anything and build is able to do it and while I agree to some extent what I found is when you’re building a tool that you will actually use. When you give the agent a proper codebase with solid abstractions, what ends up happening is whenever you’re working, let’s say, on a new feature, you end up with a much more consistent result that is similar to what you’ve already built before. And the reason is

[3:51:46] like it’s very simple. The agent doesn’t need to reinvent the same like wheel every time it tries to add a new feature or it doesn’t need to introduce new patterns. it will just essentially follow existing patterns. And when it comes to like what you choose, I feel like it kind of doesn’t really matter as long as you have a codebase that is properly structured. But like my go-to choice today is one tanstack libraries for anything when building on the web. And if you’re building anything content

[3:52:16] related, I would say definitely go with payload. Solid experience, great abstraction. I went down like a big rabbit hole of like comparing CMSS at some point because I don’t believe that I should uh build it from scratch even though I can. But again, who knows? Maybe the future will change. But yeah, and that’s kind of like the main first item that I kind of ran into. when you use like a lot of SAS products out there that you actually love that

[3:52:47] you use every day when you’re a user, there’s like a lot of things you don’t notice, but when you actually try to like replicate an experience, you quickly find out how much care and thought goes into different flows. So like something as simple as oh I want to be able to send an email or to publish something you can easily do it by having like a good old you know just [laughter] like server side rendered app with like forms

[3:53:18] that you submit but if you try to build something that is going to be used every day that you will reach for a lot you’re like oh it shouldn’t feel that way and there are kind of like a bunch of patterns that I found that agents don’t typically do unless you explicitly ask them to. And this is my list. So we’ll go through them one by one. And the first one is like autosave. I found that if like let’s say I’m building some form of document editor, autosave is kind of like a table states feature.

[3:53:49] So rather than manually clicking save to save things, you just ask it to automatically save progress in the background and to make sure that it’s like a non-blocking action so that you can let’s say if as you’re typing you’re able to type and then it just automatically saves. And one other kind of like step further that you could do is to also prevent the browser tab from closing if there are unsafe changes. So

[3:54:20] it’s kind of like this these two layers that kind of guarantee that whatever it is that you’re working on is just not going to be lost. Now you can also go a step further and to add like real-time collaboration so that you can have like concurrent edits. And again, my agent didn’t struggle at all with adding the feature. It was like, I don’t know, asking about it, reviewing how it would work, and then once that’s done, >> just 700 million tokens later, and I had real time. So, I would say in general,

[3:54:52] this is the first thing that I find agents just don’t do well from a product experience perspective. Another pattern I found that agents completely forget to implement is optimistic updates. So rather than showing your users a bunch of loading spinner whenever they’re taking any action, you essentially show them the success state, you know, optimistically and in the background you’re going to sync whatever change they made. Now if the sync or the operation fails for whatever reason, you just roll it back and then tell them like, oh, the operation didn’t work.

[3:55:23] Now, of course, you shouldn’t blindly have optimistic updates for everything. There are some scenarios where you want to show the user a loading spinner and you’re going to wait to check that everything worked properly. But in general, having optimistic updates makes the overall experience feel significantly faster, much snappier, and it will just feel much more instant. So pretty sure you can just ask your agent like, “Hey, I would like to implement optimistic updates where it makes sense. Let’s come up with a plan.” And it will tell you all the areas where it makes

[3:55:54] sense to do. Again, it’s like it’s not difficult for the agent to build it. You just need to ask and know exactly what to ask for. Now, an extension of optimistic updates, in my opinion, is giving users the ability to undo certain actions. Now, for example, if you ask your agent to implement the ability to delete records, what it will typically do is it will give you a delete button. You click it, might show a confirmation dialogue, you hit confirm, and then it will actually do the deletion. But a much nicer experience is actually

[3:56:26] allowing the user to undo that action. So they hit delete, you immediately remove the item they want to delete from the UI, but you tell them like, hey, you have like a couple of seconds where you could change your mind. And if they don’t do anything, that means you actually want to delete the thing. Then you actually implement the operation. Otherwise, if they hit undo, you just bring back the change. So it’s kind of like you do the operation in the background as well. It’s just kind of a delayed action which kind of ties into

[3:56:57] the next point which is archiving. You should tell your agent you want the ability to archive records and be able to unarchive them because sometimes you want to hide something from the UI completely or let’s say from search results and archiving will be the way to do it and you shouldn’t force your user to be like well if you don’t want to see this you have to delete it and a much better experience is just the ability to archive records. So I think it is a pattern that should definitely exist. Another big one for me is URL state. you

[3:57:28] should ask your agent to persistate in the URL whenever it makes sense of course and it’s so useful because whenever you have let’s say a list of records and you want the ability to filter or sort them and you just have a bunch of like conditions maintaining these things in the URL makes it trivial for you to give them to someone else and then let’s say another team member is just going to be able to see exactly what you want them to see now another small detail that agents don’t implement out of the box is infinite scroll I don’t want to be clicking on load more

[3:57:59] over and over and over or like a next page button as I scroll I should just get the data I shouldn’t need to click next page and then in the end I’ll just see that oh I’ve reached the end it’s a very minor thing but also when you use something every day I think it makes a huge difference now another pattern I found that made the output significantly better is telling the agent explicitly to use existing pages as references when it comes to the UI the data fetching and how works and how the thing is overall

[3:58:30] structured and that made it possible for me to essentially define what good looks like once and then just reuse it for more features. Now to be completely honest sometimes even when you tell the agent like hey use page X as a reference sometimes it just doesn’t follow it. I don’t know if models like get dumber sometimes but sometimes it does happen. But overall, I would say that my success rate is higher whenever I tell the agent to like, well, use an existing page as a

[3:59:00] reference because you also just end up with a more consistent experience. So like as you’re using your app, you’re like, oh, this just matches the other part of the app if they both share like the same concept. So like if two [snorts] parts of the app are essentially lists of records that you can create, update and delete and like list well both of these parts should be pretty much identical. This list kind of brings me to my next point which is whenever you have opinions about something they should be packaged as agent skills and then this way your

[3:59:31] agent whenever it’s building something it will actually follow those skills pretty closely. And as I was building all of our internal tooling, I found myself reaching for three Asian skills. Uh two of them are related to design engineering. So one made it easier to have better UI, better typography, better layouts as well as like better error messages in general. And the second one was a set of design engineering skills that made it easier to just have better animations and other things like that. And then last but not least is the railway Asian skills of

[4:00:02] course. So like everything that I built for us internally at Railway runs on railway of course like everything. So like buckets, databases, the app itself, the real-time server, everything. And for the agent to effectively work with railway and be able to deploy everything, we just give it the Asian skills and it was just able to do it. And yeah, so like once you have all of your agent skills and everything, in my opinion, the final step and I think this is the most important step is

[4:00:32] verification. So the agents typically whenever you ask it to build something, it’s going to be like, okay, I implemented the feature, build passed, test pass, all good, right? But what I found is when you actually try out what happens, you sometimes end up with just like a very broken experience. So once you have like a verification loop in place, it’s like a night and day difference because the agent you can literally see it be like, “Okay, I built this thing. I tried it. It failed. I’m going to fix it.” And it

[4:01:03] just keeps going. And then in the end is like, “Okay, I fully tested it.” And I felt this breakthrough with computer use once it got really, really good. And now everything every time I want to add a new feature I literally just in the end say well you should verify that the feature works end to end and use it by actually running infrastructure and to test things end to end and the agents are very capable of doing this. You just have to tell them and once you have all those pieces I would say you will end up

[4:01:34] with solid internal tools that you can build quickly that work properly and work in a consistent way. And that’s it. This was my list of principles that I use whenever I’m building any internal tools. Hope you found them useful, but more importantly, that you’re inspired to build your own internal tools that feel good, that are polished, and spark joy. And I hope that you too can become your company SAS layer. And with that, thank you so much for watching, and I’ll see you in the next one.

[4:02:29] So, I really love this article from Hannis at DuckDB where he asks if we lost a decade chasing distributed architecture. that presumed compute and storage were slow and expensive. Capability in every era though defines architecture and tooling and the tooling lags behind consistently. We first made compute cheaper than storage and then we gave it to everybody and then we made it faster and every single time architectures undergo this massive change. All of our data infrastructure today is built on the idea that

[4:03:00] transformation is expensive. What if that wasn’t true anymore? I believe we’ve solved the final bottleneck in transformation, general intelligence or judgment, and we’ve made it accessible on tap all along the burrito frontier, which puts us right on the verge of a paradigm shift. So, in this talk, we’re going to cover why single ontologies always fail, the three roles models play in pipelines, intersecting model prior for better results, and burrito surfing. how

[4:03:31] today’s models can tune a workload for cost, speed, and accuracy all at the same time. Here’s a quick example. When Jeff launched, we already had an entity resolution pipeline running, working out Ohio’s campaign finance records and whether they belong to the same person, company, or committee. It was projected to cost about $10,000. Our systems took that new model, worked out where it fit, tested over a dozen approaches, and integrated it. 10 days after that first

[4:04:01] call, we had final ground truth for every donor case in Ohio under $800. That is the power of burrito surfing and just in time transformations. So, let’s get into ontologies are the enterprise version of mind maps. It’s this tarpet that sucks us all in, including me. I talked about a single universal schema when I founded Southbridge two years ago. The popular

[4:04:31] conception, and it’s not wrong, it’s just small part of the picture, is that migrations and ontologies fail because of a lack of buyin. That they’re abandoned halfway through, that organizations and people never switch over. All of that is true, 100%. But buyin isn’t the primary reason. Say if you could integrate and migrate all of your information into a single super schema in the blink of an eye, you still have to content with the truth that there is no super schema. There actually are four schemas. The first one belongs

[4:05:03] to the source wherever the information comes from. Let’s take temperature as an example. Say I ask you to write down the temperature. The source schema is whatever you have access to. your phone which gives you your regions temperature sensor on your desk which is less accurate but it’s more local or your watch but even your patience in following through on my request as part of that source schema. The second one is the storage schema. There’s only so much you can write down. You can’t write down the firmware of the device you’re using.

[4:05:35] You can’t even write the time down to the second because you couldn’t finish writing all of that inside of a second. This is the schema imposed on you by storage. The third one belongs to the decision. Why do I need you to write the temperature down? Maybe I’m figuring out what makes you comfortable, in which case I need temperatures from you spread throughout the day, and I need to make sure that it’s you that’s doing the measuring. Maybe I’m building weather migration maps, in which case I don’t care who does the measuring, but I care a lot about your exact location, the

[4:06:05] time, the device you used, and whether that’s changed. or maybe I’m deciding whether to install sensitive equipment and where and you yourself become this variable that I need to cancel out. There’s a fourth one though which we’ll get to when we talk about prior. It’s this recent addition. The true problem is that you will never know all four schemas at the same time except at the moment that the decision is being made. In almost every enterprise in every home, most of the data being recorded has little idea what it’s going to be

[4:06:36] used for. Take a customer, the first box in every ontology, to billing, a customer is whoever pays. To support, it’s whoever calls. To compliance, it’s whoever we’re on the hook for. And the only time you know is when the decision is known. Should we refund this order? Can we extend this account more credit? Suddenly, what you need to know how and to what degree becomes extremely clear. This is why I was wrong. There is no universal schema. There is no concept of

[4:07:08] a customer that’s divorced from the question that you want to answer. And pulling these schemas together is the process of transformation of making information actually useful. Taking the context that it was recorded in and merging it with the context of the decision and that takes discernment. Doing that merge when the decision space is known instead of ahead of time is what I mean by a just in time ontology. So we’ll come back to descendment with a story from my last job where like most of my job was to make sure that certain

[4:07:39] numbers just did not exist ever before that a little bit about me and us. We are best described as obsessives. Obsessives who embed intelligence into pipelines. Pipelines that can scale, that can run over and over again to take work truly off our hands. and pipelines that can mature in cost, performance and speed all on their own. And most of the work we do in data breaks into three regimes. The first is write ones run

[4:08:09] ones. If you do any kind of development, think of these as monster scale immediately invoked functions. They’re built for something single use like joining a data set, mining information, or answering one specific question and then they get torn down. The second is write many run once where lots of smaller and larger workloads are built for one large common goal. The closest thing you might know is like large migrations, years of records moved out of systems nobody fully remembers. Lots

[4:08:40] of workloads built for one move and verified individually at source checked against the others because all of it only happens once. The third though and this is bread and butter is the most common is write many run. These are repeatable pipelines that are built and maintained over time as we add more information in. And at Sopridge, we’ve moved so much work off the main thread and into these repeatable systems from benchmark design, tracking, coding to making subtitles for movies that we want to watch. Almost everything we do in the

[4:09:12] modern world is a transformation of data or it’s bottlenecked by how hard it is to transform data. And in all of these cases, our job is simple. Make sure people can rely on the results. In just two years, we’ve gone from figuring out how to make early 3.5 turbo level models reliable on things like healthcare, aging, mining research to building Hank wave or open-source harness for data work and then using that to get models to work together at terabyte scale. Today we have systems that can selfoptimize. You give them the problem,

[4:09:44] a way to fail safely, a place to work, and they find the shape of the solution. They pick the right models. They run the pilots. They scale up and they burrito surf their way to the best option they can find. So story time at my last job the question we heard most often was can we make this decision data? And sometimes that was the right question when we had thousands of vessels on the platform. The problem is that we also asked it

[4:10:14] when we only had 50 users. And if you know statistics, you can explain really well why AB testing 50 users is a bad idea. Not because you’re not going to get a result, but because you will. So the only real option was to do not produce a number at all because the moment a number exists, it argues for a result. Today though, it is worse. Interactive agents will always give you an answer. They’ll give it to you quickly. You ask for a transformation, whatever, and you get a confident yes,

[4:10:44] sir. What this means is mistakes add up quickly. Moment in chat can be a prod nightmare forever just waiting to be discovered. The primary reason that this happens is that intelligence as it relates to data work today occupies three separate roles that coding agents kind of mash into one context window. Let’s pull those apart because it’ll help a lot when we get to decision models because they fit into exactly one of these three. The first one is building and designing the pipeline which is breaking down the problem

[4:11:15] writing the early specs authorizing spend. The second one and this is usually confused with the first and given to the same models is working inside the pipeline actually doing the work reading the PDF writing to databases checking results. Before we get to the third one I want to make it clear that these two roles pull in very different directions. The first one wants slower models with heavier, thicker tokens, models that can think more, walk around a problem and see the angles, digest documentation, understand

[4:11:46] how these pipelines get built, and predict how something will do before it even starts, right? Opus or up. The models you want inside pipelines though are the opposite. You want them cheaper, faster, specialized, good at following instructions, repeatable workers with noable defects. You see the same thing in nature. A leaf cutter ant colony for example runs on four different sizes of worker. Small, medium, high, X high. As you watch any system that you design, review or hear about, listen for what

[4:12:17] slots and where in this layer cake makes a big difference. And because we had this distinction, bringing in Jev in this newly exploding class of decision models was very easy because they’re workers built. They’re built for quick contact with information and they’re deployed at the bottom end of large workloads. So third category though, this is something we call the hill climbers or surfers. Models that can take a first run and self optimize. Given the right knowledge, instructions, and an incredibly stable surface to

[4:12:47] stand on, they can try new things, vary budgets to limit cost exposure, debug quickly, take notes, surf their way not just to the right solution, but the optimal one. We call that burrito surfing and we’ll cover it at the end. But first, let’s talk about our experience with Jev. Jev launched on a Tuesday when we were deep into an entity resolution pipeline. You were working on donors in Ohio’s campaign finance. And at this point, a lot of people have seen this chart. We

[4:13:17] talked about the results before and adapted some of the ongoing work to the data set. So, you can download it for yourself, prompts and everything. What we didn’t talk about is everything behind that one arrow and what happened when we ran the same idea on the whole state. Here are all of the architectures we tried. We started with three designs on a small development set. A cheap reasoning model on its own, Jeff with a reasoning model for anything it wasn’t sure about and a reasoning model proposing answers with Jeff checking them on about 200 held out families. The

[4:13:50] cheap reasoning model on its own did as well as Fable for about 2% of the cost. Jeff first got the core answers right, but it missed nine household legs because it had confidently said no to every one of them. So, we rewrote the questions without touching the models or the thresholds. The household question now said what counts as enough evidence and Jeff went from no on all 13 development questions to yes. And as we scaled it statewide, we ran over a dozen rounds of such qualification. Each round

[4:14:21] fixed a definition. What a committee is, what a filer means, when two people live at one address, what does that mean? Every one of Ohio’s 23,317 cases now has a label that says what the answer rests on and how far it was checked. This is the hierarchy we discovered for this specific problem. And here’s everything we learned about putting decision models into pipelines. I’ll leave this up so you can screenshot it. But here’s where the money went. The whole statewide job came to $795 on an

[4:14:52] $800 budget that was set ahead of time. Checking cost about four times as much as doing 5.45 on second opinions, settling disagreements, and the audit against 128 for first answers. And before Jev, we expected this work to cost about $10,000. And now that the pipeline is built and verified, we expect the audit budget for the next state to be close to zero. The most amazing thing is that our agent 4A running on Astra and then later on Opus found most of these approaches

[4:15:23] incrementally on its own by building the system, running it, debugging it, and trying new things. It ran for 10 days, tried over a dozen architectures. Its Hanks ran for more than 4,000 times alongside 90,000 calls to Jeff. Tried practically every model on the paro frontier and the models inside those runs went through roughly 6 billion tokens. And once all of that was done, we wrote what we learned back into our library of aentic patterns. This work leaned on these existing ones and we’re

[4:15:55] adding new tested ones like the checking letter. This is to me the value of taking work off the main thread for humans and for agents because every single one of these iterations was a version controlled hank. They were easy to revert, understand, debug, and critique. So, can models do this natively now? Not quite. They’re missing four things which we’ll we’ll go over. And there’s something that doesn’t go away though as models get bigger and more capable. The prior

[4:16:26] just like humans, models bring their own priors, their beliefs about what should be in the world to every task. This is the fourth schema that I mentioned before, the one the model brings with it. Bigger models in a strange way are worse at this. Sometimes they hold on to their beliefs and argue for them even more violently. Here’s a few that we ran into. One pipeline looked for inind spelled with an underscore. The file spelled it with a capital I and a hyphen. So the model counted 15,658

[4:16:59] in kind contributions as ordinary money didn’t double check the loan payments also disappeared the same way. Another one tried four date formats when the file used to fifth. 99.4% of the transaction dates then came out empty and every row count and dollar so matched. So the agent moved on. Several runs noticed that loan amounts were negative. Decided that the sign was redundant and stored the absolute value and net of 784,000 became 5.3 million of

[4:17:33] debt in the end validated by multiple models. And this is quickly becoming the largest class of error I see across companies at data work as models take over. Sometimes you can solve this just by not vibing by checking results and applying human intuition. And what you’re actually doing there when you do this is interesting. You’re intersecting your priors with the models in that first example. Any human would catch missing in kind contributions if they knew campaign finance or think to check. It’s how we found it. But humans

[4:18:04] speaking as a human on this particular task are expensive. They are slow. They pause timelines. They’re even more nondeterministic than models and they hate interruptions. And but it turns out you can also get really far with cross model prior intersection. On our 200 held out families, Jev and Luna agreed on 194 and none of those shared answers was wrong. Every error sat in the six families where they disagree. Models from different families, different pedigrees tend to disagree more and have different

[4:18:35] priors than models in the same group. For example, the exception, I’m not going to say who, are models that are distilled outside the same company. So with that kind of work, you can shrink the surface quite a bit and the errors along with it down to a much smaller but persistent class of problems that applied to LLMs as a species. So in one benchmark, four different model families produced the same total down to the end because they all shared a sign convention that the answer key didn’t. And once you get that far, the only way

[4:19:06] forward is to list them, look out for them, and apply specific solutions. So going back, what are the four things we’re missing to be able to self-optimize? Number one is a stable deployment surface. We use Hank for this, a harness that takes the fastmoving surface of agent runtimes like cloud code and pi and that exposes a consistent well- tested log and API interface with checkpointing, roll back, budget enforcement, everything built in. Something you can build on. But other

[4:19:37] things fit this description. To be fair, for headless data work, Hankwave, I would say, is still the oldest, most stable, and the most open. I’ll leave the skill up if you’d like to try it. Number two is some way to bound your experiments. You can’t test unless you can control cost, time, and access as resources. The third one is knowhow and methodology. We found that this new class of models can take everything we’ve learned from two years of deployments, agentic patterns, debugging techniques, prompting and apply it to

[4:20:08] complex problems. With the right abstraction layer, you can express it very token efficiently and the models can implement it. The fourth and the most important one is a failure surface. Our committee said, give me a place to stand and I will move the earth. And in our case, we haven’t met a problem or a constraint that we couldn’t iterate ourselves to solving given a stable stack to build on and a failure surface to iterate against. That last one has been the hardest to put into words and into tooling and instructions that helps

[4:20:38] models get there. The current best models are still only barely good at this sparks of intelligence, so to speak. The whole process though involves going through six stages. First, we spec the job and we split it. For Jeff, that means splitting some 800,000 rows into 200,000 smaller specialized cases and each of those cases into typed questions. What kind of donor, one donor, you know, different different questions that needed to get answered. Then we decide the failure surface. In this case, we ran good models on a small

[4:21:09] slice of the data with some of it being manually checked to set a baseline that we can fail against. In other cases, we’ve set automated failure systems. We’ve set schema checks. We’ve also covered behavior as a thing that we can measure against. But it’s very important to have to define a failure surface before you ever start. But now comes the fun part. We run minimal bounded pilots to test architecture. And once something starts working, we move those checks into rigs. Code that runs between

[4:21:39] bounded work segments that we call codons. These codons are then reused, looped independently, validated, and placed in sequence. Finally, working pipelines get deployed to production where they can slowly mature and that middle part is where the surfing happens. We find an architecture that gives a solid result. We use it as a baseline and we swap models and some other parts for faster, cheaper options, compare against known intermediates, tighten the requirements for success each time, moving closer and closer to

[4:22:11] the ideal, and you just watch the frontier move. Being able to break a complex problem into pieces means each piece can move its own to its own best position. As Adam Smith would say in a system like this, ontologies exist as intermediates between intelligence and result, which makes them easier to reuse. That’s the other half of what I mean by just in time ontologies. It’s built when the job needs it, kept with its receipts, and reused when the next job needs the same thing. And once you

[4:22:42] have those, you can make these things cheaper. You can you can run them in parallel across data sets to scale up. I close with an apology, right? That the answer is there is no ontology. Not a universal one. At least there never was one. The good news is that this makes every ontology and schema valid as long as you can label and preserve the context around it. And if we can harness this cheap intelligence is starting to percolate through the world around us, we’re rapidly approaching a future where any information in any format is made as

[4:23:14] useful as it can be. And at Subridge, we’re working as hard as we can to make that future a reality. Thank you.

[4:23:49] Hello, I’m Kartik, CTO at Perpetual. In this presentation, I’ll talk about building workflows that are both reliable and intelligent for finance, wealth, and insurance. In regulated domains, workflows must be reliable enough to meet regulatory standards while still being intelligent enough to handle the real world in fields such as finance and wealth management. This presents both a technical and a compliance issue. Reliability and intelligence are not opposites. It is up to you where you draw the boundary between them. And that is the point of this talk, deciding where that boundary

[4:24:21] lies. For us, it’s not merely a thought experiment, but a question that surfaces serious consequences. Perpetual is a wealth management rollup we acquire running traditional wealth management firms and we maximize their throughput and revenue with the help of AI. Wealth management is a regulated industry and that is where we build with AI in production. Everything in this talk is grounded in building for those constraints. Workflows in finance and wealth management come with four facts and each

[4:24:51] of them pushes the architecture in the same direction. First, they’re complex and they need runtime strategies as the process unfolds. You can’t script every path in advance. Second, the data is sensitive. So, you need a path to move these workflows entirely onto privately hosted models. Third, in a highly regulated industry, a policy violation isn’t a bug report. It has severe consequences. So fourth execution has to be highly reliable and deterministic. Inject intelligence only where runtime

[4:25:21] judgment is genuinely required and minimize reliance on LLMs everywhere else. AI is spreading through regulated industries. But there’s still no consensus on an architecture that gives you high reliability with the least use of LLM intelligence. Meanwhile, most of what developers hear from the big labs is how to burn more tokens. But in a regulated industry, token maxing is the wrong goal. These tasks are close to main. You can lay them out in advance and build them into a massive state

[4:25:51] machine. And that machine needs only a sprinkle of intelligence to navigate it. Most steps just follow the next edge. Only at a few judgment points does the model pick a branch. So the intelligent way to build is to use intelligence minimally and on purpose. Let’s make this concrete with a real wealth management workflow. A wealth advisor calls to their assistant and says one sentence. Fill out the IRS W9 for Mr. Harper. To a person, that’s a simple instruction. Watch what it

[4:26:23] actually triggers when a human being executes it. The task has complexities that go beyond what meets the eye. First, the assistant finds form W9 from the firm’s records or from the IRS website. Then, they look for Mr. Harper in the system of record and find three Harper households. So they call the adviser. Which Harper do you mean? Only once that ambiguity is resolved do they move on to the form. A lookup an ambiguity and a human in the loop all in the first minute of a oneline task.

[4:26:58] Filling a form sounds like data entry. It isn’t. Every form is a small program. A W9 first decides who the taxpayer is, the person or the owner if it’s a disregarded entity. A foreign person stops right here because they need a W8 instead. Then how they’re taxed. Exactly one box on line 3A and an LLC adds its letter. That decides which name goes on line one and which on line two. Then whose number? An SSN or an EIN? Never

[4:27:30] both. Taken from a verified document. Never from memory. Exemption codes apply only to some entities and never to an S corporation. And finally, who signs under penalties of perjury? Each answer changes the next question, and the people involved only ever see three kinds of gates. A question, a document to collect, or a signature. Now, they start filling the form and realize the system of record is missing three of the values it needs. They check

[4:28:01] the documents on file and the system of record again still missing. So they start an email thread with a client asking for exactly those three values. The task now depends on someone outside the firm on their timeline. And now the workflow waits. The request is with the client and all three values are still missing. If the client doesn’t reply within two days, the assistant follows up and brings it to the adviser at the daily standup. If the client

[4:28:31] replies with only two of the three values, they follow up again for the missing one. When all three arrive, they complete the form and write the new information back to the system of record, including the trail of how they obtained those values. In this industry, how you know a value matters as much as the value itself. Once the form is filled, it goes out for e- signature. If the client doesn’t sign

[4:29:01] within a day or two, the assistant nudges them again. Once it’s signed, they file it for the client, send the acknowledgement and update the adviser at the next day standup. One sentence from the adviser became a process that runs for days, crosses several systems, waits on two people, and loops back on itself more than once.

[4:29:34] Look at what’s inside that one sentence. Ambiguity to resolve data to gather approvals weights measured in days. Follow-up loops and an evidence trail at the end. Workflow automation tools exist, but they rarely handle this real world complexity and ambiguity. A fixed flowchart breaks at the first witch harbor and the lack of a native system of record with an integration and an

[4:30:06] agent that improvises its way through is exactly what a compliance team can’t sign off on. One breaks on ambiguity, the other can’t be signed off. Neither handles what’s inside that sentence. So what do we do about it? The fashionable framing is more agency and better models. Given agent, the whole task and wait for the next model to make it reliable. The reflexive answer especially inside regulated firms is the opposite. Less agency, more rules, lock it down and hardcode every path. Both

[4:30:39] are the wrong axis. In regulated verticals, reliability comes from where you place the boundary between the two, between the parts that must be deterministic and the parts that genuinely need judgment. Here’s the principle. Determinism governs control flow, evidence, and side effects. what runs next, what we know and how we know it. And anything that changes the world, like a record written, an email sent, or a form filed,

[4:31:11] intelligence provides interpretation and judgment. Reading and ambiguous instruction, deciding which Harper, understanding a client’s reply, the model answers a typed question, and the deterministic system decides what to do with the answer. And the interplay is recursive. A judgment can open a new smaller plan that’s compiled, gated, and deterministic. Again, you’ll see that in a moment with follow-ups. The boundary between the two is the design. Here’s how that works in the workflow engine we built.

[4:31:50] The request goes to a planner that is a model call and its only job is translation. It emits a typed semantic graph of intents, entities, facts, artifacts, events, and constraints. Each grounded in the words of the request with any ambiguities it found. Every node points back to the words it came from. That graph goes to a compiler that never calls a model in 11 deterministic stages. It turns the graph into an execution tag or it fails closed. There

[4:32:21] are only three verdicts. Valid, needs clarification or refused. Which Harper comes back as a question, not a guess. The plan is compiled, immutable, and pinned by its hash. The model translates. The plan is compiled. The compiler checks the plan against the grammar, the vocabulary of

[4:32:53] what the firm is allowed to do. 42 typed action contracts across forms, documents, email, e signature, calendar, and human steps. Each action the planner asks for has to match a contract. Here, form fill finds its forms contract and locks in. If the planner asks for an action that isn’t in the grammar or wires one up wrong, the compiler refuses. There are about 40 ways to fail closed from a cycle in the graph to an unsupported action. And the same

[4:33:24] contract digest is pinned in the engine, the back end, and the UI. So, all three agree on what an action means. That is what a closed domain buys you. The model can only ask for things the firm already knows how to do safely. Here is a compiled plan for a W9 chase. Send the client the form. Wait for it to come back. Check it and file it. Before anything runs, a person approves the plan itself. Find the form. Prepare it for the client to fill. Render the PDF and draft the email. Drafting is a model

[4:33:56] call, so it is valid. Sending is an action gate. Nothing leaves the firm until a person approves that exact email. Then the plan waits for a reply and a judge steps in to read it. The returned form is verified. If it matches, it’s archived behind another gate. If it doesn’t, the plan follows up. Now look at the dashed steps. Rendering the PDF, attaching it, judging

[4:34:28] the reply. The planner never asked for them. The grammar added them because the contracts require them. In the story, waiting, approvals, and follow-ups were most of the work. Here, there are nodes in the plan, not prompts. A reply weight defaults to 72 hours, and an explicit deadline can be anything from a minute to 30 days. When it passes, a rule decides what happens, not a model. One approval covers the plan and every external action like sending an email or

[4:35:00] a signature request has its own gate. The approval is tied to a hash of the exact payload and it’s checked again right before sending. When a client replies with only part of what we asked, the reply judge marks it partial. That judgment is provisional. The step stays blocked until a person confirms it. A person confirms it and the step unblocks. Then the followup runs as a new child plan. The approved parent is never changed and there are at most five rounds.

[4:35:35] Once a plan is approved, a state machine runs it. It picks every step and records every result. When a step needs judgment, it makes one fixed schema model call. Compose an email, judge a reply, spot missing values, extract fields, verify a document. The answer comes back typed, and the state machine decides what to do with it. Side effects get a life cycle of their own. Prepare, dispatching, succeeded, or when the world doesn’t answer cleanly, outcome

[4:36:06] unknown, and manual review. There are no automatic retries. A chat message can approve a step or answer a question. It can’t change an already approved plan. The model steers. It never drives. Now look at what is left for the model to do. Outside the planner, the judgments are small and typed. Is this reply complete? Does this document match? Which field is which? They don’t

[4:36:36] need frontier intelligence. A fast small model, the flash tier, can handle them. In this illustrative run of 20 decisions, 19 go to the flash tier and one goes to the frontier. That is why we designed for about 95% of model decisions in a workflow, never needing a frontier model. And the flash tier can run on hardware you control. Only the genuinely hard cases go to a frontier model. And the 5% is not a permanent tax

[4:37:07] because every judgment is typed and logged and the provisional ones are confirmed or rejected by a person. Each frontier decision produces eval grade distribution real training data by construction. That data can postrain the flash tier logging and evals exist today. The training loop is next. So the frontier share shrinks release over release until even the hard cases run locally.

[4:37:40] Remember the requirement we started with because data is sensitive you need a path to move workflows entirely to privately hosted LLMs. So can this design really get there? Take one type call from the Harper BB9 plan. Every model call is small, typed, and checked against a schema. So pointing it at a privately hosted model is a configuration change, not a rewrite. One line changes and the same answer comes back. Every other call has that same small typed shape. So the same change

[4:38:13] applies to almost all of them. That is how about 95% local inference becomes viable as an architectural consequence, not a policy promise. That is the path that sensitive data demands and compliance risk goes down as an engineering road map release by release. So if you remember one thing, don’t ask whether your system should have more agency or less. Ask where the boundary is. Let determinism govern control flow, evidence, and side effects. Let

[4:38:45] intelligence handle interpretation and judgment. At typed points, you can inspect and use every judgment you log to need less of it. Next time, ask where the boundary is. Thank you. I’m Karthik, CTO at Perpetual. If you’re building AI into regulated work, I’d love to compare nodes.

[4:39:27] Hello everyone and welcome. My name is Edu and alongside Javi, we represent the AI platform experience team at Flywa. Our core mission is to build practical agentic infrastructure that empowers our sovereign engineers while following our established engineering standards and practices. Today, we’ll share how structure workflow automation delivers real enterprise value, ensuring control, safety, and reliability across our development process. Before we dive into the deep technical

[4:39:58] details of our AI platform, let us give you some essential context about Flywire. Flywire is built to process the world most complex payments across global industries like education, healthcare, travel, and business services. Today, we serve over 5,000 clients across more than 240 countries around the world. Because we process high value international transactions, regulatory compliance, privacy and security are not optional add-ons. They

[4:40:28] are core requirements of our business. We operate under strict compliance frameworks like PCI, ESS and SOCK 2. This means that customer data, personal identification and payment details must remain completely safe. We cannot simply take sensitive context and pass it to third party services without strict governance and architectural boundaries. To give you an idea of our engineering organization, we have around 400 software engineers distributed globally

[4:41:00] across our teams. We maintain diverse technology stacks including Java, Ruby, Go, Python, .NET, and PHP. Almost everything we build and run is deployed on Victoria, our internal platform as a service that operates on top of GitLab and AWS infrastructure. This bring us to Orbit, our own toile killer. Orbit is an internal platform that eliminates daily engineering is called only where we every day. It also keeps the code base that the other AI

[4:41:31] services and tools we use across flywware can start workflows directly. For example, an engineer will be able to ask clo in Slack cases send can start workflows directly. Victoria it starts. >> Um

[4:42:01] and shares the mer request with the scorecards. measures co >> great sorry I’m good hey everyone I’m ash CTO of modal and I’m going to talk about really need from their infrastructure so I I’m told this audience is uh very finance adjacent so I thought I’d talk about what if

[4:42:34] Every cell in a spreadsheet could be backed by an agent. And uh imagine you’re a financial analyst at a fund. You want to run a complex analysis on every company in your portfolio. Normally in the past, this would take days. You’d have to connect every portfolio company, look at their data sources, uh run some Python for each of them. Uh and now obviously with agents

[4:43:04] this should be much easier. Well actually one of our customers Hebia built something that’s exactly this. You can go in right now in their product you can uh you have a spreadsheet and you can uh run a query where literally every cell is backed by a different agent. And I wanted to talk about what does building this really look like? Well, uh first every agent is backed by

[4:43:39] a modal sandbox. Uh so sandbox is a uh secure environment for running untrusted code. And uh it used to be that every sandbox was onetoone with a container or microVM. That’s actually no longer the case. Uh today actually modal has this uh feature where you can run multiple containers or microVMs inside a sandbox and you actually need to do that for doing

[4:44:09] something like this where um in this architecture you run the harness. Uh the harness is the agent loop that does things like running the calling the model API for inference uh running the tool calls and then looping over it. uh you want to separate that from the place where the tool calls actually run uh for security and isolation and a b bunch of other things. Uh so you have the sandbox that’s running multiple containers including a sidecar. Uh you also want

[4:44:41] shared storage uh because you want your agents to be able to talk to each other and it’s up to you how you uh stripe it like maybe you have every row uh gets the same volume and agents in that row in the spreadsheet can collaborate. Uh and you also want to share storage between your main container and the sidecar for some cases. And finally, you need all of this to spin up really really fast because your spreadsheet can have lots of cells. If someone runs a query, you want to launch thousands of agents and then you want to

[4:45:12] spin them back down when it’s over. So before I talk more about uh that, I just wanted to take a quick aside to talk about what is modal. Modal is a platform of primitives that is built for AI applications. Uh so we’ve basically built this platform for uh from scratch. We’ve built our own file systems, the scheduling and uh the runtime uh to give you really great performance and devx for use cases like inference including LM inference

[4:45:43] sandboxes training and uh functions running a lot of batch processing and whatnot. Uh and today in particular I’m going to talk about sandboxes what this primitive is and how it’s evolving. Uh so if you want to build something like this uh or even further and we’ll talk more about what that means uh what are the primitives you need for that. So the first thing is if you’re building an agent you need a workspace and I have some examples from some of our current customers. You might have heard of ramp inspect. Uh ramp inspect is ramp’s

[4:46:16] internal coding agent that uh I think at this point pushes almost every single PR at ramp. Uh and if you’re building a coding agent, you need your uh repo uh your GitHub repo. You need your dependencies, you need your dev services all in the same workspace uh for each agent. Another example is basis there. What it looks like is your documents might arrive. Your uh agent is then

[4:46:47] triggered to work on them. But then it’s waiting for a response from the accountant and you don’t know how long this could take. Could take many days. When the you want to persist the state over time memory, your usage is going to change. And in the second chart, you can see usage for each sandbox. And uh there’s definitely some consistent trends, but it’s all over the place. So if you were provisioning, this doesn’t make sense. and then reliably get them when the sandbox needs them uh and only

[4:47:19] pay for them for for that duration. The other interesting emerging thing is agents need a lot more uh cloud science where uh pre-process some data on CPUs uh or spin up GPUs for running pre-process some data on CPUs uh or spin up GPUs for running a scientific model. Uh it will offload that to a model sandbox. is a scientific model. Uh it will offload that to a modal sandbox and

[4:47:49] we’re seeing this show up RSI about what happens when you give an agent uh sandboxes to hill client. The next emerging thing is agents are collaborating a lot more and um that means that you share a file system with your sub agent. You share file system. The next emerging thing is agents are collaborating a lot more and um that means that you share a files and files

[4:48:21] with your uh human where uh you’re all collaborating with the same thing and this needs file systems that are fast have consistency and uh devx you can reason about uh something we’re working on with motoral volumes related thing is we’re seeing a lot more self-improvement uh so agents will uh save and update memory. They’ll run background tasks uh which is now called dreaming to update this memory over time. And actually this also just looks

[4:48:52] like files in a file system. But again, you want really great performance from this file system. And the scary thing about agents is they can mess up and uh they don’t really know when they might leak your sensitive data to a German forum or something. So you need to have a lot of control over what they can and cannot do. uh and you need things like controlling what IPs

[4:49:24] can even talk to the agent, how do you authenticate it, uh what domains can it talk to, uh and also if you’re using credentials for talking to services, um basically you want to inject them in a way that the agent cannot actually see them and then exfiltrate them somewhere later. And the interesting evolution of this is we’ve realized that domain um related allow lists are actually um not enough you a lot of our users actually want

[4:49:55] very specific control over uh even like what paths can I talk to uh on let’s say data dog or github like maybe I want to uh reason about specific operations that the agent’s doing and going back to sidecarves we’ve seen this emerging as a pattern where users actually write their own lightweight proxy that has custom rules about what exactly it can do. And RAMP is another example of uh company that’s been using this successfully.

[4:50:26] Uh and the final underrated thing is it’s really important to have really great observability. Uh so going back to the example of auto research and an agent doing a lot of training, uh what happens when the training run fails? uh you’re you want your agent to be able to easily look at the logs of the failure uh reason about what happened and do another iteration with a different set of parameters. And while training is running, you wanted to be able to look at the metrics. You want to look at GPU

[4:50:56] utilization and make sure it’s not stalled. Uh maybe you want to look at the budget and make sure you’re not spending too much on your sandbox. Uh and obviously all of this is really important for humans. Uh but as agents are driving a lot more compute uh it’s we’re spending a lot of time exposing all of this to the agents themselves so they can reason about all of this. All right, I think uh we know what we need. Uh why don’t we have Astra build us an agent platform? Well, I don’t think it’s a good idea. I

[4:51:27] don’t think you should vibe code a sandbox platform. Uh and and there’s three main reasons for that. Uh number one is reliability. I think we’re all painfully aware how hard it is to get right. Uh certain websites we use every day keep going down. Uh and the reason for that is even with AI, it’s actually really hard to reason about the feedback loop of like what happens in the case of this tail event when the system breaks. Uh and this is why you need to be very careful when building systems. Uh

[4:51:59] security is another one. Uh you could vibe code a sandbox platform, but who is going to do all the work to like continually reason about the security boundaries and make sure it’s uh defensible in in an age when everything is evolving very fast. Uh and finally scale. Uh we have a blog post about how we scale to a million sandboxes which involves a lot of very interesting engineering design and reasoning about systems. And this is again something that you kind of don’t want to leave up

[4:52:31] to a vibe coded platform because when you get to scale, you want it to work. Uh and on that point, we’re we’re actually seeing massive scale for for a lot of things I mentioned. So, uh for example, for the snapshots I mentioned, uh it’s growing quite fast. We’re seeing 20 million snapshots a week. uh we’re processing uh about eight pabytes of data uh a day uh for for each of these snapshots and u our users are creating uh almost 2.6 6 million volumes a week.

[4:53:02] Uh, and all of this growing super fast. And just to take a customer workload for personal assistant, you need to create 10,000 sandboxes a second. You need to run um almost a million sandboxes. And they’re not going to last very long. They’ll just last for like two or three minutes. Uh, but when they come up, you want them to be interactive in in less than a second. That’s that’s what this workload really demands. And the other interesting thing on scale

[4:53:35] is you actually cannot get all of this scale from a single cloud platform. The world is actually getting crunched on CPUs as well, not just GPUs. Uh so one thing we spend a lot of time doing is actually aggregating cloud capacity from a bunch of hyperscalers and neoclouds. Uh so our users have access to CPU capacity across the world when they need it. Uh but we cannot rely on one cloud provider to do that. Okay, so where is all this going? I I hinted at this earlier, but the

[4:54:05] harnesses are really good at making use of dynamic environments. And what this is leading to is a lot of separation of the brains, which is the harness uh from the hands, which is the sandbox or the runtime where stuff is running. And um what this means have an example here is the harnesses are going to be able to spin up environments based on what they need right now. They they they’re good at snapshotting them and keeping them around for uh as artifacts

[4:54:37] that they need later. Uh and again adjusting all of this as necessary. So I I think this points at an interesting evolution of the pets to cattle uh analogy we’re all familiar with. Uh to recap, in the olden days, uh people thought of services like pets. Uh each one was bespoke. You had to manage it. Uh you had to reason about this individual deployment uh specifically. Uh and then over time it um with containerization

[4:55:09] and Kubernetes people started to think about it as homogeneous uh templates uh of uh these servers. They’re all the same. You can scale them up and down. If one of them fails, it’s not an issue because our system can heal from that. And I think this is where a lot of people deploying agents are today. They’re kind of using these homogeneous environments and scaling up these agents. But but I think that’s really limiting because the models are so good at reasoning about dynamic environments, snapshotting, uh

[4:55:41] creating lots of environments when needed and working across them. Uh so what what does the new world look like? One analogy here is it kind of looks like an ocean of microbes of all these organisms that are self- evolving and working with each other. Uh, and credit SPI fix for the analogy here. Um, but one thing I’m really excited about is as you give agents these really rocksolid primitives for compute and storage and networking, they will be able to

[4:56:13] actually do a lot more uh by doing the stuff I talked about like spinning up lots of environments, working with each other and being very dynamic. So yeah, I and us at modal really think that great primitives let your agents do more. And uh yeah, if you’re interested in talking about this more, reach out to us. Thank you. [applause]

[4:56:48] Heat. Heat. Heat. Heat. N.

[4:59:18] Heat. Heat. N.

[5:00:05] Heat. Hey, Heat. Heat. Heat.

[5:01:25] What are you doing? Heat. Heat.

[5:02:12] Heat. Hey, heat. Hey, heat.

[5:02:50] Hey, hey, hey.

[5:03:31] Heat up here.

[5:04:50] Heat. Heat. Heat. Heat.

[5:05:44] Heat. Heat. Heat.

[5:06:59] Good everyone. I’m Ryan. I’m the CEO and one of the co-founders of Val’s AAI. I’m going to talk a little bit about going from beyond the model card, how evaluations can be used to measure this jagged frontier. Special focus on finance for this audience as well. Um yeah, so first off talking about model cards themselves, we’ve built uh some of the most important benchmarks over the last couple of years that the major foundation model labs have included in their model releases. So people I think are familiar with artifacts like this. Uh last week we have Sundur talking about our valves index on stage and then uh even just

[5:07:31] yesterday muse models uh was citing our our finance agent benchmark. You know it keeps our lives interesting to have to keep re-updating these slides as new models come out. Had to double check level numbers. You can get a sense of how capable a model is for valuable work. Um but that is actually driving value for a lot of companies. Uh and I think two interesting stats that jump out at me. The groups that are able to actually track AI cost and spend are much much more likely to inferior perform. But we also have fun. The Xac again it’s not immediately obvious which is number one or will be consistently

[5:08:01] two or three. In the X-axis you’ve got cost. In particular it’s cost per task not just token Excelis you’ve got cost. In particular it’s cost per task not just token Excel models that are core. The results may be intuitive unintuitive. Um when we actually build benchmarks one of the most important things that we need to look at is the metric we use to report accuracy. Uh and so you you you have a different takeaway if you pick a different metric. A lot of benchmarks deal with partial credit. And so what this is answering is in expectation. If I were to give a question or task to a model, what percentage of the points would I expect

[5:08:32] to see satisfied by the the the work the work output of that model, especially compared to humans? And then the fully corrected answers metric is more looking at of the percentage of questions that I give to models, what percentage of them will come back perfect. And that’s that’s a very different metric. It may mean uh that a model is very good at producing an incremental response that you can work with to build a better response. Um but if you were to pass this directly to a client, it would be a coin toss of whether it was meeting all the criteria that you have. Uh and so

[5:09:02] picking the right metric is very important to accurately representing the performance of a model and actually forming a good intuition of what it can do. There’s another three components that we think a lot about. So validity. Are you actually evaluating what’s going on in the real world? That means are the questions or tasks reflective of actual work going on or are they contrived? Um and then are the rubrics actually describing what we’re looking for or the standard of excellence we want to see. Reliability. This is usually a function of the number of tasks or the sample count. Um a lot of companies they have maybe five or six samples and they’re

[5:09:33] kind of vibeing new models or products as they get access. Um but it’s actually really important to have a rigorous approach and have enough tasks and samples to make sure your repeated runs actually show consistent results. And then last discriminability. So we we don’t think it’s that valuable to have benchmarks where all models score 100% or all models score 0%. Ideally, we can we can actually discriminate between models and see what the frontier looks like. In particular, we also want to make sure we’re building benchmarks forward-looking. So what are the new set of tasks that are even more ambitious than what models can do today to make

[5:10:04] sure that there’s room at the frontier for us to to continue to see model progress as they get better. Okay. So and then some of the high level problems that we’ve seen and I think others you know can and do run into. The first is that agents solve the test not the problem. So this is talked a lot about as reward hacking. Um and we’ve seen a lot of instances where we’ll have a sandbox and models will be run with our model proxy and sometimes they may try and actually call other models uh within that proxy to escape the sandbox

[5:10:34] or make use of the internet. Uh so it’s really important to to build the the containers in a way that you’re actually testing for what matters. Can they can they do the task at hand or are they actually leveraging other tools or maybe even other models to get there? Um, we’ve also seen this issue in finance in particular where a lot of the times eval are looking at a set of rubrics or or items that we want to see included in the response and so models can hedge and give three possible answers uh which has a higher chance of satisfying all the criteria uh but in practice that’s way way too much. A person does not want to

[5:11:05] consider three different answers. They just want to get the the first answer and and have it be right. Um, and so the goal here is to try and build evals that are reflective of the actual work people are doing and the work output they want to see. Um, not to build these contrived eval that the models can actually gain. The second is I think a lot of people are starting to see that the cost of software is coming down and it’s actually very very easy to produce code but unfortunately we still see in practice that running evals is incredibly challenging especially from an infrastructure side of things. Um and

[5:11:37] in particular as we get to longer running agents it means that it’s really important to have infrastructure that can stay consistent over a long period of time and then if interrupted can be resumed and respun back up. Um we have I think just recently crossed six trillion tokens just in evaluation. Um so we’ve run you know considerable a set of evals and we run everything in as highest degree parallel as possible. Um so I think this has really been load tested but I think other people are going to run to this even on a much smaller scale. Uh and the last is that I think a lot of the existing benchmarks they deal

[5:12:08] with a single prompt, single response, but in practice everything is multi-turn. Uh you have an initial spec which you think covers everything but then you get questions back or you have additional feedback once something’s built and then it takes more of this iteration to actually drive to the end output. And so I I think benchmarks and eval component that’s not going to go away. So to look at a case study in particular when we looked at our team, we did a little token maxing experiment uh where we we got free access to some tools and just gave it to all the engineers. Um and they they really made use of these

[5:12:40] unlimited tokens. Um and and if if we actually look back for that month, we spent $ 1.5 million worth of tokens. This was like a team of I think 10 or 12. So it roughly 10 times the amount we were spending on salary for tokens in that month. Uh and so that was pretty insane. But we saw great output. And so our goal was to try and maintain the same level of output across all these engineers but massively cut cut down on cost and and really our solution to do that was of course to build an eval um we built a bunch of tools internally and then have now exposed this as a product called bell smith and so this is you

[5:13:12] know what we’re doing in coding and I think it’s again a sign of what’s what’s going to come in other parts of knowledge work. Um so what we were able to do is look at the GitHub repo um as a a centralized way of seeing what work has already been done and what work is continuing to happen. Um and in particular GitHub repos are comprised of PRs or pull requests which have a GitHub issue and a resolution. And so what we can do is unwind the clock and give those same tasks to agents to see if they could have equivalently done the work of humans. Um, and in doing that, we found a a much clearer understanding of which models were overkill, were way

[5:13:43] too expensive, and did not need to be used, and then which ones were actually capable of getting the task done. Uh, and I think again, this is another place where the intuitions that a lot of people have may not be what’s actually borne out in practice. So, I think you may see, oh, we’re using a lot of closed source models. We should try and cut cost and use our own self-hosted open source model. Uh, you can see the comparison here we have between GBT 5.6 Soul and Kimmy K3. And we see that 5.6 Soul is better. It’s it’s growing 2% better on this internal eval. It’s also considerably cheaper than than hosting it through a very, you know, inference

[5:14:14] optimized stack. So, it’s 250 instead of $11. And it’s faster half the time. And so, there’s no real reason why um this kind of intuitive sense of using open source would be a legitimate way to drive down costs. Um and so this has resulted in two main differences. one, we can actually figure out which tools we’re going to procure, what the usage limits of those things should be across the organization, but then also we can give recommendations for engineers and say we think that for this GitHub issue, you should actually use this particular coding tool with this model and this is

[5:14:45] able to drive the cost down considerably. I think we’re spending 90% less but still able to get the same output. I think the question I would have for you all, we’re we’re continuing to expand this approach and and take this model of coding to other domains, knowledge work, legal, finance, things like that. But the key question is where are you tracking the history of work that has already been done by that firm? Some of these law firms have been around for like a hundred years. And so where where is that I think quality of the organization stored? Where are you tracking the standard of excellence? And

[5:15:16] so that’s today may exist in places like email from the history of responses that people have had with their clients exist in sharepoints may exist in data bricks dumps. But I think this is the key treasure trove that a lot of companies have and don’t realize will be the major unlock for evals and then the unlock for AI adoption more systematically. Once these evals are constructed they can enable adoption to happen. But we’ve also seen that there’s more advantageous

[5:15:47] ways that they can be used. So first is right sizing. So rather than just token maximizing, how do you figure out what the right usage limit should be across the organization negotiation? Once you realize uh you have actual leverage, you can take that to the conversation you have in bulk pricing. Then routing. This is becoming a core primitive in uh in a lot of AI products. Um but can also be done by users directly. And so they can build intelligent routers that actually figure out the right model to use. And then fine-tuning or post training. Uh

[5:16:18] this this can be the most reliable way for you to actually mint the tasks and then have an external eval set to make sure that this approach is working. Last thought I’d leave you with is I think for a lot of companies they have a competitive advantage that has existed in the heads of employees through things like institutional knowledge. And what evolves allow you to do is actually com codify the competitive advantage and put that down in words or in scripts in language and that will actually be the the biggest unlock for uh making sure that a company succeeds the gentic era.

[5:16:49] Okay, that’s all. Thanks everyone. [applause]

[5:17:35] Heat. Hey, Heat. Heat up here.

[5:18:30] Heat. Heat.

[5:19:19] Heat. Hey, Heat. Heat. Heat.

[5:19:50] Heat. Heat.

[5:20:49] Hey, hey, hey.

[5:21:58] Heat. Heat.

[5:23:30] Heat. Heat. Heat. Heat. N.

[5:24:02] Heat. Heat. Heat. Hey. Hey. Hey.

[5:24:55] Heat. Heat.

[5:27:22] Heat. Heat.

[5:28:55] Hey everyone, how are you? Thank you all for uh for being here. My name is Venu. I’m the CEO of Kepler. Excited to have Jack Woodruff with me. Want to quickly introduce yourself? >> Yeah. Hi, I’m uh Jack Woodruff. I am the founder and former CIO of Candlestick Capital Management, a long short equity hedge fund based in Greenwich, Connecticut. Uh before founding Candlestick uh I was a partner and portfolio manager at Surveyor Capital which is a division of Citadel.

[5:29:26] Very cool. Thanks Jack. Um so the reason we did this this way is we’ve had this conversation before and I think this is one of the most enlightening folks to chat with given that Jack has spent his career picking stocks in an environment that’s changing more than it ever was before. Um, so we’ll treat this really as a as a fireside chat. Uh, so Jack, paint the picture for us. What does fundamental investing look like in the age of AI, say five years from now? Well, it’s it’s hard to say. Like long-term stock picking, I don’t believe

[5:29:59] is really going to change much at all. There’s always been a mosaic and there’s always been alpha creation by finding a divergent view. So that isn’t going to change at all. I I I think that that still will stay the same. Now, how people synthesize all of the information and where table stakes go to in to in terms of like what everybody has and then how you synthesize that data is going to change completely. um the roles the traditional roles of say a portfolio

[5:30:31] manager or an analyst are going to be completely thrown upon their heads and I still think it’s like too early to say what that’s all going to look like as these tools are just so new especially to the users you got a lot of people doing a few things but it’s just not clear to me that it’s like we’re there and oh my gosh it’s going to be these new things like we have we We have a bunch of other things to kind of talk about, but um I think it’s going to be super fascinating

[5:31:02] to to to watch how it all plays out. >> Very cool. >> So at Citadel, you had 18 people covering 400 stocks and at Candlestick, you had 30 stock pickers. Could one great analyst cover all 400 by 2030? >> So the biggest issue is is is humans are still the bottleneck? I mean like at the end of the day uh you have to get the information into your head. So it’s really all about sort of how man and machine can work

[5:31:33] together. Um investment management is a time management exercise. What I mean by that if I spent all of my time working on one stock that’d be great. I’d probably know it better than anyone else in the world. But like if there wasn’t anything to do in that stock, I’d be kind of there there isn’t much to do. Well, if I do two, well then I have half as much time and and so forth until I go. So you start getting diminishing returns uh

[5:32:04] on how much time you could spend on any particular stock. So you know what can AI do? Can AI help me cover more names? Perhaps um maybe it allows me to raise the table stakes on what I just kind of like have as a general knowledge um because that work used to take me hours to prepare to get me ready for what it was and now maybe the you know an AI program can you know help me prepare a lot of that work in five minutes where

[5:32:35] which used to take me six to eight hours. Um, so that allows me to do other things again like it’s a very competitive industry. So it’s not like if I get rid of all these people or if I have like five analysts whereas before I had 30 um yeah maybe those people can do more but now all of a sudden this opens up other time this opens up time that I could spend doing either more proprietary research channel checks um more sort of like industry backdrop work because again like you’re going to need

[5:33:06] to find these divergent views. So, it’s like if if I do the exact same thing I was doing before and it’s like, hey, wow, I can get my work done in two hours. Well, someone else is going to be still working 16 hours a day trying to find like that extra thing that’s going to that that that’s going to make you money. Um because you know just doing this stuff is is obviously like what we used to pay an analyst to do um you know a year or two ago is not what

[5:33:36] we’re going to be paying an analyst to be doing you know in a year. >> Very cool. And on that what’s what is something today that a junior analyst does that you think will be absurd if they’re still doing in five years? >> Well it’s funny like it’s like oh you’re you’re not going to be reading 10ks. they’re not going to be reading, you know, transcripts. I actually don’t believe that to be true. Like I if you’re truly close to a name, um you’re going to still need to like process a lot of that information. Now, you might be able to get like summarized versions

[5:34:08] that can cut down the time it takes you to do those things, but you still need to get that information sort of into your head. Um like we we used to have a lot of analysts that would be going through a lot of like sort of like big data and things like that. I definitely think that that can sort of be outsourced and that’ll be super easy to, you know, I would be surprised if if a lot of these guys aren’t necessarily doing that stuff. But what I believe the AI is going to do or the agent or whoever it is is going to

[5:34:39] be [sighs] pushing you in the right direction to work on the right names. Like I said, this is time management. It’s all about how do I know to work on the right things? And that’s where the winners are going to is going to be is is the people who can figure out how to use these tools to get you to spend the right amount of time working on potentially finding like a divergent view. >> Very cool. And on

[5:35:25] Heat. Hey, Heat. Heat. Heat.

[5:35:55] Heat. Heat.

[5:36:55] All right. Hello everyone. Welcome. My name is David. I lead AI operations at a company called Revolute. We have uh 50 minutes today together. We’ll talk about high performance engineering and self-hosting open source model on dedicated GPU. How’s that sound? >> Cool. So, it’s gonna be a technical one, so bear with me. Um, so maybe to start off because I know

[5:37:25] this is the US and you may not know Revolute. Uh, quick words about our company. We’re a digital bank in Europe. We have 80 million customers. We’re live in 45 markets with the most downloaded financial app uh in Europe for the last year. And as of July, we’re Europe’s largest private company. Um, so we’re doing okay. The the emphasis of Revolute is, you know, shipping a lot of product. And so

[5:37:56] there’s a high focus on engineering culture and uh excellence on that domain. And so we’ll talk about that. So let’s talk about some AI. We have a chart here. You’re going to see two lines. This is a sample of 2,000 engineers performance over the last year. So the green line is going to be lead time. So it’s going to be when engineer picks up a feature until a feature is merged and ready to be deployed. The

[5:38:28] blue line is going to be coding time. So the green line is in days. The blue line is in hours. Just to reset the timeline in case people forget because AI moves really fast. Clothe code came out around February 2025, right? And that’s the CL code at 3.7, the one that would delete your pro database, right? Not the safe cloud and codec that we have today. So bear in mind when we talk about adoption. So what you see on this chart is um

[5:38:58] January 25 first introduced AI, the company, right? Um Gemini, first time people were able to use private data within AI. around February we started playing around with cloud code and then January is when we first launched cl code at scale what you see is um Gemini had 10% improvements in lead time 20% improvement in coding time so that’s people no longer need to load stack overflow and reading documentation but then cl code not so much impact at

[5:39:30] the time so when we launched it we were highly skeptical about the cost of AI we were seeing engineers spend a,000 a month, 10,000 a month with not so much ROI. And so when we launched it, we launched it with strict budget limits. And so we’re looking at the next thing, right? So how can we provide unlimited tokens to engineers so they can use AI guilt-free for a fraction of the cost and so we looked into open source. So around April 26 is when we started

[5:40:01] self-hosting open source model. We’re a big fan of GLM for coding. So around that time what you see uh April 26 GLM51 we see 60% improvement in uh coding time 70% improvement in lead time. So dramatic impact what do we learn from this? Well there’s more impact on the lead time than on the coding time. So what we find is the bottleneck for engineering is not necessarily coding. You can save a lot of time not having to

[5:40:31] dig through your inbox or messing with J and conference. So when you have a limited token, you’re free to do that. You no longer have to save your tokens for the end of the quarter or the most difficult task. So where do we stand? Well, open source is now a priority at Revolute. New economics are favorable. The billing is flat. We don’t have any build shock end of the month. And the frontier is the exception. So obviously we keep using codeex code. The latest model are

[5:41:03] fantastic. uh Jim and I are going very well very good as well but um we keep them as exception so how do we get there some metrics that matter when you’re self-hosting model so to serve 200 engineers we roughly need 56 B200 and that’s to host GM53 JLM is a big model right parameters what you want to aim for is sub3 second

[5:41:35] time to first token. This is empirical evidence. As soon as you exceed 5 seconds, my slacking box starts to blow up. And so we know that’s the limit. Terms of throughput doesn’t really matter as much, right? So we serve in terms of interactivity 200 token per second. People are fine to go higher. Um the way people work has changed. We no longer look at the stream of thinking tokens. people run task in parallel and check in when the task is done. But if you want to have high throughput

[5:42:05] and you’re an engineer at Revolute, you just connect after 5 p.m. when the one is on GPU and you can get 800 TPS and then you know it’s a dream. Terms of cost in terms of impact uh self-hosting GLM or blended cost of token is 30 cents per million and so our invoice is onetenth of what we were spending on entropic and open. So there’s a lot of tuning that goes into running open source models.

[5:42:38] If you just get GPUs and upload weights on a GPU and you start doing some inference, you’re going to get terrible performance. It’s because your workload is going to be very dependent um on the parameters that you set. So if you look all the way to the left of that chart, the blue line is going to be demand. So that’s request per second. That’s going to be what’s going to be the bottleneck for your latency for your GPUs. And the red line is what we’re optimizing for. That’s the time to first token.

[5:43:09] So when we started back in April, you could see requests per second around three, which is high but not so high and temp token over 10 seconds, which is very slow. But the data that you see is the same number of GPU. We didn’t increase GPU count. We still have 56. And by the end you see in August request per second we’re over seven and time to first we’re around 1.6. So we’ve had 88% improvement in performance for 76%

[5:43:41] increased demand. So the learning from this is there’s a lot of parameters that you can improve on and you really need to resist scaling if you’re looking to self-host a model. So let’s talk parameters. There’s no secret recipe but the things you could consider are the following. First one long context is a scam. You really need to be mindful that even though you can serve 1 million token 256 256 is really what you need.

[5:44:13] quantization. If you’re running black wall generation GPU, you don’t want to run anything higher than FP4, NVFP4 is best. Roughly going from FP4 to FP8 is a 40% saving in GPU footprint for zero loss in uh precision. Other parameters to consider, tensor palism, even though GLM fits on uh TP4, you don’t have enough KV cache and so maybe a TP8 works better depending on how large your workload is.

[5:44:43] And then on the more zoteric um check your cache it coding test needs to be above 90% cache it and you can look into optimize spec decoding uh sequential prefill pdag all of these. Cool. So now let’s talk about um production setup. GM obviously is a text only model which is a limitation for some people. The trade-off I would say uh we would make every time is get the smarter model

[5:45:14] and figure out how to do image recognition another way. You can easily have a local router. Open codeex is one where you would route any image recognition to Gemini or Luna and keep JM for the main task. If you really need some uh vision model GM FG flash uh works really well. We have our UI designer making great use of it. um turnar around for UI product has gone a really really

[5:45:44] long way and then the last one is going to be about the harness. So all of these endpoints are going to be open AI compatible API with response API and so you can use them inside open codeex codeex app as well works really well and so that’s what we uh we recommend and then um last message and this one is for the CIO in the room there’s been a

[5:46:16] lot of stigma in using Chinese uh open source model. So the thing to consider is you’re not using the inference dedicated endpoint that goes to China. You’re just getting the weights and putting them on a US-based service. So for data sharing side, this is totally fine. Revolute in particular, because we’re a EU regulated bank, we fall under the most uh strict regime in terms of compliance. And so what we find that

[5:46:47] works is all of these coding task are not considered autonomous agent. They’re always with a human in the loop. And so how do you give reassurance that you have a human in the loop? You start by creating a sandbox that guarantees that. And the sandbox means now if you’ve used codeex code, it has all these features of approve for me. You just have to set the rules for the operations that you don’t want to allow. So you can allow grab but not gradal for instance and that’s going to give

[5:47:18] confidence uh to your regulator that this is not an autonomous agent that needs different supervision. The sandbox also protects you from uh rogue use right you may have bad actor inside your company and you want to shield uh for that. You’d be surprised what you find in a large company. And then the last one is prompjection. not not so much a thing now given how smart models are but always a thing in terms of data privacy we spoke about it so as long as the data sits in one of

[5:47:50] the countries that are in the data equivalency framework so US EU UK Israel you’re fine you can get your GPUs there all of your inference provider or GPU provider are going to have zero data retention by default and then the last thing you need is a very strong uh open telemetry so that if you ever have an incident um you need to be able to go deep uh and look at the logs also gives you some yeah analytics.

[5:48:24] All right, thanks everyone. That was my talk. [applause] Heat. Heat.

[5:49:49] Heat. Heat.

[5:50:39] Heat. Heat. Heat. Heat.

[5:51:27] Heat. Heat. Heat. Heat.

[5:52:21] Heat. Heat.

[5:53:14] Heat. Heat. Heat. Heat.

[5:54:07] Heat. Heat.

[5:54:59] Heat. Heat. Heat.

[5:55:45] Heat. Heat up here.

[5:57:54] Heat. Heat.

[5:58:57] Heat. Heat. Heat. Heat. N.

[5:59:41] Heat. Heat. N.

[6:00:30] Heat. Heat. Heat. Heat.

[6:02:01] >> [clears throat] >> Good afternoon um everyone present here. It’s u it’s been a it’s been a great day and um an absolute pleasure to be here. The topic of my talk today is everyone has AI who has the advantage. I’ll be talking about what the orgs that are doing that are leading in AI with

[6:02:31] their implementation and adoption, what are they doing differently? Um, and so before that, who am I and what’s my POV? So, I’m Dr. Sid Pedicker. I am an AI technology and data exec in asset management. I’ve spent most of my tenure in hedge funds and um investment and academic research. Uh what I’ve done and focused on is lead strategy and build

[6:03:02] specialized teams towards three main verticals. Optimizing efficiency, driving P&L and reducing costs. So um I’ll be following the discussion along with uh two hypothetical companies, company A and company B right at the slider below. Uh these are hypothetical um you know with um with madeup workflows but we’ll be following their journey along um the rest of this

[6:03:34] presentation. So everyone has AI. Who has the advantage? Um before we get started there, first let’s see what the lay of the land is. And recent studies have shown that only about 37% of enterprises that were surveyed are showing a positive contribution to their EBIT and only about 6% of those would be qualified as

[6:04:04] high performers. So that’s about 5% contribution to their EBIT. Other studies earlier in the year have shown that about 66% are saying they’re having a productivity increase but only about 40 and 20% are actually seeing cost reductions and uh revenue growth. So as we know access of AI is widespread yet the impact remains uneven. So

[6:04:35] [cough and clears throat] the question I would ask or how I would think about this is really in terms of three verticals. And the way I think about these three verticals should apply to organizations and individuals alike and it should apply to functions regardless of where you are in that organization. Um so the three main vertical pillars that I think of are

[6:05:06] number one design the right problem number two build shared capabilities and number three compound the advantage. Now before we dive into each of these pillars, there is an idea that I think goes through all these verticals and I think the best leading firms are taking advantage of that and capitalizing on it. As we know throughout time, the only constant in this world has been change.

[6:05:38] What’s different in the AI and super intelligence era is that intelligence has become cheap. Regardless of what your unit of intelligence is, whether it be software, analytics, recommendations, reports, AI is creating an abundance in all of it. And um as we know, more answers don’t necessarily create more value. So what is scarce? What is a scarce resource in an abundant world?

[6:06:11] What what are companies taking advantage of? the leaders at least it’s judgment. What is judgment? Judgment is choosing what matters and how to act when there’s no single obvious answer. It’s the creativity that lets you explore what possibilities are worth exploring. It’s the taste that tells you what good looks like in your given context. It’s the decisions where you can weigh what tradeoffs are worth

[6:06:41] making. Judgment is ubiquitous. It exists throughout your organization on a daily basis. Your seuite, the seauite is asking questions, taking advantage of jud judgment all the time. So are the software engineers, the AI leaders, the portfolio managers and the data scientists. So the question that they’re focused on is given judgment is a finite asset a

[6:07:12] limited capacity the main question becomes where is our best judgment worth spending like for you to hold on to that thought with that we’ll dive into our first pillar design the right problem so questions uh a question that um the leading organizations are asking all the time is they’re obsessed over what is the right problem to solve. Right? It’s tempting to start with the tool. Today we’re surrounded with

[6:07:43] better models, harnesses. We’re surrounded with all these AI tools. We’re surrounded with co-pilots, but that isn’t the way about, is it? At least that’s not the way the leaders are approaching it. Now, let’s go back to our hypothetical um two companies. Let’s say they’re from asset management. Let’s say uh we’re tracking the workflow of two research analysts in these hypothetical um organizations. Well, let’s say organization B starts with the tool, the co-pilot. They’re

[6:08:15] asking where can we add AI to the analyst work? They’re looking at the current existing process to say earning transcript comes in. I discovered a summarization workflow. Let me pass all of this in through my fire hose. Analysts get earnings summaries faster. Win-win, right? Well, not so much. At least not compared to the guys who are leading. And such a workflow of of being a faster horse introduces one key um

[6:08:46] nuance that is you are losing context as you have information um I guess reduction as part of your summarization. So what what is a hypothetical organization A doing in this? Well, they’re obsessed on the right problem to ask. They could be asking why are our material signals reaching us too late? Where do we focus the attention, the AI, the bandwidth, the capability on where is our bottleneck, right? And so it becomes this redesigning of the workflow

[6:09:18] or at least the re-evaluation on what to focus on. That’s what they’re doing different. Now [clears throat] this consideration isn’t particular to finance. It’s across the the realm and function. You know you’re asking the same question on what to focus on whether it be research capacity, decision speed, quality of your data, latency, reliability. It it it traverses all of that. And studies show this. They showed leading studies um on average spend their attention on

[6:09:52] fewer higher quality decisions than the other cohort. So leaders are being more selective in where they focus their attention and what they focus their attention. So it’s great the leading companies have um an idea of what the right problems are. Where do they go from there? Well, they also concentrate their investments in the highest value workflows. I get it and I’ve been uh I’ve been culpable of of something similar where

[6:10:23] you know is AI is almost creating too many opportunities and experimentation can be a good thing but one needs to separate experimentation and the resulting innovation theater or worse the productivity theater which actual value generation Going back to our two um hypothetical companies, what does this mean? Company B is looking at how do we launch the most number of AI pilots. And what that ends up looking like is a a document

[6:10:53] summarization bot here, a co-pilot there, um a a data retrieval bot here. It’s scattered all over the place. Whereas what company A is focused on in their investments is potentially use cases like end-to-end workflows on the research um on the research pipeline. They’re focused on aligning engineering, analytics, AI, capacity and judgment towards a singular focus. And research

[6:11:24] has shown that the leaders spend more than 80% of their investments on these high value use cases, transforming key business functions and creating new offerings. Perfect. We we know they’re focusing on um finding the right problem and they’re also spending deep investment in select workflows. Well, they’re also doing something different. They’re reimagining how work is done.

[6:11:57] I think this is this is key and it goes back to what we discussed previously which is judgment. They’re redefining and reorganizing functions, roles, capacities around this key element of judgment. What does that mean for our hypothetical company? Well, company B might be focused on, as we discussed, I’m getting my earnings transcript. I’m getting my research uh my research reports. How do I summarize it? Maybe I make that faster. Maybe I update my financial

[6:12:27] models faster. Maybe I send my recommendation to my PM faster. Company E A is focused on an entirely different ballgame. Hypothetically, they could be asking the analyst to define the investment thesis and they’re watching and gathering evidence that could refute that thesis or support it. They’d be monitoring continuously. They’d be investigating exceptions and they could be deep diving on, you know, select

[6:12:58] examples that could lead to actual generation of value. So the winners just don’t just automate, they redesign. And studies show that the cohort of high performers are 75% more likely or in practice they actually do redesign their workflow versus 25% of the cohort that doesn’t. So where does this leave us with our two hypothetical companies um and designing the right problem? Company B adds AI to existing workflows. They’re completing

[6:13:30] individual projects and they’re moving to the next initiative. Whereas company A is rethinking how work is done. They’re redesigning processes around AI and they’re obsessing over the the the right problem. That’s that’s the difference in how organizations put AI to work. Great. So they’ve picked the right problem. Uh what what happens next? Um well, we all know in order to actually enable that capacity, you need to build share capabilities across the org.

[6:14:00] And what’s what’s a trend that’s seemingly emerging for for some time now is that the lines between technology and business are converging. And we’re seeing this everywhere. We’re seeing engineers that are moving closer to business outcomes. We’re seeing business professionals that are building tools and automations. And as you can see and imagine, you can have forward deployed engineers, you can have forward deployed product managers, but you could also have the inverse, which is for forward deployed uh portfolio managers. And it’s really this

[6:14:33] combination of getting the right people in the room by breaking down organization silos that the leaders are really leaning on. Studies have shown that uh more and more of the large enterprises are viewing their technology arm as a business growth function. Um and that’s creating an edge for these for these companies. So the other sort of vertical inside building shared capabilities that um is

[6:15:04] probably a personal favorite of mine, it’s um standardizing the core and personalizing the edges. And this is something that isn’t new uh to the technology world. We’ve we’ve built infrastructure, we’ve built, you know, shared modules and system design. But what’s interesting here today is that’s taking a very different shape with the capabilities out there and with the org and the breaking down of silos. And this could look very different depending on where you sit. You could be building shared cores for a you know a team that

[6:15:37] looks very different with analysts and and clients. You could be doing that with, you know, a bunch of analysts or you can do be doing that for software engineers or or data scientists. with the data scientist example in particular that could look very interesting where instead of having oneoff workflows that that is really common in the industry you could build a shared core of the data sets their semantic layers the trade-offs are what worked what didn’t what you know what what some

[6:16:09] data sets do good of where are the gaps and and so on and so forth such that each new personnel becomes almost a plugandplay play module in this system where they can then stand on the shoulder of their predecessors. So what should the next person not have to rebuild? [clears throat] Now what’s also interesting is um you know the enterprise wasn’t really built for agents. Um agents they they work across workflows and applications. They they

[6:16:41] take context, they uh deliberate, they take actions. whereas really the enterprises are focused um previously on uh single human or a collection of them interacting with a single application. So the leaders are cognizant that something needs to change and that they need to modernize um their infrastructure and they’re very self-aware of where they are in their journey. And so studies show that you know 75 71% of the orgs are modernizing their core

[6:17:13] infrastructure to support AI and um you know 6 to 10% um or 23% of them are investing 6 to 10% of their annual revenue in in core system modernization um to take advantage of this. And a common complaint here or a common challenge here is um you know data quality and and the ability to reuse data. Um so great we you know we we have the right people in the room we um have you

[6:17:43] know we have the right knowledge there what is what do we do next and then comes the concept of hey how do we make this knowledge reusable and accessible and that’s where we have you know depending on on the adoption and where where they are you can have different types of team agents where you can have expert agents being subject matter experts you can have workflow agents that work across streams like Slack bots that are creating and opening tickets, they’re closing them and what have you. And then you can have really chief of

[6:18:13] staff kind of agents that keep a tab on what the state of the organization is and what needs to be done. So um you know going back to our workflows a again is looking at this very differently in terms of shared capabilities. Now [clears throat] the last pillar here that I want to draw your attention to is well when does this system really compound? What happens when it’s deployed? Well leading companies what they’re doing is they’re actually thinking about

[6:18:44] it slightly differently. What are failures that can give us an edge that we can learn from? If if there’s a success, how do we make it part of the system? And the way they think about this is, you know, the individual learned but did the system. Is there a way perhaps when they’ve encountered something where they need to make a correction that that knowledge is fed back into the org either through a new tool or context or or or what have you. And um what’s what’s key here is preserving the evidence along with those learnings.

[6:19:18] So um really the last vertical here is AI freeze capacity where does it go being cognizant that you need to redesign your system and really focus it on key metrics that you’re evaluating you’re monitoring and you’re creating a f flywheel off. So where does this leave us for companies A and B? You know, company A has their entire work redesigned. They’re building

[6:19:48] capabilities that compound and they have shared capabilities built. So, I want to leave you off with one final question. Everyone has AI. Who has the advantage? Thank you. [applause]

[6:20:35] Heat. Heat.

[6:21:41] Heat. Heat. Heat. Heat.

[6:22:12] Heat. Heat. Heat. Heat.

[6:26:00] Heat. Heat.

[6:26:34] Heat up here. Heat.

[6:27:20] Heat. Heat. Heat. Heat. Heat.

[6:29:11] Heat. Heat. N.

[6:30:02] Heat. Heat. Hey, hey, hey.

[6:30:52] Heat. Heat. N. Heat. Heat.

[6:32:05] Heat. Heat. Heat. Heat. N.

[6:33:24] Heat. Hey, Heat. Heat. Heat.

[6:34:35] Heat. Heat. Heat. Heat.

[6:35:51] Heat. Heat. Heat. Hey, Heat.

[6:36:25] Heat. Hey, heat. Hey, heat.

[6:37:34] Heat. Heat. Heat. Heat.

[6:38:35] Heat. Heat.

[6:39:45] Heat. Heat. Heat. Heat.

[6:40:44] Heat. Hey, heat. Hey, heat.

[6:42:29] to guide us back into the closing keynotes of today’s program. Please welcome once again to the stage our MC, Alex Lieberman, managing partner at 10X. >> How’s it going? How’s the Who is the most energized in the room? >> Whoever that was most energized. Well, welcome back for the closing keynote block here at AI Engineer New York 2026.

[6:43:01] I’m Alex Lieberman, co-founder, co-managing partner at 10X applied a partner for for Fortune 500 businesses. And we are most of the way through the first session today and hopefully it’s been filled with incredible conversation which I’m going to share a little bit about uh some of the conversations I’ve had uh offstage in a minute. Um but hopefully that the the mix of the programming, the conversation you’ve had amongst everyone has been really fruitful today. Now, before we hop into

[6:43:31] the final block of the day, let’s just take a moment again to give a round of applause to our partners who make this entire event possible. So, let’s start with our presenting sponsor, Arise. Let’s give a shout out to Arise. Yeah, Arise. Next up, we have our platinum sponsors, Oracle, Sonar, Work OS, and Exa. Let’s give a shout out for them. [applause] And then two more. We have gold sponsors. I love them all. They’re all my favorite children. Can’t read them all off right now, but thank you so

[6:44:02] much. Our silver sponsors and to all of our supporting partners who make this possible. Thank everyone. Yeah, I don’t know if that was the first person who said they have the most energy, but that person has a lot of energy. So before we hop into the next block, one thing that I just wanted to share, and I’m sure a lot of you are already feeling this already, is not only is the energy palpable across the room in between all of the sessions, but

[6:44:33] what you realize when you come to AI engineer is that the content is incredible. The speakers that are curated are incredible. The depth by which they talk about the work they’re doing is incredible. But this is also just surface area that acts as a starting point for conversation amongst everyone in the room. And so for me, not only has it been incredible to stand in the back of the room at various points in the day and just listen to these incredible speakers who are truly living in Edge City, but then to use all of

[6:45:06] these conversations, all these talks as surface area to have conversations with folks. So, a few conversations that come to mind that I’ve had throughout the day because of the content. One was a conversation with uh Swix um one one of the people behind this incredible event. We were talking about just the diffusion gap that exists in enterprise AI right now. And just some fun stats for you all. We talked to hundreds of big enterprises at 10X across financial services, healthcare, industrials, etc.

[6:45:38] And the way I think about diffusion of AI across these organizations is almost in in milestones of a race. So the the first big milestone at an enterprise is just adopting a general purpose LLM. Out of curiosity, of the let’s call it 100 firms we talked to, what percentage of those firms do you think have adopted and rolled out an LLM to all of their employees? Someone screaming out a number. 9% I think I heard >> 17 >> 17% so specific uh 90% so 90% of the

[6:46:13] enterprises we work with have rolled out a general purpose LLN under that is people actually getting trained in how to use the technology how to actually use these surfaces in their work that’s like 60% next up is coding agents agents that are actually used within engineering and product workflows that’s around 50% of all the enterprises we’ve been And then the final one where we are truly still day one organization that is around 5% right

[6:46:45] now. So going back to what I said earlier this community really is edge city. The the topics that are being talked about we are going to continue to see those play out over the next 12 24 36 months. I’ve had a variety of conversations like this throughout the day. to fusion gap, uh, open source versus fine-tuned models, how hard it is to hire great AI engineers at scale. And so, as we go about the rest of today, but also as you think about the conference in general, use the content

[6:47:16] as a starting point to have interesting conversations at the edge. With that, I would love to introduce you to our next talk, which is with Frank Long, the head of AI at COTU. He’s going to be talking about a hedge fund as a function. Let’s welcome Frank. [applause]

[6:47:47] Hello. Exciting to be here. My name is Frank. I work at KOTU, which is a technology investment firm across public and private markets. So in our business, what you really need to do is be able to take high conviction bets on big themes and watch those play out. I think honestly a career is the same way. And last year when I joined COU, the bet that I wanted to make was I think that agents will have an even bigger impact in investing than they did at coding. I know that’s a big statement. We’re all here because of the transformation

[6:48:18] transformative impact that AI has had in coding, but I really believe it strongly. And today I want to talk a little bit about the framework that we use to actually realize that impact. So at a high level you can think about a hedge fund as a function that takes in two parameters context external and context internal and spits out one tuple selection size timing what stock how much when right and I think this is a

[6:48:49] good framework to actually to ground our work which is we’re trying to solve this compression problem of how do you take all the information in the and spit out this one simple tupole and the product that we provide is essentially a time series of this tupole that constructs a portfolio. So let’s start from the top which is the very simple philosophy. We use our screens we do every single thing that a human can see in pixels on the screen an agent

[6:49:20] in your building should be able to see via API. Uh the analogy I use is imagine you brought the smartest people ever, the greatest investors alive and you brought them into your company, but you gave them a computer without login to 75% of your services. It’s almost immaterial how smart the system is if it doesn’t have the tools to actually action that. So the two parts external context, right? No surprises here. Think the news, prices, filings, all of that

[6:49:51] should be easily accessible. and not via dragging and dropping, copy and pasting like directly via API. Internal context is just as important, right? So this is your own firm situation. So that might be our current positions, potential liquidity and risk requirements we have around certain names and past case studies or um you know history with a certain sector or stock or management team. That stuff’s all super important. So this is the

[6:50:22] foundation and I think uh no credit to me CO2 has been an amazing leader on this for over a decade. It’s both technological and cultural. We have an amazing data science team, amazing amazing processes, amazing amazing systems that bring all this in. And just as importantly, we have a culture that is super super rigorous and built from the ground up to capture all this insight. For decades, we filed every single note about every single trade, about every single decision we made or didn’t make about what went well and what didn’t go well.

[6:51:03] a context window and get my magic numbers and go home, right? It can’t be that easy to break down this function a bit further, right? So maybe the first step is I take in that external and internal context and I gather it, right? I want to filter out what’s relevant and not relevant. Okay, well I pulled some news articles about the MBA that probably isn’t material to stocks, but oh well this is actually related to some local

[6:51:33] permitting that might actually impact data centers. Like there’s a lot of nuance in this gather step. Um then you’ll see probably the next step is I need to analyze that information and form a view, right? I actually need to think about what that means for the markets public and private. uh and then I need to take that view and turn it into a decision. A decision object has these three parameters, right? These three sort of sub subpieces. So you can

[6:52:04] see every single step has an input and an output and the input for the subsequent step is the output that the previous function generated. I think as an engineer, this is a way for me to conceptualize the problem in a way that makes a lot of sense. But even this it really can’t be as simple as writing three functions. Right? So let’s just to really appreciate the scope and understand the full complexity of the problem. Let’s look into the first step.

[6:52:36] A tiny subpiece of a tiny subpiece of just gathering information. And let’s do a case study on interpreting the news. Right? So it’s probably no secret to you guys that you know news from Asia and Korean media outlets has been super important this year because semis AI have been a huge huge theme in the market huge theme and I think this is an area where AI is poised to have a lot of impact is reading uh Korean language

[6:53:06] news better than our completely non- Korean staff. Right? Uh I think I have a good thesis that this might be a good use case. So you can imagine the first step is I have uh articles. I need to collect the articles, right? So this could be an MCP. This could be a CLI. License the data feeds. Clean the data feeds. There’s actually a lot of ways to do this and a lot of dimensions of freedom for how you can even just write this simple piece. How do I chunk it when I

[6:53:37] pass it to the LM? Do I want to pull the images as images? Do I want to pull the images and then turn the images into text? There’s actually a lot of knobs here. And I almost think about those knobs as like hyperparameters in a traditional machine learning system, right? I think about each of these knobs as something for me to tune and optimize. Obviously, we talked about it. Uh Korean, there’s probably Korean NBA fans, right? There’s probably a bunch of

[6:54:08] stuff that’s not necessarily material to the the names and themes and stocks in our portfolio that really really matter, right? So, I want to make sure that I filter those out. There’s this like translate slash extract slash should I summarize? Should I extract this into some sort of structured form? Again, so so many ways to do this, so many ways to experiment how to expose information to the model. And one of the reasons this is hard is it keeps changing

[6:54:39] and obviously checking checking like our own internal notes our own internal views potential conversations we’ve had meeting recordings against these things we actually need to cross reference those things actually the idea of pulling information from disparate sources and cross referencing them that’s super powerful so you’ll see on on the right here I have code lm lm code person uh there’s many many ways to run these functions. I think about uh oh yeah and finally update potentially we

[6:55:10] update uh our views. So there’s many ways to run these functions. I think of each line as having uh a runner and uh the most obvious one is code. Code is very good. It’s fast. It’s cheap. It’s reliable. So for something like if the prices to earnings ratio is less than 15, I should just use deterministic code for that. Runner number two is statistics, classical machine learning

[6:55:40] and you can imagine fitting a line to a regression for a specific pattern. This is very powerful because you can model much more complex relationships than just pure deterministic code, right? And for even more complex relation, that’s the state of the art, right? It’s probably totally impossible to build a bunch of if statements that can summarize better than a modern LLM. And

[6:56:13] of course, uh people people are important runners in the system, right? So, uh, imagine a function meetings the management team of a company. I probably don’t want to send I mean, I like the new unit robots, but I probably don’t want to send an LLM or an AI agent in to do that. I probably don’t want to send an if statement into that meeting. I think there’s many cases where because of judgment and the ability to navigate the real world. And all of these things, a person is the best runner for a given piece of the function. And I think this is like a super super

[6:56:44] important point. There is no glory in automating things for the sake of automating things. The goal is not to take as many things and make them LLM as possible for us. The goal is about the function. It probably looks something like this. It’s probably not just a linear statement of a bunch of different things. There’s probably all kinds of branching logic and all kinds of ways to actually fork this. So maybe

[6:57:17] I want to collect the information and then translate it and my main goal is to extract quotes and check those against sources to make sure that these are actually things that people said and and that’s my approach. But that might be totally wrong. Maybe actually what I want to do is I want to ddup and then I want to filter and then I want to pull external figures or maybe I want to do something totally different. I actually want to I’m passing in a note first and I actually just want to find other confirmatory data points or maybe I’m trying a red team. Uh there’s a million different ways to configure this. So yet

[6:57:47] again more hyperparameters within the control flow, right? So so many ways to think about just this very simple problem of polling, filtering, summarizing, aggregating the news for LLMs. And each of these boxes probably has an optimal runner, right? So u the optimal runner might be deterministic code for collection, right? I’m pulling last 24 hours for a given source. That’s

[6:58:19] deterministic code. decision models maybe statistical methods a combination right so this probably understates the complexity the reality is most things are multi-runner most things have deterministic code plus LLM plus statistical method or human with LLM in conjunction u the reality is it’s probably combinotaurics between my four buckets and there’s even more buckets than that because within the LLM category I can tune the model. I can

[6:58:53] choose big model, small model, medium model. I can tune X high, high, medium. I can tune. I can choose the harness. I can choose which skills load with the harness. I can choose which hooks load with the skills. So yet again, more hyperparameters within my search space. I have an absolutely enormous amount of hyperparameters within my search space. And this is just for this one tiny problem, right? I’m just filtering the news. So the way uh to think about breaking down these problems is what can I actually compartmentalize in a way

[6:59:24] that we can understand and evaluate Oh, no. That actually shouldn’t be a model at all. That should be an if statement. Or, oh man, LM are really, really bad at translating that to portfolio impact. It should really be a human on that step, but they’re using a deterministic system to help them search and pull the information. It could be all different things, right? And if you don’t have a north star to hill climb

[6:59:55] against, you’re just kind of uh you’re just fidgeting around. And I think I cannot convey enough that this is just one tiny thing we do. Imagine every single data source that we pull in there’s probably more than just three transformations to get them to the intermediate output. So the actual graph of code and funds like CO2 it actually probably looks oh not like this. Uh this is my screen saver. The actual graph probably looks something like this, right? It’s

[7:00:26] probably massively complex. In each of those nodes, we just talked about at least 10 hyperparameters with at least 20 different valid values for them. also absorb culturally organizationally. That is the great challenge of applying AI investing. And beyond investing, what we’re really talking about is

[7:00:58] creating a state machine that can take information from the world and understand it well enough to make coherent decisions. There’s use cases for this far and above uh wider than just investment firms in policy, in nonprofits, in drug discovery, in corporate strategy. I think one of the most exciting things for me about being in forums like this is talking to other people in different spaces with different problems that kind of congeal on the same problem space. I’d love to keep talking about this. I’ll hang out

[7:01:29] in the hallway afterwards. Here are my socials. And thank you everyone for your time. >> [applause] >> And now let’s take a look at frontier models built to act in space and time. Please welcome co-founder and CEO of

[7:02:01] General Intuition, Pim Dit. Hello. Um, I want you to uh zoom out for a second and think about if somebody were to tell you today that we would take all the information on the internet

[7:02:32] and then we would train a model on it and we would use that in order to solve scientific problems that were not on the internet. I think a lot of people would tell you that that’s crazy. Um, and uh what we’re doing um has a lot of parallels to that story. Um, and so if you think about how intelligence works, imagine for a second that you’re in the movie Frozen and you’re Olaf, the the snowman. Um, if if Olaf was an LLM and it there there’s a scene which is one of

[7:03:03] my favorites, which is where he rolls down the mountain and there’s a little stone that come that pops up and Olaf spreads out temporarily, becomes a disassembled snowman and then becomes an assembled snowman. Olaf knows how to do that because Olaf can observe as he is acting. Olaf can unlike LLMs which autogressively predict tokens um constantly part of that behavior is that it’s constantly observing as it is acting. And so um this is the big

[7:03:36] difference between you know when you see LLMs try to solve robotics problems or when you look at native architectures like what we’re working on um it’s very very easy to think of LLMs in the demos you see on Twitter as the thing that will solve everything. There’s fundamental limitations that we see uh where purposebuilt models are a much better fit. Now today I’m going to talk a little bit about what the other side of that coin looks like. Um, and so for us it all started with metal. We built the largest video game recorder in the world. Um, and we think of that as the

[7:04:10] internet. So people use metal to record themselves playing tens of thousands of different video games. And if you think about it, uh, as a human, we can tell operate a robot with the exact same brain that we played that video game. And in fact um in many cases we also can use the same controller. So what this means is that the action space of video games often because of game controllers and the action space of tele operations

[7:04:40] or the real world in many cases is the same. Um and so every single robot below um certain degrees of freedom ships with the game controller. A majority of the supply chains already work this way. And so we thought, what if you just take all of the action data that we get through the video recorder um which associates the inputs and the actions with the actual frames. We label the actions so we understand semantic meaning behind every action. And we use it to give it to a vision- based model. And so what

[7:05:10] you see here on the left is just an intuitive way of how the model works. So you give the model a set of keys to choose from essentially a computer use model. It it it gives frames as the inputs. You can give it a text prompt as well and you send it through API and you say somebody weighs that you wave back in the input space model understands that you have a greed action available. It will output the action associated with that. Um one way of intu of intuitively understanding how this works. So um I’ve obviously simplified

[7:05:42] here because it’s predicting the next token not the next word but bear with me here. Um, LMS took large scale internet data, then trained it to predict the next text token and now use it for writing software. Um, and these are all workloads that are really, really well fit for futures that are not simultaneously unfolding as you are predicting, right? Code is turnbased. You can say something, the model will do something. You can say something again, the model will do something again. And um you can use it for lots of valuable

[7:06:12] work, but at the end of the day, because it’s turnbased, um it’s very very difficult for it to generalize to environments, especially that that include um space and time. And so our models, the way that they work is they’re continuously receiving frames. So receiving batches of essentially um information from the camera of the robot or it could be a screen and it predicts everything as if it were just a video game. So you can think of the way

[7:06:44] anthropic focused on just nailing coding. So you know they were never frontier and just base text generation. They always focused on being the best at generating code. And then what the bet that they made is that more people would start bringing more problems into coding space. If you think of general intuition, our bet is that you can as humans we are generally pixel toaction converters plus senses which in many cases you can convert into pixels as well and you can output actions at the same time and those actions are in this

[7:07:15] case either a keyboard and mouse or a game controller. So the output tokens of the model are um essentially equivalent to that of a enhanced computer use model with more more more actions on the output space to internalize it. So you send frames and you get actions. This works again because every single thing that you see here can control um all of these different embodiment, right? So um as humans we do not know how to predict motor torque. We do not we do not know what

[7:07:47] value to send to a machine. Um there’s this beautiful device that has been made for many years uh which actually does that work for us so we can control them. Most robotics companies today are trying to solve the problem at the endto-end level, trying to predict exact poses or exact um values uh in the motor. Uh instead of just looking and picking up the thing that every robotics company has built to generalize our very limited

[7:08:18] um abilities to have physics understanding and predict values and solve for it. And so our approach is let’s just use that. Um and so Metal at the moment sees about a billion videos uploaded per year. This year on we’re on track for three billion. Um which lead to over a trillion and a half uh action tokens per month. So just for comparison to think about the bet the total amount of data that Frontier Labs use today to

[7:08:49] train robotics models we collect in at the moment half a day. Um, and so, uh, the the the type of bet and again, think of the fact that humans can use the exact same controllers and their eyes to play video games that they can’t upgrade robots. It is the same thing. We just bet on scaling pixel space the same way that anthropic skilled coding space and betting that people will just as we scale data compute into pixel space that people will bring more problems into pixel space.

[7:09:21] And so what happens? Um, all of a sudden you get an incredibly general agent that can go and solve problems on computers in the real world. Um, and in addition, similarly, Tanthropic focuses on doing coding environments. We focus on world models which most of you know us for the mirror release world models to then generate additional environments for these models to learn in. One way of internalizing a big

[7:09:53] advantage of this approach against LMS is if you’re an if you’re an LLM company and you have to bet on the ability to generate environments for your models to learn, you have you have two problems. One, you actually need to spend the compute to simulate environments. And the more realistic you try to simulate, the more expensive that gets. Um, and so imagine you have you want to learn a new thing. You want to learn that new thing in the exact input space of the human, right? So you if if we are learning from

[7:10:23] pixels, we’re we’re learning by looking around. If I’m trying to communicate something, I want my robot partner to observe that exact same thing. And so, um, what what I don’t want is for that to have to go through an LM, for a digital twin to have to be created, for the model to have to get deployed, for there to be a bunch of verifier checks whether or not things are equivalent, and then for the robot to to learn much later, right? And so, one way of thinking about it is when you can learn in the native modality of the human, you can all of the sudden start solving a

[7:10:54] lot more problems a lot faster. What you’ll see when these models come out is they’re significantly faster than any LLM um at doing these things. We because games are so action dense. So what you see right is um one thing that’s interesting is uh use soft for a model predicting multiple actions at the same time. Um we’re able to uh take that action density from gamers and convert them into really complex robotics workloads. So for example, if you are

[7:11:25] operating a drone and you need to make lots of little adjustments, you really really really want to start with games, you don’t want to start with uh tele operations because the human will just take a lot less actions. It has a lot less information. So you want a model that can predict really high APM. Um and so the APM of the data set puts a lot of these problems all of the sudden in reach so that it can do a lot of these actions simultaneously. And as I mentioned, the model doesn’t just understand the key it’s predicting. It also understands the semantic meaning associated with that key it’s predicting which is really important for things

[7:11:56] like um interpretability. So uh we will be releasing the models this year. Um uh we are very happy. I think the correct word would be that we’re we’re stunned by the fact of what these models can do. Um it is uh this is a live stream so I unfortunately couldn’t share the release videos without breaking the surprise but if you’re in New York we are also in New York and so uh we have started doing a

[7:12:26] few demos uh of the model. So if you can know somebody on the team reach out and we can start showing you some of the uh some of the capabilities live. Um but we have essentially one model which can play video games at the highest level and control over 10 types of robots uh using the exact same primitives. So pixels in actions out completely real time. Um and uh we’ll be rolling out early access uh to these models over the next few months. Um we already have some customers that are on them but it’s still uh private so you’re not hearing

[7:12:57] too much about it. But if you scan this QR code, you’ll be able to get the models um [snorts] because we go by who signs up on the weight lists at which times. So um this is a great this is a great moment to get in touch. As I mentioned, we are in New York. I think what you’ll find is similar to how uh Jev and a lot of these decision-making models have kind of opened people’s eyes on what you can do when you have a new architectural primitive. People are ready to kind of do away with the unpredictability of an LLM and put

[7:13:28] something in that is more reliable and faster and you just understand how it’s going to react as opposed to having to work around it. If that resonates, these models are exactly what you’re looking for. Um and all of the sudden um you can start exploring the environments that you generate with LLMs. All of the sudden one of the use cases that I’m really really excited about is well these models they um can take actions as if a human was on the interface and so if you’re doing UX work and you’re trying to understand is this

[7:13:58] an intuitive interface well this is a very interesting way of solving the problem. So all these problems that LLMs can’t solve because they can’t actually explore like a human, you can use these problems to start you can you can start using these models for. So um the way that they’re going to be released is we still expect you to use uh an orchestrator model. So you may use something like Gemini or Astra in order to do long-term planning and and everything. And you’ll be able to plug these into your workloads. Um, and we’re actually the models are so general. It

[7:14:28] is it is genuinely going to I think feel like the early LM days when you have a new toy and you just want to figure out what it does and all the things you can use it for. I my reaction was like that when when I when I first started using the checkpoints and I think I think you’ll have the same reaction. Um and I think a lot of you will just like with LLMs if you’re a bit early and you start understanding these primitives I think you’ll understand uh that you can even build lots of businesses on top of this

[7:15:00] right you know think about for instance um uh a sc a science lab right if you uh all of the sudden if you can reliably orchestrate robots in space and time and they can take text instructions and do things all of the sudden um this It’s a recursive problem, right? Robotics is interesting because one of the big problems of solving robotics is making more robots. And so there are all these businesses that because it’s so bottlenecked by intelligence are going to emerge just from solving this one

[7:15:31] simple problem which is pixels to actions. And I think if you’re early on getting your hands on on these, it will have a similar effect on getting your your hands on early LLMs. Um I am most excited also uh one of the things that that we’re working on which is interesting is if you have any friends or family who uh are um in some way um need accessibility help for using their computer because these models can use computers like a human. All of the

[7:16:01] sudden, for instance, if you’re if you’re uh if you only can use one arm, um all of the sudden the model can allow you to play video games because you can you can use you can just control the mouse and the model [snorts] is predicting the actions for your keyboard. And because the model also understands which actions you’re predicting because that’s the input, right? It’s it’s observing as it’s acting, it will actually just not predict the things that you’re doing and it will just predict the keys. And so it has all these downstream effects of things that you can build on top that I’m an engineer. If you’re interested in

[7:16:33] building in this space, uh, this is going to be the most interesting toy that comes out this year. I uh, I I’m fairly certain. Um, and I also think a lot of the initial usage will sit in simulation. So if a lot of you are into generating environments with Astra or with Gemini, it’s perfect. Now all of a sudden you can have something that can explore it and you don’t have to do it yourself. Um, and it’s perfect timing because of all the environment generation capabilities going going into these models. Um, okay. So, really quickly before I wrap up, um,

[7:17:04] I want to talk about the team. Um, so we are based in New York City. The metal team and the general intuition team is here in New York City. So, if you’re here, you should reach out to us and uh, uh, we can both show you the models. Uh, especially if you want to join a team. I think we’ll we’ll prioritize even higher. uh [laughter] but um uh we really are looking for um people who a want to understand these models as much as we do. So people if you’re really really good at generating novel environments uh typically if you

[7:17:35] have some sort of research uh background but I don’t have a research background so that’s okay if you you know if you um if you come from an engineering background and you’re very very happy to learn this is this is fine too. Um, and ideally what we want is somebody who um, uh, has experience shipping uh, end to end uh, AI uh, products, but it doesn’t have to be on the research side. So, we just want to kind of hire people that understand the entire thing. Um, let’s see. Uh, we have three teams. So, one is world modeling, the other is the

[7:18:07] policy, so the agent, and the other one is working on um, essentially the the data generation and the environment generation. So, these are the main teams. If you’re an engineer, the best one to join is probably the environment generation team. Um, and then you sort of grow into uh getting access to there once. Um, yeah, we I’m very very excited for November. I really hope that uh you’ll be on the lookout. Um, as I mentioned, it will be either late November, early December is the current planning. Um, one more thing, uh, we are going to organize

[7:18:38] three hackathons. Um, so the first is going to be in New York City. It will be mid November. Um and uh we were we will send out um if you sign up for the partner weight list, we’ll send out some emails so that everybody can get access. Uh we hope to see everybody at the hackathons. I think it will be really the first time to get your hands on them the way that we’re playing with them internally now. And uh there will be one in New York City and one in London. So if you’re in either of those cities or want to travel to either of those cities, uh those will be good uh times to meet the team. Um yeah, let’s see. Um

[7:19:11] I have time for one or two questions and then uh I think we can we can wrap. See >> uh yeah how’s it different from so Jeppa is doesn’t train alongside the action labels. So they bet on inferred action labels for the most part which I think like one other way of thinking about it is JPA I think in the limit is the more correct approach but it’s just a lot less practical in the short term because you need to bet on a separate scaling

[7:19:41] law on the action inference itself. Um and we really like Jetpa as a concept. We think it’s a you know we we use some of the things in the models um and uh but at the end of the day it’s it’s an approach not a product. Um, and I think we’ll, you know, borrow concepts both ways. Um, like one way of thinking about it is, um, because we have so much action data, let’s say you’re flying a plane and

[7:20:12] you’re moving the rudder in the back, there’s no way of being able to tell that from the video frames. It’s it’s very very difficult. So our mode on having the action data really transfers better to action sequences than it does to world models and to to generating the pixels. And that’s why we just went all in on training these general foundation models for action predictions. And we we use all sorts of techniques to do world models. You know, we our own we we really like other companies building them as well. Um so

[7:20:42] great one more and then I got to run I think. Great. Um, good. All right. Thank you everyone. Have a good one. Ladies and gentlemen, for our final talk of the day, please welcome to the stage the CEO of Noose Research, Dylan Rolnik.

[7:21:21] Hey everyone. Uh, I’m Dylan Rolnick. I’m the CEO of News Research and today we’re going to talk about building on foundations and platforms that you can actually own. There we go. All right.

[7:21:51] How do you make back a centillion dollar infrastructure and research bet? Labs individually have spent hundreds of billions of dollars training and building ever more sophisticated intelligence system. And the industry as a whole has spent trillions perhaps. The problem is though that the models have begun to commoditize.

[7:22:22] You guys in this room who are hopefully practitioners of AI have known this intuitively. You switch among models readily. You switch between Astra, Fable, Opus, Kimmy, whatever it may be without too much regard for who’s on the back end or what it may be. You want to try the new model. We’ve seen this in data, too. There was some charts going around Twitter this week showing the average cost of a token going down while the total spent on tokens surges and the infrastructure

[7:22:54] costs associated with serving those tokens has stayed flat. Meaning where there used to be margin in a very very performant model, it’s now starting to narrow as we see competition and you know a baseline level of intelligence be available to people. Okay. So, if the models are starting to commoditize and you’ve spent hundreds of billions, trillions of dollars on them, you need to make that back. And you need

[7:23:24] to find a different way to do it. And in my opinion, there are two pretty obvious ways to do it. One, you find a different layer of the stack to compete at. You go down to the infrastructure or you go up to the user. or two, you build God, and you build God faster than anyone else, and you monetize God. If you’re in front of the user, you have an opportunity for stickiness. Stickiness means margin. This is why the fight has largely shifted to the agent layer. Lately, we

[7:23:56] started talking, I heard somebody previously talk about 5% of, you know, a workforce engaging in agents. This is becoming more and more the zeitgeist of where the AI battle is taking place. Consumers though are fickle and they’re terrible customers. Businesses on the other hand spend tons of money on tokens and they have economically productive use cases for those tokens. So if you’re going to be competing at the user layer and you’re going to be bringing this fight somewhere else,

[7:24:28] you’re going to be bringing it to businesses. The best thing to do is to get ingrained in a business because when you’re in a business, it’s hard to take you out, right? And if you think about your business 2 3 years into the future, how much of your workforce as measured by its output is agentic? 70% conservatively, probably more. And if 70% of your workforce is organized by somebody else who may or may not have

[7:24:59] adverse incentives to you, they can be organized into a strike. And so what you would do if you had to make back a trillion dollar investment was you would embed, you would use your asymmetric leverage and you would change the rules of the game or like I said, you would build God. If you succeed at building God, what you would do is you would point God at the most lucrative problems in the world.

[7:25:30] The best shot at earning it back is not to sell it for an ever decreasing margin to others to solve these hard and lucrative problems. The best shot is to solve them yourselves. Labs think that markets are solvable problems and that’s exactly how they view the financial industry as a problem to be solved

[7:26:00] and attractable problem at that perhaps not even a very hard one. Right now though, they know, at least the smart ones know that they don’t have enough context, knowhow or experience in the financial industry to be able to do that themselves. So they will partner, they hire investment banking analysts, they partner with some of the biggest firms on the globe and they start to build their foundation here. My belief is that they will eventually go to the source because like I said,

[7:26:32] that’s where the money is and we’re trying to make back a trillion dollars. And so you might say this is nothing new. We have always been trying to trap people into these games and change the margin and once we have you and you’re stuck, we are able to raise the prices. But the difference is that the stakes are much higher. We’re talking about meaningful deca percentages of the Earth’s economy. And you in this room need AI.

[7:27:04] Everybody has seen what they can do, what these models can do, what agentic systems can do, and there’s no going back. People in this room who are um making decisions, vice presidents and executives and engineers about what they’re building on are going to have to make decisions now about where they grow roots around these tools and processes that will affect the future of these businesses. And whatever you pick, you’ll start to harden. You’ll gain knowhow. It’ll stop

[7:27:36] up the intelligence of the organiza organization itself. You will start to build processes and systems around it. I implore you, do not build on quicksound found quicksand foundations. Build on open foundations. Build on Hermes agent. >> [snorts] >> So, I just spent a fair amount of time convincing you hopefully that the highest expected value move in AI right now is to either trap you and jack up the prices or replace you directly. So,

[7:28:08] why am I standing here? Uh, we view the world very differently. And the first thing I hope you guys will learn about me and about news research is that we built this company primarily for moral and philosophical reasons. And a lot of times in business morality and incentives don’t always align. And when that happens, it’s probably easiest to change your morality. But we think the world is changing and we think it’s different. And for that reason, we think that the best course of

[7:28:39] action is one in which we are both aligned. When we built the company originally, we built it to combat a seemingly inexurable trend towards centralization and centralized control of perhaps the world’s most int most most important technology and most important invention. Noose research was built by and staffed by nerds. Nerds who love science fiction. And we’ve all seen what happens when a centralized entity gets control of godlike intelligence and uses that for exploitation.

[7:29:10] Skynet was, after all, a closed source company. The next thing that you need to know is that there’s no longer really a strong moat in proprietary software. The marginal cost to reproduce a piece of software has plummeted. A few months ago, uh, XAI red released Grockbots and we saw that and we thought, wow, that’s an intuitive user interface. That’s really nice. So we pointed Hermes Agent at it and we reproduced it in a weekend and released

[7:29:42] it as a feature within Hermes Agent open source of course and the game has changed. It used to be that software was difficult to produce and it took coordinated teams of engineers long hours to piler open source and take libraries and combine them together into proprietary pieces of software and then sell that software as SAS. But now the opposite is true. Anything can be reverse engineered. And there are many, many motivated open source builders pointing their agents at

[7:30:13] these different softwares. If the closed competitors do manage to make interesting features, open source will have it not long afterwards. The moes of yesterday were in proprietary IP. The moes of tomorrow are in network effects, reputation, and reliability. What’s funny is that in a lot of ways the labs have always seemed to underestimate their own tools or perhaps they are underestimating the users of those tools and their genius and their

[7:30:43] motivation. This happened and is happening on the model side and we’ll talk about why that’s important. But it turns out that models can fairly easily teach another model to be you know nearly as smart as the original model. And the advantage in a model is very rarely in the architecture or some novel system that was created in a proprietary way for that model. In fact, it’s usually in the quality of the data and the scale

[7:31:14] and [sighs] sorry the uh the model started to re the model company started to realize that the you know scale was catching up and that you could create these things with supplementary quality data by

[7:31:48] teaching one model from another. So they labeled the teaching process distillation and they labeled illicit distillation theft. You cannot call that copyright infringement because copyright infringement would imply that you somehow took every living human being’s written or creative work and then trained on top of it. They also labeled the process of they also trained the models to not assist in the process of training other models and they labeled that safety.

[7:32:26] The next thing that you need to know about agents and about the new world is that agents are like operating systems and they’re like frameworks and they’re a lot more like those than they are like chat bots. And so if you continue to think about your agent as merely a personal assistant, you will forever live on the surface of what it means to engage in agentic systems. And so what do I mean by that? If you guys were here a little bit earlier, there was a presentation about a financial firm and how they think

[7:32:56] about AI and these different inputs that go into ultimately what becomes an investment decision. Agents are really at their heart a system that combines determinism and non-determinism. If you remember from that talk, there are data sources, there are routine code, there are people’s opinions, and there’s judgment. And all these things come together to create what is the new application. The new application is no longer necessary that it is deterministic and solid and cold

[7:33:26] hard code. It can inject intelligence, reasoning, judgment, all of these things together to combine to create the new application. And so as you at your company think about building these new applications, you should be building these systems on foundations that you own. You should be able to swap in and out the models that you want. You should be creating ever more sophisticated towers of

[7:33:56] functionality on top of these core primitives of determinism, non-determinism, code, data sources, judgment, reasoning, intellect, but you should not be spending your entire lives being intelligence companies. What has made you successful this far? Most of you are most likely not agent companies. Most of you are not likely AI companies. You should be focused on the things that you do well. And when the

[7:34:27] state-of-the-art changes and it evolves and what it means to be an agentic system starts to shift, you should inherit that, not rebuild it and maintain it. Remember, these are tools that should make you better. They are not dropins to replace you. Do you know how much energy it takes to create a human? And the beauty of the Hermes agent proposition is that you can run it however you want, wherever you want. Modify it as you see fit. If you’re not having fun anymore, you can take your ball and you can go home. The moat has

[7:35:00] changed. The moat is no longer entrapping you. The moat is in reputation. And that’s what Hermes agent offers you. And so what do I want out of all of this? Well, I want to build a standard. Hermes agent today is the most used and downloaded open source agent in the world. It is order of of magnitude more downloaded than some of its closed competitors. And I want everybody to be able to build on these open foundations because as

[7:35:31] long as one of us us is willing to open source these tools and these agentic systems, water will continue to flow downhill. and I want to be downhill so that I can work with you to provide support, safety, scalability to go along with the world’s best open agent. I’ve seen where this goes and we’ve seen where the moes will lie. Network effects, reliability, and reputation. People are going to continue to solve hard problems with Agentic Systems.

[7:36:02] People are going to solve lucrative problems with Agentic Systems. Somebody is going to earn back the trillion dollar investments that we’ve made. Make sure that it’s you. Make sure that you are in control of your own destiny. You can have your cake and eat it, too. You can have state-of-the-art features and reliability without sacrificing your autonomy. Build on something you own. Build with us. Thank you. [applause]

[7:36:37] And now for a few closing thoughts and remarks. Please welcome back to the stage our MC and the managing partner at 10X, Alex Lieberman. >> Okay, let’s close this [music] thing out. Look at the range we just had in the last 30 minutes. We had Pim talking about world models going from pixels to actions. We had Dylan talking about building agents on owned versus rented land. And then we had Frank talking

[7:37:07] about how they think about leveraging applied AI as it relates to making decisions around investments. Um, first of all, let’s just give a round of appl applause to all the speakers, to everyone who made the event possible, and all the sponsors today. [applause] And then two final housekeeping items before we close out the day. First very important one, go speak to humans. That is housekeeping item one. There’s been incredible content covered today. Again,

[7:37:38] that is surface area for you to be able to connect with others and live in Edge City by having intellectually stimulating conversations. Don’t let the opportunity pass you by. And then second, this is just one day of an amazing event. So tomorrow things kick off again right before 9:00 a.m. So make sure to get here bright and early. Thank you all for coming. Thanks for having me. And see you tomorrow.