Antigravity Teamwork: Wann sich der Einsatz lohnt (Guide 2026)

50 Millionen Zeilen Lean 4 für einen einzigen Beweis, 800.000 Zeilen sicheren Rust-Code in zwei Wochen und TPU-Kernels, die 4,09-mal schneller laufen: Googles Forschungsupdate vom 13. November zeigt eindrucksvoll, was Antigravity Teamwork leisten kann. Im Alltag lohnt sich der Ansatz aber meist nur bei Projekten mit klaren Meilensteinen, die sich über Stunden oder Tage erstrecken. Ein einziger Lauf kann bereits einen großen Teil des Wochenkontingents verbrauchen.

Was Antigravity Teamwork tatsächlich ist

Antigravity Teamwork ist Googles Multi-Agenten-Workflow für umfangreiche, stark verifikationsabhängige Aufgaben in Antigravity. Der Befehl /teamwork startet ein koordiniertes Team aus Sentinel, Project Orchestrator, Explorers, Workers, Critic, Challenger, Auditor und Success Auditor. Dieses Team plant in Meilensteinen, arbeitet in einem eigenen Projektverzeichnis und lässt jeden Meilenstein unabhängig prüfen.

Teamwork läuft in zwei Phasen ab. Phase 1 besteht aus einem Scoping-Interview: Der Hauptagent hält Ziele, Anforderungen, Prüfmethoden, Abnahmekriterien und das Projektverzeichnis fest. Standardmäßig ist das ~/teamwork_projects/{PROJECT_NAME}. In Phase 2 arbeitet das Team autonom mit strukturierten Artefakten wie Anfrage, Projektplan und Fortschrittsprotokollen. Jeder Worker und Critic besitzt exklusive Dateirechte; vor der Übergabe greifen die Prüfungen durch Critic, Challenger, Auditor und Success Auditor (Teamwork-Dokumentation).

Die im Interview gewählte Integritätsstufe legt fest, wie streng geprüft wird:

• development (Standard): schnelle Iteration; Code-Wiederverwendung und Frameworks sind erlaubt, erfundene Ergebnisse und Fassaden-Implementierungen werden abgelehnt.
• demo: reproduzierbare Präsentationen; das Kopieren zentraler Logik aus Open Source, das Auslagern der Kernarbeit und das Lesen von Testquellen auf der Suche nach Antworten sind verboten.
• benchmark: maximale Strenge; Implementierung von Grund auf mit der Standardbibliothek der jeweiligen Sprache und unabhängige Auswertung anhand einer Ground Truth.

Die Ausführungspfade passen die Teamstruktur automatisch an:

• General Distributed Coding (Standard): Entwicklung und Refactoring über mehrere Dateien hinweg.
• Iterative Coding: ein einzelner, klar begrenzter Fix, wenn die Anfrage ausdrücklich sagt: "keep it small."
• Document Review: Kritik aus mehreren Blickwinkeln an Papers und Designdokumenten.
• Math / Proof und Math / Proof Large Team: formales Schließen und umfangreiche Beweiskampagnen.

Auf kostenpflichtigen Tarifen erstreckt sich der typische Zeithorizont in der Antigravity App und CLI von Stunden bis zu Tagen (Teamwork-Dokumentation).

Teamwork im Vergleich zu Swarm, Boost und Subagents

Antigravity Teamwork ist nur dann die richtige Wahl, wenn eine Aufgabe Meilensteine, Prüf-Gates und ein eigenes Verzeichnis braucht. Für den Großteil der täglichen Arbeit reichen die leichteren Optionen. Wer das falsche Werkzeug wählt, verbraucht unnötig Quota.

Teamwork eignet sich für eine REST-to-Fastify-Migration über Dutzende Dateien mit vollständiger Testabdeckung, einen zyklusgenauen Simulator mit Validierung gegen Hardware-Timer oder einen formalen Beweis mit Lean-4-Prüfung. Swarm ist die bessere Wahl, wenn drei voneinander unabhängige API-Handler validiert werden sollen: ein Worker pro Datei und zusätzlich ein Verifier, der npm test ausführt. Boost passt zu einer einzelnen Race Condition oder einem eng gekoppelten Refactoring, bei dem sequentielles Herausfordern, Korrigieren und Verifizieren sinnvoller ist als parallele Worker. Subagents übernehmen Hintergrundrecherche, während die Hauptunterhaltung weiterläuft.

Die Verwirrung kommt nicht von ungefähr. Ein Antigravity-Nutzer formulierte es so:

