Google's /teamwork Shows How to Stop AI Agents Grading Their Own Homework

The reviewer starts with a blank memory, and the final judge is a test. You can copy both ideas this week, in Antigravity, Claude Code or your own agent loop.

Ask an AI agent to check its own work and it will usually find the work is fine.

That is not laziness. The agent that wrote the code also wrote the reasoning behind it, and when it rereads the result, it rereads that reasoning too. The same mistakes look sensible a second time. Anthropic's new guide to building evaluations says it plainly: there is evidence that model graders favor their own outputs, so teams should consider using a different model to grade (Anthropic).

Google just published the most ambitious answer to that problem so far. Its research post on Antigravity's /teamwork feature, dated November 13, describes a system that splits big jobs across many agents and then makes those agents prove each other wrong (Google Research).

The headline results are huge and self-reported. The useful part is small enough to copy: the reviewer should not share the producer's memory, and the last word should belong to something that cannot be argued with.

What Google actually shipped

Antigravity is Google's agent-first coding environment, available as a desktop app and a command-line tool. /teamwork is a slash command inside it that turns one goal into a coordinated campaign of agents.

The research post describes the design in two sentences that do most of the work. The system pairs "parallel exploration with dedicated falsifiers" (automatic checkers that try to prove an answer wrong), and it "partitions context by construction," meaning each agent receives only the files and tools it needs for its step (Google Research).

Then the review step: critics and auditors "challenge and verify results from clean contexts without the original producer's reasoning." Coordinators also hand work off to fresh successors instead of running forever in one growing conversation.

Google's stated reason is attention. Models, the post says, lose track of details over multi-day tasks because attention spreads thin across ever-larger context windows (the running memory an AI model holds during one session).

The numbers Google reports are the kind that make people stop scrolling:

• A machine-checked formalization of the Weil conjectures, about 1.8 million lines of Lean (a language for writing proofs a computer can verify), produced with 28,800 subagent runs.
• About 800,000 lines of memory-safe Rust added in a two-week rewrite of Zircon, the microkernel behind Google's Fuchsia operating system.
• Two scheduling changes shipped to Borg, Google's cluster manager, cutting TPU workload preemption (jobs on Google's AI chips getting bumped mid-run) by 24% on some hardware types.

All of this is self-reported by Google, and the work involved human experts, including academic collaborators. Nobody has independently reproduced it yet. Treat the figures as a sign of what the pattern can reach, not as a promise of what you will see.

Idea one: the reviewer starts with a blank memory

Think about proofreading your own essay. You read what you meant to write, not what is on the page. A friend who never saw your drafts catches the missing word in ten seconds.

That is what "clean context" means here. The critic agent gets the output and the goal. It does not get the long chain of thought that produced the output, so it cannot be talked into agreeing by reasoning it never saw.

Antigravity's documentation spells out the roles. A coordinator called the Sentinel runs the campaign, a Project Orchestrator manages milestones, read-only Explorers investigate, Workers own their files exclusively, and a set of verification gates (Critic, Challenger, Auditor and Success Auditor) checks the results (Antigravity docs).

Read-only explorers and exclusive file ownership are the boring details that make the clean-context idea hold. An agent that can only read cannot sneak in a "fix" to the thing it was asked to inspect.

Idea two: the final judge is a test, not an opinion

Clean review helps, but a second model is still an opinion. The other half of the design is what Google calls a falsifier: an objective checker that says pass or fail no matter how persuasive the agent sounds.

The post lists examples: the Lean 4 proof checker, unmodified software test suites, execution simulators, web search and hardware counters (Google Research).

Notice the word "unmodified." An agent that can edit the tests can make any test pass. A test suite only counts as a falsifier if the agent under review cannot touch it.

A deli scale works the same way. The butcher can tell you the cut weighs a pound, but the number on the display settles it.

Put the two ideas together and you get the rule this whole article is about. Separate the part that makes from the part that checks, and make the final check something that cannot be persuaded.

Where parallel agents lose

The post carries one finding that cuts against the "more agents" story, and it is the most practical line in it.

A long-running /teamwork campaign looked back at its own past runs and found that tightly coupled code is best handled through sequential implementation and revision stages rather than parallel splits (Google Research). Google folded that into /boost, a separate command described as a sequential solve-and-verify loop.

