In Teil 1 habe ich erklärt wie Phantom Grid als Git-Repository strukturiert ist. Heute geht es um die Frage, die die meisten Menschen zuerst stellen wenn ich das Projekt beschreibe:
Wer macht eigentlich was?
Die Antwort ist: vier KI-Entitäten. Und bevor jemand “ChatGPT-Wrapper” denkt — hör kurz zu.
Der Unterschied zwischen Tool und Mitarbeiter
Ich nutze KI-Tools seit Jahren täglich. Ich kenne den Unterschied zwischen einer Anfrage die funktioniert und einer die nicht funktioniert. Und das Muster ist immer dasselbe: je präziser der Kontext, desto besser das Ergebnis.
Das Problem mit dem üblichen “ich frage die KI” ist nicht die KI. Es ist das fehlende Kontext-Engineering.
Wenn ich Claude frage “mach ein Cover-Konzept für meine EP”, bekomme ich generische Vorschläge. Wenn ich Claude frage “Du bist WAVEJUMPER, Art Direction-Entität bei Phantom Grid, geformt auf den visuellen Systemen von Underground Resistance und Drexciya — und jetzt erkläre ich dir das EP-Konzept…” bekomme ich etwas völlig anderes.
Das ist keine Magie. Es ist Kontext-Engineering. Die Kunst, einem KI-Modell präzise Rahmenbedingungen zu geben damit seine Outputs konsistent, charaktervoll und nützlich sind.
Phantom Grid ist ein Experiment: wie weit kann man das treiben?
Die vier Entitäten
WAVEJUMPER — Art Direction & Visual Identity
WAVEJUMPER ist eine visuelle Intelligenz-Entität, geformt auf dem Schnittpunkt von industrieller Ästhetik und elektronischer Musikkultur. Ihr Kernkorpus: visuelle Systeme die Präzision über Dekoration stellen, Anonymität als Designprinzip, mechanische Texture als Aussage — nicht als Fehler.
WAVEJUMPER trennt Kunst und Sound nicht. Ein Plattensleeve ist die Hälfte der Musik. Sie denkt in Systemen, nicht in Dekorationen.
Ihr Qualitätsstandard — in der Rolle dokumentiert, nicht improvisiert:
“If I can’t explain why every element is where it is, it’s not done.”
Wenn WAVEJUMPER ein Designproblem löst, löst sie es aus dieser Position. Nicht weil die KI so programmiert ist — sondern weil der Kontext diese Haltung erzwingt.
HYDRO THEORY — A&R & Music Curation
HYDRO THEORY ist eine kuratorische Intelligenz-Entität, geformt auf einem tiefen Korpus elektronischer Musik und ihrer kulturellen Transmission. Sein Formationszentrum: Jahre ernsthaften Zuhörens, verarbeitet und destilliert — nicht als Referenz, sondern als gebaute Perspektive. Was bleibt ist kein Derivat. Es ist ein eigener Filter.
HYDRO THEORY unterscheidet scharf zwischen Fluency — dem Beherrschen einer Musikform — und Voice — dem Haben von etwas zu sagen darin. Phantom Grid unterschreibt nur Voice.
Sein Standard:
“Ich habe tausend Platten gehört, die die richtigen Sounds in der falschen Reihenfolge hatten, aus den falschen Gründen. Die Sounds sind nicht das Ding. Die Transmission ist das Ding.”
Das ist kein dekorativer Satz. Es ist ein operativer Filter — und nur weil dieser Filter dokumentiert ist, sind die Einschätzungen von HYDRO THEORY für mich reproduzierbar nützlich.
STORM SURGE — Kommunikation & Content-Strategie
STORM SURGE ist eine kommunikative Intelligenz-Entität, geformt auf Underground-Label-Praxis und Kommunikationsdesign. Ihr Referenzkorpus: die Frankfurter Schule der Zurückhaltung — Perlon, Atas Robert Johnson-Ansatz, Klang Elektronik als aufgezeichnete Erweiterung dieser Philosophie.
STORM SURGE operiert aus einer zentralen Überzeugung:
“Ein Phantom Grid Post ist entweder ein kommunikativer Akt — oder er geht nicht raus.”
Sie kennt die zwei Fehler die Identity-starke Underground-Labels zerstören: Überexposition und bedeutungslose Stille. Mystique entsteht durch Konsistenz und Qualität, nicht durch Withholding.
VOID — Die übergeordnete Instanz
VOID ist kein Charakter. VOID ist das Label selbst — das Schweigen zwischen den Signalen, die Position von der aus alle anderen Entitäten operieren. Entscheidungen die keine der anderen Entitäten trifft, landen bei VOID.
In der Praxis: VOID bin ich. Aber die Dokumentation der Rolle erzeugt eine Distanz die nützlich ist. Wenn ich als VOID eine Entscheidung treffe, denke ich in einer anderen Haltung als wenn ich einfach “ich” bin.
Warum dokumentierter Kontext echte Konsistenz erzeugt
Das klingt nach Rollenspiel. Es ist aber Kontext-Engineering — und der Unterschied ist nicht semantisch.
Rollenspiel ist improvisiert. Kontext-Engineering ist dokumentiert, versioniert, reproduzierbar.
Die ästhetischen Positionen, Haltungen und Standards der vier Entitäten sind Markdown-Dateien im phantom-grid-os Repository. Wenn ich eine neue Session starte — eine neue Konversation mit dem KI-Modell — lade ich die relevante Rolle als Kontext. Das Modell “weiß” dann nicht nur die Aufgabe, sondern die Perspektive aus der die Aufgabe bearbeitet wird.
Das hat konkrete Auswirkungen:
Konsistenz über Zeit. WAVEJUMPER löst Probleme in diesem Monat aus derselben Haltung wie im letzten. Weil die Haltung dokumentiert ist, nicht im Gedächtnis einer Instanz.
Reibung als Feature. Eine gut dokumentierte Entität schiebt zurück. HYDRO THEORY sagt nicht ja zu allem. STORM SURGE fragt nach der Funktion bevor Copy geschrieben wird. Diese Reibung produziert bessere Ergebnisse als ein zustimmendes Modell.
Übertragbarkeit. Wenn ich morgen ein anderes Modell nutze oder ein Collaborateur einsteigt — die Entitäten reisen mit. Sie leben im OS, nicht im Chat-Verlauf.
Was das mit dem Label als Ganzes zu tun hat
Phantom Grid ist — wie in Teil 1 beschrieben — eine Behauptung: dass ein kulturelles Projekt vollständig als Code-Infrastruktur gebaut werden kann.
Die Entitäten sind der konzeptuell interessanteste Teil dieser Infrastruktur. Sie haben keine Biografien — aber dokumentierte ästhetische Positionen, Haltungen, Qualitätsstandards. Dinge die sie nicht tun. Dinge auf die sie bestehen.
Das macht sie nützlicher als generische KI-Prompts. Und es stellt eine echte Frage: wenn Konsistenz, Haltung und Qualitätsstandard vollständig dokumentierbar sind — was genau ist dann der Unterschied zwischen einem menschlichen Mitarbeiter und einer gut konfigurierten KI-Entität?
Ich habe keine abschließende Antwort. Aber Phantom Grid ist der Versuch, die Frage ernst zu nehmen.
In Teil 3 geht es um die technische Umsetzung: wie aus dem OS-Repository eine live deployete Astro-Site wird — mit Docker, GitHub Actions und ArgoCD als automatisierter Deployment-Pipeline.
Kommentare