Agentes sem código: Skills, YAML e sistemas de arquivos substituíram Python — Philipp Schmid, Google DeepMind

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: Agents Without Code: Skills, YAML, and Filesystems Replaced Python — Philipp Schmid, Google DeepMind · Canal: AI Engineer · 17:59 · Assistir no YouTube

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

Resumo

Philipp Schmid demonstra três versões de um agente para revisar pull requests no GitHub, cada uma com menos código e mais arquivos. A evolução vai de um loop Python escrito manualmente, passa por um framework e chega a um agente remoto que usa um sandbox, ferramentas gerais e instruções em arquivos. Com essa abordagem, o modelo escolhe como executar tarefas, enquanto a equipe se concentra em instruções, skills, workflows e evals. A mensagem central é simplificar o harness e remover código de orquestração conforme os modelos melhoram.

Pontos-chave

Um agente pode ser definido como um LLM que usa ferramentas em loop até alcançar um objetivo.
A implementação inicial exige loops em Python, JSON schemas, roteamento de ferramentas, tratamento de erros e gestão de estado.
Frameworks como ADK abstraem parte dessa infraestrutura, mas ainda dependem de ferramentas implementadas em Python.
Agentes remotos podem executar ferramentas em um sandbox Linux isolado e usar fontes como repositórios GitHub, buckets GCS e arquivos inline.
Um proxy de rede pode inserir credenciais nas solicitações sem expô-las ao agente e limitar os domínios acessíveis.
Com ferramentas gerais como bash, sistema de arquivos e GitHub CLI, o agente pode descobrir como realizar tarefas sem ferramentas específicas para cada ação.
Instruções e capacidades podem ser ampliadas com arquivos de agente e skills, sem alterar o código de orquestração.
À medida que os modelos melhoram, é possível reduzir a orquestração; um harness que fica mais complexo pode estar sendo superprojetado.
A recomendação é fornecer ferramentas gerais, definir instruções e workflows do domínio, verificar resultados e investir em evals.

Capítulos

Início	Capítulo	Resumo
00:12	O que é um agente e a implementação em Python	Schmid define agente como um LLM que usa ferramentas até cumprir um objetivo e mostra uma versão de revisão de pull requests feita com loop Python.
04:32	Frameworks reduzem o código repetitivo	O exemplo com ADK abstrai loops e chamadas de ferramentas, mas ainda exige ferramentas implementadas em Python.
07:14	Agentes remotos e sandbox	O agente remoto usa um ambiente isolado, fontes configuráveis e um proxy que protege credenciais e controla o acesso à rede.
10:01	Um agente guiado por arquivos e ferramentas gerais	Em vez de ferramentas específicas, o agente recebe instruções em arquivos e usa bash, sistema de arquivos e GitHub CLI para realizar tarefas.
13:40	O que ainda cabe à equipe	A infraestrutura e a gestão de estado passam para o serviço, enquanto a equipe define instruções, capacidades, skills e evals.
16:22	Princípios e recomendações finais	Schmid recomenda evitar a micromanipulação da execução, fornecer ferramentas gerais e remover código à medida que os modelos melhoram.

Citações

Um agente LLM usa ferramentas em loop até alcançar um objetivo. — 00:12

Ainda somos responsáveis pelo código Python de integração. — 07:14

Agentes são apenas arquivos. — 16:22

Não devemos lutar contra o modelo. — 16:54

Conceitos e entidades

Agent (conceito): É descrito como um LLM que usa ferramentas em loop até alcançar um objetivo.
Interactions API (ferramenta): API apresentada para executar modelos e agentes, com suporte a etapas, estado no servidor e execução em segundo plano.
ADK (ferramenta): Framework citado como exemplo de abstração de loops de ferramentas, chamadas de função, novas tentativas e tratamento de erros.
Antigravity (ferramenta): Agente remoto apresentado, disponível pela Gemini API e executado em um ambiente sandbox hospedado.
GitHub CLI (ferramenta): Interface de linha de comando usada pelo agente para interagir com pull requests do GitHub.
sandbox (conceito): Ambiente Linux remoto e isolado onde o agente pode executar ferramentas e comandos e salvar arquivos.
skills (conceito): Arquivos que ampliam as capacidades do agente com instruções e contexto, sem exigir mudanças no código.
Cursor (empresa): Empresa citada por uma apresentação sobre substituir cerca de 12 mil linhas de TypeScript por arquivos de agente menores.
Google DeepMind (empresa): Organização associada ao palestrante Philipp Schmid no título do vídeo.
Philipp Schmid (pessoa): Palestrante que apresenta a evolução de agentes baseados em código para agentes configurados com arquivos e ferramentas gerais.