"agy has way too many modes now and honestly it's getting confusing. right now we have ... /teamwork (long milestone projects with audit gates) ... and now dynamic workflows... to be fair, we really don't need all of them. fewer modes = less confusion..."

— @Heamanth_alturi (X)

Als Faustregel gilt: Hat eine Aufgabe nur eine Definition of Done und lässt sie sich in einer Sitzung erledigen, ist Teamwork überdimensioniert. Braucht sie dagegen ein Planartefakt, ein Fortschrittsartefakt und die Abnahme jedes Meilensteins durch eine andere Person als den Autor, ist Teamwork passend.

Was das Forschungsupdate vom November tatsächlich belegt

Das Google-Research-Update vom 13. November ist ein Ergebnisbericht und keine Ankündigung des Starts. Teamwork gab es zuvor für kostenpflichtige Tarife als /teamwork-preview. Das Update dokumentiert, was meilensteinbasierte Teams mit Gemini 4 Argon, Carbon und Hydrogen erreicht haben. Menschen definierten weiterhin Probleme, Randbedingungen und Evaluationsaufbauten; neue Kritiker prüften die Ergebnisse aus sauberen Kontexten heraus.

Google hat außerdem Bewerbungen von 10.000 akademischen Forschern geöffnet, die sechs Monate Zugang zur Top-Tier-Version erhalten sollen. Einige der im Beitrag beschriebenen Workflows werden für externe Nutzer noch ausgerollt. Die Tabelle ist daher als Beleg für die Fähigkeiten zu verstehen, nicht als Versprechen, dass jedes Projekt dieselben Verbesserungen erzielt.

Die Quota-Rechnung, die offizielle Seiten verschweigen

Die Antigravity-Preisseite (Preisseite) führt Individual mit 0 $ pro Monat, unbegrenzten Tab-Vervollständigungen und grundlegenden Wochenlimits auf. Pro und Ultra bieten höhere Limits sowie ein flexibles KI-Guthaben; genaue Anfragezahlen werden nicht veröffentlicht. Die Quota von Pro und Ultra wird alle fünf Stunden erneuert, bis das Wochenlimit erreicht ist. Für darüber hinausgehende Nutzung können gekaufte Credits eingesetzt werden, abhängig von der Einstellung Never oder Always (Tarif-Dokumentation). Teamwork und Boost setzen einen bezahlten Tarif voraus; Swarm benötigt Pro oder Ultra (Swarm-Dokumentation). Googles eigener OS-Beitrag warnte, dass ein paar komplexe Preview-Aufgaben bereits ein komplettes Wochenkontingent verbrauchen können (Antigravity-OS-Beitrag).

Anekdotische Nutzerberichte, die keine repräsentative Stichprobe bilden, reichen von problemlos bis drastisch:

"holy crap that sucked all my quota in about only 5 minutes (3.5 Flash (high))"

— u/Several_Bag_3665 (Reddit)

"very usable on ultra sub actually, had a teamwork preview with gemini flash medium going for 50 minutes straight and it took about 20% of my 5-hour quota and did huge refactorings properly"

— u/ningkaiyang (Reddit)

Zwei Mechanismen erklären diese große Spannweite. Antigravity dokumentiert für /swarm, dass jeder Worker ein eigener Agent ist, wartende Worker keine Tokens verbrauchen und Worker nach Erreichen der Quota pausieren, statt automatisch neue Versuche zu starten. Fortgesetzt wird erst nach einem neuen Board-Post, einem Modellwechsel oder einer direkten Nachricht (Swarm-Dokumentation). Die Teamwork-Dokumentation macht keine entsprechende Aussage zum Fortsetzen. Dieses Verhalten sollte daher als gemeinsame Multi-Agenten-Eigenschaft betrachtet und für den eigenen Tarif überprüft werden. Teamwork erzeugt zudem umfangreiche Zwischenartefakte – Anfrage, Plan und Fortschrittsprotokolle sowie Notizen und Prüfprotokolle der einzelnen Agenten (Teamwork-Dokumentation). Das ist erwarteter Zustand und nicht automatisch ein Zeichen für echten Fortschritt.

So läuft der erste Teamwork-Versuch, ohne eine Woche Quota zu verbrennen

Teamwork startet zwar mit einem einzigen Befehl, doch das Scoping-Interview entscheidet maßgeblich über die Kosten. Öffne in der App eine Projektunterhaltung und gib /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation ein. In der CLI startest du /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests aus dem Projektverzeichnis heraus. Den Fortschritt beobachtest du über das Subagent-Panel oder die Statusleiste der CLI. Mit Alt+J springst du zu Freigaben; Plan- und Fortschrittsartefakte lassen sich in Echtzeit prüfen (Teamwork-Dokumentation).

