Talk by Philipp Schmid (Google DeepMind) at the AI Engineer World's Fair 2026 on giving AI agents their own managed cloud sandboxes. Covers the Gemini Interactions API (one interface for models and agents, server-side state, background jobs, built-in and custom tools across text, audio and images, and a timeline of steps replacing user/model turns), the Antigravity agent in the Gemini API running in a managed cloud sandbox, sharing environments between agents, skills and AGENTS.md files, the Agents API for packaging reusable agents, the Gemini API CLI, and a demo of an AI talk radio agent built from an AGENTS.md file and skills. Description-based outline; the video's content is not independently verified here. # Channel Identity Observations: Philipp Schmid, Google DeepMind ## Source Scope - **Video:** "Why AI Agents Should Have Their Own Sandbox — Philipp Schmid, Google DeepMind" - **Source type:** Title and transcript only. No curated metadata was supplied, so no additional identity context is available. - **Note on attribution:** The title and transcript attribute the talk to Philipp Schmid of Google DeepMind. Observations below concern presentation style and claimed scope, not the channel's broader identity. --- ## 1. Explicit Self-Description These are statements the speaker makes about himself or his role. - **Role and team:** The speaker introduces himself as Philip and says he is "part of the Google DeepMind team, mostly working on AI studio and Gemini API." > "I'm Philip. I'm part of the Google DeepMind team, mostly working on AI studio and Gemini API." - **Team size framing:** He describes his team as small and frames his presentation style around that. > "we have a small crew, so I try to keep the boring stuff short and like the exciting demo stuff long." - **Stated purpose of the talk:** He presents the session as an explanation of why agents need their own sandbox, and says questions are welcome at the end. > "welcome to why agents should have their own sandbox." These are self-descriptions. They are claims by the speaker and have not been independently verified from the material. --- ## 2. Intended Audience The transcript indicates an audience of developers and technically engaged attendees. - **Developer-oriented onboarding:** He directs viewers to try the product themselves. > "if you haven't used Gemini API or AI studio before, you can go to AI.studio ... get your own API key." - **Code-level explanation:** He walks through API snippets and request structure, implying a developer audience. > "on the left side we have some code snippets." - **Comparative framing for developers:** He compares the product to a competitor's API to help developers orient. > "it's our answers to like the responses API from OpenI. It is much more developer focused, much more simpler, much more web developer friendly." - **Coding-agent users:** He addresses users of coding agents directly. > "install the coding skills to have claude codeex or whatever model you use to to help you get started." --- ## 3. Claimed Scope The speaker makes a range of product and technical claims. These are presented as statements by the creator and are not independently verified by the transcript. ### 3.1 Product and Model Claims - Gemini and Gemma models are referenced as recent achievements. - A new image model ("Nano Banana Light") is described as "super fast" and "super cheap," at "4 cent per image." - Omni Flash is said to be available on the interactions API for video creation and editing. ### 3.2 Platform Capability Claims - **Interactions API:** Described as a Gemini equivalent to the responses API, with server-side state management and long-running operations. - **Managed remote sandbox:** The speaker says the agent "gets a sandbox managed by us" and that "our back end starts a cloud sandbox." - **Agents API:** Described as allowing a base agent and environment to be defined and shared. - **CLI:** Described as a tool that lets coding agents call the Gemini API. ### 3.3 Demonstrated Patterns in the Material These are behaviors shown on screen or in the narrative, separate from the speaker's claims about them. - **Live demo structure:** He demonstrates an AI talk radio applet, plays a sample audio clip, shows the agent's files (`agents.md`, skills, a Python script), and runs a live prompt in the anti-gravity agent template. - **Sample environment check:** The shown agent reports running on Ubuntu with 8 vCPU and 16 GB of memory. This is what the transcript records the agent reporting, not an independently verified fact. - **Preference for demo-led explanation:** He states an intent to keep background short and demos long, and the structure of the talk reflects that. --- ## 4. Evidence Summary by Observation | Observation | Type | Supporting passage | |---|---|---| | Works on AI Studio and Gemini API at Google DeepMind | Self-description | "I'm part of the Google DeepMind team, mostly working on AI studio and Gemini API." | | Presents to a developer audience | Observed presentation | Code snippets, API comparisons, setup instructions | | Favors demos over background | Observed presentation and self-described | "keep the boring stuff short and ... the exciting demo stuff long" | | Frames products as shipped and recent | Claim | "yesterday we shipped Nano Banana Light" | | Sandbox is managed and stateless per request | Claim | "your agent gets a sandbox managed by us" | --- ## 5. Limits of This Analysis - Observations are confined to this single video and its transcript. - No channel-level conclusions are drawn here. Claims about product performance, pricing, and capabilities are the speaker's statements, not verified facts. - The transcript contains automated-style artifacts (e.g., unclear words, bracketed music cue), so some passages may be imprecise. # Delivery Observations: "Why AI Agents Should Have Their Own Sandbox" (Philipp Schmid, Google DeepMind) ## Scope and Evidence Basis These observations cover only the spoken delivery visible in the supplied transcript: vocabulary, recurring phrases, teaching structure, and pacing markers. They do not assess the speaker's character or intentions. The transcript contains filler and self-corrections, which are noted where relevant. --- ## 1. Opening and Framing Habits - **Self-introduction with role context.** The talk opens with a brief introduction of role and team: > "Uh, I'm Philip. I'm part of the Google DeepMind team, mostly working on AI studio and Gemini API." - **Explicit time-allocation statement.** The speaker announces a split between content types: > "I try to keep the boring stuff short and like the exciting demo stuff long." - **Audience-interaction invitation.** Questions are deferred to the end, with a request for audience positioning: > "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." --- ## 2. Recurring Verbal Tics and Hedges These are the most frequent filler and hedging patterns in the transcript. - **"Uh" / "um" as spoken pauses.** Appears throughout, for example: > "Uh, welcome to why agents should have their own sandbox." > "Um so I want to start with a little bit of a background." - **"like" as a filler or softener.** Examples: > "I try to keep the boring stuff short and like the exciting demo stuff long." > "and like hopefully have it running for multiple hours or even days" - **"I guess" / "I assume" / "I don't know" as hedges.** Examples: > "we can also ask some questions I guess at the end." > "I assume everyone has heard about agent has heard about large language models." > "maybe like a I don't know like um research the latest tech news" - **"right?" as a rhetorical check-in.** Examples: > "we could continue sentences, right?" > "and then you want to do like a follow-up interaction" *(note: this one lacks "right?"; see below)* > "Function calling is not very uh a user role, right?" > "So if you build a function calling agent, you return a function result..." The clearest "right?" usages are the first two quoted above and the third; the pattern is observable but not dense. - **Self-correction mid-sentence.** Examples: > "Super fast uh sorry super fast uh super cheap." > "Sorry left side we have some code snippets." > "And our agent is just files." --- ## 3. Vocabulary and Terminology Patterns ### 3.1 Repeated Anchor Terms The speaker repeatedly uses a small set of named concepts, reinforcing them through restatement: - **"managed agents"**, **"environment"**, **"sandbox"**, **"harness"**, **"interactions API"**, **"agents API"**, **"skills"** ### 3.2 Explicit Term Definition The speaker defines terms that may be new to listeners, sometimes with a contrast: > "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." > "If you have never heard about the interactions API you can think a little bit about that's our answers to like the responses API from OpenAI." ### 3.3 Comparative Framing Terms are frequently positioned against familiar alternatives: - Interactions API versus OpenAI's responses API. - Remote environment versus client-managed state. - Step-based timeline versus the "user / model" turn model. ### 3.4 Simplicity and Accessibility Language The speaker emphasizes ease of use with repeated phrasing: > "It is much more developer focused, much more simpler, much more web developer friendly." > "no setup required" > "very easy" *(appears multiple times, e.g., "very easy to use", "very easy for you to use agents")* --- ## 4. Teaching Structure and Sequencing The delivery follows a recognizable progression that the speaker signals verbally: 1. **Historical arc.** Chronological framing from pre-trained models through instruction following, chat, and function calling to current goal-driven agents. 2. **Platform entry point.** How to get started (URLs, API key, credit card, budget controls). 3. **API concepts.** Interactions API, with code-level comparisons across modalities. 4. **Conceptual shift.** The move from user/model turns to steps. 5. **Product application.** Remote environments, sharing environments, skills, and the agents API. 6. **Tooling.** The CLI. 7. **Live demonstrations.** AI Talk Radio, then the anti-gravity agent. 8. **Closing call to action.** Documentation and coding-skill installation. Signposting language is used to mark transitions, for example: > "And I want to start about or talk about the interactions API..." > "And now let's let's do some some demos." > "to quickly reflect where we are coming from." --- ## 5. Pacing and Demo Narration Style - **Narrates actions as they happen during demos.** The speaker describes what the system is doing in real time: > "So first step we start our environment and then the model starts thinking on what it needs to do..." > "So it runs so it checks what uh version west version I'm running on..." - **Acknowledges latency openly.** Rather than hiding wait times, the speaker sets expectations: > "Since this will take a little bit, I already ran a talk show radio..." > "it starts the environment should take for the first request like 7 to 10 seconds" - **Uses pre-recorded or pre-run material as a fallback.** The cereal-versus-milk example is presented as already completed. --- ## 6. Use of Analogies and Concrete Examples - **Culinary and everyday analogies** appear in the demo content, such as the cereal-first debate and the "mashed potato analogy" within it. - **Developer-facing analogies** are used for conceptual points, such as: > "Function calling is not very uh a user role... the output or the new input is coming from the environment and not from the user." - **Scale or cost framing** with specific numbers: > "it's like 4 cent per image" --- ## 7. Tone and Register (Observable Features Only) - **Conversational and informal.** Contractions, fragments, and spoken connectors ("so", "and", "right?") dominate. - **Enthusiasm markers.** Phrases such as "super fast," "super cheap," "very excited," and "really like" are present, and the speaker states directly: > "which I'm very excited and why which we are going to talk about later" - **Inclusive pronoun use.** Frequent "we" (Google team) alongside direct "you" addressing the audience: > "We manage agent." > "you can go to AI.studio" --- ## 8. Limitations and Uncertainty - **Transcript quality.** The transcript contains garbled or unclear spots, for example "passse," "Kubernates," "toi.dev," and "reh sees." These are transcription artifacts and may not reflect the speaker's actual wording. Quotes in this document reproduce the transcript as written. - **Speaker-label artifacts.** Multiple speakers appear in the demo audio (the radio hosts), and their lines are not labeled as distinct speakers in the transcript. Observations about tone apply to Philipp Schmid's presenting voice only. - **Thin evidence for some patterns.** The "right?" tag and "I guess" hedge appear only a few times each, so their frequency is noted as low-confidence. - **Visual cues not available.** Gestures, slides, and screen content are not captured in the transcript; the demo observations rely on narration alone. # Observation Record: "Why AI Agents Should Have Their Own Sandbox" — Philipp Schmid, Google DeepMind ## Speaker & Context - **Speaker:** Philipp Schmid, identified in-transcript as part of the **Google DeepMind team**, working mostly on **AI Studio and the Gemini API**. - Format: conference-style talk with demos; speaker notes he'll "keep the boring stuff short" and prefers Q&A at the end. --- ## Claims on Google Model Releases - Schmid states Google's standard "progress slide" is **"already outdated since yesterday"**, citing two new releases (as stated by him): - **Nano Banana Light** — new image generation model, described as "super fast, super cheap," at roughly **4 cents per image**. - **Omni Flash** on the **Interactions API**, enabling programmatic video generation/editing for "gen media applications." - He also promotes AI Studio access (`AI.studio` or `toi.dev`), noting billing and budget controls are now handled inside AI Studio without going to Google Cloud. ## Claimed History of LLM Interaction Paradigms Schmid offers a staged narrative (presented as his framing, not settled fact): 1. ~**2018–19**: BERT/GPT-era models — coherent text continuation, "nice but not very useful" for building things. 2. **Instruction following** — models answering questions. 3. **ChatGPT era** — user/model turn-based conversation. 4. **Function calling** — models taking actions. 5. **Current agentic paradigm** — a "black box with goals, thinking and functions," potentially running for hours or days. ## Position: The Interactions API - Schmid characterizes the **Interactions API** as Google's answer to OpenAI's **Responses API** — "much more developer focused, much more simpler, much more web developer friendly." - Claims made about its design: - **Single interface** for both models and agents (e.g., Gemini or the anti-gravity agent), across all modalities. - **Server-side state management**: follow-up turns require only the previous turn's ID; the server reassembles context. - **Long-running operations**: async requests with polling/streaming for slow tasks like video generation. - **Combined built-in tools** (Google Search, URL context) with **custom function calling**; the model decides tool usage on its own. He claims the tool-use code shown suffices to build a small CVE-detection agent for React. ## Position: Moving Away from User/Model Turns - Schmid explicitly argues the **user/model turn principle** broke down: function outputs come "from the environment and not from the user," which "always felt a little bit weird" to him. - His stated solution: a **timeline of typed steps** rather than turns, which he claims eases extension to future capabilities. ## Position: Environments & Sandboxes (Core Thesis) - The **anti-gravity agent** in the Gemini API ships with its own **remote sandbox environment**, powered by the **same agent harness** as the anti-gravity product (IDE, anti-gravity 2.0, CLI). - **Qualification he stresses:** same *harness* ≠ same *agent* — the IDE's coding agent may have different tools/system instructions, but harness improvements benefit both product and API. - Properties of remote environments as described: - Google-managed cloud sandbox; agent can run code, create/write files, install dependencies, call custom APIs. - **Stateless infrastructure for the developer**, but **persistent environments** across multi-turn conversations. - **Shareable between agents** — multiple agents can share context via the file system; sub-agents can pick up prior work. - **Sources** can be GCS buckets, GitHub repos, or inline files; **skills directories** and **AGENTS.md files** are auto-appended to the system instruction. ## Position: The Agents API - Enables defining a **base agent** (brain, instruction, environment) that can be shared across teams. - He describes a workflow where an **agent builds its own environment** (e.g., installing GitHub CLI, adding skills), returns an environment ID, and that preconfigured environment seeds a new reusable agent — "without writing any Terraform without thinking about Kubernetes, microservices, firecracker or anything else." ## Position: CLI for Coding Agents - Schmid distinguishes the new **Gemini API CLI** from Gemini CLI: it is *not* a coding agent but a tool *for* coding agents to call Gemini models (Nano Banana, Omni) and to create/iterate on agents. Dedicated skills exist for the Interactions and Agents APIs. ## Demo Observations (as demonstrated on stage) - **AI Talk Radio applet** (free daily usage in AI Studio's gallery): generates a multi-host talk show; demo prompt was "whether pineapples belong on a pizza"; a pre-run episode on **cereal-first vs. milk-first** was played, featuring callers "David" (Boston, cereal-first, "cereal is the independent variable") and "Sarah" (Sydney, milk-first for texture). These are generated fictional agent outputs, not factual claims. - **Agent internals are "just files":** an AGENTS.md instructions file plus skills (e.g., a Python file calling the Interactions API for TTS). He claims migrating the agent from UI to backend is "copy that file and create the agent." - **Anti-gravity agent playground**: environment startup takes **7–10 seconds** for the first request (his figure); agent self-inspected Ubuntu, 8 vCPU, 16 GB memory, Python/pip. Environment can be **downloaded** via UI or API. - **Managed agents run the loop server-side**: single API call instead of client-side function-call management; supports **remote and local MCP servers** inside the environment. ## Unresolved / Open Items - The talk ends with an open Q&A invitation; no counterarguments or alternative design views (e.g., critiques of server-managed state or sandbox lock-in) are presented or addressed in the transcript. - Performance, pricing (beyond the 4-cent image figure), and security of shared environments are asserted only qualitatively and not substantiated within the transcript. # Speaker & Provenance Record ## Video Identification - **Title:** Why AI Agents Should Have Their Own Sandbox — Philipp Schmid, Google DeepMind - **Format:** Conference-style talk with live demos and closing Q&A invitation ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Philipp Schmid** | **Creator / Presenter** — Google DeepMind team member working on AI Studio and Gemini API | Self-introduction: *"I'm Philip. I'm part of the Google DeepMind team, mostly working on AI studio and Gemini API"* | | **"Paul" (AI-generated radio host)** | **Fictional character within demo content** — voice in the AI Talk Radio demo output | Part of generated demo audio, not a real speaker | | **"David" and "Sarah" (AI-generated callers)** | **Fictional characters within demo content** | Simulated call-in guests in the generated radio segment | > Note: All voices in the radio demo segment are machine-generated content produced by the agent being demonstrated, not human speakers. ## Referenced Sources & Products (First-Party Claims) Claims below originate from the presenter and concern Google/DeepMind products; they are **not independently verified** in the transcript. - **Gemini models, Gemma open models** — referenced via a "popular slide" at Google presentations - **Recent releases claimed:** "Nano Banana Light" (image generation, ~4¢/image) and "Omni flash" on the Interactions API ("shipped yesterday" per presenter) - **Interactions API** — described as Google's answer to OpenAI's Responses API; server-side state, long-running operations, step-based (non user/model-turn) design - **Anti-gravity agent** — shipped at Google I/O; same agent harness as the Anti-gravity IDE/CLI/2.0 product; remote managed sandbox environments - **Agents API** — shareable, preconfigured agent definitions with reusable environment IDs - **Gemini API CLI** — GitHub repository referenced via QR code (URL not stated in transcript) - **Access points cited:** AI.studio, toi.dev, AI Studio build-section gallery ("talk show radio" applet, free daily usage, remixable) - **Documentation** — claimed quick start guide under Gemini API "agents" docs ## Third-Party References - **OpenAI** — Responses API compared; ChatGPT cited in LLM history narrative - **BERT/GPT models** (~2018–19), ChatGPT — historical context only - **Claude Code / Codex** ("claude codeex") — mentioned as coding-agent tools usable with provided skills - **React CVE agent example**, Google Search, URL context, MCP servers (remote and local) — technical references ## Promotional Segments - **Product promotion throughout** — the talk functions as a product walkthrough for Gemini API, AI Studio, Interactions API, Agents API, and the Anti-gravity agent; no paid sponsorship is stated, but the content is vendor-presented by a Google DeepMind employee. - Sign-up encouragement: "get your own API key," credit-card billing and budget setup mentioned. ## Availability & Access Limits - Demo applet described as **free to use with free daily usage** via AI Studio gallery. - Larger models / more usage require **entering a credit card**, manageable inside AI Studio. - Transcript contains **no comment availability** information. - No external citation list or bibliography provided; all claims are verbal presenter statements. ## Uncertainty Flags - Product names rendered from auto-transcript may be inexact (e.g., "Nano Banana Light," "toi.dev," "anti-gravity 2.0"). - Demo hardware/environment specs (Ubuntu, 8 vCPU, 16 GB RAM) are agent-reported within the demo, not independently confirmed. 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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 questions I'm like here