Elephant-Goldfish Model: Was hinter dem Google-Projekt für KI-Programmieragenten steckt
Das Elephant-Goldfish Model, kurz EGM, ist eine frei verfügbare Erweiterung für KI-Programmieragenten wie Claude Code und Codex. Ein Agent mit vollem Projektwissen schreibt die Spezifikation, frische Agenten ohne Gesprächsverlauf suchen darin nach Lücken, und erst nach Ihrer Freigabe entsteht Code. Das Projekt liegt bei Google auf GitHub, ist laut eigener Angabe aber kein offiziell unterstütztes Google-Produkt.
Stand 08.11.2026. Grundlage: Dokumentation und Quellcode des Projekts auf GitHub sowie egm.dev, Version 0.1.1.
- Was das Elephant-Goldfish Model ist
- Warum ein Prüfer ohne Gedächtnis mehr finden kann
- Der Ablauf: von der Idee bis zum Abgleich mit dem Code
- So installieren Sie EGM
- Entscheidungshilfe: Wann sich der Aufwand lohnt
- Grenzen, die Sie vor dem Einsatz kennen sollten
- Was Betriebe daraus mitnehmen können
Was das Elephant-Goldfish Model ist
EGM ist kein eigenes KI-Modell und keine eigene Anwendung. Es ist eine Sammlung von Arbeitsanweisungen und Prüfer-Rollen, die in einem vorhandenen Programmieragenten läuft. Der Name beschreibt die Aufgabenteilung: Der Elefant vergisst nichts, der Goldfisch fängt jedes Mal bei null an.
| Rolle | Was sie weiß | Was sie tut |
|---|---|---|
| Elephant | Projekt, Anforderungen, bisherige Entscheidungen | Untersucht das Problem und schreibt die Spezifikation |
| Goldfish | Das Dokument und bereitgestelltes Quellenmaterial, nicht das Gespräch davor | Sucht fehlende Annahmen, unklare Anforderungen und Umsetzungsrisiken |
| Mensch | Ziele und Rahmenbedingungen des Vorhabens | Entscheidet Zielkonflikte, gibt den Entwurf frei, legt fest, was gebaut wird |
Das Projekt liegt im GitHub-Konto von Google, die Website nennt Google LLC im Copyright. Zugleich steht in der Projektbeschreibung ausdrücklich, dass es sich nicht um ein offiziell unterstütztes Google-Produkt handelt. Laut egm.dev arbeiten Tausende Google-Ingenieure damit. Das ist eine Angabe des Projekts selbst, eine unabhängige Zahl dazu gibt es nicht. Die Idee geht auf einen Aufsatz von Dave Rensin zurück, auf den die Dokumentation verweist.
Warum ein Prüfer ohne Gedächtnis mehr finden kann
Wer lange mit einem KI-Agenten an einem Entwurf arbeitet, baut gemeinsame Annahmen auf. Vieles wurde im Gespräch geklärt und steht trotzdem nirgends. Bittet man denselben Agenten um eine Prüfung, liest er den Text mit diesem Vorwissen und ergänzt Lücken stillschweigend.
Ein Prüfer ohne Gesprächsverlauf kann das nicht. Was weder im Dokument noch im bereitgestellten Material steht, existiert für ihn nicht. Genau dadurch fallen Stellen auf, die später auch der umsetzende Agent oder ein neuer Mitarbeiter nicht verstehen würde. Das Dokument muss also für sich allein tragen.
Deshalb ist die frische Sitzung bei EGM keine Empfehlung, sondern Bedingung: Kann der Agent keine unabhängigen Unteragenten starten, bricht die Prüfung ab, statt sie im selben Gespräch nachzuahmen.
Der Ablauf: von der Idee bis zum Abgleich mit dem Code
Die Dokumentation beschreibt einen Kernablauf, betont aber, dass jeder Schritt auch einzeln nutzbar ist.
- Idee schärfen mit
/egm-brainstorm: Rückfragen klären das Vorhaben, frische Prüfer greifen es an, am Ende steht ein Konzeptpapier. - Entwurf schreiben mit
/egm-draft: Aus dem Konzept entsteht Abschnitt für Abschnitt ein Design-Dokument, nach jedem Abschnitt fragt der Agent nach. - Entwurf prüfen mit
/egm-review: Fünf Stufen laufen durch, nämlich ein erster Blick aufs Ganze, eine Verständnisprüfung, die Kritik am Design, ein zweiter Blick aufs Ganze und die Prüfung auf Umsetzungsreife. - Befunde bearbeiten mit
/egm-resolve: Sie entscheiden, welche Hinweise in den Entwurf einfließen. - Menschliche Prüfung und Umsetzung: Die Anleitung sieht vor, den Entwurf einem Kollegen vorzulegen. Danach baut der Agent nach dem freigegebenen Plan.
- Abweichungen finden mit
/egm-drift-report: Dokumente und aktueller Code werden verglichen. Das Projekt rät zu einem wöchentlichen Lauf.
Für bestehende Software gibt es /egm-bootstrap, das fehlende Dokumentation aus dem Code aufbaut. Mit /egm-review-loop lassen sich Prüfer und Maßstäbe auch für andere Dokumente als Software-Spezifikationen zusammenstellen. Die Reihenfolge ist nicht vorgeschrieben: Einen einfachen Fehler soll laut Anleitung niemand durch den ganzen Entwurfsprozess schicken.
So installieren Sie EGM
Für Claude Code:
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egmFür Codex CLI:
codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egmFür Antigravity CLI:
agy plugin install https://github.com/google/elephant-goldfish-modelDanach eine neue Sitzung starten. In Claude Code und in der Antigravity CLI bekommen die Befehle das Präfix /egm:, also zum Beispiel /egm:egm-review. In Codex wählen Sie die jeweilige Fähigkeit aus der Auswahlliste. Installieren Sie immer die komplette Erweiterung: Wer nur den Ordner mit den Fähigkeiten kopiert, nimmt ihr die Prüfer-Rollen und Dokumentstandards, auf die sie zur Laufzeit zugreift.
Ohne Installation geht es auch. Die Anleitung empfiehlt sogar, den Ablauf zunächst ein- oder zweimal von Hand durchzuspielen, um ein Gefühl dafür zu bekommen.
Entscheidungshilfe: Wann sich der Aufwand lohnt
Die folgende Einordnung ist unsere eigene Einschätzung. Maßstab ist, wie teuer ein Denkfehler wäre, der erst nach der Umsetzung auffällt.
| Vorhaben | Empfehlung | Begründung |
|---|---|---|
| Kleiner Fehler mit klarer Ursache | Ohne EGM | Es gibt nichts zu entwerfen, ein Test belegt die Korrektur |
| Kleine Funktion ohne Datenänderung | Höchstens /egm-review auf eine kurze Notiz | Der volle Ablauf kostet mehr, als er bringt |
| Neue Funktion mit Fehlerfällen, etwa Webhooks oder Zahlungseingänge | Voller Ablauf | Wiederholungen und Ausfälle entscheiden die Qualität, und genau diese Fälle fehlen oft im ersten Entwurf |
| Änderung an Datenbank, Rechten oder Schnittstellen zu Fremdsystemen | Voller Ablauf, dazu menschliche Prüfung | Fehler sind schwer rückgängig zu machen |
| Gewachsene Software ohne Dokumentation | Zuerst /egm-bootstrap, dann Drift-Bericht | Ohne Dokumente hat der Prüfer keine Grundlage |
| Fachkonzept, Angebot oder Richtlinie | /egm-review-loop mit eigenen Maßstäben | Der fertige Ablauf ist auf Software-Spezifikationen zugeschnitten |
Grenzen, die Sie vor dem Einsatz kennen sollten
- Frühe Version. Die erste getaggte Fassung 0.1.0 erschien am 27.10.2026 mit dem Hinweis, dass sie noch nicht als stabil gelten soll. Aktuell ist 0.1.1 vom 06.11.2026.
- Keine Garantie für Code. Die Prüfung ersetzt laut Projekt weder Tests noch menschliches Urteil. Sie prüft den Entwurf, nicht das fertige Programm.
- Viele Hinweise. Die Dokumentation sagt offen, dass die Prüfung absichtlich sehr viel Rückmeldung liefert. Auswählen müssen Sie selbst.
- Höherer Verbrauch. Jeder Prüfer ist ein eigener Agent. In einem dokumentierten Testlauf mit dem Agenten Muse waren es 15 Prüfer für einen Durchgang. Das schlägt sich im Kontingent oder in den Nutzungskosten Ihres KI-Dienstes nieder.
- „Frisch“ heißt nicht „leer“. Ein Goldfish kennt das Gespräch nicht, kann aber je nach Umgebung Projektanweisungen wie
AGENTS.mdmitbekommen. Für Claude Code ab Version 2.1.271 unterdrückt die Erweiterung die üblichenCLAUDE.md-Dateien beim Start der Prüfer, verwaltete Vorgaben und Regeln aus Unterverzeichnissen können trotzdem greifen. Für Codex CLI 0.166.0 und die Antigravity CLI ist in Issue 237 gemeldet, dass solche Dateien trotzdem ankamen. Alles, was der Prüfer gezielt hinterfragen soll, gehört daher als Prüfkriterium in den Auftrag. - Nicht überall lauffähig. Die eigenständige Antigravity-IDE wird nicht unterstützt, weil sie keine frischen Unteragenten bereitstellt. Für Claude Cowork und ChatGPT Work sind Installationswege beschrieben, der Nachweis in der Cloud steht noch aus.
- Datenweg bleibt gleich. EGM läuft in Ihrem Agenten. Entwurf und Quellcode gehen an denselben KI-Anbieter wie bisher, nur an mehr Sitzungen. Für vertrauliche Projekte gelten dieselben Regeln wie für jede andere Agentenarbeit.
Was Betriebe daraus mitnehmen können
Auch wer nie selbst einen Agenten bedient, kann das Prinzip nutzen, etwa wenn ein Dienstleister Software mit KI entwickelt. Die Rückfragen dazu sind einfach:
- Gibt es vor dem Programmieren ein schriftliches Design-Dokument, das Sie lesen und freigeben?
- Prüft jemand dieses Dokument, der nicht am Entwurf beteiligt war, Mensch oder frischer Agent?
- Sind Fehlerfälle beschrieben: Was passiert bei Ausfall, doppelter Lieferung, fehlenden Rechten?
- Wer entscheidet über Zielkonflikte, und ist das dokumentiert?
- Wird nach Änderungen geprüft, ob Dokument und Code noch zusammenpassen?
Einen einfachen Goldfish können Sie auch ohne Erweiterung einsetzen: Eröffnen Sie eine neue Sitzung, geben Sie nur das Dokument und die zugehörigen Quellen hinein und bitten Sie um eine Liste unklarer Annahmen und fehlender Fälle. Das ist nicht der Prüfablauf von EGM, nutzt aber denselben Gedanken. Wie klare Anforderungen und überprüfbare Tests zusammenspielen, zeigt unser Beitrag zu intent.md. Warum die Umgebung um das Modell herum oft mehr ausmacht als das Modell selbst, steht im Text zum Agent Harness.
Ob mit EGM oder ohne: Bei eigener Software entscheidet sich die Qualität oft schon im schriftlichen Entwurf. Wenn Sie ein solches Vorhaben planen, klären wir mit Ihnen zuerst, was gebaut werden soll, und erst dann, wie.
Mehr dazu: Eigene Software für Ihr Unternehmen – individuell entwickelt
Quellen
- Elephant-Goldfish Model, Projektseite und Beschreibung, github.com
- EGM, offizielle Website, egm.dev
- EGM, Anleitung zu Einrichtung und Ablauf, github.com
- EGM, unterstützte Umgebungen und bekannte Grenzen, github.com
- EGM, Beschreibung der Prüfstufen, github.com
- EGM, veröffentlichte Versionen, github.com
Alle Quellen gelesen am 08.11.2026.
Erstellt von der Redaktion Die Netzhandwerker mit KI-Unterstützung. Die Sachangaben wurden vor der Veröffentlichung automatisch gegen die genannten Quellen geprüft.
Die Netzhandwerker