Google Antigravity: So migrieren lokale Jobs rechtzeitig

Was sich bei Google Antigravity tatsächlich ändert

Es geht um den Antigravity Managed Agent in der Gemini API. Gemeint ist nicht die Antigravity-IDE, die lokal auf einem Computer installiert wird.

Beide Produkte beruhen auf gemeinsamen Laufzeitgrundlagen, daher die Namensüberschneidung. Geändert wird hier die Agent-ID, die eine Anwendung an die Interactions API von Google sendet, und bei manchen Integrationen auch die integrierten Tool-Aufrufe, die diese Anwendung verarbeitet. Ein Update der IDE aktualisiert diesen API-Vertrag nicht automatisch.

Der neue Agent heißt antigravity-preview-09-2026. Standardmäßig arbeitet er mit Gemini 3.8 Flash als Reasoning-Modell. Der Leitfaden zum Antigravity Agent zeigt jedoch, wie eine Anwendung über agent_config ein anderes unterstütztes Modell auswählen kann. Der frühere Überblick zu Gemini Managed Agents behandelt den gehosteten Workspace, Hintergrundjobs und die Tool-Schleife. Diese Migration greift eine Ebene tiefer: Sie entscheidet, ob solche Jobs noch starten und ihre Tool-Aufrufe weiterhin ausführen können.

In den Versionshinweisen vom 17. September unterscheidet Google zwei Migrationspfade:

• Bei einem Job in einer Remote-Sandbox, der nur output_text oder model_output liest, muss lediglich die Agent-Zeichenfolge geändert werden.
• Ein Job, der local_environment nutzt oder function_call-Schritte auswertet, benötigt zusätzlich einen aktualisierten Tool-Adapter.

Genau diese Unterscheidung bestimmt den Aufwand. Ein Adapter ist das kleine Stück Anwendungscode, das den Namen und die Argumente eines Tools entgegennimmt, beides validiert, die lokale Aktion ausführt und das Ergebnis zurückgibt.

Der Vertrag für lokale Tools ändert sich an fünf Stellen

Der alte Agent behandelte Dateioperationen überwiegend als allgemeine Lese- und Schreibvorgänge. Der September-Agent verwendet enger zugeschnittene Namen und Argumente. Außerdem wechseln die Argumentschlüssel von snake_case zu PascalCase.

Fünf Funktionsgruppen für Dateien und Suche haben sich geändert. Zwei der aufgeführten integrierten Tools bleiben unverändert. Deshalb kann ein pauschaler Handler rund um write_file scheitern, obwohl die neue Agent-ID korrekt gesetzt wurde.

Auch der neue Bearbeitungsvertrag arbeitet präziser. Statt für eine kleine Änderung die gesamte Datei zurückzusenden, nennt der Agent einen Zeilenbereich, den dort erwarteten Text und den Ersatz. Der Adapter sollte den Aufruf ablehnen, wenn TargetContent nicht mehr mit der Datei übereinstimmt. Andernfalls kann ein verzögerter Job eine neuere menschliche Änderung überschreiben.

Welche Jobs tatsächlich migriert werden müssen

Ein Solo-Gründer mit einem Report-Job in der Remote-Sandbox

Angenommen, ein nächtlicher Job lässt Antigravity Daten in der Sandbox von Google sammeln, einen Bericht speichern und den fertigen Text zurückgeben. Die Anwendung liest output_text und wertet die darunterliegenden Schritte nie aus.

Das ist die kleine Migration. antigravity-preview-05-2026 wird durch antigravity-preview-09-2026 ersetzt. Anschließend läuft ein repräsentativer Bericht parallel zum alten Job, das Endergebnis wird verglichen und erst dann der Zeitplan umgestellt. Einen nicht vorhandenen lokalen Tool-Dispatcher neu aufzubauen, wäre unnötig.

Ein Plattformteam, das Tools auf eigenen Systemen ausführt

Anders sieht es bei einem Repository-Worker aus, dessen Tool-Aufrufe im eigenen Runner ausgeführt werden. Er liest Dateien, durchsucht Code, bearbeitet Konfigurationen und sendet Tool-Ergebnisse an die Interaktion zurück.

