How Google DeepMind Runs Agents at Scale — KP Sawhney & Ian Ballantyne, Google DeepMind

What happens when you ask an agent to build from a specification, but the project already contains an implementation? That is the starting point for Ian Ballantyne and KP Sawhney’s demonstration. Ballantyne, a developer relations engineer at Google DeepMind, introduces Antigravity as more than a Visual Studio-style editor. Behind its familiar interface is an agent manager that can spawn agents across projects. Sawhney works on DeepMind’s AI platform team, where the harness behind that interface is itself an engineering concern.

Ballantyne attaches a specification file and asks Flash to implement it. The first attempt produces errors, so he restarts and submits the request again. Once work begins, the agent discovers existing generated files rather than an empty project. Its built-in planning and to-do mechanisms give it a way to decide what still needs changing. It then opens a browser that Antigravity can control to inspect the application. The welcome page shown here marks that browser launch, not a completed application test.

The browser loop goes beyond taking a picture of a page. The agent can inspect the DOM, feed information about the page back into its work, and attempt interactions with the application. Ballantyne describes a completion report explaining what changed, with screenshots or a recording available as review artifacts. At this point, those are expected outputs; the game has not yet loaded successfully.

The implementation plan provides a separate intervention point before further changes proceed:

1. Inspect the changes the agent proposes.
2. Edit or comment on a particular line to correct the intended behavior.
3. Select proceed to send the agent back to work.

The plan is an editable part of the workflow, allowing a person to correct intent before judging the finished implementation. Ballantyne leaves the agent working while the discussion moves to the internal harness.

Sawhney previously worked on the Deep Research agent, available through the Interactions API. His focus has since shifted to improving the Antigravity harness internally, including its use against Google’s enormous monorepo. That work raises a broader question: can the same environment support research and other tasks as well as coding?

One proposed change concerns how research stages exchange information. Instead of passing huge blobs of search text from one stage to the next, different parts of the pipeline could collaborate through a shared filesystem. Files would become a common workspace for the research process. Sawhney presents this as a direction for generalizing the harness, rather than an already completed replacement for Deep Research’s architecture.

Inside Google, another major focus is the growing library of skills that help people perform specialized work. Sawhney leaves further projects for possible discussion at I/O, but describes the immediate problem plainly: useful contributions can become uncontrolled skill sprawl. Improving the library therefore includes selecting which skills deserve to survive. His Darwinian comparison captures the desired selection pressure, although the evaluation machinery behind it remains a later question.

Returning to the demo, Ballantyne points out the blue border indicating that Antigravity has control of the browser. The agent appears to have figured out how to start the game, although he is unsure whether it understands the controls. He reports that the previous game, generated by a different model, has been completely rewritten from the specification. The agent is now inspecting the DOM, looking for errors, and trying to work out how to use what it built.

A final video is still anticipated when Ballantyne opens the agent’s scratchpad. These notes expose a trace of the behaviors it is trying to work through, giving the user another place to inspect progress and interrupt unwanted activity. The demonstrated loop therefore includes implementation, attempted browser interaction, and inspectable task notes; it does not establish that the promised final recording was delivered. Ballantyne describes this as a familiar harness workflow for using Gemini models in development.

At Google scale, Sawhney’s first concern is how many tokens these workflows consume. A single user request can initiate substantial downstream work, making per-user and per-team quotas central operational controls. Reducing cost also means deciding which components actually require the most capable model.

Sawhney proposes mixing Gemma 4 running on available GPUs or TPUs with more advanced models for selected components. His description of local inference as effectively free concerns hosted-model quota, not hardware or operating cost. Evaluation adds another demand on compute: the team needs to determine whether complicated workflows succeeded while keeping the cost of testing manageable. He mentions investigating mock TPUs to exercise the harness and agentic flow without consuming substantial TPU hours. That separates testing orchestration behavior from paying for every test to run through real inference infrastructure.

Audience projects make the demand problem concrete. One participant is building first for personal use, then for hospital radiology departments, combining EHR data with radiologist data. The participant is considering Gemma because they want open-source models. Another contribution describes open-source memory infrastructure built around an ontology-driven complex graph—a harness layer that other developers can use.

The memory-project participant claims roughly 15,000 stars. They report roughly 3 million complex-graph generations or pipelines per month, with one user able to create a thousand in a day. These are participant-reported workload figures, with no counting method or workload conditions supplied; the monthly figure is not a user count. The operational implication is that user count alone says little about the volume an agent service must absorb.

Ballantyne extends that into a hypothetical power user operating a team of 100 agents: how do you stop one person from overwhelming the system? Sawhney says the current internal answer is blunt quota enforcement. DeepMind has power users who eventually have to stop. He also cites what he describes as Anthropic blocking OpenClaw in a discussion of subscription economics: sustained agent activity can consume far more tokens than a subscription model comfortably covers.

There is a human operational layer behind those controls. Ballantyne recalls asking how an engineer knows when a Google job is using too many resources and being told that someone will tell them. In practice, SRE teams monitor resource spikes around the clock and may ask an engineer to stop a job on a particular cluster. Quotas and operator intervention both remain part of running the system.