Tradução completa (pt-BR)

00:12 Oi, pessoal. Obrigado por terem vindo. Sei que é o quarto dia, a última sessão antes de a palestra principal recomeçar, e vamos fazer algo divertido. Vamos ver como os arquivos estão basicamente substituindo Python. E, antes de começarmos, gostaria de partir da minha definição favorita do que é um agent, de Simon. Um agent com LLM executa ferramentas em um loop até alcançar um objetivo. O que vamos fazer é criar o mesmo agent, o mesmo agent de revisão de pull requests do GitHub, de três maneiras diferentes. E vamos apagar código ao longo do caminho. A cada nova versão, menos código e mais arquivos.

00:46 Basicamente. Antes de começarmos, gostaria de apresentar rapidamente a API Interactions, nossa nova API do Gemini. É uma interface unificada para executar modelos e agents. Você pode usar a API Interactions para chamar diretamente os modelos Gemini ou chamar nossos novos agents, que também vêm com um sandbox. Ela oferece suporte ao gerenciamento de estado no servidor e à execução em segundo plano. Por isso, é perfeitamente adequada para tudo o que está por vir nos próximos anos. E, em termos de recursos, é a mesma API para tool calling, compreensão multimodal

01:20 e geração multimodal, então você sempre tem a mesma interface. Ela pode parecer muito familiar se você usa outras aplicações de LLM. Nós realmente tentamos criar algo que os desenvolvedores gostem de usar para construir, e é isso que vamos fazer. Uma coisa um pouco diferente na API Interactions em relação a outras aplicações ou APIs de LLM é que deixamos de usar o histórico de conversa baseado em turnos e passamos a usar etapas. Até alguns meses atrás, eu diria que a maioria das aplicações era realmente baseada em turnos. Normalmente, havia uma entrada do usuário

01:52 e depois uma saída do modelo, uma entrada do usuário, uma saída do modelo, o que definitivamente funciona para uma aplicação de chat normal. Mas, assim que você começa a criar agents e usar modelos de raciocínio, temos mais do que apenas um papel de usuário e um papel de modelo, certo? Temos diferentes tipos de entrada, temos diferentes tipos, temos raciocínio. Então, decidimos fazer um corte, uma mudança, e criar algo realmente voltado para agents. É isso que vocês veem na linha do tempo de etapas planas à direita: há uma entrada do usuário, depois raciocínio, uma chamada de função, um resultado de função, e você não precisa mais abusar do papel de usuário

02:24 para passar dados de volta de um ambiente. Então, há mais ou menos um ano, um ano e meio, escrever agents significava, em grande parte, escrever um loop em Python. Era preciso definir um esquema JSON. Era preciso definir funções Python. Era preciso examinar a saída do LLM. Era preciso verificar se era uma chamada de função ou uma resposta em texto. Depois, era preciso comparar com o tipo e então chamar a ferramenta, verificar se havia ocorrido um erro e, depois, ir e voltar. Vamos ver

02:56 alguns exemplos de código de como isso ficaria e também executá-lo, torcendo para que os deuses da demonstração estejam do nosso lado. Então, criei — ou deixei o Gemini criar — uma implementação básica desse loop em Python. Temos nossa classe. Temos uma função run que usa a API Interactions. Temos toda aquela lógica complexa e estranha de processamento, com tool calling, anexando os erros, verificando se ocorreu um erro e, depois, temos o resultado novamente. E, claro, para um agent, também precisamos de uma instrução de sistema. Então, há um arquivo separado

03:29 para a instrução de sistema. Bem básico: revisor de pull requests do QR GitHub. E, claro, precisamos de ferramentas; para elas, precisamos escrever essas especificações de esquema JSON, com descrições que definam exatamente quais ações o agent pode realizar. E, claro, precisamos da implementação, neste caso usando a API básica do GitHub, apenas enviando algumas solicitações. Então, podemos executar isso e, basicamente, a implementação principal

03:59 é uma interface de entrada bem simples. Podemos dizer algo como “olá” e, sim, recebemos de volta “oi, sou um agent”. Depois, pedimos que ele revise um pull request no repositório Gemini skills, e o que devemos ver é o agent começando, esperamos, em breve a enviar chamadas de função, resultados de função, chamadas de função, resultados de função. Mas ele está muito limitado às ferramentas que definimos. Então, se pedirmos ao agent para fazer algo para o qual ele

