Modelos mais inteligentes mataram o harness. O que ainda resta — Jediah Katz, SpaceXAI

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: Smarter Models Killed the Harness. Here’s What’s Left — Jediah Katz, SpaceXAI · Canal: AI Engineer · 18:08 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Modelos de IA, Segurança de IA

Resumo

Jediah Katz explica como o agent harness evoluiu e por que modelos mais capazes tornaram desnecessárias algumas soluções que antes compensavam limitações de programação. Ele descreve um ciclo em que o harness viabiliza tarefas mais difíceis, gera mais dados de uso e ajuda os modelos a aprender novas capacidades. Ainda assim, o harness continua essencial para abrir novas fronteiras de trabalho e oferecer infraestrutura, segurança, confiabilidade e eficiência. Por fim, prevê que os harnesses serão mais flexíveis, usarão agentes como blocos de construção e funcionarão cada vez mais fora do laptop.

Pontos-chave

O agent harness conecta o modelo ao mundo e inclui tanto um runtime quanto camadas de contexto e orquestração.
Modelos mais inteligentes já incorporaram habilidades de programação que antes eram ensinadas ou reforçadas pelo harness.
O ciclo de dados descrito pelo palestrante permite que o harness viabilize tarefas difíceis, gere mais dados e contribua para modelos mais capazes.
Mesmo quando a capacidade de programação se torna comum, o harness pode abrir novas fronteiras de tarefas, como trabalho de conhecimento e coordenação de agentes.
Infraestrutura em nuvem, confiança, segurança e eficiência são funções do harness que não desaparecem com modelos melhores.
O custo por tarefa pode variar entre harnesses mesmo quando os resultados em evals são semelhantes.
Primitives, como subscriptions, permitem que agentes reajam a eventos por meio de uma interface compartilhada.
O palestrante prevê harnesses mais fáceis de modificar, menos detalhes internos expostos aos usuários e mais trabalho de agentes fora do laptop.

Capítulos

Início	Capítulo	Resumo
00:01	O que é um agent harness	Katz apresenta a evolução do conceito e divide o harness entre runtime e camadas de contexto e orquestração.
03:07	Modelos mais inteligentes e o harness de programação	A palestra examina evidências de que modelos mais capazes reduziram a importância de instruções e guardrails específicos para programação.
06:55	O harness abre novas fronteiras	Katz explica o ciclo de dados e usa o Grokbot e a coordenação de agentes para mostrar como o harness viabiliza novas tarefas.
11:44	Infraestrutura, segurança e eficiência	O palestrante aborda requisitos que modelos não substituem, incluindo execução confiável na nuvem, controle de permissões e redução de custos.
14:25	O futuro do agent harness	Katz prevê harnesses mais modulares e fáceis de atualizar, construídos em torno de agentes e cada vez mais executados fora do laptop.

Citações

Um harness sofisticado, hoje em dia, já não acrescenta inteligência de programação. — 05:49

O harness está tornando a si mesmo obsoleto por meio do que chamo de ciclo de dados. — 06:23

Um harness de ponta é necessário para estar na fronteira das tarefas com agentes. — 11:44

O harness de ontem pode estar morto, mas vida longa ao agent harness de amanhã. — 17:36

Conceitos e entidades

Jediah Katz (pessoa): Engenheiro que trabalhou no agent harness da Cursor e apresenta sua visão sobre a evolução dos harnesses.
Cursor (empresa): Empresa em que Katz trabalhou no desenvolvimento de agent harnesses antes de se juntar à SpaceX.
SpaceX (empresa): Empresa à qual Katz diz ter se juntado como parte da aquisição da Cursor.
Grokbot (ferramenta): Produto apresentado como um colega autônomo que coordena agentes para realizar tarefas de programação e outros tipos de trabalho.
Grind Swarm (ferramenta): Harness multimodal e de longa duração usado pela Cursor para coordenar vários agentes e máquinas na criação de um navegador.
agent harness (conceito): Sistema que envolve o modelo, orienta sua execução e o conecta a computadores, ferramentas e serviços externos.
data flywheel (conceito): Ciclo em que o harness viabiliza tarefas mais difíceis, cujo uso gera dados que ajudam os modelos a adquirir novas capacidades.
software factory (conceito): Abordagem em que vários agentes coordenados participam de diferentes etapas do ciclo de desenvolvimento de software.
Hyrum’s Law (conceito): Princípio citado na palestra segundo o qual usuários passam a depender de qualquer comportamento ou detalhe exposto por um sistema.
subscriptions (conceito): Primitive que permite a um agente se inscrever em eventos, como mensagens no Slack ou mudanças no status de um PR.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é Jedidiah, entrei na Cursor no início de 2025 como o engenheiro há mais tempo na equipe que trabalhava no nosso agent harness e, recentemente, vim para a SpaceX como parte da aquisição da Cursor. Então, hoje quero falar com vocês todos

