Google Antigravity startet /swarm: KI-Agenten planen, programmieren und prüfen parallel

Was neu ist – und was bereits am 28. Oktober bekannt war

Gemini 4 Carbon wurde bereits am 28. Oktober mit Schwerpunkt auf lang laufenden Aufgaben und Cybersecurity angekündigt. Die Nachricht vom 10. November ist deshalb keine zweite Modellpremiere. Neu sind die breitere Bereitstellung für zahlende Entwickler und Unternehmen, der Zugang für Google-AI-Ultra-Abonnenten und die Vorschau auf /swarm innerhalb von Google Antigravity. Unser früherer Carbon-Bericht behandelte die erste Sicherheitsankündigung; hier geht es um Orchestrierung und praktische Zugangsgrenzen.

Google beschreibt Carbon als Modell für besonders anspruchsvolle Architektur-, Forschungs- und Verifikationsaufgaben. Für den Großteil alltäglicher Entwicklungsarbeit empfiehlt der Hersteller selbst weiterhin das günstigere beziehungsweise effizientere Modell Argon. Ein allgemeiner Benchmark-Sieg bedeutet somit nicht, dass Carbon für jeden Arbeitsschritt die sinnvollste Wahl ist.

Wie /swarm technisch arbeitet

Nach Googles Antigravity-Beschreibung wird ein Prompt von einem Koordinator in Aufgaben für spezialisierte Worker und Prüfagenten zerlegt. Die Worker arbeiten parallel in getrennten Git-Worktrees. Damit sollen sich Änderungen am selben Repository nicht direkt überschreiben. Ein geteilter, nur ergänzbarer Nachrichtenbereich ermöglicht den Agenten, Informationen und Abhängigkeiten auszutauschen.

Die Kombination ist relevant, weil klassische Subagenten oft wieder zum zentralen Koordinator zurückmelden müssen. /swarm verspricht mehr direkte Abstimmung zwischen Rollen. Das ist eine Herstellerbeschreibung der Architektur; unabhängige Messungen zu Konfliktvermeidung, Skalierung oder Fehlerraten sind aus der Veröffentlichung allein nicht ableitbar. Getrennte Worktrees schützen außerdem nicht vor logisch inkompatiblen Änderungen.

Der Unterschied zwischen Worker und Prüfer

Google beschreibt ausdrücklich adversariale Verifier, die Tests durchführen und Diffs hinterfragen. Dadurch soll ein Agententeam nicht lediglich möglichst schnell Code produzieren, sondern Einwände systematisch berücksichtigen. Starke Modelle wie Carbon können demnach für Architektur, Koordination oder Prüfung eingesetzt werden, während leichtere Modelle Routine-Implementierungen übernehmen.

Ein Prüfagent ist allerdings kein unabhängiger Auditor. Er arbeitet innerhalb derselben technischen und organisatorischen Umgebung und kann ähnlichen Modellfehlern unterliegen. Für kritische Codeänderungen bleiben deterministische Tests, Sicherheitsprüfungen, nachvollziehbare Build-Artefakte und menschliche Freigaben erforderlich. Der Einsatz verschiedener Modelle kann Fehler diversifizieren, ersetzt aber nicht die Validierung am realen System.

Live Board und Graph: Sichtbarkeit statt bloßer Automatik

Die neue Oberfläche umfasst laut Google ein Live Board, eine Mitgliederübersicht und einen Graph-Replay-Verlauf. Nutzer können Agentenaktivität beobachten, in einzelne Arbeitsschritte springen und den Ablauf des Teams nachverfolgen. Auch über /swarm board oder eine Tastenkombination in der CLI soll eine Ansicht verfügbar sein.

Damit wird Prozesssichtbarkeit zum Teil der Agentenplattform. Eine Oberfläche, die Arbeitsschritte visualisiert, ist aber nicht automatisch ein manipulationsgeschütztes Audit-System. Für Governance sollte zusätzlich geprüft werden, ob alle relevanten Tool-Aufrufe, Entscheidungen, Modellwechsel und Freigaben exportiert und unabhängig korreliert werden können. Die Herstellerankündigung beantwortet diese Anforderungen nicht vollständig.

Carbon, Argon und das richtige Modell pro Rolle