04:32 não tem os recursos necessários, ele simplesmente diz: “Ei, não consigo fazer isso”, o que é uma pena. Mas era assim que criávamos agents: código Python puro, muitos arquivos, muitas coisas que podem dar errado, muito código para gerenciar. Então, o que aconteceu depois — ou o que precisamos fazer — é: temos a geração de tokens, o tool calling nativo e precisamos executar o loop. Precisamos lidar com o roteamento das ferramentas. Precisamos criar esquemas JSON. Precisamos escrever o código Python. Precisamos executar o código Python. Precisamos

05:03 gerenciar o estado. Há muitas coisas que precisamos fazer para colocar um agent em funcionamento. Então surgiram os frameworks de agents. Havia muitos frameworks de agents diferentes que abstraíam parte dessa complexidade. Um exemplo aqui é o framework ADK, em que agora temos uma classe de agent que cuida de todos os loops de ferramentas, do tool calling, das novas tentativas e do tratamento de erros, o que tornou tudo um pouco mais fácil. Basicamente, removemos todo o código boilerplate que sempre precisávamos escrever para agents e o colocamos em um framework

05:34 para ajudar as pessoas a criar coisas com ele. Então, de volta à demonstração e ao mesmo exemplo. Vamos para o CR2. E é muito interessante — se vocês me deixarem abrir os dois. Então, ainda temos… já não temos mais nosso arquivo de agent. O agent desapareceu. Ainda temos nosso prompt, o mesmo system prompt. Ainda temos nossas ferramentas, mas, neste caso, também não há mais definições JSON, porque esses frameworks de agents agora usam a assinatura das nossas funções para criar esses esquemas JSON

06:07 dinamicamente e fornecê-los ao modelo. Então, vamos parar nosso agent. Agora vamos executar nosso segundo agent. Interface parecida, prompt parecido, e devemos ver um comportamento esperado semelhante, com chamadas de função. Tentamos obter os dados do PR. Tentamos obter o diff, tentamos obter todo o código de que precisamos, e funciona. Esperamos o agent continuar. Mas aqui temos uma dificuldade parecida. Se eu perguntar, por exemplo: “Como está o tempo em

06:42 São Francisco?”, esperamos receber uma resposta como: “Ei, não consigo fazer isso; não tenho acesso à API de clima”, o que obviamente faz sentido, porque não definimos nenhuma ferramenta. Ainda assim, é muito frustrante, porque precisamos ser muito explícitos sobre o que nosso agent pode fazer, e todos sabemos que, hoje em dia, queremos apenas dar um prompt e que o agent faça o que for necessário para alcançar esse objetivo. Então, o que nos resta fazer? O que o framework resolve? O framework resolve os loops de alternância de turnos, o roteamento, o mapeamento da execução, a criação de esquemas JSON

07:14 para as diferentes chamadas de função, mas ainda somos responsáveis pela infraestrutura em Python. Ainda precisamos escrever essas ferramentas com código Python. Ainda precisamos adicionar regras ou requisitos específicos para garantir que o agent faça o que queremos, e precisamos fornecer o ambiente em que todas as ferramentas são executadas, onde queremos hospedá-las. Então, o que vem depois? Esperamos que venham agents remotos. No Google I/O, lançamos o agent remoto Anti-Gravity na API Gemini. O agent Anti-Gravity é alimentado pelo mesmo

07:48 agent harness que alimenta a IDE Anti-Gravity. Aqui, “o mesmo harness” — isso é muito importante — não significa o mesmo agent, porque, no momento, o agent Anti-Gravity é um agent de programação, e o agent disponível na API Gemini é um agent de uso geral. Então, pode haver instruções de sistema diferentes e ferramentas um pouco diferentes, porque a API Gemini já tem uma ferramenta da Pesquisa Google. Então, usamos o que construímos e, muito importante, ele vem com este novo parâmetro de ambiente, que permite ao agent ter acesso a um sandbox na nuvem hospedado e isolado, onde ele

08:21 pode executar ferramentas, executar comandos bash e salvar arquivos. E esses ambientes podem ser configurados. Então, você pode fornecer fontes, que podem ser um repositório do GitHub, um bucket do GCS ou arquivos inline. E, claro, é muito importante garantir que esses agents sejam seguros e não possam usar nossas credenciais de nenhuma forma. Por isso, criamos um proxy de rede em torno do sandbox do agent, que basicamente injeta as credenciais quando o agent faz uma solicitação de dentro do sandbox para

08:53 fora do sandbox. Assim, o agent nunca vê de fato sua credencial. Ele simplesmente sabe: “Ei, posso chamar a API do GitHub”, e então garantimos, em tempo real, que ele receba o token correto que você definiu. Você também pode limitar os domínios aos quais o agent tem acesso. Então, se quiser restringir completamente o acesso do agent à rede ou os sites que ele pode acessar, basta deixar esse campo em branco. Por padrão, o agent pode acessar tudo, porque seria um transtorno ter que definir primeiro para onde ele pode ir. Tentamos manter as coisas simples. E, claro, fazer uma chamada de API é bom, mas pensamos: “Ei, as pessoas querem reutilizar

