Por que agentes de IA devem ter seu próprio sandbox — 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: Why AI Agents Should Have Their Own Sandbox — Philipp Schmid, Google DeepMind · Canal: AI Engineer · 20:23 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Ferramentas de desenvolvimento com IA

Resumo

Philipp Schmid apresenta a Interactions API e a Agents API do Gemini, destacando recursos para criar e executar agentes. A proposta central é oferecer a cada agente um sandbox remoto gerenciado, com arquivos, ferramentas e dependências, sem exigir que o desenvolvedor administre a infraestrutura. O ambiente pode persistir entre interações, ser compartilhado por agentes e ser preparado previamente para reutilização. Demonstrações mostram agentes que criam um programa de rádio e exploram o ambiente de execução.

Pontos-chave

A Interactions API permite interagir com modelos e agentes usando uma interface comum, com suporte a entradas multimodais, estado no servidor e operações longas.
A API organiza as interações como etapas, distinguindo resultados de ferramentas das mensagens do usuário.
O agente Anti-gravity usa um harness compartilhado entre produtos, embora suas ferramentas e instruções possam variar.
Um sandbox remoto gerenciado permite executar código, criar arquivos, instalar dependências e chamar APIs sem administrar a infraestrutura.
Ambientes persistentes podem ser reutilizados em interações seguintes ou compartilhados entre agentes e subagents.
Fontes como buckets GCS, repositórios GitHub e arquivos podem fornecer contexto ao agente; skills e arquivos AGENTS.md também podem ser carregados.
A Agents API permite configurar agentes reutilizáveis com instruções e ambientes previamente preparados.
A CLI do Gemini API ajuda agentes de programação a chamar a API e criar ou ajustar agentes.
Nas demonstrações, um agente produz um programa de rádio com diferentes modelos Gemini, e outro inspeciona seu ambiente de execução.

Capítulos

Início	Capítulo	Resumo
00:12	Contexto e evolução dos modelos	Philipp Schmid apresenta o trabalho da equipe e revisa a evolução de modelos de continuação de texto para agentes orientados a objetivos.
03:33	A Interactions API	A apresentação explica entradas multimodais, estado no servidor, operações longas e uso de ferramentas pela API.
07:50	O agente Anti-gravity e seu sandbox	Schmid diferencia o harness do agente e descreve o ambiente remoto gerenciado, persistente e compartilhável.
11:08	Configurar e reutilizar agentes	A Agents API permite preparar ambientes e criar agentes reutilizáveis, e a CLI facilita o trabalho com a Gemini API.
13:14	Demonstração: AI Talk Radio	Um agente usa modelos Gemini para pesquisar e produzir um programa de rádio com vozes, música e opiniões distintas.
16:05	Inspecionando o agente e o ambiente	A demonstração mostra os arquivos, as skills e as instruções do agente, além de testar o ambiente de execução.
19:18	Execução remota e documentação	Schmid resume o fluxo de execução no sandbox remoto e indica a documentação para começar a criar agentes.

Citações

Basicamente, damos um objetivo ao modelo e dizemos como verificá-lo. — 02:26

O agente recebe um sandbox gerenciado por nós para essa chamada da API. — 08:58

É muito fácil usar agentes para construir seus próprios ambientes e depois criar agentes a partir deles. — 12:09

Com os agentes gerenciados, é realmente uma única chamada à API. — 19:18

Conceitos e entidades

Interactions API (ferramenta): API do Gemini para interagir com modelos e agentes, com suporte a ferramentas, estado no servidor e operações assíncronas.
Agents API (ferramenta): API que permite definir e reutilizar agentes com instruções e ambientes configurados.
Antigravity agent (modelo): Agente apresentado na palestra que pode operar em um sandbox remoto e usar ferramentas.
agent harness (conceito): Estrutura de backend que executa o agente e pode ser compartilhada por diferentes produtos.
sandbox remoto (conceito): Ambiente gerenciado em nuvem no qual um agente pode executar código, manipular arquivos e instalar dependências.
AI Studio (ferramenta): Plataforma apresentada para experimentar modelos Gemini, agentes e aplicações de demonstração.
Gemini API (ferramenta): API usada nas demonstrações para acessar modelos e criar agentes.
Google DeepMind (empresa): Organização da qual Philipp Schmid diz fazer parte.
Philipp Schmid (pessoa): Palestrante que apresenta as APIs do Gemini e o uso de sandboxes para agentes.

Tradução completa (pt-BR)

00:12 Então, olá a todos. Sejam bem-vindos à palestra “Por que os agents devem ter seu próprio sandbox”. Sou Philip. Faço parte da equipe do Google DeepMind e trabalho principalmente no AI Studio e na Gemini API. Somos uma equipe pequena, então vou tentar manter a parte entediante curta e deixar mais tempo para as demonstrações interessantes. Acho que também podemos fazer algumas perguntas no final. Talvez vocês precisem se sentar um pouco mais à frente para que eu consiga ouvi-los. Quero começar dando um pouco de contexto. Não sei se vocês já viram este slide, mas ele é muito popular em apresentações do Google para mostrar um pouco do que