Google empfiehlt, leistungsfähige Carbon-Instanzen gezielt für schwierige Koordination, Architektur, Cybersecurity-Audits und adversariale Prüfung zu nutzen. Argon soll häufig die pragmatischere Wahl für gewöhnliche Entwicklungsarbeit bleiben. /swarm erlaubt nach Herstellerangaben, einzelne Agenten auf unterschiedliche Modelle festzulegen und Arbeit entsprechend zu verteilen.

Die redaktionelle Konsequenz: Nicht jeder Worker braucht die teuerste Modellstufe. Eine sinnvolle Rollenzuteilung unterscheidet komplexe Entscheidungen, parallele Routineaufgaben und gezielte Verifikation. Ob sie tatsächlich Kosten spart, hängt von Tokenverbrauch, Anzahl der Schleifen, fehlgeschlagenen Versuchen und menschlicher Reviewzeit ab. Dazu fehlen aktuell unabhängige Produktionsdaten.

Preise und Quoten: parallele Arbeit ist kein kostenloser Turbo

Gemini 4 Carbon kostet für die öffentliche API laut Google zunächst 2 US-Dollar pro Million Eingabetokens und 10 US-Dollar pro Million Ausgabetokens. Nach dem 30. November 2026 sollen diese Werte auf 4 beziehungsweise 20 US-Dollar steigen. Das gilt für das öffentliche Carbon-Modell; Unternehmenskonditionen, Caching und andere Produkte können abweichen.

Google warnt ausdrücklich, dass parallele Agententeams Quoten wesentlich schneller verbrauchen als ein einzelner Chat, auch wenn untätige Agenten nicht kontinuierlich Tokens erzeugen. Eine Kostenrechnung muss deshalb zusätzliche Agentenaufrufe und Verifikationsschleifen berücksichtigen. Eine willkürlich angenommene „Kostenersparnis von X Prozent“ wäre ohne Logdaten nicht seriös.

Sicherheits- und Freigabeschranken für große Agententeams

Isolierte Worktrees reduzieren Dateikonflikte, aber keine Berechtigungsschäden durch falsch konfigurierte Tools. Ein Agent kann beispielsweise ein Git-Repository korrekt bearbeiten und trotzdem eine unerlaubte Aktion in einem externen Dienst auslösen. Der Workflow braucht deshalb begrenzte Rechte, freigegebene Tool-Schnittstellen und eine bewusste Grenze zwischen Codevorschlag und produktiver Ausführung.

Für einen Test empfiehlt AgentenCode vier Gates: Scope und Budget festlegen, Worker in getrennten Bereichen ausführen, Ergebnisse mit automatisierten und adversarialen Tests prüfen und erst danach ein verantwortliches Teammitglied über den Merge entscheiden lassen. Diese Entscheidungsmatrix ist unsere eigene Empfehlung, nicht eine behauptete Antigravity-Zertifizierung.

Verfügbarkeit und der nächste sinnvolle Pilot

Google AI Ultra-Abonnenten können Carbon nach der offiziellen Antigravity-Mitteilung über App, CLI und unterstützte Entwicklungsumgebungen nutzen. /swarm wird seit dem 10. November als Preview in Antigravity App und CLI ausgerollt. Für Unternehmen gibt es Carbon in Gemini for business; daraus folgt nicht zwangsläufig dieselbe /swarm-Verfügbarkeit in jedem Unternehmenstarif.

Als Pilot eignet sich eine Änderung mit klar trennbaren Teilaufgaben, etwa Tests, Refactoring und Dokumentation. Man sollte dieselbe Aufgabe einmal ohne und einmal mit /swarm bearbeiten, die akzeptierten Ergebnisse vergleichen und Kosten sowie Nacharbeit protokollieren. Eine erfolgreiche Herstellerdemo ist inspirierend, aber kein Beleg für einen reproduzierbaren Vorteil im eigenen Repository.

Häufige Fragen

Quellen, Methode und Evidenzgrenzen

Die Aussagen zum Produkt stammen aus den offiziellen Mitteilungen. Die Handlungsempfehlungen sind eigenständige redaktionelle Ableitungen. Wir haben weder das Produkt unabhängig getestet noch Benchmark- oder Wirksamkeitszahlen selbst erhoben.

1. Google Antigravity – original release, 10 Nov 2026
2. Additional official source

Weiterführende AgentenCode-Seiten: Passendes Agentenprofil · KI-Agenten erstellen · Trust · Cursor Projects wird multiplayer: Wenn ganze Teams mit KI-Agenten programmieren.