Engenharia de harness explicada: por dentro da stack por trás de Antigravity, Claude Code e Cursor

Autoria: Google Cloud Tech · 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: Harness Engineering Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor · Canal: Google Cloud Tech · 30:37 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Infraestrutura e hardware de IA

Resumo

O vídeo explica como um agent harness amplia as capacidades de um LLM ao conectá-lo a ferramentas, contexto e ao ambiente em que atua. Ryan Lopopolo defende que a autonomia dos agentes depende de boas práticas de engenharia, documentação, verificações e ciclos de trabalho iterativos, e não apenas de modelos mais capazes. Em seguida, uma demonstração compara harnesses lineares, loops fechados e configurações com salvaguardas. Por fim, o vídeo apresenta uma stack de agentes formada por modelo, harness e conhecimento especializado, com exemplos de Gemini 3.8 Flash, Antigravity Boost e Google Skills.

Pontos-chave

Um agent harness reúne os componentes ao redor do LLM que permitem ao agente usar ferramentas, obter contexto e agir no ambiente.
Documentação, convenções de código, linters, testes e verificadores estáticos ajudam a orientar o agente e reduzir comportamentos indesejados.
Deslocar intervenções para ferramentas e contexto reutilizáveis pode reduzir a necessidade de instruções detalhadas em cada prompt.
A autonomia deve crescer de forma iterativa: mudanças pequenas e fáceis de revisar podem sustentar tarefas maiores e horizontes de trabalho mais longos.
Agentes podem classificar tarefas e buscar dinamicamente o conhecimento e a expertise necessários para executá-las.
Harnesses lineares favorecem fluxos previsíveis; loops fechados permitem iterar sobre mudanças e testes até atingir uma condição de saída.
Salvaguardas, como bloquear comandos destrutivos, permitem personalizar agentes com mais segurança.
Uma stack eficaz combina modelo, harness e conhecimento especializado; modelos rápidos podem ser vantajosos em workflows com muitas iterações.
Google Skills fornece conhecimento de domínio sob demanda para agentes que trabalham com produtos como Google Cloud, Firebase, Flutter e Maps.

Capítulos

Início	Capítulo	Resumo
00:00	O que é um agent harness	O vídeo apresenta a ideia de que um agente combina um LLM com um harness que fornece contexto, ferramentas e acesso ao ambiente.
02:04	Harness engineering e autonomia	Ryan Lopopolo explica como contexto, documentação e boas práticas de engenharia ajudam agentes a entender o que se espera deles.
05:11	Intervenções, ferramentas e contexto	A conversa aborda como deslocar intervenções para documentação, verificadores e ferramentas que tornam o contexto mais acessível aos agentes.
10:00	Loops de trabalho e autonomia crescente	O entrevistado descreve como mudanças pequenas e revisáveis podem sustentar tarefas maiores e permitir que agentes assumam mais autonomia.
14:12	Práticas para adotar harness engineering	Ryan recomenda testar modelos recentes, investigar falhas e aprimorar ferramentas e contexto sem criar estruturas excessivamente rígidas.
19:34	Padrões de harness na prática	A demonstração compara harnesses lineares, loops fechados para edição e testes, e configurações com salvaguardas para comandos destrutivos.
25:21	Modelo, harness e conhecimento especializado	A parte final apresenta uma stack composta por Gemini 3.8 Flash, Antigravity Boost e Google Skills para tarefas de diferentes níveis de complexidade.
30:04	Resumo das ferramentas e encerramento	Os apresentadores recapitulam como usar modelos rápidos, Boost e conhecimento especializado, e encerram o vídeo.

Citações

Aspiro a ser uma pessoa que escreve prompts com o mínimo de esforço. — 04:07

Tenho tentado manter o Antigravity, por assim dizer, fixo no seu sistema agentic. — 14:43

É muito importante atualizar continuamente o que você considera possível com essas ferramentas. — 18:28

Seu agente de programação não precisa de um modelo mais inteligente. Precisa de uma stack melhor. — 25:21

Conceitos e entidades

agent harness (conceito): Camada ao redor do LLM que fornece ferramentas, contexto, memória e mecanismos para conectar as intenções do modelo a ações.
Harness Engineering (conceito): Prática de configurar ferramentas, contexto e ambiente para orientar agentes e ampliar sua autonomia.
Gemini Flash (modelo): Modelo citado como exemplo de modelo que pode ser combinado com um harness, inclusive em workflows agentic.
Gemini 3.8 Flash (modelo): Modelo apresentado como opção rápida e econômica para ciclos agentic com muitas iterações.
Antigravity (ferramenta): Harness mencionado no vídeo, incluindo o comando Boost para coordenar agentes e verificar o trabalho.
Agent Development Kit (ADK) (ferramenta): Kit do Google apresentado como opção para criar agentes com personalização, memória compactada e salvaguardas.
Google Skills (repo): Repositório de skills com conhecimento de domínio para agentes, incluindo conteúdo sobre Google Cloud, Firebase, Flutter e Maps.
Ryan Lopopolo (pessoa): Engenheiro do Google entrevistado sobre harness engineering e o desenvolvimento de agentes autônomos.
Google Cloud (empresa): Área do Google em que Ryan Lopopolo trabalha para desenvolver agentes que ajudem a operar a plataforma de Cloud.
Codex (ferramenta): Ferramenta citada no vídeo no contexto de agentes de programação e adoção de repositórios de skills.
Claude Code (ferramenta): Produto mencionado no título como um dos sistemas associados à stack de agentes discutida.
Cursor (ferramenta): Produto mencionado no título e na discussão sobre harnesses para programação.

Tradução completa (pt-BR)

00:00 Até que ponto no futuro você consegue reduzir a ambiguidade para dar autonomia aos seus agents nessa tarefa? Assim, eles captam mais sinais do contexto e do ambiente em que estão operando, em vez de se basearem apenas no que você diz explicitamente no prompt. Isso mesmo. Quero ser uma pessoa incrivelmente preguiçosa ao escrever prompts. Se fiz meu trabalho e dei ao modelo as ferramentas e o contexto de que ele precisa para se orientar, não preciso colocar tudo isso no prompt logo de cara. É muito importante continuar atualizando sua ideia do que é possível com essas ferramentas incríveis que temos.

00:30 Neste episódio, vamos nos aprofundar no conceito de agent harnesses. Agent harness é a mais nova palavra da moda na IA. Então, o que exatamente é isso? Bem, resumindo, um agent de IA é um LLM mais um agent harness. O harness é tudo nesse agent de IA que não é o LLM. Por exemplo, Gemini Flash é o modelo e Google anti-gravity é o harness. Exatamente. Então, se você fizer perguntas como “por que o céu é azul?”

01:03 Ou “me conte uma piada”, o modelo pode responder sem fazer nenhuma pesquisa adicional. Ele já sabe essas respostas. Mas, se você fizer uma pergunta mais complexa, como “devo usar uma capa de chuva?”, o LLM não sabe a resposta. Precisa de mais informações. Então, o harness precisa descobrir como está o tempo. Praticamente sempre que interagimos com IA, na verdade estamos interagindo com um agent. Então, perguntamos ao agent: “devo usar uma capa de chuva?”. O agent envia essas palavras ao LLM,