Hier fällt die größere Migration an. Der Dispatcher muss die neuen Namen erkennen, Argumente in PascalCase validieren, Richtlinien für Pfade und Befehle durchsetzen, Änderungen an Zeilenbereichen sicher anwenden und das von der Interaktion erwartete Ergebnisformat zurückgeben. Der Nutzen ist Betriebskontinuität: Code-Reviews, Berichtserstellung und Wartungsjobs laufen weiter, nachdem der Mai-Endpunkt verschwunden ist.

Ein Observability-Team, das jeden Schritt verarbeitet

Manche Anwendungen führen zwar alles remote aus, übernehmen function_call-Schritte aber dennoch in ein Audit-Protokoll, eine Fortschrittsanzeige, eine Freigabewarteschlange oder ein Kosten-Dashboard. Solche Teams sind keine reinen Ausgabekonsumenten.

Selbst wenn Google die integrierte Dateisystemaktion ausführt, kann der Parser weiterhin write_file, path und content erwarten. Deshalb müssen Positivliste und Test-Fixtures aktualisiert werden. Sonst stuft das Dashboard eine echte Änderung womöglich als unbekannt ein, verwirft ihre Argumente oder ordnet sie der falschen Freigaberichtlinie zu.

Ein Operations-Verantwortlicher mit unbeaufsichtigten Triggern

Zeitgesteuerte Trigger bergen das höchste Risiko, weil beim Start niemand zusieht. Ein Trigger verknüpft Agent, Umgebung, Prompt und Cron-Zeitplan. Verweist die gespeicherte Interaktion noch auf den Mai-Agenten, kann der Zeitplan fehlerfrei erscheinen, obwohl die dahinterliegende Ausführung nach der Abschaltung fehlschlägt.

Deshalb muss die Agent-ID in jeder Trigger-Definition erfasst werden, nicht nur im SDK-Aufruf der Hauptanwendung. Danach sollte für jedes unterschiedliche Tool-Muster ein Job im Schattenbetrieb laufen. Ein Berichtjob und ein Job zur Reparatur eines Repositorys sind nicht derselbe Migrationstest, nur weil beide Antigravity verwenden.

Ein kleiner Vertragstest für Dateiänderungen

Der sicherste erste Test kommt ohne Produktionszugangsdaten aus. Dazu erhält der Adapter ein aufgezeichnetes Fixture in Form eines Aufrufs, bearbeitet eine wegwerfbare Datei und prüft, ob ausschließlich die vorgesehene Zeile geändert wurde.

Ich habe den folgenden Test mit Node ausgeführt. Er verwendet den von Google veröffentlichten Namen replace_file_content und die Felder in PascalCase. Es handelt sich um einen lokalen Adaptertest, nicht um einen Live-Aufruf der Gemini API.