09:25 suas configurações, querem reutilizar seus agents”. Então, adicionamos a API de agents, onde você pode definir seu próprio ID personalizado, usar as mesmas instruções de sistema, o mesmo agent base e o mesmo ambiente base. Depois, pode criar esse agent e usá-lo exatamente da mesma forma que usa modelos Gemini ou o agent do anti-gravity, fornecendo o ID. Assim, todo o código existente pode ser reutilizado com seu próprio agent personalizado, suas próprias ferramentas personalizadas, suas próprias credenciais personalizadas, ambientes e tudo o que você precisar para executá-lo. Então, vamos ver como isso fica no VS Code, como demonstração. E

10:01 certo, agora, 03. E talvez seja bem óbvio que já não temos um diretório de fontes. O código desapareceu. Agora temos uma pasta agents/ com um arquivo AGENTS.md com instruções de sistema. As instruções são muito parecidas. A única diferença é que dizemos ao agent: “Ei, você tem acesso à CLI do GitHub”. Então, não criamos mais ferramentas específicas para ler arquivos de um pull request do GitHub nem para acessar um pull request do GitHub. Nós simplesmente

10:33 dizemos ao agent: “Ei, você tem uma CLI do GitHub, uma ferramenta bash e sistemas de arquivos. Tente usá-los sempre que achar importante”. E, como a CLI não está instalada, temos neste caso um script bash bem básico que verifica: “Ei, se a CLI do GitHub estiver instalada, use-a. Caso contrário, baixe-a e instale-a na primeira interação”. Então, vamos ao terminal e executamos nosso agent. Neste caso, talvez seja importante dizer que uso uma versão em fluxo contínuo; caso contrário, esperaríamos alguns segundos e não receberíamos nada de volta. Não

11:03 receberíamos nada de volta. Usamos o mesmo prompt e, em breve, devemos ver nossas chamadas de função e os resultados delas chegando. Sim. Então, neste caso, como estamos executando dentro de um sandbox, o agent primeiro explora o sandbox para confirmar: “Ei, temos essa CLI do GitHub instalada?”. Depois, tenta executá-la. Não a encontrou na primeira interação, então a instala. Em seguida, podemos ver o agent trabalhando. E, neste caso, ele não está usando as chamadas de função predefinidas. Está usando a CLI do GitHub e o conhecimento que já tem sobre como ela funciona. Ele já

11:34 sabe como funciona. Tenho uma ferramenta bash, tenho acesso ao sistema de arquivos e faço todo esse trabalho para analisar ou revisar o pull request. Vamos esperar um pouco. Certo. E acho que a parte incrível aqui é que, se fizermos a mesma pergunta de antes — “Como está o tempo em San Francisco?” —, esperamos ver o agent tentar usar… Ah, neste caso, ele usa a Pesquisa Google para consultar o dia 2 de julho. Deixe-me

12:07 conferir rapidamente. Sim, é hoje. E está fazendo cerca de 20 °C. Funciona. Então, o agent se tornou mais um agent de uso geral, e não precisamos especificar todas as ferramentas. Basicamente, confiamos que o modelo entenda: “Ei, tenho um conjunto específico de ferramentas gerais e bastante atômicas para resolver minha tarefa ou a tarefa do usuário”. E, se olharmos o código da entrada — ou melhor, da interface —, temos nossas fontes aqui. Temos o

12:38 script bash que instala a CLI do GitHub. Temos o arquivo AGENTS.md e dizemos: “Ei, você pode usar a API do GitHub com credenciais”. Então, quero acessar ou usar as credenciais do GitHub de forma segura. Criei um token para a API e também para github.com, porque você precisa dos dois URLs. Um é usado para os comandos git. O outro é usado para os comandos HTTP. E “todos os domínios” significa basicamente: “Ei, além dos URLs do GitHub, você pode usar toda a web, mas não tem credenciais para isso”. Então, é uma única chamada simples de API para

13:10 o agent do anti-gravity, com sua entrada ou a entrada do usuário, com o ambiente e também com o ID da interação anterior, que usamos para manter a conversa em várias interações. É só isso que é necessário: uma única chamada de API. No backend, iniciamos esse sandbox na nuvem, carregamos o arquivo AGENTS.md e as skills do ambiente fornecido ao modelo. Então, o modelo, entre a API e o sandbox, faz todo o ciclo: chama a função, retorna os resultados da função, chama a função, retorna os resultados da função. É só isso que é necessário. Então,