01:33 e o LLM as vê, mas não sabe a resposta. Então, ele gera palavras que equivalem a “descubra como está o tempo. Qual é a previsão? Encontre essa informação para mim”. Aí, o agent harness obtém essa informação sobre o tempo, por exemplo, que está ensolarado. Então, o harness pega nossa pergunta original — “devo usar uma capa de chuva?” —, acrescenta a nova informação sobre o tempo obtida pelo harness, que está ensolarado, e envia tudo de volta ao LLM. Aí o modelo pode responder: “Não, está fazendo 98 graus e está ensolarado. Você não precisa de uma capa de chuva”.

02:04 Então, um agent harness é tudo que envolve o LLM para dar ao agent poderes além de apenas receber um texto e devolver um texto. Para explorar melhor esse conceito, tilde conversou com Ryan, funcionário do Google e também a pessoa que cunhou o termo agent harness. Olá, sou tilde e estou aqui com Ryan lopopolo. Oi! Vamos falar sobre harnesses. Como “harness” virou um termo? E é verdade que foi você quem o cunhou?

02:35 Sim, fizemos muito trabalho para descobrir como tornar esses agents de programação totalmente autônomos. E fizemos várias coisas interessantes em torno do agent de programação para tornar isso possível. Publicamos um ótimo trabalho sobre o assunto em fevereiro deste ano, e ele meio que tomou o setor de assalto. Então, estou animado para falar disso em detalhes com vocês hoje. Sim, com certeza. Li seu ensaio sobre aproveitar o Codex em um mundo que prioriza agents, e achei fascinante. E qualquer pessoa que se interesse pelo futuro da engenharia de software precisa lê-lo. Você defende de forma muito convincente

03:05 que não se escreva código manualmente. Sim, tenho feito o possível para não fazer isso, e acho que não abro um editor desde mais ou menos maio do ano passado. Continuo firme aqui no Google. Uau, faz oito semanas que estou nessa. Incrível. Tenho que admitir que me assusta um pouco não ler o código que vou colocar em produção, mas você apresenta um argumento muito convincente. Então, os engenheiros vão simplesmente escrever especificações em linguagem natural, e é só isso que

03:35 vamos fazer. Então, qual foi a coisa mais surpreendente que você aprendeu ao colocar isso em prática? Acho que é muito importante aceitar que os modelos vão continuar melhorando. Mas, mesmo à medida que melhoram, entendi que eles não necessariamente vão ficar melhores em saber o que eu quero por padrão. Então, a ideia toda de harness engineering é organizar o contexto e o ambiente ao redor do modelo, para que, cada vez que ele é iniciado, entenda com mais naturalidade

04:07 o que exatamente eu quero. E, à medida que os modelos ficam melhores e mais inteligentes, e seguem instruções cada vez melhor, eles conseguem fazer coisas cada vez mais complexas. Quanto mais eu os oriento sobre o que considero um bom resultado. Assim, eles captam mais sinais do contexto e do ambiente em que estão operando, em vez de se basearem apenas no que você diz explicitamente no prompt. Isso mesmo. Quero ser uma pessoa incrivelmente preguiçosa ao escrever prompts, porque, se fiz meu trabalho e dei ao modelo as ferramentas e o contexto de que ele precisa para se orientar, não preciso colocar tudo isso no prompt logo de cara.

04:40 Uma coisa que me chamou a atenção no seu ensaio foi que você defende aplicar práticas recomendadas de engenharia que talvez sejam usadas ao ampliar uma equipe — como linters e convenções de código bem definidas. Quais dessas práticas você acha que funcionaram melhor em um workflow que prioriza agents? Para ser sincero, todas elas. Quero muito tentar levar a autonomia ao limite. E acho que existe um espectro de intervenções

05:11 que podemos implementar nos modelos. A intervenção mais simples, mais limitada e mais idiota que consigo imaginar é literalmente tentar meu prompt de novo, sem mudar mais nada, para ver se obtenho resultados melhores. Mas isso não funciona com meus colegas de equipe. Também não funciona ao longo do tempo. Então, posso pensar em colocar essas intervenções cada vez mais à esquerda no processo de engenharia de software. Posso adicionar documentação, alguns agents que apontem para essa documentação, ou um verificador estático e um teste.

05:42 Talvez esses próprios verificadores estáticos introduzam prompts para o agent, e assim por diante. Se tivermos sorte — ou não tanta sorte —, um dia isso pode chegar a evals que possamos encaminhar às nossas boas pessoas do DeepMind, para ajudar a tornar o app Gemini o melhor possível. Incrível. E, falando em deslocar, você pode explicar um pouco o que quer dizer com “deslocar para a esquerda”? Sim, quero que as intervenções que oferecemos ao modelo, ao ambiente e às ferramentas dele sejam o mais baratas possível de implementar. E, para esses agents que anseiam por texto e operam com texto,

06:16 fornecer mais texto de maneiras cada vez mais sofisticadas e automatizadas é o que quero dizer com deslocar isso para a esquerda. Acrescentar um pouco de texto ao meu prompt é, basicamente, o mais à direita que podemos ir. Dar ao modelo ferramentas e a capacidade de raciocinar sobre o corpus de documentação que fornecemos leva cada vez mais à esquerda: significa dar ao modelo os meios para descobrir esse contexto por conta própria. Quais são algumas das novas práticas recomendadas que estão surgindo, por exemplo,

06:49 autocorreção, observabilidade e loops agentic, que talvez não fossem possíveis antes de a tecnologia chegar ao nível atual? Sim, é isso mesmo. É muito legal que ferramentas simples, alinhadas às práticas recomendadas que você e eu já usamos em engenharia de software, possam ser aproveitadas por esses agents de maneiras cada vez mais criativas. Uma das razões para isso é que as ferramentas consideradas práticas recomendadas estão muito bem representadas nos dados de treinamento. Se eu conseguir reduzir um problema de observabilidade

07:21 a algo que usei durante toda a minha carreira, como PromQL e técnicas de observabilidade online, isso é algo que o modelo vai saber fazer bem. As peças se combinam muito bem. Transferimos a coleta e a agregação de dados de observabilidade para uma ferramenta de ponta feita para isso. Damos ao modelo algo que se combina muito bem com uma CLI, capaz de transformar raciocínio em determinismo e proporcionar acesso muito fácil ao contexto

07:52 em um formato denso que ele vai saber como usar. E podemos usar esse padrão em todo lugar para pegar suas melhores ideias de alta escala para engenharia de software e simplesmente colocá-las em prática, porque produzir código está muito barato agora. Consigo ver o agente falhar de uma maneira específica. Uma coisa que acrescentei outro dia é que gosto da ideia de estruturar meu Markdown com os links incorporados, não como parte do fluxo do texto, mas como uma âncora mantida por perto.

08:24 E faço isso para tornar realmente eficiente para o agente ler o texto propriamente dito da documentação. Mas, para o link em si, escrevo algum teste. Ele fica perto desse texto. Então, minha âncora nomeada fica no fim do parágrafo ou da lista a que está associada. E este é um código meio tosco que fiz com vibe coding, que, de certa forma, mantém o contexto eficiente. Mantém o texto legível para mim. Assim, é fácil revisarmos. E resolvo esse problema há muito tempo. Isso talvez seja um pouco idiossincrático às minhas preferências,