00:46 conquistamos nos últimos dois anos com os modelos Gemini, mas também com nossos modelos open source, como o Gemma. E este slide já está desatualizado desde ontem. Ontem lançamos o Nano Banana Light, nosso novo modelo de geração de imagens. Super-rápido — quer dizer, super-rápido e superbarato. Custa cerca de 4 centavos por imagem. Também lançamos o Omni Flash na Interactions API. Agora, você pode usar o Omni programaticamente para criar e editar vídeos e, sim, desenvolver aplicações de mídia generativa. Para dar um pouco de

01:21 contexto histórico, imagino que todos já tenham ouvido falar de agents e de LLMs. Mas, para recapitular rapidamente de onde viemos: acho que, por volta de 2018 e 2019, com os primeiros modelos BERT e GPT, ficamos superanimados porque conseguíamos continuar frases, certo? Podíamos gerar poemas fornecendo as primeiras palavras, e então o modelo continuava o texto de forma coerente. Isso era legal, mas não muito útil nem prático para que qualquer um de nós construísse algo. Depois, passamos para a

01:52 abordagem baseada em instruções. Antes, tínhamos modelos pré-treinados que podiam continuar textos; depois, com o seguimento de instruções, basicamente treinamos modelos para responder a perguntas. Então, fazíamos uma pergunta, e o modelo respondia corretamente. E, com o ChatGPT, tudo mudou um pouco. Acho que a maioria das pessoas provavelmente começou por aí, e passamos a ter conversas em turnos entre usuário e modelo: uma entrada do usuário, uma resposta do modelo, uma entrada do usuário, uma resposta do modelo. Depois, combinamos isso com function calling, porque queríamos que o modelo executasse ações por nós. E agora estamos

02:26 nesse tipo de caixa-preta com objetivos, raciocínio e funções, em que não apenas damos um prompt ao modelo. Basicamente, damos um objetivo ao modelo e explicamos como verificar se ele foi alcançado ou como implementá-lo, para, com sorte, deixá-lo em execução por várias horas ou até dias e voltar depois com os resultados que queremos. Se você ainda não usou a Gemini API ou o AI Studio, pode acessar AI.studio ou toi.dev. São URLs bem rápidas e curtas. Crie sua própria chave de API. Se estiver com o computador e quiser acompanhar

02:58 mais tarde, experimentando algumas coisas que lançamos recentemente, pode fazer isso. Não é necessário configurar nada; você pode usar sua conta do Gmail e começar a experimentar. Se quiser usar modelos maiores e ter mais uso, informe os dados do cartão de crédito. Melhoramos bastante esse processo: você não precisa mais sair do AI Studio e ir para o Google Cloud. Pode fazer tudo dentro do AI Studio. Também pode definir seus próprios limites de gastos para que nada saia do controle. Quero começar falando da Interactions API, nossa nova API para os modelos Gemini e os agents Gemini. E, no lado direito

03:33 — desculpem, no lado esquerdo — temos alguns trechos de código. Se você nunca ouviu falar da Interactions API, pode pensar nela como nossa resposta à Responses API da OpenAI. Ela é muito mais voltada para desenvolvedores, muito mais simples e muito mais amigável para desenvolvedores web. E dá para perceber pelos dois trechos aqui: chamar um modelo, como o Gemini, ou chamar um agent, como o agent Antigravity, usa literalmente a mesma interface. Isso funciona com todas as modalidades oferecidas pelo Gemini. Então, você tem um modelo ou um

04:04 agent, uma entrada, que pode ser uma string simples ou dados multimodais, e ferramentas ou um ambiente — algo que me deixa muito animado e sobre o qual vamos falar mais tarde: por que todo modelo ou agent deveria ter sua própria caixa. Uma novidade da Interactions API é o gerenciamento de estado no servidor. Se não quiser gerenciar o estado no cliente, você pode transferi-lo para o servidor. Também temos operações de longa duração, ou seja, requisições assíncronas: você inicia algo. Se falarmos da geração de vídeo com o Omni,

04:36 ela leva bastante tempo, e talvez você não queira manter sua conexão HTTP aberta. Então, envia uma requisição, recebe um ID e pode configurar streaming ou polling para aguardar até que a geração seja concluída. Além disso, a API traz muitas simplificações para criar agents e usar ferramentas. Você pode combinar ferramentas integradas, como a Pesquisa Google, com function calling personalizado. Para ver alguns exemplos de código: o gerenciamento de estado no servidor é muito parecido com o da Responses API, se você já a usou. Chamamos de Interactions porque não recebemos apenas uma