00:32 sobre como o agent harness evoluiu até chegar ao ponto em que estamos hoje e para onde acho que as coisas estão caminhando. E há uma pergunta que motiva esta conversa e que quero responder com vocês hoje: o agent harness está morto? Então, vamos começar. >> [limpa a garganta] >> Aqui está uma versão mais natural e fluida desse roteiro, que soa como uma palestra coesa de conferência, em vez de uma série de pontos curtos. Opa.

01:03 Só queria garantir que todo mundo ainda está com os detectores de bajulação ligados antes do almoço. Não, falando sério. A história começa no início de 2023, quando engenheiro de prompt era o cargo mais cobiçado. Em meados de 2025, isso evoluiu para engenheiro de contexto: alguém que monta programaticamente o melhor contexto para o modelo, em tempo real. E só no início deste ano a indústria chegou ao termo agent harness e engenharia de harness para

01:34 descrever o trabalho que minha equipe e eu vínhamos fazendo há algum tempo. Então, o que compõe um agent harness? O harness é como os olhos e as mãos do modelo. Ele envolve o modelo, o direciona e o conecta ao mundo. Os usuários se conectam ao nosso harness por meio de aplicativos, e então o harness conecta o modelo a computadores e também a serviços de terceiros, como MCPs. Gosto de dividir o harness em duas

02:04 camadas: o runtime e as camadas de contexto e orquestração. O runtime é mais ou menos como a fundação do harness. Ele controla onde o loop principal do agent é executado e como o estado é armazenado, para que o trabalho possa ser retomado. Construir essa fundação é muito parecido com a engenharia de software tradicional. Já as camadas de contexto e orquestração são mais ou menos como o Velho Oeste. É a isso que muita gente se refere quando fala do harness.

02:36 Essas partes do harness controlam quais modelos são chamados, quando são chamados e que contexto recebem. Isso inclui coisas como prompts e ferramentas, claro, mas também compactação da memória e vários truques que talvez vocês não saibam que usamos para fazer o agent se comportar da maneira que queremos. Então, essa é a área em que trabalho principalmente. No ano novo, mais ou menos chegamos ao auge do harness. A Cursor anunciou que havíamos criado um navegador inteiramente do zero

03:07 usando um novo harness de longa duração chamado Grind Swarm. Era um harness multimodal que orquestrava muitos, muitos agents e muitas máquinas, e era muito caro de executar. Na verdade, chegou a derrubar a Cursor talvez uma ou duas vezes para conseguirmos fazer essa demonstração. Agora, como acontece com tudo no mundo dos agents, bastaram alguns meses desde o auge do harness para as pessoas na internet começarem a dizer que o harness estava morto. Tariq, da Anthropic, falou sobre como

03:42 eles haviam eliminado boa parte do system prompt do Claude Code. Garry Tan, da YC, achava que o harness desapareceria e que só as skills importariam. Até eu e meu colega Stefan escrevemos sobre como havíamos removido todas aquelas proteções que tínhamos na Cursor para compensar as lacunas na inteligência do modelo. Antes, tínhamos coisas como um modelo pequeno só para aplicar edições de código a um arquivo, porque os modelos de ponta não eram bons nisso. Também tínhamos todo tipo de instruções específicas para programação

04:13 sobre como explorar a base de código e verificar o próprio trabalho. Então, se todas essas pessoas estão dizendo que o harness está morto, elas estão dizendo que foram os modelos mais inteligentes que o mataram. E há muitas evidências disso. Quero que vocês pensem em um harness muito simples, no qual o modelo só tem acesso ao terminal e a todos os meus segredos. A propósito, por favor, não tirem uma captura de tela deste slide. Este está fora dos limites.