08:56 mas também é bom para meus agents e minha equipe. Então você está resolvendo o problema da perda de informação no meio e também garantindo a legibilidade para as pessoas ao mesmo tempo. Isso mesmo. Isso mesmo. Porque não escrevo nenhum código. Exijo que ele seja bastante legível. Assim, posso espiar por baixo do capô da execução do agent, porque quero avaliar os agents pelo artefato final produzido, seja código, Google Docs ou Google Sheets. Quero olhar para o artefato final e dizer: isto é razoável?

09:26 E, se não for razoável, preciso de alguma maneira de descobrir por que, que absurdo levou à produção dessa Google Sheet irracional que preciso dar um peteleco na cabeça do agent para garantir que ele não cometa o mesmo erro de novo. Dar petelecos na cabeça dos agents, adorei. Então você escreveu esse ensaio em fevereiro de 2026, e agora estamos em setembro de 2026. E uma coisa que você disse que não sabia na época era: como esse sistema vai evoluir a longo prazo? É, se eu tivesse que dizer qual desafio

10:00 venho tentando resolver com harness engineering durante todo esse tempo, seria: os agents conseguem se manter coerentes ao longo de períodos prolongados? Acredito muito que todo o trabalho que fazemos em organizações humanas é um processo bastante iterativo. Não criamos o Google Business de uma só vez. Foram necessários muitos anos para construí-lo até o ponto em que está, com contribuições de muitas pessoas ao longo de um processo muito iterativo; e, para que os agents participem plenamente dessa produção

10:32 de trabalho, precisamos realinhar continuamente o que eles produzem com o fio condutor do que a organização considera bom. Basicamente, harness engineering é um conjunto cada vez mais sofisticado de truques para trazer o agent de volta à linha de base, seja com PRs pequenos e fáceis de revisar. E, se os PRs pequenos são fáceis de revisar, então deve ser fácil operacionalizar agents para fazer parte dessa revisão, o que significa que podemos reduzir o espaço de estados desses PRs pequenos e, assim, avançar por períodos mais longos com menos intervenção humana.

11:05 E é isso que se quer dizer com aumentar o tamanho do ciclo em que você usa agents. Quanta confiança você tem de que uma pequena alteração vai resultar em algo razoável? É possível encadear essas pequenas alterações, de ponta a ponta, para obter algo razoável ao longo de um período mais longo? E o que significaria para mim, como supervisor desse sistema, tentar algo mais ambicioso e fazer um ciclo maior? Nossa! Então, você começa com algo pequeno e trabalha iterativamente a partir daí para dar cada vez mais autonomia aos seus agents, fazendo alterações cada vez maiores à medida que amplia a escala.

11:37 Isso mesmo. E, eventualmente, você pode chegar ao ponto em que coisas como migrações completas de linguagem se tornam viáveis, porque implementou salvaguardas suficientes para saber que várias alterações encadeadas, de ponta a ponta, são boas. Você pode confiar no código produzido, o que significa que pode aplicar essa confiança e autonomia em uma direção nova. Enquanto trabalhava nesses vários engenheiros de software e gerentes de engenharia autônomos,

12:07 foi muito legal ver diferentes pessoas contribuindo para esses agents, porque dava para acompanhar a evolução dos atributos de um personagem de RPG. Entra uma pessoa nova na equipe, que é arquiteta de React, e pronto: a atenção que ela dá ao assunto consegue elevar os atributos de arquitetura e desempenho de frontend. E isso é algo que normalmente não trago para a mesa. Então, formar uma equipe diversificada assim e fazer com que todos contribuam para um produtor central de trabalho de alto impacto

12:37 significa, na verdade, que você pode ter um agent bastante versátil, que reúne o melhor de cada pessoa. Nossa, isso é incrível. Você está contratando para uma equipe, mas poderia simplesmente especificar exatamente quais habilidades precisa, e então o agent as traz para a mesa. Isso mesmo. E, voltando à ideia de harness engineering como um conjunto de truques para refinar esse fio condutor da execução: preciso que o agent seja tanto arquiteto de backend quanto especialista em desempenho de frontend, porque não sei qual tarefa vou fazer.

13:08 E você pensaria nisso como uma reunião de planejamento de sprint no início da semana, distribuindo o trabalho com base na experiência de cada pessoa. Mas, se apenas agents fazem o trabalho, eles precisam descobrir qual especialidade devem ativar. É por isso que fazer o agent classificar o trabalho que vai realizar e usar isso para descobrir dinamicamente qual contexto precisa buscar faz parte do que significa ter alta autonomia. Porque, se você não está prestando atenção minuciosa ao código produzido, isso também significa que provavelmente não quer ficar atolado em prompts e na identificação de tarefas e em apontar o rumo certo para o agent desde o começo, o que, mais uma vez, vai nos permitir ampliar esse ciclo.

13:41 É, parece que você também está ampliando a autonomia que dá a eles em relação à lógica de negócios, apresentando problemas cada vez mais ambíguos para resolver, da mesma forma que faria ao desenvolver um engenheiro, de júnior a sênior, ao longo da carreira. Isso mesmo, isso mesmo. Sobre esse assunto, acho muito interessante pensar nos tipos de habilidades que agora são aplicáveis ao usar agents como força de execução para produzir código.

14:12 E penso nisso em termos do tamanho desse ciclo. Até que ponto no futuro você consegue reduzir a ambiguidade para dar autonomia aos seus agents naquela tarefa? Da mesma forma, quero que engenheiros staff resolvam problemas para a organização com seis meses de antecedência. Quero engenheiros, de júnior a sênior e a staff, com agents. Pense em até que ponto no futuro eles conseguem desbloquear sua equipe de agents. Agora, voltando ao panorama geral, queria saber se você tem algum conselho para o engenheiro médio sobre quanto ele precisa saber de harness engineering,

14:43 ou se talvez faça sentido criar o próprio harness. Nunca criei um harness. Acho que há um grande equívoco sobre o que chamo de harness engineering. Sempre mantive fixa a parte tipo Antigravity do seu sistema de agents. Use o melhor modelo assim que ele for lançado. Tenha grandes ambições com ele. Descarte ativamente todas as suas ideias preconcebidas sobre o que é possível, porque o mundo está mudando muito rápido hoje em dia.

15:16 Tenha grandes ambições. Observe quando o agent não faz um bom trabalho, interrogue-o e questione a si mesmo sobre o motivo e, então, tente aproveitar o fato de que produzir código é muito barato. Produzir prosa é muito barato. Refine o ambiente ao redor do agent e faça o possível para evitar esses desvios do bom comportamento. E, quanto mais você fizer isso, mais ferramentas dará ao agent. Quanto mais documentação rica houver, mais você ajudará o agent a navegar por ela e a encontrar o que precisa na hora certa,

15:47 encontrar as coisas certas. Quanto mais complexas forem as tarefas que ele deve ser capaz de realizar, menos você precisa ficar com a mão no volante. E as ferramentas no contexto são algo muito, muito essencial para o agent. Todos os harnesses expõem essencialmente ferramentas para acessar arquivos, ler, usar grep e executar comandos arbitrários, o que significa que, se você concentrar todos os seus esforços em melhorar a qualidade das ferramentas e do contexto, poderá adotar livremente os modelos mais novos à medida que forem lançados,