05:07 resposta. Interagimos com modelos e agents. Você envia uma entrada e, se quiser fazer uma pergunta de acompanhamento, fornece uma nova entrada e, basicamente, apenas o ID do turno anterior. Então, no servidor, concatenamos todas as entradas diferentes e garantimos que o modelo veja o que foi feito até então. Isso vale para todas as modalidades. Para geração de áudio, você tem um modelo — temos nosso modelo Gemini TTS — e uma entrada. Como queremos receber áudio, não texto, você define a modalidade da resposta como áudio e algumas

05:42 configurações de geração. Por exemplo, se quiser usar — o mesmo padrão funciona para geração de imagens. Aqui temos nosso modelo de geração de imagens, o Nano Banana, uma entrada, algumas configurações de geração e, então, você recebe a imagem. Para usar ferramentas, também ficou muito melhor, eu diria, do que antes. Basta definir suas ferramentas, como Pesquisa Google, contexto de URL ou suas próprias funções personalizadas. Depois, você envia a requisição, e o modelo decide por conta própria: será que primeiro preciso fazer uma pesquisa no Google ou chamar

06:16 a função? Basicamente, todo o código que vocês veem aqui já é suficiente para criar um agent de CVE bem simples, que detecta se há alguma CVE para o React, neste caso. Ele usa a Pesquisa Google, usa o contexto de URL para visitar esses sites e, depois, usa function calling para estruturar os resultados, para que você possa, por exemplo, salvá-los no seu banco de dados ou consultá-los. E uma novidade, talvez diferente do que outros provedores de modelos fazem, é que deixamos de lado

06:46 o princípio dos turnos de usuário e modelo. Se você criar uma aplicação com outro provedor de LLM ou com modelos open source, sempre encontrará esse conceito de turnos de usuário, modelo, usuário, modelo. Como usuário, você fornece uma entrada e espera que o modelo retorne uma saída. Isso funcionava até um ou dois anos atrás, eu diria, quando recebíamos apenas respostas desses modelos. Mas, com os agents e o raciocínio, tudo isso mudou, certo? Agora, os modelos pensam por muito tempo

07:16 e podem expor alguns pensamentos diretamente ou apenas uma assinatura. Function calling não é bem algo que pertença ao papel de usuário, certo? Com as APIs normais, ou melhor, com as APIs anteriores, você teria que usar o turno do usuário para retornar a saída de uma função. Isso sempre me pareceu um pouco estranho, porque a saída, ou a nova entrada, vem do ambiente, não do usuário. Por isso, deixamos de usar esses turnos e passamos a usar etapas, como uma linha do tempo síncrona de etapas, em que cada ação ou geração é sua própria

07:50 tipo, o que facilita muito a extensão para novos recursos e capacidades que possam surgir no futuro, mas também mantém tudo muito simples de usar, porque você realmente define o que é feito. Então, se você cria um agent de chamada de função, retorna o resultado da função, e não algo como um usuário com função de usuário e algum conteúdo que pode ou não ser o resultado de uma função. E, no Google I/O, lançamos o agent anti-gravity, que vem com o próprio sandbox. Então, o agent remoto anti-gravity dentro da Gemini API é alimentado pelo mesmo agent harness usado

08:25 com o produto anti-gravity. Então, se você usou a IDE, o novo anti-gravity 2.0 O ou a CLI, talvez já tenha usado esse harness. Isso é muito importante. Quando falamos de harness, não queremos dizer o mesmo agent. O harness é basicamente o backend do nosso agent, mas pode ser diferente entre produtos diferentes. Então, a IDE anti-gravity é um agent de programação. Portanto, pode ter algumas ferramentas diferentes ou uma instrução do sistema um pouco diferente da do agent anti-gravity que temos na Gemini API, mas ainda é o mesmo harness. Ou seja, se melhorarmos o Gemini para que funcione melhor com esse harness,

08:58 também nos beneficiamos disso no anti-gravity, mas também na Gemini API. E, com esse novo agent, também introduzimos este campo de ambiente. Aqui, um ambiente remoto é basicamente um sandbox gerenciado por nós para aquela chamada à API. Isso significa que, se você enviar uma solicitação, nosso backend inicia um sandbox na nuvem onde o agent pode executar código, criar arquivos, gravar arquivos, instalar dependências, instalar suas próprias ferramentas ou

09:33 talvez chamar suas próprias APIs, e tudo é gerenciado e sem estado do nosso lado. Ou seja, você só envia a solicitação à API. Não precisa gerenciar a infraestrutura, e esses ambientes permanecem persistentes. Então, se você tiver uma conversa com várias interações, em que o agent — você define a entrada do usuário, sei lá, algo como “pesquise as notícias de tecnologia mais recentes e crie um arquivo” — e depois quiser fazer uma interação de acompanhamento, poderá usar o mesmo ambiente da interação anterior nessa nova interação. Mas isso também significa que você pode compartilhar