04:43 Então, quem aqui acha que esse harness realmente simples teria o mesmo desempenho em evals de programação que um mais sofisticado? Alguém acha que teria? Quem acha que sim? Quem acha que teria, se vocês… Levantem a mão se acham que teria. Algumas mãos, mas a maioria de vocês sabe que não. Então, alguns estudos recentes tentaram investigar exatamente essa questão. O primeiro, da UC Berkeley, testou sete modelos de ponta em uma série de harnesses, incluindo Pi, Codex e Claude Code. E o que descobriram, especialmente com os modelos mais novos e mais inteligentes, foi que a escolha do harness não fez diferença significativa na pontuação do SWE-bench Lite.

05:16 E outro estudo, da Apple e da EPFL, chegou a uma conclusão semelhante: um harness especializado para MLE não fez grande diferença no MLEBench. Então, o que está acontecendo? Será que é mesmo verdade que o harness está morto? Eles têm razão? Eis o que acho que as evidências mostram. Hoje em dia, um harness sofisticado já não acrescenta inteligência de programação. Acho

05:49 que isso é verdade. Sei que é surpreendente. Mas o modelo absorveu essas capacidades de forma nativa: as coisas que costumávamos fazer no harness para compensar lacunas na capacidade básica de programação do modelo, como ensiná-lo a explorar a base de código, a trabalhar persistentemente por muito tempo com coisas como /goal e a executar testes para verificar o próprio trabalho. Então, por que isso está acontecendo? Acontece que o harness está, na verdade,

06:23 tornando-se obsoleto por meio do que chamo de ciclo virtuoso de dados. Nesse processo, o harness coloca tarefas de programação cada vez mais difíceis ao alcance dos usuários. Com isso, mais usuários conseguem tentar essas tarefas de maneira produtiva com agents. Isso significa que mais dados de programação são compartilhados com os laboratórios. E, por fim, os modelos aprendem a executar essas capacidades de forma nativa também. Eventualmente, os modelos ficam tão bons que o harness pode até excluir as coisas de que precisava para fazer essas tarefas funcionarem em

06:55 primeiro lugar. É um processo muito interessante. É assim que surgem pessoas dizendo que o harness está morto. E, se os modelos são bons o bastante para programar bem em qualquer harness, por que você deveria se importar? Será que faz mesmo diferença qual harness você usa? O harness está realmente morto? Eu digo que não, e há duas razões para isso. Primeiro — e vou explicar os dois pontos —, o harness abre, na verdade, a nova fronteira de tarefas que o modelo pode resolver.

07:26 E, em segundo lugar, há algumas tarefas ou partes do harness, especialmente fora da camada de contexto, que o modelo não consegue absorver. Para começar a falar sobre como o harness desbloqueia a próxima fronteira, quero falar sobre o Grokbot. Quem aqui já experimentou o Grokbot? Posso ver algumas mãos? Ótimo. Vamos lá. Que bom. Então, para quem ainda não experimentou, o Grokbot é nosso colega autônomo que realiza tarefas para você. Não só programação, mas todo tipo de trabalho de conhecimento. E recomendo muito que experimentem. Eu

07:58 não vou tentar vendê-lo demais, mas é um produto novo e revolucionário. Ele já criou uma nova categoria. Vamos falar apenas do harness, porém. O Grokbot tem um novo tipo de harness, que não funciona com base em conversas isoladas, mas em bots coordenadores de longa duração que orquestram uma frota de agents trabalhadores. Dá para pensar nele como contratar um advogado altamente qualificado que lida diretamente com você e é responsável pela estratégia, mas delega as tarefas a uma equipe de assistentes jurídicos. É mais ou menos isso.

08:32 Agora, algo interessante sobre o harness do Grokbot é que mencionei como, na Cursor, acabamos removendo coisas do harness — removendo instruções, removendo proteções — à medida que os modelos ficavam mais inteligentes. Mas, curiosamente, no Grokbot, acabamos recolocando muitas dessas coisas, adicionando novas instruções e novas proteções. Isso porque há muitas tarefas novas nessa nova forma de trabalhar, nos novos domínios que o Grokbot pretende resolver, que os modelos ainda não dominaram. Para dar alguns exemplos desse tipo de

09:03 coisas, apenas algumas coisas em que estamos focados agora quando se trata do Grockbot: há fluxos importantes no site, como criar apresentações de slides e reservar viagens; comunicação. Um colega autônomo precisa manter você atualizado sobre o que tem feito sem sobrecarregar você. Agir ou perguntar é outra questão importante. O Grockbot pode fazer muitas coisas que são meio arriscadas em certo sentido, como enviar e-mails aos seus colegas. Queremos poder fazer isso, mas você só quer que façamos da maneira que você pretendia. E então, é claro, aprender ao longo do tempo a maneira como você trabalha por meio de memórias é outro grande foco.