13:40 aonde isso nos leva? Não precisamos mais executar ciclos. Não precisamos mais fazer o roteamento de ferramentas. Temos uma conversa e um estado de sessão no servidor. Portanto, só precisamos fornecer novas entradas. O context window e a compactação também são gerenciados automaticamente pelo agent. Então, se continuarmos nossa conversa, em certo momento o contexto será compactado e poderemos continuar sem precisar gerenciar nada. Também temos um sandbox Linux remoto e isolado, que podemos usar para executar nosso código. Então, o que ainda nos resta fazer? Precisamos definir

14:11 instruções. Precisamos definir regras e comportamentos em um arquivo AGENTS.md. Precisamos fornecer capacidades ou contexto e um arquivo SKILLS.md, e precisamos cuidar dos evals. Todo o trabalho pesado, o gerenciamento da infraestrutura e todo esse código que provavelmente cada um de nós aqui já escreveu umas 20 vezes deixam de ser necessários. E você pode começar de verdade a construir seu produto, em vez de precisar reescrever o mesmo código várias vezes. E é muito importante perguntar: “Ei, isso é ótimo, mas e quanto à extensão?”. Acho que, ao observar como estender agents anteriores para que funcionem como esses novos agents, fica muito

14:47 óbvio que, antes, se quiséssemos fazer algum tipo de análise de segurança em um pull request, precisaríamos definir ou escrever uma função Python. Precisaríamos entender quais ferramentas de CLI usar. Teríamos que definir um novo esquema de função, adicioná-lo às nossas ferramentas, executá-lo e assim por diante. Havia muita coisa a fazer. Com agents baseados em arquivos, escrevemos um arquivo SKILLS.md, talvez com informações adicionais sobre qual ferramenta de CLI usar, ou talvez forneçamos a ferramenta de CLI dentro do ambiente. Assim, ampliamos as capacidades. Não precisamos mudar nosso código. Apenas fornecemos mais

15:18 arquivos ao agent, e o agent decide o que queremos fazer. Gosto de mencionar alguns exemplos muito bons. Um engenheiro na Europa, da Cursor, fez uma ótima apresentação sobre como substituíram cerca de 12 mil linhas de código TypeScript por 200 linhas de arquivos de agent para criar algo semelhante. Eles tinham uma orquestração de código muito rígida para trabalhar com árvores de trabalho do git e conseguiram substituí-la por uma skill e arquivos Markdown. E há mais lições amargas de engenharia de agents. A Manus refatorou seu

15:51 O harness mudou cinco vezes em seis meses no ano passado. A LangChain reestruturou o Open Deep Research três vezes em um ano, e a Vercel também removeu 80% das ferramentas para alcançar menos etapas, respostas mais rápidas e maior precisão. Então, há uma tendência evidente: com modelos mais capazes, podemos remover código de orquestração. Mas, se o seu harness está ficando mais complexo à medida que o modelo melhora, é muito provável que você esteja complicando demais o seu harness. Então, se você tem dificuldade com as melhorias dos modelos e com a adição de novas capacidades, que levam a

16:22 mais complexidade e mais código, talvez você precise repensar um pouco a estrutura do seu agent harness. E onde isso acaba nos levando? Agents são apenas arquivos. Escrevemos arquivos Markdown para ampliar as capacidades. Agents podem aprender com eles e criar os próprios arquivos. Então, se você tiver uma sessão e disser ao agent para se lembrar de algo, anotar regras ou preferências, o agent simplesmente escreve isso aqui e depois pode reutilizar essas informações em uma sessão futura. Você também pode externalizar o contexto. Então, se você tiver uma sessão muito longa e, durante

16:54 essa sessão, perceber: “Ei, talvez eu queira trabalhar também em outro recurso”, você pode simplesmente escrever essas informações, esse repasse, em um arquivo e dizer ao agent para retomá-las mais tarde. Então, quais são os aprendizados? Não devemos lutar contra o modelo. Devemos parar de microgerenciar os caminhos de execução, fornecer ferramentas gerais ao agent e deixar o modelo explorar, raciocinar e descobrir a solução certa. Assuma o que é seu, ou seja, concentre-se nas instruções do seu domínio. Concentre-se nos workflows. Concentre-se especialmente nos evals, defina ferramentas claras e verifique os resultados. E, de fato, desenvolva pensando em apagar. Como vimos muitas e muitas vezes no passado, quanto melhor o modelo fica, mais código podemos remover e mais coisas precisamos mudar. E, obviamente, todos queremos aproveitar modelos melhores. Então, o que vocês podem fazer na segunda-feira? Vocês podem escanear esse código QR, que leva diretamente ao AI Studio, onde podem experimentar imediatamente o harness do Antigravity. Assim, já podem começar a escrever prompts. Ele vai iniciar seu próprio sandbox personalizado. Se não, criem ou gerem sua chave de API. No momento, estamos trabalhando em um plano gratuito para a API. Então,