16:17 e você estará acumulando continuamente vantagem em uma parte do sistema que nunca ficará obsoleta, o que é um grande desafio. Com esses agents, é muito fácil exagerar na estrutura criada ao redor deles, o que os restringe desnecessariamente à medida que melhoram e leva você à falácia do custo irrecuperável, fazendo com que não queira descartar tudo isso. Sim, certamente me identifico com isso. Ah, isso é incrível. Fico muito feliz que você tenha se juntado a nós no Google. Quer contar um pouco sobre por que veio e no que tem trabalhado? Sim, estou trabalhando no Google Cloud.

16:51 Estou tentando criar os melhores agents para ajudar você a operar sua infraestrutura na nuvem. E o motivo de eu achar isso tão empolgante é a minha motivação de vida inteira. Trabalhar com IA tem sido uma busca por aplicações práticas. Acredito que hoje temos o que chamamos de capacidade excedente, em que os modelos são muito mais capazes do que conseguimos aproveitar em termos de trabalho útil. Então, meu objetivo como engenheiro de aplicações é tentar aproveitar ao máximo essa capacidade excedente

17:22 o que significa tentar ampliar as ambições e os espaços em que implantamos essa tecnologia e colocá-la em áreas onde ela ainda não existe. E acho que o Google Cloud é um espaço muito amplo e profundo, cheio de sistemas muito complexos. É essencialmente um computador muito grande. E parte do sucesso de um agent é dar a ele um computador. Quero fazer do Google Cloud o melhor computador para agents, para que eles possam operá-lo extremamente bem. E ajudar os clientes a fazer isso por conta própria nesse processo.

17:55 Não existe nuvem. É só o computador de outra pessoa. Isso mesmo. Isso mesmo. Isso mesmo. E queremos dar — queremos dar aos agents um computador enorme que pertence a outra pessoa. Você tem algum conselho final ou alguma opinião polêmica que queira compartilhar com nosso público? É muito importante atualizar continuamente o que você acha que é possível fazer com essas ferramentas maravilhosas que temos. O ritmo do progresso da IA é muito rápido, e você precisa garantir que sua experiência com elas

18:28 e a experiência que você está adquirindo com sua equipe continuem fazendo sentido à medida que os agents e seus harnesses evoluem. Isso significa que, para conseguir isso, o caminho é se concentrar nessas duas interfaces extensíveis: ferramentas e contexto. Os agents sempre precisarão de contexto para fazer aquela adaptação final ao que você considera bom. E, à medida que você puder transferir esse conhecimento para ferramentas cada vez mais capazes, deslocando-o para a esquerda,

19:02 que funcionam como uma forma de memória e de aplicação do que você considera um bom resultado, você continuará se surpreendendo com as coisas cada vez mais interessantes que os modelos conseguirão fazer por você com o passar do tempo. Muito obrigado, e obrigado por acompanhar. Obrigado. Agora que Tilda e Ryan falaram sobre os conceitos por trás de um agent harness, sabemos que muitos de vocês são desenvolvedores que querem ver o código e pôr a mão na massa. Vamos nos aprofundar um pouco mais. Então, vamos ver como Billy personaliza o próprio agent harness

19:34 para tarefas específicas, avaliando decisões de projeto como repetição e memória. Também veremos as diferenças entre padrões lineares e de loop fechado. Um mentor de engenharia meu sempre dizia: você pode simplesmente usar o framework, mas um ótimo engenheiro realmente entende o framework. Criar um harness por conta própria é como você entende o que está acontecendo nos bastidores quando as coisas dão errado. Os agent harnesses são o meio pelo qual conseguimos impulsionar nossos modelos e tirar o máximo proveito deles. Se observarmos um modelo sozinho, sem harness,

20:07 ele pode conhecer ferramentas, mas não tem como executar nada. E sabemos que muitos modelos passaram por fine-tuning para usar ferramentas, então podem realizar ações como interagir com arquivos, fazer chamadas de API e gerenciar o contexto e a memória. Mas, sozinho, o modelo não tem como interagir com o ambiente. Vamos dar uma olhada em um código que tenho aqui. Se eu executar este código, o modelo só poderá gerar um texto dizendo que deve inspecionar o arquivo. O harness precisa fazer o trabalho de conectar

20:38 essa intenção à ação. O objetivo dessa conexão é fazer o modelo realizar o que queremos. Talvez queiramos que ele programe, escreva ou pesquise. E os agent harnesses são o meio de fazer isso. Não existe um harness definitivo que sirva para tudo. Não há uma única solução ideal aqui, e é justamente isso que estamos explorando neste espaço de problemas dos agent harnesses. O que é importante em um problema talvez não seja relevante em outros.

21:09 Então, há algumas decisões que você pode tomar em cada harness. Repetição: quantas vezes ele vai repetir o processo? Ferramentas: quais ferramentas deve usar? Quando deve usá-las? Como deve usá-las? E memória: qual é a importância da memória para o workflow e quando você quer recuperá-la? Vamos analisar três harnesses diferentes. O primeiro padrão que quero mostrar é um harness linear, sem repetição. Ele poderá inspecionar um arquivo, gerar

21:43 uma recomendação e encerrar, ou simplesmente gerar a resposta se não precisar consultar o arquivo, retornando diretamente. E sempre seguirá exatamente o mesmo fluxo. Isso é ótimo se você precisar de algum nível de determinismo. Você quer que ele seja capaz de fazer a mesma coisa todas as vezes. Vamos executar este também. Na verdade, vamos executá-lo. E vamos dar um instante para gerar o resultado. Então, consultamos este arquivo.

22:15 Geramos o resultado, sintetizando as informações do arquivo e fazendo a análise que queríamos. Mas ele sempre seguirá exatamente o mesmo fluxo. Lê a ferramenta uma vez, gera a resposta e encerra. Outro padrão muito comum em edição de código e em outras tarefas é este tipo de loop fechado: executar continuamente, repetidas vezes, até chegar a um estado de saída.

22:45 Então, se eu quiser fazer algo que envolva trabalhar com código e editá-lo, quero usar este tipo de harness de loop fechado. Quero que ele continue executando até o problema ser resolvido. Aqui, vamos basicamente aplicar uma alteração no código e, depois disso, executar os testes. Portanto, não retornaremos até os testes passarem. Ou acho que aqui retornaremos depois de talvez cinco iterações. Mas isso vai nos permitir alterar o código, executar o conjunto de testes, capturar a saída da falha — não apenas

23:15 ver se passou ou não. Vamos ver por que falhou, enviar esse erro de volta para a memória e repetir o processo até conseguirmos fazer os testes passarem. E, por fim, quero analisar hoje algo com mais proteções de segurança. Se quisermos criar algo do zero, mas não quisermos implementar toda essa funcionalidade uma parte de cada vez, talvez possamos recorrer a uma ferramenta como hk, o Agent Development Kit do Google. Ela nos permite criar algo mais avançado, com mais proteções e compactação de memória integrada.