import assert from "node:assert/strict";
import { mkdtempSync, readFileSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";

function applyReplaceFileContent(call) {
  assert.equal(call.name, "replace_file_content");

  const {
    TargetFile,
    StartLine,
    EndLine,
    TargetContent,
    ReplacementContent,
  } = call.arguments;

  const lines = readFileSync(TargetFile, "utf8").split("\n");
  const current = lines.slice(StartLine - 1, EndLine).join("\n");
  assert.equal(current, TargetContent, "line window no longer matches");

  lines.splice(
    StartLine - 1,
    EndLine - StartLine + 1,
    ...ReplacementContent.split("\n"),
  );
  writeFileSync(TargetFile, lines.join("\n"));
}

const dir = mkdtempSync(join(tmpdir(), "antigravity-adapter-"));
const file = join(dir, "scheduled-job.env");
writeFileSync(file, "owner=ops\nstatus=old\nmode=scheduled\n");

applyReplaceFileContent({
  name: "replace_file_content",
  arguments: {
    TargetFile: file,
    StartLine: 2,
    EndLine: 2,
    TargetContent: "status=old",
    ReplacementContent: "status=ready",
  },
});

assert.equal(
  readFileSync(file, "utf8"),
  "owner=ops\nstatus=ready\nmode=scheduled\n",
);
console.log("PASS: line 2 changed from status=old to status=ready");

Der Test war erfolgreich. Wichtiger noch: Sobald TargetContent im Fixture geändert wird, bricht er ab, statt veraltete Inhalte zu bearbeiten.

Wirtschaftlich zählen Migrationsaufwand und der Wert verpasster Jobs

Google hat mit dieser Agent-Migration keinen neuen Token-Preis angekündigt. Geändert hat sich im Budget die Position für Entwicklungs- und Betriebszeit.

Zwei einfache Formeln reichen aus:

Bei einem reinen Ausgabejob in der Remote-Sandbox kann der Entwicklungsanteil aus dem Wechsel der Agent-Zeichenfolge und einem Schattenlauf bestehen. Für eine Integration mit lokalen Tools müssen fünf geänderte Funktionsgruppen, Parser-Fixtures, Sicherheitstests und ein vollständiger Lauf je unterschiedlicher Workflow-Form einkalkuliert werden.

Daraus sollte keine erfundene allgemeingültige Stundenschätzung entstehen. Ein eng begrenzter Berichtsgenerator und ein lokaler Coding-Agent unterscheiden sich bei Tool-Abdeckung, Freigabelogik und Ausfallkosten. Werden der eigene vollständige Stundensatz für Entwicklung und der geschäftliche Wert pro Lauf in die Formeln eingesetzt, erhält das Finanzteam eine belastbare Entscheidungsgrundlage statt einer Liste von Anbieter-Features.

Die ehrliche Einordnung

Der lokale Test oben beweist, dass Fixture und Adapter übereinstimmen. Er beweist nicht, was ein Live-Agent bei jedem Prompt ausgibt. Für diesen Testlauf lagen keine Zugangsdaten zur Gemini API vor; daher wurde auch nicht vorgetäuscht, der gehostete Agent sei ausgeführt worden. Die letzte Abnahmeprüfung ist ein aufgezeichneter Aufruf des September-Agenten in einer wegwerfbaren Umgebung.

Auch ist der Aufwand nicht für alle Nutzer von Antigravity gleich:

• Noch diese Woche handeln, wenn ein Produktionsjob antigravity-preview-05-2026 nennt, local_environment verwendet, function_call-Schritte auswertet oder unbeaufsichtigt nach Zeitplan läuft.
• Den kleinen Migrationspfad wählen, wenn der Job in einer Remote-Sandbox läuft und nur output_text oder model_output verarbeitet. Dann genügen ID-Wechsel und Schattenlauf.
• Direkt mit der neuen ID starten, wenn die API noch evaluiert wird und keine Jobs mit dem Mai-Agenten produktiv laufen.
• Diese Migration ignorieren, wenn ausschließlich die Antigravity-IDE genutzt und der Managed Agent nicht über die Gemini API aufgerufen wird.

Was am Montag ansteht

Eine Person übernimmt die Verantwortung für die Bestandsaufnahme. Ausgerollte Konfigurationen, Trigger-Definitionen, Umgebungsvariablen, Dashboards und Fixtures werden nach der ID des Mai-Agenten und den alten Tool-Namen durchsucht. Noch bevor Code geändert wird, werden die Treffer in reine Ausgabejobs und Jobs mit Adapterbedarf aufgeteilt.

Danach wird aus jeder Liste ein repräsentativer Job migriert. Der alte Zeitplan bleibt pausiert, aber verfügbar, während der September-Lauf geprüft wird. Anschließend folgen die restlichen Jobs nach Workflow-Familie; bis zum 5. Oktober warnt ein Alert vor unbekannten Tool-Aufrufen. Das Ergebnis am Montag ist keine Präsentation, sondern eine Bestandsaufnahme mit Verantwortlichen, ein erfolgreicher Schattenlauf und ein Termin für jeden verbleibenden Job.

Weitere verständliche Hinweise für Betreiber zu Änderungen, die reale Workflows gefährden können, liefert der Newsletter.