Get Out of the Model's Way — Kevin Hou, Google DeepMind

Imagine coaching Argentina in the eighty-ninth minute with Messi on your team. Kevin Hou’s play is simple: “give Messi the ball and get the heck out of the way.” The analogy introduces a product design problem: a capable model can take on substantial work, but the surrounding application has to give it room to do so. Hou, who leads part of Antigravity’s engineering team at Google DeepMind, calls this “scaling with intelligence.” As the model improves, users should experience a more capable product.

Antigravity began as an agent-first coding product for technical and nontechnical users. Its initial IDE included an agent manager for orchestrating multiple agents. The team subsequently extracted the agent into a CLI and, with Antigravity 2.0, separated the IDE and agent manager into two applications. The standalone manager brings projects, subagents, worktrees, scheduled tasks and voice interaction into a single place. That separation is the first concrete expression of the principle: managing work should not require staying inside an editor.

The progression starts with the tools Hou worked on in 2022: autocomplete and chat sidebars supported by embeddings, rules files and abstract syntax tree parsing. Much of the surrounding application followed deterministic logic because that was what the models could handle. As capabilities changed, each generation of tools needed different building blocks:

• Agents in 2024: MCP, custom tools and permission systems supported models that could take actions across multiple steps.
• Agent managers in 2025: Humans began supervising several agents in parallel, supported by skills, hooks and artifacts.
• Agent teams in 2026: Antigravity’s proposed next layer combines dynamic subagents, generative UI and sidecars, allowing the model to organize more of the work itself.

Moving between those layers can mean taking away something users like. Giving an AI access to a terminal raised obvious fears about destructive commands. Hou describes better model judgment and investment in permission systems as the combination that made terminal access useful. The lesson depends on both pieces: an agent gains the ability to execute commands, while permission controls help govern what it may run.

Removing the chat sidebar from Windsurf produced a different kind of resistance. Users lost a familiar interaction and received an agent in its place. The justification was a change in what the model could do: multi-step research and execution made it possible to carry a task forward rather than stop at an answer. Hou treats these decisions as bets on a potentially better workflow, acknowledging that the team does not always get them right.

Separating the agent manager from the IDE extends that same bet. Hou compares the IDE’s relationship to the manager with the debugger’s relationship to the IDE: useful when someone needs to inspect a lower layer, but unnecessary for every task. In this proposed hierarchy, orchestration becomes the everyday workspace, and the editor remains available for deeper intervention. Agent teams, swarms and software factories are different names for the future the team is betting on.

The move to model-led teams comes from a relationship between model development and product development. Antigravity 1.0 put the human in charge of parallel agents; experience with that product then helped inform Gemini’s ability to manage agents. Hou describes Gemini Flash as becoming capable of leading teams as well as executing individual tasks, with improvements in speed and cost making that orchestration more practical. Task decomposition and collaboration still have substantial room to improve.

In the public-preview agent teams mode, the user enters /teamwork and describes a task. Specificity helps, and the lead agent can ask for missing information. The user then works with that lead agent, which assembles and manages the team. The division of labor is generated for the task: possible roles include frontend engineering, backend engineering, infrastructure, QA and design.

Each subagent can operate independently, and the lead agent can assign it a different model. This gives model judgment two jobs: deciding how to divide the task and deciding what kind of worker should handle each part. Hou’s Avengers analogy fits the intended behavior—a collection of specialists assembled around a mission, with roles chosen as the work demands.

The interface can adapt to the same task. Asking for progress might produce a Kanban board; asking for a view of activity over time might produce a debugger-like timeline. Both are generated on demand. The agent manager therefore does more than launch workers: it can produce a way to inspect their work that matches the user’s immediate question.

The team exercised this approach on a browser-based raw photo editor and a messaging application. Each used hundreds of subagents and took almost half a day. The more ambitious run built an operating system kernel from scratch that could run Doom, which a colleague demonstrated at Google I/O. Running the game supplies a concrete observable result: the generated kernel supported enough functionality to execute it.