17:28 esperamos que em breve vocês possam começar a explorar mais rápido e, então, com certeza, começar a criar arquivos e skills. E é isso. Obrigado por terem vindo. [aplausos] >> [música]

17:59 Espero que em breve vocês consigam começar a explorar mais rápido e, então, começar a criar arquivos e skills. É isso. Obrigado por terem vindo. [aplausos] >> [música]

Transcrição original

[00:12] Hi everyone. Uh thank you for coming. I know it’s the fourth day, last session before the keynote starts again and we are going to do something fun. Uh we’re going to look into how files are basically replacing Python. And before we begin, I would like to start with my favorite definition of what is an agent from Simon. An LLM agent runs tools uh in a loop until it achieves a goal. And what we are going to do is we are going to build uh the same agent, the same GitHub PR review agent in three different ways. And we are going to delete code on the way. Each new version, less code, more files

[00:46] basically. Um before we begin, I would like to quickly introduce you to the interactions API, which is our new Gemini API. It’s a unified interface for um running models and agents. So you can use the interactions API to call the Gemini models directly or to call our new agents, which also comes with sandbox. It supports serverside state management, background execution. So it’s perfectly suited for all that’s coming in the next years. and um the capabilities it’s the same API for tool call multimodality understanding

[01:20] multimodality generation so you always have the same interface might look very familiar if you’re using other LLM applications we really try to build something for developers which you like to use uh to build and that’s something we are going to do so something little bit different in the interactions API to other LLM applications or APIs is that we moved away from this term based based uh conversation history to steps. So until I would say a few months ago, most of the applications were really turnbased. Normally you had a user in

[01:52] input and then a model output, a user input, a model output, which definitely works for normal chat application. But as soon as you start to build agents, use reasoning model. We have more than just a user role and a model role, right? So we have like different inputs, we have different types, we have reasoning. So we decided to like make a cut, make a change and build something really for agents and that’s what you see on the flat steps timeline on the right where you have a user input then you have reasoning you have a function call you have a function result and you no longer need to like abuse the user

[02:24] role for passing back data from an environment. So roughly a year one and a half years ago writing agents mostly meant writing a loop in Python. You needed to define a JSON schema. You needed to define Python functions. You needed to look at the output from the LLM. Need to check if it was a function call or if it was a text response. And then needed to match it against um the type and then like call the tool look of if you get an error and then like go back and forth and let’s look at

[02:56] some some code example on how this would look and also run it and hope that uh the demo gods are great to us. So I built or I let Gemini build a basic implementation of this Python loop. So we have our uh class. We have a run function which uses the interactions API. We have all of the weird complex passing with function calling with uh appending the errors checking if we get an error and then we have uh the result again. And what we need of course for an agent is we also need a system instruction. So there’s a separate file

[03:29] for the system instruction. Very basic. QR GitHub PR reviewer and then of course we need tools and for tools we needed to write those um JSON schemas specifications of description exactly define which uh actions the agent can take and then of course we need the implementation in this case using the the basic uh GitHub API just sending some some requests. So we can run this um in and basically the main main

[03:59] implementation is a very simple uh input interface and we can say something like hello and yes we get back hey I’m an agent and then we yes ask it to review a pull request on the Gemini skills repository and what we should see is like the agent should hopefully start soon sending function calls function results function calls function results but it’s very limited to yes uh great it works very limited to the tools we define so if we ask the agent to do something which it

[04:32] does not have the capabilities to it just says hey I cannot do this um which is unfortunate but that’s how we were building agents um raw Python code a lot of files a lot of things which can go wrong a lot of code to manage so what happened afterwards um or what we we need to do we have like a token generation We have the native function calling and we must execute the loop. We must handle the tool routing. We must create a JSON schemas. We must write the Python code. We need to execute the Python code. We need to

[05:03] manage the state. So there’s a lot of things we need to do to get an agent running. And then we got agent frameworks. There were many different agent frameworks which abstracted away some of that complexity. One example here is the ADK framework um where you have an agent class now which handles all of the tool loops, the function calling, the retries, the error handling and it made it a little bit easier. We basically removed all of the boiler plate code which we always needed to write for agents put it into a framework