An audience question about observability shifts the focus from containing demand to explaining behavior. Sawhney describes a custom web application connected to an agent backend used for many Google workloads. When a user submits a query to an agent hosted there, the query automatically appears in the interface. Engineers can drill through the hierarchy of the system all the way down to the raw prediction request sent to the model.

A separate agent trajectory store emphasizes coding workflows, where a run may contain a huge number of steps. Its diagnostic purpose is to locate the exact point at which the model began looping or diverging from the task.

Both are custom internal tools in Sawhney’s account. The audience member’s alternative—exporting everything to a log file—highlights what the richer interface adds: navigation through a long execution rather than just possession of its logs.

Asked whether Deep Research will be available in Antigravity, Sawhney says the team is actively exploring the integration without committing to a release. The hoped-for benefits are faster execution, lower cost, and better results from orchestrating research through the same harness. API availability and harness integration are separate questions: the former already exists in this discussion; the latter remains exploratory.

The architectural motivation is the amount of context passed through the research system. Repeatedly carrying extensive material through the pipeline increases expense and consumes context capacity. A shared workspace could let each component behave more like a collaborator in a human research team. That environment could also support outputs beyond the final report, including infographics, supporting artifacts, and additional documents. Sawhney describes potential benefits rather than measured improvements.

The next question asks how many levels of nested sub-agents Antigravity supports, prompted by the questioner’s experience with Copilot. Ballantyne does not know the nesting limit or detailed implementation. He describes multiple simultaneous tracks within a project, including jobs that may overlap, but says the assignment of particular agents is relatively opaque. This is not an account of an exposed, arbitrarily deep parallel agent tree.

For Sawhney, the future engineering problem has two parts: making agent-to-agent communication efficient and giving a person the ability to shape that work. His image is a human supervising a digital assembly line. More autonomous participants increase the importance of coordination and intervention rather than removing those responsibilities.

The audience then asks where skills, MCP, CLIs, and self-improvement fit as community preferences change. Sawhney favors skills plus guardrailed CLI interactions. He is skeptical about MCP’s longevity, while valuing its authentication capabilities. His practical example is a skill for debugging raw logs that can perform most of its work through the CLI.

The organizational benefit comes from who writes the skill. At Google, an expert in a particular area can contribute instructions that transfer specialist knowledge to both colleagues and their agents. That explains Sawhney’s personal preference, but it is not a product decision to abandon MCP: Ballantyne says Antigravity supports both approaches, with community usage informing continued support.

That returns the discussion to the earlier promise that only the best skills should survive. How is quality determined? Sawhney identifies several obstacles:

• Environment setup: Evaluations require sandboxed environments configured appropriately for each problem set. Provisioning those environments is substantial mechanical work.
• Relevant datasets: Public benchmarks help with external comparisons, but creating new data for specialized skills is especially difficult.
• Author responsibility: A skill’s author bears much of the responsibility for providing a suitable test.
• Agent-designed evaluations: People are experimenting with agents designing tests, but this remains work in progress.

A large skill library therefore creates an evaluation obligation alongside its knowledge-sharing benefit.

An AI Ultra subscriber brings the discussion back to the browser: testing is valuable when it works, but retries and apparent network failures make it difficult to tell whether the real problem is exhausted quota. Even at the highest subscription tier available to the questioner, Antigravity does not make the distinction clear enough.

Ballantyne says internal users have worse limits because customers receive priority, joking that this explains his repeated clicks during the demo. He expects tier-specific limits to persist and distinguishes his corporate Ultra access from his personal account, where he changes his behavior to fit the available allowance.

The direction he describes is preference-driven model switching under the harness. If capacity runs out on Pro, the workflow could move to Flash; if subscription capacity is exhausted entirely, it could continue on a local model. This is a proposed experience, not a confirmed automatic fallback feature or a concrete setting the audience member can adjust.

Stopping for quota must remain visibly different from finishing the task. Ballantyne imagines sending a job away, doing something else, and returning to find it has spent an hour idle because it hit a limit. The intended improvement is both continuity where another model can help and clearer signaling when work cannot continue.

The final question asks how review can keep up with code generation, and whether models could learn from historical Google review comments and commits. Sawhney describes an existing system with two layers: language-specific auto-review models fine-tuned on internal style guides and good code examples, followed by product-area-specific system instructions and prompts. The first layer captures language conventions; the second tailors the signal delivered to reviewers working on a particular product.

Sawhney gives a recent example: a PR he submitted the previous day received a useful comment from an agent someone had deployed, without him manually triggering auto-review. Review is another station in the human-supervised assembly line. Assistance is needed not only to produce changes, but also to inspect the growing stream of changes before people accept them.

Ballantyne connects that internal infrastructure to Jules, a public web interface for working on users’ own GitHub projects, which he also mentions in the context of review components. He closes on the pressure created by increasing agent-generated code: producing more software expands the work of checking it. The development loop remains incomplete if implementation accelerates while review becomes the bottleneck.