09:36 Então, aqueles entre vocês que talvez tenham ampliado os limites com agents de programação podem ter percebido que nenhuma dessas tarefas é nova. Mas, para o GrokBot, elas são muito mais importantes, porque todo mundo precisa delas de alguma forma. E, neste momento, no GrokBot, é o harness que está tornando essas tarefas viáveis. É claro que o modelo é uma parte importante disso, mas o harness está ajudando a colocá-las ao alcance dele. Então, voltando ao nosso ciclo de dados, o GrokBot, esse exemplo, nos permite completar a última, a última seta do nosso ciclo, que é

10:09 quando uma capacidade como programação é comoditizada pelo modelo, na verdade é o harness que abre uma nova fronteira para o modelo resolver, dando início novamente a esse ciclo. Então, isso pode significar, sabe, assumir novas tarefas fora do domínio da programação, como acabamos de ver com o GrokBot, ou pode simplesmente significar assumir tarefas da profissão de engenharia de software além da programação em si. Tenho certeza de que alguns de vocês aqui são, sabe, bastante experientes em suas carreiras de software e talvez conheçam o quanto mais

10:40 sênior você fica, menos programação você realmente faz. Então, há muitas outras coisas importantes no trabalho. Essa é a ideia central que eu gostaria que vocês entendessem: esse ciclo e como o modelo e o harness o impulsionam juntos. Mais um exemplo de como o harness pode abrir novas fronteiras: alguns de vocês talvez já tenham ouvido falar da ideia de fábrica de software, em que vários agents se coordenam para resolver todo o ciclo de vida do desenvolvimento de software. Essa visão está longe de estar concretizada, mas há muita atividade no setor, ou há

11:14 muita inovação acontecendo no setor no nível do harness. Para dar um exemplo de como isso poderia se manifestar, sabe, internamente temos muitos canais nos quais alguém pode relatar um bug, e então uma automação faz a triagem desse bug imediatamente. Depois, ela pode iniciar um agent na nuvem para tentar corrigir o bug, e esse agent usará nossas ferramentas para mostrar vídeos de antes e depois, comprovando que o problema foi corrigido. Então, quando essa correção é implantada ou integrada e começa a ser implantada, temos nosso produto de rollouts, que inicia outro agent para monitorar a produção

11:44 em busca de quaisquer problemas. Então, vocês podem pensar em tudo isso quase como um meta-harness, que orquestra vários agents em conjunto. É assim que eu gostaria que vocês pensassem sobre isso. Essa é a primeira razão pela qual vocês deveriam se importar com o harness: um harness de fronteira é necessário para estar na fronteira das tarefas agênticas. E a próxima razão é que há algumas partes do harness que o modelo não consegue absorver. Então, vamos falar sobre elas.

12:16 Primeiro, há a infraestrutura e o ambiente de execução necessários para tornar confiável um colega autônomo. No último ano e pouco, passamos de agents que trabalham em uma tarefa típica por minutos a horas, a dias e até mais. E simplesmente não há como isso funcionar no laptop de uma pessoa, que pode entrar em repouso. Ele precisa estar em execução na nuvem se você realmente quiser um colega autônomo. E, em seguida, temos confiança e segurança. Sim, como vimos antes,

12:47 um harness simples, só com bash e todas as suas chaves de API em um arquivo, pode resolver tarefas de programação, mas você provavelmente não quer fornecer todas as suas chaves de API em um arquivo para o modelo. Ou, se não se importa com isso, tenho certeza de que o responsável pela segurança da sua empresa teria algo a dizer. Então, isso é obviamente muito importante para as empresas, onde queremos ter permissões limitadas a agents e pessoas específicas, mas também é importante ter proteções para quem não quer acordar uma manhã diante de uma ação realmente catastrófica ou de uma cobrança de US$ 10.000 de API, certo?

13:21 E, por fim, há a eficiência. Se vocês se lembrarem dos dois estudos que mostrei, nos quais a escolha do harness não fez uma diferença significativa nas pontuações de evals, ambos encontraram, na verdade, uma diferença significativa no custo por tarefa. No último mês, tenho me concentrado pessoalmente em otimizar a eficiência do harness do Grok Bot. Ao ajustar variáveis como a taxa de acerto do cache, melhorando-a, a eficiência de tokens e a combinação de modelos, conseguimos reduzir

