Google’s Antigravity Teamwork framework is built for long-running research and engineering jobs, with groups of AI agents proposing, challenging, verifying, and refining each other’s work over hours or days. Google reports seven notable open-problem results from its Long Proof work, while a Gemini 3.7 Flash team separately built a cycle-level out-of-order RISC-V CPU simulator that booted xv6 to a shell and matched hardware timing within 0.71% on average.

Google let the agents keep working — and the jobs got ambitious

Google has been testing Gemini models in teams of autonomous agents, and the latest results are far beyond the usual “build me an app” demo.

With Antigravity Teamwork, groups of agents can work for hours or days on the same objective. They propose approaches, challenge one another’s results, verify intermediate work, and keep iterating until they have something ready for human review.

Google says that setup has now produced seven notable results across open problems in mathematics and theoretical computer science. In a separate systems-engineering test, a Teamwork configuration powered by Gemini 3.7 Flash built a cycle-level out-of-order RISC-V CPU simulator from scratch, booted xv6 to a working shell, and ran more than 100 standard RISC-V benchmarks.

That combination is what makes this update worth watching. Teamwork is being used on proofs, processor simulation, and real open-source performance work — three very different jobs, all built around the same idea: give several agents a shared objective and enough structure to keep improving the result.

Teamwork is more structured than “put several agents on it”

Google first introduced Teamwork as a multi-agent orchestration framework inside Antigravity. The current version is available through the `/teamwork-preview` command, and it does not use one fixed team for every problem.

Instead, Teamwork works with patterns. A pattern defines the roles the agents should play, how their work should move between them, and what has to be checked before the job can advance. Antigravity chooses a pattern based on the task and can change the number of agents while the run is underway.

The current set includes Iterative Coding, Distributed Coding, Long Proof, Self-Verification, and Document Review. A software project that splits cleanly into parallel work can use a different structure from a mathematical proof that needs repeated strategy search and verification.

That separation is important. The useful part is not simply having more model instances running at once. It is giving them a workflow that says who proposes, who checks, who combines, and when another round is worth running.

The seven research results come with an important model detail

The Long Proof pattern is where Google reports the seven notable open-problem results. It generates several candidate strategies, pairs them with agents that try to break or verify them, and then combines the strongest surviving ideas into a more complete approach.

The results span coreset construction for ℓp subspace approximation, sparse convex optimization, maximal inner-product embeddings, Hadamard quantization, the Erdős unit-distance problem, prefix-matrix factorizations, and Knuth’s Cycles Conjecture. Five resulting papers are available on arXiv.

There is one detail worth getting exactly right: Google says the seven results were obtained using Gemini 3.1 Pro. Three of them — problems 1, 3, and 4 in Google’s list — were also reproduced with Gemini 3.7 Flash. So this is not a claim that Flash alone produced all seven results.

For Knuth’s Cycles Conjecture, Google reports first proofs for two simpler constructions of the even-integer case, with proofs running beyond 40 and 70 pages. The shorter proof was formally verified in Lean. For the broader set, Google says human experts reviewed and confirmed the results, with Lean providing the formal verification path for the Knuth work.

Then Gemini 3.7 Flash built a CPU simulator

The hardware result is easier to picture.

Using Gemini 3.7 Flash, Teamwork built a highly accurate cycle-level simulator for an out-of-order RISC-V processor. It was not just executing RISC-V instructions functionally. The goal was to model the timing behavior of a modern out-of-order design closely enough to compare cycle counts against hardware ground truth.

The agents worked through two phases. First came functional correctness: building execution logic for pieces such as reorder buffers, caches, and the out-of-order pipeline, then getting the simulator to maintain correct architectural state and boot xv6. The second phase focused on timing, aligning the simulator’s behavior against strict reference measurements.

Google says the finished simulator booted xv6 all the way to a shell and successfully simulated more than 100 standard RISC-V benchmarks. On unseen test workloads, it reached an average cycle-alignment error of 0.71% against BOOM hardware execution ground truth.

That is a much richer engineering target than generating source code that compiles. The team had to build the simulator, run microbenchmarks, inspect traces, compare timing, and keep refining the microarchitecture until the behavior lined up with the reference.

The same framework also shipped real open-source optimizations

Google also pointed Teamwork at existing open-source software.

For Eigen, the widely used C++ linear-algebra library, the agents worked through microbenchmarks and identified an opportunity around matrix-vector operations where the matrix has a single row or column. The resulting implementation added a dedicated fast path using direct data access, SIMD operations, and four-way accumulator unrolling. Google says the change went through the normal open-source review process and landed upstream with assistance from Gemini 3.6 Flash.

A second project focused on ParlayHash, a high-performance concurrent hash table. Teamwork contributed to the design of “Swiss Parlay,” which brought ideas from Swiss Table into the library.

Google reports 2× throughput on initial inserts with 64 threads, 1.5× overall throughput with a single thread, and memory use per element that was 25% lower than the comparison sequential table while staying close to its performance. The improvement also landed upstream.

These examples give Teamwork a different kind of credibility from a closed benchmark. The work ended up inside existing projects after external maintainers reviewed it through their normal process.

The interesting part is the loop, not the agent count

Multi-agent systems are easy to describe as “several AIs working together,” but Teamwork’s design is more specific than that.

For Long Proof, candidate strategies compete before the system commits deeply to one route. Subproblems can be split into a dependency graph and solved in parallel where possible. Verification is built into the process, and later rounds can reuse useful results and observations from earlier work.

The coding patterns use a different rhythm. Distributed Coding can fan a decomposable engineering job across parallel workers and bring in critic review. Iterative Coding keeps a tighter agent-test-refine loop for work that needs repeated local improvement.

The result is a framework that changes shape around the problem. Mathematics, processor simulation, and library optimization do not need the same team structure, even if all three benefit from longer-running collaboration.

This is already moving into the Antigravity developer workflow

Teamwork is not only a Google research harness. The updated framework is being rolled into Antigravity through `/teamwork-preview` on paid plans, with Google saying more of the improvements will arrive over the next few weeks.

Gemini 3.7 Flash is a natural fit for that environment because Google is positioning it specifically around coding and agents. The model launched in August as Google’s latest Flash workhorse for software engineering, knowledge work, web development, and multi-step agent workflows.

That gives the research results a direct connection to a product developers can actually experiment with. The exact high-parallelism configurations behind some of Google’s research runs are not simply the default consumer setup, but the orchestration ideas are becoming part of the same Antigravity environment.

The broader direction is clear: the unit of work is getting larger. Instead of asking one model for one answer, developers can hand a structured team a problem and let the system keep working through planning, implementation, testing, critique, and verification.

The Upgrade Feeling

The strongest part of this story is not a single benchmark number.

It is the range of work produced by the same orchestration idea. One Teamwork pattern can spend hours exploring a proof. Another can build and calibrate a CPU simulator. Another can optimize production-grade C++ and send the result through an upstream review.

That makes agent orchestration feel less like a demo layer and more like an engineering primitive. The model still matters, but the structure around the model is starting to matter just as much: roles, verification, parallelism, shared state, and the ability to keep working long enough for a difficult problem to unfold.

For developers following the agent space, that is the signal here. The next jump may come from better models — but also from giving those models better ways to work together.