10:05 ambientes entre diferentes agents. Então, se você tiver, por exemplo, três agents trabalhando no mesmo ambiente, eles poderão compartilhar contexto pelo sistema de arquivos. Ou você pode até usar subagents para basicamente retomar um trabalho que outro agent tenha feito. E, claro, os ambientes são muito bons, mas o modelo precisa do contexto certo, das informações certas ou das ferramentas certas para trabalhar nesses ambientes. Então, você pode fornecer fontes. As fontes podem ser buckets do GCS, repositórios do GitHub ou arquivos em linha. Isso é muito útil se você quiser

10:37 integrar skills. Eu diria que o agent anti-gravity é nativo de skills e do sistema de arquivos. Então, se você armazenar skills no diretório de skills, elas serão detectadas automaticamente e incluídas na instrução do sistema. Mas, se você tiver um arquivo AGENTS.md do seu agent de programação ou dos agents que já usa, ele também será acrescentado automaticamente à instrução do sistema. E então você pode criar um agent, porque enviar uma solicitação é bom, e manter toda a configuração sem estado também é muito

11:08 bom, mas e se você quiser compartilhar isso? Ou se a equipe um criar um agent que a equipe dois queira usar? Por isso, criamos a Agents API, onde você pode definir o agent base — por assim dizer, o cérebro subjacente — e definir a instrução e também o ambiente. O ambiente pode ser um ambiente bruto, com fontes, ou você pode usar um ambiente existente. Então, imagine que tenho algum tipo de estrutura inicial para preparar, em que preciso instalar a CLI do GitHub,

11:39 adicionar algumas skills e talvez fazer algumas verificações básicas. Posso usar o agent para criar o próprio ambiente. Quando o agent terminar, receberei um ID de ambiente. Posso usar esse ID de ambiente para criar o novo agent. E, sempre que eu chamar esse novo agent, ele começará naquele ambiente já carregado e pré-configurado. Assim, é muito fácil usar agents para criar os próprios ambientes e depois criar agents a partir deles, que

12:09 você pode compartilhar com seus usuários ou clientes sem escrever nenhum Terraform, sem pensar em Kubernetes, microsserviços, Firecracker ou qualquer outra coisa. E, para facilitar as coisas para você e para seus agents de programação, criamos uma CLI para a Gemini API. Então, ela não é um agent de programação. Não é a Gemini CLI. É realmente uma CLI que seu agent pode usar para chamar a Gemini API. Ou seja, ele pode chamar o Nano Banana ou o Omni, se você quiser gerar alguns

12:39 recursos visuais. Mas você também pode usá-la para criar esses agents, iterar neles e aprimorá-los. O QR code deve levar ao repositório no GitHub. Também temos skills dedicadas para trabalhar com a Interactions API e a Agents API, caso queira experimentar mais tarde. E agora vamos fazer algumas demonstrações. Estou no AI Studio, dentro do AI Talk Radio. Se você assistiu à palestra principal para desenvolvedores do Google I/O ou esteve presente nela,

13:14 talvez já tenha visto isto. É apenas uma interface simples sobre agents gerenciados. Nós gerenciamos o agent. Vamos dar uma olhada nele daqui a pouco, mas basicamente é um programa de entrevistas no rádio, e esse agent de programa de entrevistas tem acesso a todos os diferentes modelos Gemini. Então, pode gerar uma miniatura, gerar fala, gerar música, fazer pesquisas e, basicamente, criar um programa de rádio de uma só vez. Vamos experimentar. Quero um programa de entrevistas no rádio sobre se abacaxi

13:53 combina ou não com pizza. E é grátis. Então, se você acessar o applet mais tarde, poderá usar gratuitamente todos os dias para criar seu próprio programa de entrevistas de rádio com IA. O que acontece é que, primeiro, iniciamos nosso ambiente e, depois, o modelo começa a pensar no que precisa fazer. A primeira etapa é instalar nossas dependências de Python e ler nossas skills; depois, ele continua trabalhando. Como isso vai demorar um pouco, já executei um programa de entrevistas no rádio sobre se devemos colocar primeiro o cereal ou o leite

14:29 na tigela. E a parte muito interessante de um programa de entrevistas no rádio é que não é como um podcast que você só escuta. Na verdade, há várias pessoas raciocinando e compartilhando suas opiniões sobre o assunto. Vamos ouvir um trecho. Existe uma ordem física correta para preparar a tigela do café da manhã ou estamos flertando com o caos culinário? [música] Boas-vindas ao AI Talk Radio. Aqui é Paul, transmitindo do nosso estúdio em Londres. Hoje vamos explorar o grande