[05:34] and help people build with it. So back to the demo and um same example. So we go into the CR2 and what is very interesting if you let me open both. So we still have our we don’t have our agent file anymore. So the agent went away. We still have our prompt same system prompt. We still have our tools in this case also no JSON definitions anymore because those agent frameworks now use the uh signature of our functions to create those JSON

[06:07] schemas on the fly to provide the model. So let’s stop our um agent. Now let’s run our second agent. Similar interface, similar prompt and we should see a similar expected behavior where we have function calls. We try to get the PR data. We try to get the diff, we try to get all of the code we need and it works and we wait for for the agent to yes continue. But similar difficulty here. If I ask it like what’s the weather in

[06:42] San Francisco um we should get back hopefully a result like hey I cannot do this I don’t have access to the weather API which obviously makes sense because we did not define any tool still very unfortunate because we need to be very explicit on what our agent can do and we all know nowadays that we just want to prompt something and we wanted the agent to do whatever it takes to to achieve that goal. So what is left for us to do? What does the framework solve? The framework solves the turn taking loops, the routing, the execution mapping, the JSON

[07:14] schema creation for like the different function calls, but we still own the Python plumping. So we still need to write those tools with Python code. We still need to add specific rules or requirements to like make sure whatever we want the agent to do and we need to provide the environment where all of the tools are running, where we want to host it. So what comes afterwards? Afterwards hopefully comes remote agents and at Google IO we launched the anti-gravity remote agent on the Gemini API. The anti-gravity agent uh is powered by the

[07:48] same agent harness which powers the anti-gravity IDE. Here the same harness very important does not mean the same agent because the anti-gravity agent is a coding agent at the moment and the uh agent available in the Gemini API is a general purpose agent. So there might be different system instruction, there might be slightly different tools because the Gemini API already has a Google search tool. So we use that what we have built and but very importantly it comes with this new environment parameter and this environment parameter here allows the agent to get access to a hosted isolated cloud sandbox where it

[08:21] can run tools, where it can run bash commands and where it can save files. And those environments can be um configured. So you can provide sources and sources can be a GitHub repository, it can be a GCS bucket, it can be inline files and of course very important we want to make sure that those agents are secured and cannot use our credentials in any way possible. So we created a network proxy around the um agent sandbox which basically injects the credentials when the agent makes a request from inside the sandbox to

[08:53] outside the sandbox. So the agent never really sees your credential. It just knows hey I can call the GitHub API and then on the fly we make sure that it received the correct token which you define and you can also limit which domains the agent has access to. So if you want to restrict the agent completely on which network access it can or which website it can access you just leave it blank. By default the agent can access all because I mean it’s a hassle if you first need to define where to go. So we tried to stay simple and of course making an API call is nice but we thought hey people want to reuse

[09:25] their configuration want to reuse their agents. So we added the agents API where you can define your own custom ID you the same system instruction the same base agent the same base environment and then you can create that agent and then you can use that agent in the same exact way as you use Gemini models or as you use the anti-gravity agent by providing the ID. So all of the existing code can be reused with your own custom agent, with your own custom tools, with your own custom uh credentials, environments, whatever you need for it to to run. So let’s look at how this will look for SS code and as a demo. And

[10:01] okay, now 03. And what might be very obvious is that we no longer have a source directory. So the code went away. We have now an agents M uh folder with an agents MD file with system instructions. So very similar system instruction. The only difference here is that we tell the agent, hey, you have access to the GitHub CLI. So we no longer create specific tools for reading files from a GitHub pull request, for accessing a GitHub pull request. We just

[10:33] tell the agent, hey, you have a GitHub CLI, you have a bash tool, you have file systems. try to use it whenever you think it’s important. And since we don’t have the CLI installed, we have a very basic bash script in this case which checks, hey, if the GitHub CLI is installed, please use it. If not, download it and install it on the first turn. So, we go into our terminal and we run our agent here. In this case, maybe important I use a stream version because otherwise we would wait like a few seconds and we not get back any we would

[11:03] not get back any anything back. So same prompt and we should soon see um our function calls and function results coming in. Yes. So in this case since we run inside a sandbox the agent first like explores the sandbox to really make sure hey do we have this GitHub CLI installed and then tries to run it. It did not find it on the first turn. So it installs it and then we can see the agent doing its work. And in this case it’s not using the predefined function calls. It’s using the GitHub CLI and it’s already

[11:34] existing knowledge about how it works. I have a bash tool. I have like access to the file system and I do all of that work to see or to like review the the pull request. Let’s wait a little bit. Okay. And I think the the amazing part here is like if we ask the same question as before, what’s the weather in San Francisco? We should hopefully see that the agent tries to use ah it uses Google search in this case on 2nd of July. Let me quickly

