Google’s Antigravity research update puts verification at the center of agent teams

Google’s November 13 research update describes Antigravity /teamwork campaigns across mathematics, chemistry and systems engineering. The common mechanism is a loop: agents explore candidates, while separate checks determine which results survive.

What the new update adds

Google describes pairing exploration with tools such as Lean 4, unchanged software tests and hardware measurements. Specialized agents receive limited task context, while fresh reviewers challenge their outputs. Human experts define the questions and constraints.

The availability distinction matters: Google says /teamwork and /boost are usable in Antigravity today, but additional specialized workflows and a formal-proof pattern are forthcoming. The research demonstrations should not be read as a list of universally available product features.

How an agent team is organized

Google’s August 27 framework explanation describes configurable patterns rather than one fixed group of agents. A pattern specifies roles and the conditions for advancing work. The framework can change the number of agents during a run, and people retain responsibility for objectives and final acceptance.

That earlier explanation distinguishes distributed coding, which divides separable work, from iterative coding, which repeatedly revises a tightly connected problem. Choosing the structure is therefore part of the task, rather than simply assigning more workers.

Making evaluation cheaper without losing the target

The DuoDiscover preprint, submitted October 12, addresses a practical constraint: a full evaluation can be too expensive to run on every candidate. Its agents develop fast proxy tests, called yardsticks, alongside the optimization itself.

Crucially, the system rechecks whether those proxies rank candidates consistently with the real evaluation. A proxy that drifts is invalidated. This keeps the search from treating improvement on an increasingly misleading shortcut as progress on the actual objective.

A useful pilot starts with the acceptance test

For a development team, our suggested starting point is a bounded maintenance task with an existing regression suite. Write down the acceptance criteria before starting the agents, and keep a protected copy of the tests.

• Separate the two jobs. Let one process propose changes and another evaluate them against the original requirements.
• Keep the evidence. Save the candidate, test output, environment and review decision together, so another engineer can reconstruct why it was accepted.
• Account for review cost. Compare elapsed time, compute expense and human correction time with the normal workflow.
• Retest the winner fully. A quick screening test can help choose candidates, but the final check should exercise the actual deployment requirements.

For scientific work, the acceptance test may also require observations outside the software. Our earlier coverage of Antigravity’s chemistry tools explains why computational proposals still need laboratory validation.

Sources and image note

Sources: Google Research, November 13; Antigravity framework overview, August 27; DuoDiscover preprint, October 12. The cover uses an imaginary bridge-testing setup to illustrate independent checking; it does not depict Google equipment or a reported experiment.