15:00 debate do café da manhã: cereal primeiro ou leite primeiro. Vamos analisar objetivamente os prós e os contras dos dois métodos. Vamos atender às ligações. Temos David na linha, de Boston. David, você está no ar. >> É, obrigado, Paul. Olha, tem que ser cereal primeiro. É pura lógica, né? O cereal é a variável independente. Você despeja, vê o volume e depois adiciona leite para complementar. Além disso, se você despejar cereal seco numa tigela de leite,

15:31 vai espirrar para todo lado. Faz uma bagunça total. E a analogia com purê de batatas: você não colocaria molho numa tigela e jogaria um montão de batatas por cima, certo? Uma analogia marcante, David. A limpeza e o controle das porções certamente são argumentos fortes. Vamos ouvir o contraponto. Temos Sarah na linha, de Sydney. Sarah, seja bem-vinda. >> Oi, Paul. Olha, David está completamente errado. Leite primeiro muda totalmente a textura. >> Certo, legal. Então, se quiser experimentar por conta própria, acesse

16:05 AI Studio. No AI Studio, você tem a seção de criação no lado esquerdo, e há uma galeria. A galeria reúne applets e casos de uso pré-criados para o Gemini. Se você rolar a página para baixo, verá a nova experiência de criação e, ali, o Talk Show Radio. Se clicar nele, encontrará o applet e poderá fazer um remix, ou seja, ajustá-lo. Então, se não gostar de programas de entrevistas no rádio e preferir, sei lá, um aplicativo de podcast de verdade, poderá criá-lo com muita facilidade junto com o Gemini

16:37 adaptá-lo às próprias necessidades. E, como os applets são todos abertos em termos de código, também podemos dar uma olhada rápida em como nosso agent realmente funciona. E nosso agent é feito apenas de arquivos. Então, temos um arquivo agents.md dentro do nosso ambiente. Esse arquivo será carregado na inicialização do ambiente e, em seguida, incluído nas instruções do sistema. É um arquivo de agent bem básico. Ele contém todas as instruções para o nosso agent. Então, ele deve fazer algumas pesquisas, escrever alguns scripts para as diferentes pessoas, gerar música, gerar uma fala, juntar

17:11 tudo. E, para realizar todas essas tarefas, temos skills. Então, se olharmos para a geração de TDS, temos uma skill que ensina como executá-la. Temos um arquivo Python. Esse arquivo Python permite que o agent do Gemini chame outros modelos Gemini. Então, ele usa a API de interações para gerar uma fala que podemos usar depois. E é só disso que nosso agent precisa. E, se você quiser levar esse agent da interface do usuário para um backend, basta copiar esse arquivo, criar o agent e usá-lo. E, se você quiser

17:44 brincar com o próprio agent dentro do playground, há uma nova seção de agents nos seletores de modelos. Então, se quiser testar o deep research, pode testar o deep research. Mas também temos o agent do Anti-gravity. No agent do Anti-gravity, temos seis templates de agent diferentes que você pode testar e selecionar com muita facilidade para ver como funcionam. Vamos para o padrão. E o que eu gosto de fazer é explorar o ambiente. Vamos ver o que o agent descobre sobre onde está

18:14 em execução. Enviamos nosso prompt e agora ele começa. O ambiente deve levar de 7 a 10 segundos na primeira solicitação, e então vemos o agent trabalhando. Temos algum raciocínio e alguns comandos bash. Ele executa alguns comandos: verifica qual versão do sistema operacional está rodando e qual CPU e memória tenho. Depois, recebemos uma resposta do nosso agent: está rodando no Ubuntu, tem 8 vCPUs, 16 GB de memória, Python instalado e pip instalado. E então você pode

18:45 continuar mesmo. Vamos ver: você tem… temos o Node instalado? Então, é muito fácil fazer uma pergunta complementar, e ele continua com base no meu prompt. Você também tem a opção de baixar o ambiente no lado direito. Então, se o seu agent criou alguns arquivos que você quer extrair do ambiente e compartilhar, pode baixá-los com muita facilidade; há também uma API para isso. E então, o que mais?

19:18 Para mostrar rapidamente de novo como funciona, posso aumentar um pouco o tamanho. Quando enviamos uma solicitação, iniciamos o sandbox, que carrega todos os nossos arquivos, e então temos esse loop do agent rodando completamente no nosso servidor. Quando você cria agents, normalmente, muitas vezes precisa gerenciar o tool calling no seu cliente, certo? Precisa passar a chamada da função, executá-la em algum lugar e depois enviar o resultado da função de volta. Com os agents gerenciados, é realmente apenas uma chamada de API, e tudo

19:50 é executado dentro desse sandbox remoto. Você também pode se conectar a servidores MCP remotos ou executar servidores MCP locais dentro desse ambiente e, sim, começar. Então, se tiver interesse, temos uma ótima documentação na Gemini API, na seção de agents, com um guia de início rápido que mostra como enviar sua primeira solicitação, criar seu primeiro agent e começar. E, claro, instale as coding skills para que Claude Code, Codex ou qualquer modelo que você use possa ajudar você a começar. Obrigado por terem vindo. Se tiverem alguma