23:48 E você não precisa programar todos esses recursos por conta própria, mas ainda tem muito mais possibilidades de personalização do que ao usar algo pronto. Mesmo aqui, tenho esta função block destructive commands, que garante que eu não execute comandos perigosos, como remover arquivos, apagar meu banco de dados ou enviar alterações para o GitHub antes de realizar uma ação, como executar algum tipo de código. Assim, podemos trabalhar com um agent e personalizá-lo bastante

24:19 sem precisar usar algo puramente pronto para uso. Então, neste momento, os agent harnesses mais populares são ferramentas como Google Antigravity, Claude Code e Cursor. E todo mundo vai dizer: “Esta é a melhor opção no momento”. Todas essas ferramentas são fantásticas. Mas para que elas são melhores? Em que elas são fantásticas? Muitas delas são ótimas para usar um computador de uma maneira específica, usar memória de uma maneira específica e resolver problemas de maneiras específicas. Mas talvez você precise de algo mais opinativo para os problemas

24:50 que está tentando resolver. E o que faz essas ferramentas funcionarem tão bem e parecerem tão fluidas ao trabalhar no computador ou escrever código não são os próprios modelos. Esses modelos são muito inteligentes. O que faz a diferença é a engenharia do harness em torno dos modelos. Eles são projetados com inteligência, seguindo princípios de engenharia e usando todas as ferramentas certas para escrever software com eficiência hoje. Certo, vamos voltar para Smitha e Luke. Foi uma análise aprofundada excelente sobre agent harnesses, mas há muitas coisas interessantes acontecendo no espaço de IA neste momento.

25:21 E, Smitha, você tem muitas outras coisas que gostaria de compartilhar, então vamos falar sobre elas. Seu agente de programação não precisa de um modelo mais inteligente. Precisa de uma stack melhor. Quando os desenvolvedores sentem que seus agentes de programação estão empacando, o primeiro impulso é simplesmente passar para um modelo de base mais robusto. Mas, quando você trabalha com workflows de IA todos os dias, percebe que o modelo é apenas uma peça do quebra-cabeça. Uma stack de desenvolvimento de agents realmente eficiente depende de três camadas conectadas. A número um é o modelo.

25:51 A número 2 é o harness, e a número 3 é o conhecimento. Quando as três se encaixam, tudo muda. Hoje, vou mostrar as três ferramentas que tenho adorado usar nesta semana, uma para cada camada dessa stack. Então, a camada número um é a camada do modelo. E meu modelo de uso diário nesta semana tem sido o Gemini 3.8 Flash. Sua primeira reação talvez seja: por que o Flash? Por que não escolher algo com o nível de raciocínio mais robusto? E aqui está o segredo dos workflows agênticos.

26:22 Os agents não funcionam como caixas de prompt tradicionais de turno único. Eles executam loops contínuos, então um agent pode inspecionar um diretório, atualizar uma função, executar testes unitários e depois repetir essa sequência 20, 40 ou até 60 vezes só para concluir uma tarefa. Então, quando você usa algo que realiza tantos passos sequenciais, a velocidade e o custo se multiplicam rapidamente. Por isso, um modelo rápido e econômico não é uma opção inferior. É exatamente o que torna os loops agênticos em tempo real

26:55 práticos e responsivos. Como o Flash é tão leve, ele passa por dezenas de iterações sem dificuldade. Ele me mantém totalmente envolvida no processo sem gerar uma conta enorme. E, quando você tem um modelo rápido, precisa de uma estrutura dinâmica para orquestrá-lo. Isso nos leva à camada número 2, que é o harness. A ferramenta que estou usando aqui é o Antigravity, especificamente o comando boost. Em uma frase, boost é um comando que transforma um único modelo em uma equipe coordenada.

27:28 Então, em vez de depender de um agent para fazer tudo sequencialmente, boost inicia um orquestrador. Ele delega tarefas a subagents especializados em paralelo e também conclui com uma etapa independente de verificação, que audita o trabalho minuciosamente antes que qualquer coisa toque sua base de código. Veja como tirar o máximo proveito dele. Para começar, não é preciso usá-lo nas tarefas do dia a dia. Por exemplo, se você está trabalhando em funcionalidades comuns, adicionando um componente de interface ou navegando por uma base de código, o agent padrão é ágil e eficiente,

28:00 mas é melhor reservar boost para desafios de engenharia muito complexos. Por exemplo, esta tabela mostra um ótimo caso de uso para boost. A tabela a seguir compara três modos de execução no Antigravity e mostra como boost pode mudar as coisas. Então, reserve boost para os desafios de engenharia muito complexos descritos nesta tabela, que mostra exatamente quando usar boost.

28:31 Isso nos leva à terceira e última parte, a camada número 3: a camada de conhecimento. Com as camadas número 1 e 2, você tem um modelo rápido e um harness coordenado. Mas o que acontece quando você quer que seu agent tente configurar, por exemplo, sua infraestrutura na nuvem? Como ele sabe fazer isso? É exatamente aí que entram as Google skills. Esse repositório ultrapassou recentemente 19 mil estrelas no GitHub. Ainda está no início e em evolução ativa, o que significa que há muitas oportunidades para contribuir agora

29:03 se você quiser participar. Em termos simples, uma skill é um conhecimento de domínio selecionado, carregado sob demanda pelo seu agente de programação. Não é apenas um servidor MCP. Também não é um plugin pesado. É um contexto claro e preciso fornecido ao seu agent, que evita que ele fique fazendo suposições e, na verdade, o orienta sobre como fazer as coisas. Esse repositório contém mais de 100 skills diferentes para Google Cloud, Firebase, Flutter, Maps e muito mais.

29:33 E a instalação também é muito simples. Tudo o que você precisa fazer é executar este único comando para instalar todas essas skills. E o melhor de tudo: como é totalmente independente de harness, seja usando Claude Code, Codex ou Google Antigravity, todos podem acessar esse mesmo repositório. Ao analisar seu próprio workflow nesta semana, pense além de simplesmente trocar de modelo. Use ferramentas como Gemini 3.8 Flash para executar loops rápidos e de alta frequência. Você pode usar o boost do Antigravity

30:04 para realizar tarefas complexas com o Antigravity e também fornecer aos seus agents conhecimento especializado para trabalhar com Google, Flutter, Maps e muito mais. Você pode usar as Google skills. Smitha, isso foi realmente ótimo. Vou voltar ao Antigravity hoje à tarde para trabalhar em um projeto, então com certeza vou instalar essas Google Cloud Skills. Obrigado por compartilhar essas dicas. Por nada, e obrigado a todos por assistirem ao Asian Factory. Deixem um comentário contando sobre o que gostariam que falássemos a seguir.

30:37 Todos os recursos mencionados neste episódio estarão vinculados na descrição abaixo. Se quiser saber mais sobre como usar o Antigravity para automatizar o desenvolvimento de software, confira este próximo vídeo.

Transcrição original

[00:00] How far into the future can you peel back the ambiguity to empower your agents to have autonomy over that task. So they’re taking more cues from the context and environment that you’re operating in, rather than what you’re just saying explicitly in the prompt. That’s right. I aspire to be an incredibly lazy prompter. If I have done the job to give the model the tools and context it needs to ground itself, then I don’t need to front load that into the prompt. It’s very important to continually be updating what you think is possible with these lovely tools that we have.