Hou reports 93 subagents over 12 hours, 15,000 requests, two billion tokens and a cost under $1,000 for the kernel run. These are figures for one demonstrated project, rather than a general estimate for building an operating system. The result establishes an ambitious working example; it does not establish production readiness or show that increasing the number of agents always improves results. Even Hou’s description of the cost is measured: “mildly affordable.” A successful long-running team can still consume substantial time and inference.

The next example applies the same building blocks to internal research. A side-by-side evaluation begins with tasks, model rollouts and two tables of results: a control and an experiment. Comparing the tables reveals differences, but the researcher still needs to understand why they occurred and what to change in the next experiment. Traditionally, that investigation involved considerable work in Jupyter notebooks.

Follow those two tables through the new workflow. The researcher loads a skills file and asks about the evaluations in natural language. With those skills and knowledge of Google’s monorepo, the agent computes the delta. It then creates a research specialist to propose 100 hypotheses explaining the differences. Each hypothesis receives its own subagent, so the investigations proceed in parallel before their findings return as one report. A comparison has become a coordinated search for explanations.

How does one comparison expand into many investigations and become one usable result? The diagram follows the fan-out and return path. Parallel workers explore separate hypotheses; their findings converge before the researcher inspects the report. The hypotheses remain candidate explanations for review, rather than becoming established causes merely because agents investigated them.

The result also includes a generated interface with dropdowns, filters and ways to segment and slice the data. This changes what the researcher can do with the answer: inspect subsets and explore findings rather than read a single fixed response. The report and interface can be regenerated as needed. Hou reports that researchers automated 90% of this workflow and that a previously manual process now takes minutes; the talk does not define the denominator for that percentage or provide a measured baseline duration.

Previously, this kind of automation required someone to construct an asynchronous pool of agents, configure judges and connect data pipelines. Antigravity makes a dynamic subagent graph and generated presentation part of the product’s available building blocks. The skills file supplies workflow knowledge; the model organizes the investigation; the interface makes the resulting data easier to explore.

The examples lead into a more precise description of two building blocks:

• Dynamic subagents: The main agent configures, prompts and seeds workers as needed. They can run in parallel, take specialized roles and operate in environments such as sandboxes or remote execution systems. The intended scaling path is better task decomposition and collaboration as the coordinating model improves.
• Sidecars: A long-lived utility process listens for outside events. It gives the model a way to arrange triggers from SMS messages, webhooks, cron jobs or GitHub pull requests. Antigravity already uses this mechanism for scheduled tasks.

The distinction is useful: a subagent performs delegated work, while a sidecar keeps listening for something that should initiate work. Scheduled tasks are one instance of the broader listening mechanism. Hou presents sidecars as a new plugin protocol and announces a forthcoming specification for others to build on; the talk describes its purpose and existing internal use, rather than its implementation API.

The final building block is generative UI. Hou reports that Gemini Flash in Antigravity produces almost 900 tokens per second, which he describes as 10 times faster than many other frontier model experiences. The comparison’s workloads and measurement conditions are unspecified, but the product implication is clear: fast generation makes it practical to create a task-specific interface within seconds.

Antigravity renders generated UI inline in the conversation. The examples range from playing Doom to inspecting bar charts, graphs and tables. Earlier, the same mechanism produced a Kanban board for task status and an interactive evaluation report. These views serve different questions, so their controls and presentation can change with the work.

Hou’s claim that human-written specialized interfaces may be obsolete is a hypothesis about where this capability leads. His analogy is Steve Jobs’s criticism of physical keyboards and control buttons that were “fixed in plastic” and identical across applications. A generated interface can instead supply the controls needed for the current task. The evaluation example makes that distinction concrete: a researcher gets filters and data slices because the work calls for inspecting results, while a project manager can request a board or timeline.

The closing design question is what to add when implementing features has become easier. Dynamic subagents let the model organize workers; sidecars let it respond to events; generative UI lets it present and expose the results in a useful form. Hou recommends choosing building blocks that can benefit from the next model’s capabilities. Getting out of the model’s way therefore requires product decisions: provide mechanisms through which better judgment, faster generation and more capable coordination can change what users accomplish.