20:23 pergunta, estou por aqui

Transcrição original

[00:12] So, hi everyone. Uh, welcome to why agents should have their own sandbox. Uh, I’m Philip. I’m part of the Google DeepMind team, mostly working on AI studio and Gemini API. Uh, we have a small crew, so I try to keep the boring stuff short and like the exciting demo stuff long. And we can also ask some questions I guess at the end. Maybe you need to sit a little bit further at the front so I can understand you. Um so I want to start with a little bit of a background. I’m not sure if you have seen that slide but that’s a very popular slide when you do like Google presentations um to show a little bit um

[00:46] what we have achieved in the last two year with like the Gemini models but also our open models with Gemma and the slide is already outdated since yesterday. So yesterday we shipped Nano Banana Light uh which is our new image generation model. Super fast uh sorry super fast uh super cheap. Um it’s like 4 cent per image and then also we shipped Omni flash on the interactions API. So you can now programmatically use Omni to create videos to edit videos to yeah build gen media applications. And to give a little

[01:21] bit of a brief history, I assume everyone has heard about agent has heard about large language models. But to really quickly reflect where we are coming from. So I think around 2018 19 with the first bird models and GBT models, we were super excited because we could continue sentences, right? We were able to generate poems without uh with providing like a first few words and then the model coherently continue the text which was nice but not very useful or helpful for any one of us to build something. Then we we moved into the the

[01:52] instruction uh way. Before we had pre-trained models which could continue text and then with instruction following we basically trained models to answer questions more or less. So we told ask a question and the model correctly responded. Um and then with with chat GPT um everything changed a little bit. I think most of the people probably got started with that and we went into this user model turnbased conversation where we had a user input, a model input, a user input, a model output. Then afterwards we combine that with function calling because we wanted the model to take actions for us. And now we are in

[02:26] like this black box with goals, thinking and functions where we no longer just prompt the model. We basically give a goal to the model, tell them how to verify its goal or how to like deploy it and like hopefully have it running for multiple hours or even days and come back with the results we want to achieve. Um, so if you haven’t used Gemini API or AI studio before, you can go to AI.studio or toi.dev. So very quick, very short URLs. H, get your own API key. So if you have your computer with you and you if you want to follow

[02:58] along a little bit later on like trying out a few things we have shipped recently you can do that. Um no setup required can use your Gmail account. Um can start start experimenting. If you want to use bigger models more usage enter your credit card and we improved that a lot. So you don’t need to leave AI studio anymore to go into Google Cloud. You can do everything inside of AI Studio. You can set up your own budgets that nothing gets out of control. And I want to start about or talk about the interactions API which is our new uh API for Gemini models and Gemini agents. And on the right side

[03:33] sorry left side we have some code snippets. So if you never have heard about the interactions API you can think a little bit about that’s our answers to like the responses API from OpenI. It is much more developer focused, much more simpler, much more web developer friendly. And you can already tell in like the two snippets here uh to call a model like Gemini or to call an agent here like the anti-gravity agent, it’s like literally the same interface. And this works for all of the modalities Gemini offers. So you have a model or an

[04:04] agent, you have an input. The input can be a basic string or it can be multimodal data. And then you have tools or environment which uh I’m very excited and why which we are going to talk about later why every model or agent should have its own box. Uh new with the interactions API is you have serverside state management. So if you don’t want to manage the state on the client you can hand it over to the server. We have long running operations. So async requests basically you start something. If we talk about omni video generation

[04:36] takes quite a long time and you might not want to keep your HTTP connection open. So you send a request get back an ID can set up streaming or polling to wait uh until the the generation is completed and then um it comes with a lot of simplifications for building agents and tool use. So you can combine built-in tools like Google search uh with custom function calling and to look at some code examples. So for serverside state it looks very similar if you have used the responses API we call it interactions because we just not get a

[05:07] response anymore. We interact with models and agents. You send an input and if you want to do a follow-up turn you provide a new input and basically just the ID from the previous turn and then on the server we um concatenate all of like the different inputs and make sure that the model really reh sees what has been done so far. And this goes for all modalities. So for audio generation you have a model. We have our Gemini TTS model. We have our input and since we want audio back not text you define a response modality with audio and some

[05:42] generation configuration which was you for example want to use the same pattern works for image generation. So our image generation model uh nano banana here our input some generation uh generation config and then you get back your image and for tool use uh also much better I would say than previously. You just define your tools with like Google search URL context or your own custom function and then you send your request and the model decides on it on its own. do I first need to like run Google search or call