[00:30] In this episode, we are going to dive deep into the concept of agent harnesses. Agent harness is the newest buzzword in AI. So what exactly is it. Yeah, well, in short, an AI agent is a large language model plus an agent harness. So the harness is everything in that AI agent that isn’t the LLM. So for instance, how Gemini Flash is the model and Google anti-gravity is the harness. Exactly like that. So if you ask questions like, why is the sky blue.

[01:03] Or tell me a joke. The model can give you words back without doing any additional research. It already has those answers. But if you ask a more complex question like should I wear a raincoat. Well, the LLM doesn’t have the answer to that. It needs more information. So something the harness needs to figure out what the weather is. So almost anytime we’re interacting with AI, we are actually interacting with an agent. So we ask the agent, should I wear a raincoat. The agent gives those words to the LLM,

[01:33] and the LLM sees those words, but it doesn’t have the answer. And so it gives words out that amount to go find out what the weather is. What is the weather. Find that information for me. So then the agent harness gets that weather information like it’s sunny out. And then the harness takes our original question should I wear a raincoat plus the new information about the weather from the harness that it’s sunny out and gives all of that back to the LLM and then the model can respond. No, it’s 98 and sunny. You don’t need a raincoat.

[02:04] So an agent harness is everything that is wrapped around the LLM to give the agent powers beyond just. Here’s some text in give me text out to dive deeper into this concept tilde sat down with Ryan, a Googler, and also the person who coined the term agent harness. Hello I am tilde, and I’m here with Ryan lopopolo. Hi and we’re going to talk about harnesses. How did harness become a term. And is it true that you’re the person that coined it.

[02:35] Yeah, we did a ton of work on trying how to get these coding agents to be fully autonomous. And there were a ton of neat things we did around the coding agent to make that possible. We published some great work on it in February of this year, and it kind of has taken the industry by storm. So excited to go into it with you all in detail today. Yeah, absolutely. I read your essay on leveraging Codex in an agent first world, and I think it’s fascinating. And anybody who cares about the future of software engineering must read it. You make a really compelling case

[03:05] for not writing any code manually. Yeah, I’ve been trying my best not to do so, and I don’t think I’ve actually opened an editor at all since around May of last year. Holding strong here at Google. Wow, it’s been eight weeks here for me. Amazing I have to admit that not reading code that I’m going to put into production scares me a little bit, but you make a very compelling case for it. So that engineers are just going to be writing specs in natural language, and that’s all

[03:35] we’ll be doing. So what was the most surprising thing you learned putting this into practice. It is very much the case, I think, that you have to take models getting better and better over time as a given. But even as the models get better and better, I think I have come to understand that they won’t necessarily become better at better at knowing what I want by default. So the whole idea with harness engineering is to do that context and environment curation around the model so that it more naturally every time it boots up, comes to understand

[04:07] what it is exactly that I want. And as the models get better and better and smarter and smarter and follow instructions more and more, it allows them to do more and more complex things. The more I ground them in what good looks like for me. So they’re taking more cues from the context and environment that you’re operating in, rather than what you’re just saying explicitly in the prompt. That’s right. I aspire to be an incredibly lazy prompter, because if I have done the job to give the model the tools and context it needs to ground itself, then I don’t need to front load that into the prompt.

[04:40] One thing that struck me about your essay was that you advocate for putting the kinds of engineering best practices that you might use when scaling up, in terms of number of engineers working on a project like linters, like well-defined coding conventions. Which of those best practices do you feel have worked best for an agent first workflow. To be honest, all of them. I really want to try to push the bounds on autonomy as much as possible. And I think there’s this spectrum of interventions

[05:11] that we can put in place with the models. The most simplest, smooth brained, stupidest one I can think of is literally just try my prompt again without changing anything else to see if I get better results. But, that does not scale to my teammates. It doesn’t scale across my time. So I can think about putting these interventions further and further to the left. In the software engineering process. I can add docs, I can add some agents that points at those docs, or I can add a static verifier and a test.

[05:42] Maybe those static verifiers themselves will introduce prompts to the agent and onward and onward and onward. Eventually, if we are lucky or not so lucky into evals that we can upstream to our good folks in DeepMind in order to help make Gemini app the best. Amazing And by shifting, can you define a little bit what you mean by shifting left. Yeah so I want the interventions that we give to the model and its environment and its tools to be as cheap as possible to implement. And for these agents who crave text, who operate on text,

[06:16] providing them more text in increasingly more sophisticated and automated ways is what I mean by shifting it to the left. So appending some text to my prompt, this is as basically far to the right as we can go, and giving the model tools and the ability to reason through its own documentation corpus that we give, it would be increasingly further to the left to give the model the means to go discover that context for itself. What are some emerging new best practices for example,

[06:49] self-healing, observability, agentic loops that might not have been possible before the technology got as good as it is now. Yeah it is. It’s very cool that simple tools that already lean into the best practices that you and I already use for software engineering are able to be leveraged by these agents in increasingly creative ways. And one reason that is the way it is because best practice tools are very well represented in the training data. If I can collapse an observability problem

[07:21] into something that I have used my entire career with something shaped like PromQL and online observability techniques, well, that’s something the model is going to know how to do well. It composes super nicely. We move the collection and aggregation of observability data into a best in class tool for it. We give the model something that composes really nicely with a CLI that is able to move reasoning into determinism and give it essentially a very easy access to context

[07:52] in a dense format that is going to know what to do with. And we can use that pattern all over the place to take your high scale best desires for software engineering and just go do them, because code is very cheap to produce right now. I can see the agent fail in a particular way. One thing I added the other day is I like the idea of structuring my markdown with the links embedded, not as part of the inline flow of the prose, but as an anchor kept close to it.

[08:24] And I do that to make it really efficient for the agent to read the actual prose text in the documentation. But the link itself, I write some test for that. It’s close to that text. So my named anchor is in the end of the paragraph or the list that it’s associated to. And this is some gross code that I have vibed up that sort of keeps context efficient. It keeps the text human readable for me. So it’s easy for us to review. And I have solved this problem for forever. That’s maybe slightly idiosyncratic to my preferences,

[08:56] but also good for my agents and my team. So you’re solving for the loss in the middle problem and also human readability at the same time. That’s right. That’s right. Because I’m not writing any of the code. I do require it to be pretty readable. So I can peek under the covers of the agent’s execution, because looking at the end produce artifact is how I want to treat agents, whether they’re producing code or Google Docs or Google Sheets. I want to look at the end artifact, say, is this reasonable.

[09:26] And if it’s not reasonable, I do need to have some way of backing out to why write what nonsense went into the production of this unreasonable Google Sheet that I need to whack the agent on the head to make sure it does not make that same mistake again. Whack the agents on the head, I love it. So you wrote this essay in February of 2026, and it is now September 2026. And one thing that you said you didn’t know at the time is, how is this system going to evolve in the long term. Yeah, if I were to say like what challenge

[10:00] I have been trying to solve with harness engineering this whole time. It has been. Do agents Cohere over long time horizons. I am a big believer that all the work that we do in human organizations is very much an iterative sort of process. We have not one shotted the Google Business. It has taken very many years to build it to where it is and the contributions of many over a very iterative process, and to have agents be full blown participants in that production