Betrachte Phase 1 als Kostenkontrolle. Beschreibe das Ziel, nicht den Lösungsweg: Zielsetzung, Zielgruppe (Demo, Produktion oder Benchmark), harte Einschränkungen und genau eine objektive Prüfung pro Anforderung, etwa eine Testsuite oder ein Metrikskript. Für Iteration ist development die richtige Wahl. demo oder benchmark solltest du reservieren, wenn eine vorzeigbare oder vollständig neu entwickelte Lösung entscheidend ist – strengere Prüfungen bedeuten mehr Agentenarbeit. Prüfe vor der Freigabe außerdem das dedizierte Projektverzeichnis.

Während der Ausführung bleibt die zentrale Steuerung wichtig. Leite Änderungen am Umfang über den Koordinator, integriere Änderungen der Worker, bevor du sie entfernst, und bewerte Fortschritt anhand von Meilenstein-Gates und Testnachweisen – nicht anhand der Dateianzahl. Stelle in den Einstellungen für den ersten Lauf die KI-Credit-Überziehung auf Never. So stoppt die Arbeit bei erschöpftem Basiskontingent, anstatt unbemerkt Credits auszugeben (Tarif-Dokumentation). Wo die Tarifdokumentation diese Kombination zulässt, kann ein stärkerer Planer mit günstigerer Implementierung gekoppelt werden: Ultra unterstützt Orchestrator (Carbon) und Orchestrator (Argon). Diese planen mit Gemini 4 Carbon oder Argon, während Gemini 4 Hydrogen implementiert (Preisseite). Einen ähnlichen Zielkonflikt zeigen auch die Vergleiche von Carbon und Argon.

FAQ

Was ist der Unterschied zwischen /teamwork und /teamwork-preview?

/teamwork-preview war die frühere Bezeichnung für die Research Preview. Die aktuelle Teamwork-Dokumentation verwendet auf kostenpflichtigen Tarifen /teamwork; Google hat keine separate Aussage zur allgemeinen Verfügbarkeit veröffentlicht.

Lässt sich Teamwork nach erschöpfter Quota pausieren oder wiederherstellen?

Für /swarm ist dokumentiert, dass Worker nach erschöpfter Quota pausieren und erst nach einem neuen Board-Post, einem Modellwechsel oder einer direkten Nachricht fortfahren (Swarm-Dokumentation). Die Teamwork-Dokumentation bestätigt nicht, dass derselbe Wiederaufnahmeweg gilt. Prüfe vor einem Neustart den Tarif und die Fortschrittsartefakte in ~/teamwork_projects/{PROJECT_NAME}, da abgeschlossene Teilmeilensteine als Dateien erhalten bleiben.

Welche Artefakte erzeugt Teamwork?

Anfrage, Projektplan und Fortschrittsartefakte sowie Notizen der einzelnen Agenten, Hilfsskripte und Prüfprotokolle (Teamwork-Dokumentation). Umfangreiche Markdown-Ausgaben sind normal. Entscheidend sind Meilenstein-Gates und Testnachweise, nicht die Anzahl der Dateien.

Ist Teamwork für Produktions-Repositories sicher?

Teamwork isoliert die Arbeit in einem eigenen Verzeichnis, vergibt exklusive Dateirechte und setzt Audit-Gates ein. Das reduziert das Risiko von Kollisionen (Teamwork-Dokumentation). Vor dem Mergen in die Produktion bleiben eine menschliche Prüfung der Abnahmekriterien und Testnachweise sowie die abschließende Kontrolle durch den Success Auditor erforderlich.

Die 30-Sekunden-Checkliste vor /teamwork

Verwende /teamwork nur, wenn alle fünf Punkte zutreffen: Die Arbeit umfasst mehrere Meilensteine, jeder Meilenstein besitzt eine objektive Prüfung, ein eigenes Verzeichnis ist hilfreich, unabhängige Audit-Gates sind wichtig und ein quota-intensiver Lauf ist günstiger als wochenlange manuelle Arbeit. Andernfalls nimm Swarm für parallelisierbare Aufgaben, Boost für schwierige und eng begrenzte Bugs oder Subagents für Hintergrundaufgaben. Teamwork sollte dem Projekt vorbehalten bleiben, das tatsächlich ein Team braucht.