[06:16] the function and all of the code you see here is basically enough to create a very simple small CVE agent to detect if there are like any CVE um for react in this case and then like it uses Google search it uses URL context to visit those websites and then function calling to basically give structure to it so you can like save it in your database or look it up for example um and something new and maybe different to other model providers is that we moved away from

[06:46] this user model term principle. So if you build an application with another LLM provider or with open models, you have always this uh user model user model turn concept. So you as a user provide an input and expect the model to return an output. This worked until like one or two years ago I would say where we just got back responses from those models. But with agents and with reasoning, all of that changed, right? Models now think for a very long time

[07:16] where they might expose some thoughts directly or might just expose a signature. Function calling is not very uh a user role, right? With normal or like with previous APIs, you would need to use the user turn to return some function output, which for me always felt a little bit weird because the output or the new input is coming from the environment and not from the user. So that’s why we moved away from like those turns into steps or like to um like synchronous timeline of steps where every action or generation is its own

[07:50] type which makes it very easy to extend to new features and capabilities which might come in the future but also makes it still like very simple to use because you really define what it is done. So if you build a function calling agent, you return a function result and not like a a user role user with some content which might be a function result or not. And at Google IO we ship the anti-gravity agent uh which comes with its own sandbox. So the anti-gravity remote agent inside the Gemini API is powered by the same agent harness which is used

[08:25] with the anti-gravity product. So if you have used the IDE or the new anti-gravity 2.0 O or the CLI, you might have used that harness already. Very important here. When we talk about harness, we don’t mean the same agent. The harness is basically the the back end of our agent, but it might be different between different products. So the anti-gravity IDE is a coding agent. So it might have a little bit of different tools or a little bit of of a different system instruction than the anti-gravity agent we have in the Gemini API, but it’s still the same harness. Meaning if we improve Gemini to become

[08:58] better with that harness, we benefit inside anti-gravity, but we also benefit inside of the Gemini API. And with that new agent, we also introduce this uh environment field. And an environment here remote is basically for that API call, your agent gets a sandbox managed by us. Meaning if you send a request, our back end starts a cloud sandbox where the agent can run code, can create files, write files, um, install dependencies, install your own tools or

[09:33] maybe call your own APIs and it’s all managed and stateless on our side, meaning that you just send the API request. You don’t need to manage the infrastructure and those environments stay persistent. So if you have multi-turn conversation where the agent um you set user input I don’t know like um research the latest tech news and create a file and then you want to do like a follow-up interaction you can like use the same environment from your previous turn with that new interaction but also this means that you can share

[10:05] environments between different agents. So if you have like three agents working inside the same environment, they can share context through the file system or you can like even use sub agents to basically pick up a work uh another agent has been done and then of course environments are very good but the model needs the right context and the right information or the right tools to work inside those environments. So you can provide sources uh sources can be um GCS buckets, GitHub repositories or inline files. It’s very useful if you want to

[10:37] integrate skills. So the anti-gravity agent is skills or file system native I would say. So if you store skills inside the skills directory, it will automatically picked up and uh be pro uh included into the system instruction. But also if you have an agents MD file from your coding agent or from your existing agents, it will also be automatically appended to the system instruction. and then um you can create an agent because like sending a request is nice and having all of the configuration stateless is also very

[11:08] good but what if you want to share it or what if team one builds an agent team two wants to use um therefore we created the agents API where you can define the base agent so what’s the underlying brain so to speak you can define instruction and then also the uh environment um and the environment can be a raw environment like with sources or you and uh use an existing environment. So you can think about I have some kind of a scaffolding to do where I need to install like the GitHub CLI

[11:39] uh add some skills and maybe do some like sanity checks. I can use the agent to create its own environment. And after the agent is done, I get back an environment ID. I can use that environment ID to create the new agent. And every time I call this new agent, it will start from that already pre-loaded, preconfigured environment. And so it’s like very easy for you to use agents to build their own environments and then like to create agents out of them which

[12:09] you can share with your users or with your customers without writing any Terraform without thinking about Kubernates, microservices, firecracker or anything else. And to make it easier for you and for your coding agents, we created a CLI for the Gemini API. So it’s it’s not a coding agent. It’s not Gemini CLI. It’s really an a CLI that your agent can use to call the Gemini API. Meaning it can call Nano Banana or Omni if you want to generate some

[12:39] assets. But you can also use it to create those agents, iterate on those agents, and improve those agents. The QR code should bring you to like the GitHub repository and then also we have dedicated skills for working with the interactions API and the agents API um if you want to to play around with it later. And now let’s let’s do some some demos. So I’m in AI Studio inside the AI talk radio. If you have seen or attended the

[13:14] Google IO developer keynote, you might have seen uh this already. Um that’s just a simple UI on top of managed agents. We manage agent. We are going to look at the agent in a little bit, but it’s basically a talk show radio and that talk show u agent has access to all of the different Gemini models. So it can generate a thumbnail, it can generate um speech, it can generate music, it can do research and it’s basically a one short radio generator and we give it a try. And I want a talk show radio on whether pineapples