13:52 significativamente os custos e o tempo de execução do Grok Bot para os usuários, sem qualquer perda de qualidade. Os usuários têm apreciado muito isso. Tem sido ótimo ver. Poderia haver uma palestra inteira diferente sobre como fizemos isso, mas a principal conclusão aqui é que, quanto mais vocês usam agents para fazer seu trabalho, mais isso importa e mais valioso será para vocês ter o harness mais eficiente. Então, a esta altura, talvez vocês estejam convencidos de que o harness ainda importa. Aí talvez estejam se perguntando: “O que vem a seguir?” Aqui estão algumas tendências que estou

14:25 prevendo. Primeiro, esse ciclo está acelerando e, neste momento, entramos em uma nova era em que o produto voltou a avançar mais rápido que o modelo. Isso significa que o harness vai ficar mais bagunçado antes de ser organizado. Mais coisas serão lançadas. Por isso, esperamos que as pessoas construam seus harnesses e os projetem de modo que seja mais fácil lançar e retirar novos recursos. Uma maneira como já estamos vendo isso se manifestar é que, tanto no Grok Bot quanto em outros produtos semelhantes, cada vez menos aspectos internos do

14:55 harness são expostos ao usuário. Alguns de vocês talvez já tenham ouvido falar da Lei de Hyrum, segundo a qual qualquer coisa que você expõe aos usuários acaba se tornando algo de que eles dependem. Obviamente, há concessões ao dar aos usuários menos visibilidade do que está acontecendo, mas uma vantagem é que há menos mudanças a gerenciar e você pode iterar muito mais rápido. Outra maneira como temos visto essa tendência se manifestar é um foco maior em projetar primitivas para agents. Primitivas são interfaces como blocos de construção

15:28 que podem ser compostas e ampliadas para formar recursos poderosos. Quando você tem primitivas, pode adicionar novos recursos sem complicar as coisas para o agent e pode remover recursos sem precisar fazer uma refatoração complexa na sua base de código. É simplesmente boa engenharia. Um exemplo de primitiva que adicionamos aos nossos harnesses de agent é chamado subscriptions. Os agents precisam de uma maneira de serem ativados em resposta a eventos. Pode ser alguém publicando no Slack, o CI ficando vermelho em um PR que interessa ao agent ou simplesmente um determinado horário do dia.

16:00 Agora, em vez de ter uma integração separada para cada uma dessas coisas, temos uma estrutura e uma ferramenta que o modelo, ou o agent, pode usar para se inscrever em um evento. E outra coisa legal que fazemos: mencionei antes que temos essas proteções determinísticas para corrigir comportamentos ruins do modelo. Por exemplo, se o GrokBot não responder ao usuário rápido o bastante, podemos dar um pequeno toque nele e dizer: “Ei, o usuário está esperando por você.” Preferiríamos não fazer essas coisas. Elas são meio que soluções improvisadas, mas preferimos

16:32 corrigi-las agora a esperar pelo próximo checkpoint do modelo ser lançado. Então, para deixar nossa base de código menos bagunçada e evitar que seja mais difícil iterar no futuro, rastreamos centralmente todas essas coisas, que chamamos de shims, e, sempre que o modelo usa uma, isso é registrado. Agora temos um bot que monitora esse painel e, sempre que um shim deixa de ser acionado, esse modelo ou agent abre um PR e diz que esse shim pode ser removido. Outra coisa que acho que vem por aí para o harness é que ele está subindo para um nível mais alto de abstração. A geração de harnesses de ontem era

17:06 construído pela composição de várias chamadas de LLM. Agora, os novos harnesses que estamos vendo, como GrokBot e a fábrica de software, estão usando agents como bloco de construção central. E, por fim, prevejo que, dentro de 6 meses, 90% do trabalho com agents vai rodar no laptop. É para isso que as coisas já estão caminhando, e acho que isso é indispensável para termos agents verdadeiramente autônomos, que possam realmente trabalhar conosco da maneira que queremos.

17:36 Então, o harness está morto? As partes que o tornavam melhor em programação, sim: esse é o ciclo virtuoso em ação. Esse é o ciclo virtuoso em ação. Mas, como vimos, o harness é como os agents podem abrir caminho para a próxima fronteira do trabalho. E a confiança, a eficiência e a infraestrutura que o harness oferece também não vão a lugar nenhum. Então, o harness de ontem pode estar morto, mas vida longa ao agent harness de amanhã. Obrigado.