[10:32] of work essentially means we need to keep realigning the things they produce to the Golden thread of what the organization considers to be good. And basically, all of harness engineering is an increasingly sophisticated set of tricks to bring the agent back to baseline, whether that’s small PRS that are easy to review. And if the small PEs are easy to review, well, then it should be easy to operationalize agents to do some of that reviewing, which means we can narrow the state space of those small PRRs which lets us go longer horizon with less human intervention.

[11:05] And this is what is meant by increasing the size of the loop that you are using agents for. How much confidence do you have that in a small change you can get something reasonable. Can you stack those small changes end to end in order to get something reasonable over a longer arc. And then what would it mean for me, as the supervisor of this system, to try something more ambitious to do a bigger loop. Oh, wow. So starting with something small and working iteratively from there to give your agents more and more autonomy, making bigger and bigger changes as you scale up.

[11:37] That’s right. And eventually you can get to the point where things like wholesale language migrations are tractable because you have put enough guardrails in place to know that a bunch of changes stacked end to end are good. You can trust the code that’s being produced, which means you can apply that trust and autonomy in a novel direction. As I was sort of working on these various autonomous software engineers and engineering managers,

[12:07] it was very cool to see different individuals contribute to these agents, because you could watch building out the stats of RPG character. I get a new person on the team who is a React architect and boom, like the attention that they pay is able to bump out the stats in front end architecture and performance. And this is something that I don’t normally bring to the table here. So curating a diverse team like this and having them all contribute to a central leverage

[12:37] producer of work, actually means you can get quite well-rounded agent that has the best of everyone as a result. Wow that’s amazing. You’re hiring for a team, but you could just specify exactly what skills you need, and then the agent just brings those to the table. That’s right. And moving it back to harness engineering being a set of tricks to refine that golden thread of execution. I need the agent to both be a backend architect and a front end performance expert, because I don’t know what task I’m going to do.

[13:08] And you would think around sitting in sprint planning in the beginning of the week, divvying up work based on who has the expertise. But if you only have agents doing the work, they need to figure out which expertise they need to activate. And this is why having the agent classify what work it’s going to do, and use that to dynamically discover what context it needs to pull in, is part of what it means to have high autonomy. Because if you’re not paying attention to the code that is produced in great detail, that also means you probably don’t want to be super in the weeds on prompting and identifying

[13:41] tasks and pointing the agent in the right direction in the first place, which is again, another thing that’s going to let us expand that loop. Yeah, it sounds like you’re also like expanding the autonomy you’re giving them as far as business logic, like giving them more and more ambiguous problems to solve, the same way you would with growing an engineer from a junior engineer to a senior engineer across the span of their career. That’s right, that’s right touching on this is I think it’s very interesting to think about the sorts of skills that are now applicable with using agents as the execution force between producing code.

[14:12] And I do think about it in terms of that loop size. How far into the future can you peel back the ambiguity to empower your agents to have autonomy over that task. And in the same way, I want staff engineers solving problems for the organization six months out. I want from junior to senior to staff engineers with agents. Think about how far into advance they can unblock their agentic team. Now bringing it back to the bigger picture, I was wondering if you have advice for your average engineer and how much they need to know about harness engineering,

[14:43] or whether it might make sense for them to build their own harness. I have never built a harness. I think this is a big misnomer with what I term harness engineering. I have always kept the anti-gravity like thing in your agentic system as fixed. Take the best model you can as soon as it comes out. Try to have high ambition with it. Be actively discarding all your priors on what is possible because the world moves very quickly these days.

[15:16] Try and have high ambition. Observe when the agent fails to do a good job, interrogate it and yourself on why, and then try to use the fact that code is very cheap to produce. Prose is very cheap to produce, to refine the environment around the agent to just try your best to disallow these divergences from good behavior. And the more and more you do this, the more tools you give to the agent. The more rich documentation, the more you help the agent navigate that documentation and just in time,

[15:47] find the right things. The more and more complex tasks it should be able to accomplish the less you have to keep your hand on the wheel. And tools in context is a thing that is very, very core to the agent. All harnesses expose essentially a file, read a grep and an arbitrary command execution tool, which means if you focus all of your efforts on improving quality on tools and context, you can freely adopt the newest models as they come out,

[16:17] and you’ll be constantly accruing leverage into a bit of the system that will never become obsolete, which is a big challenge. With these agents, you can very much over scaffold around them, which constrains them unnecessarily as they get better and gets you into sunk cost fallacy around not wanting to throw this stuff away. Yeah, I can certainly relate to that. Oh, this is amazing. I’m so glad you joined us at Google. Do you want to tell us a little bit about why and what have you been working on. Yeah, so I am working on Google Cloud.

[16:51] I am trying to build the best agents to help you operate your Cloud. And the reason I find this to be so exciting is my entire motivation. Working in AI has been to chase after deployment. It’s my belief that today we have what’s called capability overhang, where the models are so good beyond what we are able to extract from them in terms of useful work today. So the goal for me as an applied engineer is to chase after gobbling up as much of that capability overhang

[17:22] as I which means trying to increase the ambition and spaces in which we deploy this thing and put it into places where it just doesn’t exist so far. And Google Cloud, I think, is this very wide and deep hole of very complex systems. It is essentially a very large computer. And part of having an agent be successful is to give it a computer. And I want to make Google Cloud the best computer for agents such that they can operate it exceedingly well. And to help customers do that on their own in the process.

[17:55] There is no Cloud. It’s just someone else’s computer. That’s right. That’s right. That’s right. And we want to give we want to give the agents a big somebody else’s computer. Do you have any last words of advice or any hot takes you want to share with our audience. It’s very important to continually be updating what you think is possible with these lovely tools that we have. The pace of AI progress is so fast, and you want to make sure that your experience with them

[18:28] and the expertise that you are building with yourself and your teams, is one that will continue to make sense as the agents and their harnesses continue to improve, which means focusing on these two extensible interfaces around tools and context is the way to do that. Agents will always need context in order to do that last mile adaptation into what you think good is. And as you can continue to shift that knowledge right, left shifted to the left in terms

[19:02] of increasingly capable tools, which act as a form of memory and enforcement of what you think good looks like. You’ll continually be amazed as the models are able to do more and more interesting things for you over time. Thank you so much and thank you for tuning in. Thank you. So now that Tilda and Ryan have talked about the concepts behind an agent harness, we know that a lot of you are developers who want to see the code and get hands on. Dive a little deeper. So let’s look at how Billy customizes his own agent harness

[19:34] for specific tasks by weighing design decisions like looping and memory. And we’ll also look at the differences between linear and closed loop patterns. An engineering mentor of mine always said, you can just use the framework, but a great engineer will really understand the framework. Building a harness yourself is how you understand what’s happening under the hood when things break. Agent harnesses are the ways that we’re able to push on our models and get the most out of them. If we look at a model on its own and unharnessed model,

[20:07] it can know about tools, but it has no way to execute anything. And we know that many models have been fine tuned for tool use so they can take actions like interacting with files, making API calls, managing their context and memory. But on their own, the model doesn’t have a way to interact with the environment. Let’s take a look at some code I’ve got here. If I run this code, the model can only output the text saying that it should inspect the file. The harness needs to do the work of connecting