[13:53] belong on a pizza or not. And it’s free to use. So if you go to the applet later uh you can like have free daily usage to create create your own um AI talk show radio and what happens is like first step we start our environment and then the model starts thinking on what it needs to do and then the first step is like it installs our Python dependencies and it reads our skills and then it continues to work. Since this will take a little bit, I already ran a talk show radio on whether we should put in cereal first or milk

[14:29] first. And the very interesting part about a talk show radio, it’s not like a podcast you listen to. It’s really you have multiple um people like reasoning and like sharing their opinions on it and we give it a quick listen. Is there a correct physical order to preparing your breakfast bowl or are we flirting with culinary chaos? [music] Welcome to AI Talk Radio. I’m Paul broadcasting from our London studio. Today we are exploring the great

[15:00] breakfast debate. Cereal first versus milk first. We will objectively break down the pros and cons of both methods. Let’s go to our lines. We have David calling from Boston. David, you’re on the air. >> Yeah, thanks Paul. Look, it’s got to be cereal first. It’s basic logic, right? Cereal is the independent variable. You pour it, you see the volume, then you add milk to compliment it. Plus, like if you pour dry cereal into a bowl of milk,

[15:31] it splashes everywhere. It’s a total mess. And the mashed potato analogy, you wouldn’t put gravy in a bowl and drop a lump of potatoes on top, right? A striking analogy, David. Cleanliness and portion control are certainly strong arguments. Let’s hear the counterpoint. We have Sarah on the line from Sydney. Sarah, welcome. >> Hi, Paul. Okay, look, David has it all wrong. Milk first is it’s a total game changer for texture. >> Okay, cool. So, if you want to play around with it yourself, you can go to

[16:05] AI.studio. And on AI. studio you have that build section on the left side and there’s a gallery and gallery is basically pre-built applets use cases for Gemini and if you scroll down to it uh you have new build experience with and there’s the talk show radio if you click on it you will find the applet you can uh remix it meaning you can like adjust it so if you don’t like talk show radios and you would rather have I don’t know some real podcast uh application you can like very easily together with Gemini

[16:37] adjust it to their own needs. And since applets are all open uh in terms of code, we can also take a quick look on like how our agent really is. And our agent is just files. So we have an agents MD file inside our environment. That file will be loaded on environment startup which is then included into the system instruction. Very basic agent file. It has all of like the instructions for our agent to do. So it should do some research, write some scripts for the different people, generate music, generate a speech, mix

[17:11] everything together. And to do all of those works, we have skills for it. So if we look into like the TDS generation, we have a skill on how to run it. We have a Python file. That Python file itself allows the Gemini agent to call other Gemini models. So it uses the interactions API to generate some speech which we can then use. And that that’s all it takes for our agent. And if you want to take that agent from the UI to like a back end, it’s really you just need to copy that file and create the agent and then use it. And if you want

[17:44] to play around with the uh agent itself uh inside the playground, we have uh inside the model pickers a new agent section. So if you want to test deep research, go test deep research. But there’s also the anti-gravity agent. And on the anti-gravity agent, we have six different uh agent templates uh which you can like very easily test, select and and see how it works. We go into like the the standard one. And what I really like to do is like explore the environment like let’s see what the agent finds out about where it is

[18:14] running. We send our prompt and now it starts the environment should take for the first request like 7 to 10 seconds and then we see the agent like doing its work. So we have some reasoning, we have some bash commands. So it runs so it checks what uh version west version I’m running on what CPU memory I have and then we get back a response from our agent that is runs on Ubuntu um has 8 vCPU 16 GB of memory python installed pip installed and then you can like

[18:45] really continue let’s see um do you have do we have node installed um so you can like very easily follow up um and it just continues based on like my prompt and then also you have the option on the right side to download the environment. So if your agent has created some files you want to extract out of the environment, share it, can very easily download it or there’s an API for it as well. And then um uh what else? Uh

[19:18] to quickly show you again how it works, I can make that a little bit bigger. So when you when we send a request um we like start the sandbox and it loads all of our files and then we have like this agent loop completely on our server. So when you build agents normally a lot of times you need to manage the function calling on your client right you need to passse the function call run it some somewhere and then send back the function result and with the managed agents it’s really just a single API call and everything

[19:50] runs inside that remote sandbox you can also connect remote MCP servers or run uh local MCP servers inside of that environment and um yeah really get started so if you are interested about it uh we have great documentation inside the Gemini API under agents with a quick start which walks you through how to send your first request, build your first agent and get started and then of course uh install the coding skills to have claude codeex or whatever model you use to to help you get started. Uh thank you for for coming. If you have some

[20:23] questions I’m like here