18:08 [aplausos]

Transcrição original

[00:01] [music] >> My name is Jedidiah and I joined Cursor early in 2025 as the longest tenured engineer working on our agent harness and recently I came along to SpaceX as part of the acquisition of Cursor. So, today I want to talk to you all

[00:32] about how the agent harness has evolved to where we are today and where I think things are going. And there’s a motivating question that I have for us to answer today, which is is the agent harness dead? So, let’s get started. >> [clears throat] >> Here’s a more natural and flowing version of that script which reads like a cohesive conference talk rather than a series of short points. Oops.

[01:03] Just making sure everyone’s still got their soft detectors on before lunch. Um no, for real. So, the story starts in early 2023 when prompt engineer was the hottest title out there. By mid-2025, that had evolved to context engineer, someone who programmatically puts the best context for the model together on the fly. And then only at the beginning of this year did the industry land on the term agent harness and harness engineering to

[01:34] describe work that my team and I have been doing for a while. So, what’s in an agent harness? The harness is like the eyes and the hands for the model. It wraps around the model, steers it, and connects it to the world. Users connect to our harness through apps and then the harness connects the model to computers and also to third-party services like MCPs. I like to divide the harness into two

[02:04] layers, the runtime and the context and orchestration layers. The runtime is kind of like the foundation of the harness. It controls where the core agent loop runs and how state is stored so that work can resume. Building this foundation is a lot like traditional software engineering. And then, the context and orchestration layers are kind of like the wild west. This is what a lot of people refer to when they talk about the harness.

[02:36] These parts of the harness control which models are called when and what context they see. That includes things like prompts and tools, of course, but also memory compaction and a bunch of tricks you might not know that we do to make the agent behave in the way that we want. So, this is the area that I primarily work in. In the new year, we kind of hit peak harness. Cursor announced that we had created a browser entirely from scratch

[03:07] uh using a new long-running harness called Grind Swarm. This was a multimodal harness that orchestrated a lot of a lot of agents and a lot of machines and it was very expensive to run. Uh it actually took down Cursor maybe once or twice to to get this demo. Um now, like anything in the world of agents, it only took a few months of peak harness for people online to start saying that the harness was dead. Tariq from Anthropic talked about how

[03:42] they had killed much of the system prompt from Claude Code. Garry Tan from YC thought that the harness would fade away and only skills would matter. Even myself and my colleague Stefan, we wrote about how we had removed all these guardrails that we had in cursor to patch over gaps in the model’s intelligence. We used to have things like a small model just to apply code edits to a file because the frontier models weren’t good at this. We also had all sorts of coding specific

[04:13] instructions like how to explore the codebase and how to check your work. So, if all these people are saying the harness is dead, they were saying that smarter models are what killed it. And there’s a lot of evidence for that. I want you all to think about a very simple harness where the model only has access to the shell and to all of my secrets. Please don’t screenshot this slide by the way. This one’s off limits.

[04:43] So, who here thinks that this really simple harness would do just as well on coding evals as a more sophisticated one? Maybe some hands who thinks it would? Who thinks so Who thinks it would if you Raise your hand if you think it would. A few hands, but most of you know. So, a few recent studies tried to investigate exactly that question. The first one out of UC Berkeley tried seven different frontier models on a series of harnesses including Pi, Codex, and Cloud Code. And what they found, particularly on the

[05:16] newer smarter models, is that the choice of harness did not actually make a difference significantly in the score on SweetBench light. And then another another study from from Apple and EPFL found similarly that a dedicated MLE harness did not make a big difference on MLEBench. So, what is going on here? Is it Is it actually true that the harness is dead? Are they right? Here’s what I think that the evidence shows. A fancy harness in this day and age, no longer adds coding intelligence. I think

[05:49] that is true. I know that’s surprising. But, these things that we used to do in the harness to patch over gaps in the raw coding muscle memory of the model, like teaching it how to explore the code base, uh how to work persistently for very long time with things like slash goal, uh how to run tests to check your work. The model has natively absorbed these skills. So, why is this happening? It turns out the harness is actually

[06:23] making itself obsolete through what I call the data flywheel. So, in this process, the harness brings harder and harder coding tasks within reach. At that point, more users can productively attempt those tasks with agents. That means more coding data is shared with the labs. And eventually the models learn natively how to do these skills as well. Eventually, the models get so good that the harness can actually delete the things it needed to do to make those tasks work in the