[20:38] that intent to the action. So the goal of that connection is to optimize a model to do what we want. And maybe we want it to be coding or writing or researching. And agent harnesses are the way to do that. Now there isn’t one best harness to rule them all. There isn’t one best solution here, and that’s kind of what we’re exploring right now in this problem space of ancient harnesses. What’s important in one problem might not matter in others.

[21:09] So with each harness, there are a few things you can make decisions about. Looping how many times will it loop. Tools what tools should it use. When should it use them. How should it use them. And memory. How important is memory for the workflow and when do you want to retrieve it. So we’re going to take a look at three different harnesses here. And the first pattern I want to show is a linear harness with no looping. So this is going to be able to inspect a file, output

[21:43] a recommendation and exit or just output the answer if it didn’t need to look at that file just returning there. And it’s always going to go through this same exact flow. This is great. If you need some level of determinism. You want it to be able to do the same thing each time. So let’s just run this one as well. Let’s actually run it. And we’ll give this a second to output the result. So we went through this file.

[22:15] We outputted the result synthesizing the information from the file and the analysis that we wanted it to do. But this is always going to go through that same exact flow each time. Read the tool once, output the response, and then ends. Now another pattern which is super common in code editing and more is this kind of closed loop. So just continuously running over and over until there’s an exit state.

[22:45] So if I want to do something that’s working on code, making edits to that code, I want to use this kind of closed loop harness. I want it to run until the problem is resolved. So here we’re going to basically apply a code edit change, and then after that change we’re going to run the tests. So until the tests pass we will not be returning. Or I think here we’ll return after maybe five iterations. But this is going to let us change the code, then run the test suite, capture that failure output, not just

[23:15] see did it pass or not. We’re going to see why it failed and feed that error back into memory and loop through it until we can get those tests to pass. And then a final one I want to look at today is just something with more safety guardrails. If we want to build something from scratch but don’t want to implement all of this functionality one at a time, you might reach for a tool like hk, the Agent Development Kit by Google, and this allows us to build something more advanced with more guardrails, with memory compaction built in.

[23:48] And you don’t have to code all those features yourselves, but you still have a lot more customization than using something out of the box. So even here, I’ve got this block destructive commands function, and I’m making sure I don’t do any dangerous commands like removing files, dropping my database, pushing to GitHub before taking an action, like running some kind of code. So here, we’re able to work with an agent to give it a lot of customization

[24:19] without having to use something purely out of the box. So right now, the most popular agent harnesses are tools like Google antigravity Cloud Code cursor. And everyone’s going to say, this is the best thing right now. And all of these tools are fantastic. But what are they the best for. What are they fantastic for. And a lot of them are great for using a computer in a specific way, using memory in a specific way, solving problems in specific ways. But you might need something opinionated for the problems

[24:50] you’re trying to solve. And what makes these tools work so well and feel really smooth when working on your computer or writing code isn’t the model themselves. Those models are really smart. It’s the harness engineering around the models. They are smartly designed with engineering principles and all the right tools to write software effectively right now. All right, back to Smitha and Luke. That was an excellent deep dive into agent harnesses, but there’s a lot of cool things happening in the AI space right now.

[25:21] And I Smitha, you’ve got a lot of other things that you’d like to share, so let’s talk about those. Your coding agent doesn’t need a smarter model. It needs a better stack. Whenever developers feel like their coding agents are hitting a wall, the first reflex is to just jump to a heavier foundational model. But once you work with AI workflows day in and day out realize that the model is only one piece of the puzzle. A truly high performing agent devstack comes down to three connected layers. Number one is the model.

[25:51] Number 2 is the harness, and number 3 is the knowledge. When all three click into place, everything changes. Today, I’m walking you through the three tools that I’ve been loving this week one for each layer of that stack. So layer number one is the model layer. And my daily driver this week has been Gemini 3.8 Flash. Now your initial reaction might be why Flash. Why wouldn’t you want something with the heaviest reasoning tier. And here’s the secret to agentic workflows.

[26:22] Agents don’t work like traditional single turn prompt boxes. They run in continuous loops, so an agent might inspect a directory, update a function, execute unit tests, and then repeat that sequence 20, 40, or even 60 times just to finish one task. So when you have something that uses that many sequential hops, speed and cost compound dramatically. So a fast, cost effective model isn’t a downgrade. It is the exact thing that makes real time agentic

[26:55] loops practical and responsive. Because Flash is so lightweight, it churns through dozens of iterations effortlessly. It keeps me in the complete loop without running up a massive bill. And once you have a fast model, you need a dynamic structure orchestrating it. That brings us to layer number 2, which is the harness. The tool I’m using here is anti-gravity, specifically their boost command. In one sentence, boost is a command that transforms a single model into a coordinated team.

[27:28] So instead of relying on one agent to do everything sequentially, boost actually spins up an orchestrator. It delegates specialized subagents in parallel, and also it finishes with an independent verification pass that thoroughly audits the work before anything touches your code base. Here’s how to get the most out of it. First off, you don’t need to use it for everyday tasks. So, for example, if you’re just working on standard features or you’re adding a UI component or navigating a code base, the default agent is snappy and efficient,

[28:00] but you want to save boost for deeply intricate engineering challenges. So for example, this table right here shows you a really good use case on when boost is super useful. So the following table actually compares three execution modes in anti-gravity. And it shows you how boost can actually change things around. So you want to save boost for the deeply intricate engineering challenges that are described in this table right here, which tells you exactly when you want to use boost.

[28:31] That leads us to our third and final piece, which is layer number 3, the knowledge layer with layer number 1 and 2, you’ve got a fast model and you’ve got a coordinated harness. But now what happens when you want your agent to try and configure, for example, your Cloud infrastructure. How does it know how to do that. That’s exactly where Google skills comes in. So this repository actually recently crossed 19,000 stars on GitHub. It’s still early and actively evolving, which means the contribution window is wide open right now

[29:03] if you want to get involved. To put it simply, a skill is a curated domain knowledge that your coding agent loads on demand. So it’s not just an MVP server. It is not a heavy plugin. It’s clean, precise context that is given to your agent that stops your agents from guessing and actually informs them on how to do things. So this repository contains over 100 different skills across Google Cloud, Firebase, Flutter, Maps, and many more.

[29:33] And also installation is super simple. All you have to do is run this single command to install all of these skills. And best of all, because it’s completely harness agnostic. Whether you’re running Cloud Code, Codex or Google anti-gravity, they can all pull from this exact repository as you look at your own workflow this week. Think beyond just changing models. Use things like Gemini 3.8 Flash to power rapid high frequency loops. You can make use of anti-gravity boost

[30:04] to do complex tasks with anti-gravity, and then also to give your agents specialized knowledge to do things on Google, as well as Flutter Maps and many more. You can make use of Google skills. Smither that was really terrific. I’m going to be jumping back into anti-gravity this afternoon to work on a project, so I will definitely be installing those Google Cloud Skills. So thank you for sharing those tips. You’re welcome and thanks to everyone, for watching the Asian factory. Leave a comment on what you’d like to see us talk about next.

[30:37] All of the resources talked about in this episode will be LinkedIn the description box below. If you want to learn more about using anti-gravity to automate building software, check out this next video.