The docs make the split concrete. /teamwork starts with a scoping interview and runs for hours to days. /boost starts immediately and suits hard bugs, race conditions and tricky refactors; its improvement workers try to break earlier attempts and run real tests before the orchestrator spot-checks (Antigravity docs).

So the lesson is not "use a swarm." Split work when the pieces are independent. Keep one thread, with a hostile reviewer, when every change touches every other change.

Put this into practice

You do not need Google's scale to use the pattern. Here are three ways in, from least to most setup.

If you use Antigravity

/teamwork is available on paid plans in both the Antigravity app and CLI. Start a new conversation and type the command with your goal, for example:

/teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation.

That example comes straight from the docs. Expect a scoping interview first. One of its questions asks for an independent check for each requirement, and that answer is the most important thing you will type. If you cannot name a test, benchmark or checker for a requirement, the agents cannot falsify it either.

For a single nasty bug or a refactor where everything is connected, use /boost <task> instead. It skips the interview and starts at once.

If you use Claude Code

Claude Code, Anthropic's terminal coding agent, has subagents: helper agents defined as Markdown files with a short settings block at the top. Its docs say each subagent "runs in its own context window with a custom system prompt, specific tool access, and independent permissions" (Claude Code docs). That separate context window is your clean reviewer.

Create .claude/agents/cold-reviewer.md in your repo:

---
name: cold-reviewer
description: Reviews a finished change against the task spec without seeing how it was written. Use after any implementation step.
tools: Read, Grep, Glob
---
You are reviewing a change you did not write. You will get the task
spec and the diff. Do not trust comments that explain intent.
List every requirement in the spec and mark it met, unmet, or
unverifiable, with the file and line that proves it. Then name the
test command that would catch each unmet item.

The tools line is an allowlist, so this reviewer can read and search but cannot edit or run commands. Project subagents in .claude/agents/ can be checked into version control, so the whole team gets the same reviewer (Claude Code docs).

When you ask for a review, pass the spec and the diff, not the conversation. The whole point is that it never sees the reasoning.

Make a real falsifier, in any setup

The reviewer is half the pattern. The other half is a check the agent cannot edit. Three cheap versions:

1. Freeze the tests during a change. After the agent finishes, run git diff --stat main -- tests/ and reject the change if the agent touched test files it was not asked to touch. The command only reports; to make it a gate, add a CI step that fails when those paths change.
2. Run the tests somewhere the agent does not control. A CI job on the pull request is a falsifier. A test command the agent runs and reports back is a claim.
3. Write the check before the work. For each requirement, write down the command that proves it before the agent starts. That is the same question the /teamwork interview asks, and you can ask it of yourself in two minutes.

If you are checking prose or decisions rather than code, Anthropic's guide gives the grader version of the same rule: break criteria into small yes/no questions and confirm your grader agrees with human labels before trusting its scores (Anthropic).

Honest limitations

The big numbers are Google's own. The post offers no independent replication of the Lean, Rust or Borg results, and it credits human experts, including academic collaborators, working alongside the agents. Read them as a demo of the ceiling.

Some of the best patterns are not out yet. The post says the formal-proof pattern and the Rust rewrite pattern are "soon to be available." What ships today is /teamwork and /boost with Gemini 4 models, on paid plans.

Falsifiers only exist where truth is checkable. Code with tests, proofs with a checker and kernels with a benchmark all have one. A product spec, a marketing page or an architecture choice usually does not. There, a clean-context reviewer is the best you get, and it is still an opinion.

A blank memory can miss real context. A reviewer that never saw the conversation also never saw the constraint you mentioned on turn twelve. Put the constraints in the spec you hand it, or it will flag things you already decided.

More agents cost more. Every critic and auditor is another model run. On a small change, one careful reviewer and your existing test suite beat a campaign.

The habit to build

The interesting thing about /teamwork is not that Google ran 28,800 subagents. It is that, at that scale, the company still landed on an old engineering habit: the person who wrote the code does not get to sign off on it.

You can start this week. Pick your next agent task and write one check per requirement before the agent starts. Add a read-only reviewer that sees only the spec and the diff. Run the tests where the agent cannot edit them.

Then watch what the reviewer catches that the agent swore was done.

Sources: Google Research, "Advancing science & engineering with Antigravity's /teamwork" (Nov 13, 2026) · Antigravity /teamwork docs · Anthropic, "Building strong safety evaluations" (Nov 13, 2026) · Claude Code subagents docs. Documentation read November 14, 2026.