[06:55] first place. It’s a very interesting process. So, that’s how you get people saying that the harness is dead. And if the models are good enough to code well in any harness, then why should you care? Does it really matter which harness you use? Is the harness really dead? I say no, and there’s two reasons why. First of all, and I’m going to go into both these points, the harness actually opens the new frontier of tasks for the model to solve.

[07:26] And then, second, there are some tasks or some parts of the harness, especially outside the context layer, which the model cannot absorb. So, to first talk about how the harness unlocks the next frontier, I want to talk about Grokbot. Who here has tried Grockbot? Can I see some hands? Awesome. Let’s go. That’s great. Um so, for those of you who haven’t, Grockbot is our autonomous colleague who gets work done for you. Not just coding, but all kinds of knowledge work. And I really recommend you try it. I’m

[07:58] not going to sell too much, but it’s a groundbreaking new product. It’s already created a new category. Let’s just talk about the harness, though. So, Grockbot has a new kind of harness that operates not based off of one-off chats, but long-lived coordinator bots that orchestrate a fleet of worker agents. You can kind of think of it like hiring a high-powered lawyer who deals with you, you know, directly and owns strategy, but they farm out their tasks to a team of paralegals. It’s like that.

[08:32] Now, something interesting about the Grockbot harness is I mentioned how in Cursor we found ourselves removing things from the harness, removing prompting, removing guardrails as the models got smarter. But, curiously in Grockbot, we’ve actually found ourselves putting back a lot of these things, adding new prompting, adding new guardrails. And that’s because there’s a lot of new tasks in this new way of working, in the new domains that Grockbot is meant to solve, that the models have not nailed yet. To give a few examples of those kind of

[09:03] things, just a few things that we’re focused on right now when it comes to Grockbot, there’s key website flows like making slide decks and booking travel, communication. An autonomous colleague needs to keep you up to date on what it’s been doing without overwhelming you. Acting versus asking is another big one. Grockbot can do a lot of things which are kind of risky in some sense, like emailing your colleagues. You want us to be able to do that, but you only want us to do it in the way that you intended. And then, of course, learning over time the way that you work through memories is another big focus.

[09:36] So, those of you who might have pushed the boundaries with coding agents might have noticed that none of these tasks are new. But, for GrokBot, they’re much more important because everybody is needing them in some way. And right now in GrokBot, it is the harness that is making these tasks feasible. Of course, the model is a big part of that, but the harness is helping bring them into its own reach. So, going back to our data flywheel, GrokBot, that example, lets us fill in the last the last arrow in our cycle, which is

[10:09] when a capability like coding gets commoditized by the model, it’s actually the harness which unlocks a new frontier for the model to then solve and kicks off that flywheel again. So, that might look like, you know, taking on new tasks outside of the coding domain, um as we just saw with GrokBot, or it could just mean taking on tasks in the software engineering job beyond pure coding. I’m sure some of you here are, you know, pretty senior in your software careers, and you might know the more

[10:40] senior you get, the less coding you’re actually doing. So, there’s a lot of other things in the job that matter. Um this is the core idea that I would like you to understand, this flywheel and how the model and the harness together drive it. One more example of how the harness can unlock new frontiers is some of you may have heard of this idea of the software factory, where you have multiple agents coordinating together to solve the full software development life cycle. Now, this is far from a solved vision, but there’s a lot of industry or there’s

[11:14] a lot of innovation happening across the industry at the harness. To give an example of how this might manifest, you know, internally, we have a lot of channels where someone might report a bug to that channel, and then an automation immediately auto triages that bug. Then it might kick off a cloud agent to try to fix the bug, and that agent will use our tooling to show before and after videos to prove that it’s fixed. And then, once that fix is deployed and or is merged in and starts deploying, we have our rollouts product, which kicks off another agent to watch in production

[11:44] for any issues. So, you can think of all this as almost like a meta harness, which is orchestrating many agents together. That’s how I’d like you to think about this. So, that’s the first reason you should care about the harness because a frontier harness is needed to be at the frontier of agentic tasks. And then the next reason is there are some parts of the harness that the model can’t absorb. So, let’s talk about those.

[12:16] First of all, there is the infrastructure and runtime needed to make an autonomous colleague reliable. Over the past year plus, we’ve gone from agents that work on a typical task for minutes to hours to days and even longer. And there’s just no way that this can work on one person’s laptop, which might go to sleep. It has to be running in the cloud if you really want an autonomous colleague. And then next, we have trust and security. Yes, like we saw before,