[12:07] check. Yeah, that’s today. And we have around 20° Celsius and it works. So the agent became more of a general purpose agent and we don’t need to like specify all of the tools. We basically trust the model on understanding hey I have a specific set of very atomic general purpose tools to solve my task or the task for the user. And if we look at the the code uh for like the the input or like the the sorry the the interface we have our sources here. So we have the

[12:38] the bash script which install the GitHub CLI. We have the agents MD file and then we say hey you can use the GitHub API with credentials. So I want to access or use GitHub credentials in a secure way. So I created a token for the API and also for github.com since you need both URLs. one uses is used for the git uh commands. The other one is used for HTT commands and then domain all is basically hey in addition to the GitHub URLs you can use all of the web but you don’t have credentials for it and then it’s a it’s a simple single API call to

[13:10] the anti-gravity agent with your or user input with the environment and then also with the previous interaction ID that we keep the multi-turn going and that that’s all it takes and it’s a single API call on the backend side we start that cloud sandbox we load the agents MD file and the skills from the environment provided to the model and then the model between the API and the sandbox does all of the the looping calling the function returning the function results calling the function returning the function results and that is all it takes. So

[13:40] where does it leave us? We no longer need to execute loops. We no longer need to do two routing. We have a serverside conversation and session state. So we only need to provide new inputs. The context window and the compaction is also automatically managed by the agent. So if we continue our conversation at a certain point the context is compacted and we can continue without the need to manage anything and we also get an isolated remote Linux sandbox which we can use to run our code. So what is still left for us? We need to define

[14:11] instructions. We need to define rules behaviors in an agent MD file. We need to provide capabilities or context and skills MD and we need to own the evils. So all of the heavy lifting, the infrastructure management, all of the same code which probably every one of us has written of us here like 20 times is no longer needed. And you can start really building your product instead of like needing to rewrite the same code over and over again. And very important is like, hey, that’s great, but what about extending? And I think looking into how extending previous agents to like those new agents work. It’s very

[14:47] obvious that previously if we want to do like some kind of security scanning on a pull request, we would need to define or write a Python function. We would need to understand okay which CLI tools do we need to use? We need to define a new function schema and then we needed to add it to our tools need to run it and then so there’s a lot of things we need to do on on agents powered by files. We write a skills MD file maybe with some additional information on which CLI tool to use or maybe provide the CLI tool inside the environment and then we extended the capabilities. we don’t need to change our code. We just provide more

[15:18] files to the agent and the agent decides on what we want to do. And I like to bring up some very good examples. So at a engineer in Europe, Cursor did a great talk on how they replaced uh roughly 12,000 lines of TypeScript code with a 200 lines agent files to create something similar. So they had a very hard-coded code um orchestration for doing git work trees and they were m able to replace it with just a skill and markdown files and there are more I would say bitter lessons of ancient engineering manos has refactored their

[15:51] harness five times in six months last year langen has rearchitected their open deep research three times a year and then also worsel has removed 80% of their tools to achieve fewer steps faster responses and better accuracy so there’s an obvious trend that with better model capabilities, we can remove orchestration code. But if your harness is getting more complex as the model improves, you are most likely overengineering your harness. So if you struggle with model improvements and adding new capabilities which lead to

[16:22] more complexity and more code, you might need to rethink a little bit on how your agent harness looks. And so where does it end up? Agents are just files. We write markdown files to extend capabilities. Agents can learn from those um can create their own files. So if you have a session and tell the agent to remember something to take notes of rules of preferences, the agent just writes it to this and then can reuse it in the later session and you can also externalize context. So if you have a very long running session and during

[16:54] that session you notice hey maybe I want to additionally work on another feature you can like just write that information that hand off to a file and like tell the agent to later pick it up. Uh so what are the takeaways? We should not fight the model like we should stop micromanaging the execution paths provide general tools to the agent and let the model explore reason and discover the right solution. Own what is yours meaning focus on your domain instructions. Focus on the workflows. Focus especially on the evals, define clean tools and verify the outcomes and really build to delete. Like we have

[17:28] seen in the past many many times, the better the model get, the more code we can remove and the more things we need to change and obviously we all want to benefit from better models. So what the things for you to get to do on Monday, you can scan that QR code which brings you directly to EI studio where you can immediately try out the anti-gravity harness. So you can already start prompting it. it will start your own custom sandbox. If not, um, start or create your API key. We are currently working on a free tier for the API. So

[17:59] hopefully you can start exploring faster soon and then definitely start building files and skills. And that’s it. Thank you for for coming. [applause] >> [music]