[12:47] uh a simple harness with just bash and all your, you know, all your API keys in a file can solve coding tasks, but you probably don’t want to give all your API keys in a file to the model. Um or if you’re okay with that, I’m sure that your head of security would have something to say. Um so, this is obviously really important companies where we want to have permissions that are scoped down to specific agents and specific people, but it’s also important to have guardrails for anyone who doesn’t want to wake up one morning to a really catastrophic action or to a $10,000 API fee, right?

[13:21] And then finally, there’s efficiency. If you think back to to two studies I showed, where the choice of harness did not make a significant difference in eval scores, both of those studies actually found that there was a significant difference in cost per task. I have personally been focused over the past month on optimizing the efficiency of the Grok Bot harness. Now, through tweaking variables like uh cache hit rate, improving that, token efficiency, um model mix, we were able to bring down

[13:52] the costs and the speed of Grok Bots significantly for users without any hit to quality. Users have really, really been appreciating this. It’s been awesome to see. Um now, it could be an entire different talk about how we did this, but the key takeaway here is that the more and more that you use agents to do your work, the more it matters, the more valuable it will be for you to have the most efficient harness. So, by now you might be convinced that the harness still matters. Then you might be asking, “What’s next?” Here’s a few trends that I’m

[14:25] anticipating. First of all, that flywheel is speeding up, and right now we’ve entered a new age where the product is once again moving faster than the model. That means that the harness is going to get more messy before it gets cleaned up. There’s going to be more things shipped. So, because of this, we’re expecting people to um build their harnesses, design them so it’s easier to ship and unship new features. One way we’re already seeing that manifest is with both Grok Bot and other similar products, less and less of the

[14:55] harness inner workings are being exposed to the user. Some of you may have heard of Hyrum’s Law, which says that anything that you expose to users, they will come to depend on. Now, obviously there are tradeoffs to giving users less, you know, less visibility into what’s happening, but one advantage is that there’s less change management to deal with, and you can iterate much faster. Now, another way that we’ve been seeing um this trend manifest is a bigger focus on designing primitives for agents. Primitives are like building block

[15:28] interfaces that can be composed and extended into powerful features. When you have primitives, you can add new features without making things more complicated for the agent, and you can remove features without having to do a complicated refactor in your code base. It’s just good engineering. One example across our agent harnesses of a primitive we’ve added is called subscriptions. Agents need a way to wake up in response to events. Those might be someone posting in Slack, CI going red on a PR that the agent cares about, or just a certain time of day.

[16:00] Now, rather than having one separate integration, you know, having separate integrations for each of these things, we have one framework and one tool that the model can use or the agent can use to subscribe to an event. And then another cool thing that we do, I mentioned earlier that we have these deterministic guardrails to patch over bad behaviors in the model. That might be, for example, if GrokBot doesn’t respond to the user fast enough, and we might give it give it a little nudge and say, “Hey, user’s waiting on you.” Now, we’d rather not do these things. They’re kind of like hacks, but we would rather

[16:32] fix them now than, you know, wait for the next model checkpoint to to get released. So, in order to make our code base, you know, be less messy and and have less of a worse time iterating the future, we track all these things, which we call shims centrally, and every time the model uses one, it gets logged. So, now we have a bot who watches this dashboard, and whenever a shim stops firing, that model or that agent will put up a PR and say this shim can be cleaned up. Another thing that I think is next for the harness is it is moving up to a higher level of abstraction. Yesterday’s generation of harnesses were

[17:06] built from composing a bunch of LLM calls. Now, the new harnesses we’re seeing, like GrokBot and the software factory, are using agents as the core building block. And then finally, I predict that within 6 months, 90% of agent work is going to run off the laptop. This is already where things are going, and I think there’s just no way that, you know, this is this is not necessary in order to have truly autonomous agents who can, you know, really work with us in in the way that we want.

[17:36] So, is the harness dead? The parts that made it smarter at coding, yes, that is the flywheel at work. That is the flywheel at work. But, the harness, as we saw, is how the agents can unlock the next frontier of work. And then also the trust, the efficiency, the infrastructure that the harness brings, those things are not going anywhere. So, yesterday’s harness may be dead, but long live the agent harness of tomorrow. Thank you.

[18:08] >> [applause]