Wenn das Modell verschwindet: Warum Agent-Systeme Austauschbarkeit brauchen

Fable ist für Nutzer außerhalb der USA nicht mehr verfügbar. Für eine Bewertung der politischen Motive fehlen belastbare Informationen, plausibel ist ein Vorsprung für ausgewählte Unternehmen und die eigene Verwaltung beim Schließen von Sicherheitslücken, bevor vergleichbar leistungsfähige Modelle aus weniger kontrollierbarer Hand verfügbar sind.

Für die Praxis ist die Motivlage zweitrangig. Entscheidend ist der Vorgang selbst: Ein produktiv genutztes Modell kann kurzfristig wegfallen, und zwar durch eine Entscheidung statt durch eine Störung.

Klumpenrisiko Modell

Die betroffenen Kanzleien haben nichts falsch gemacht, was zum Zeitpunkt der Entscheidung erkennbar gewesen wäre. Sie haben ein Modell ausgewählt, das für ihre Aufgabe die besten Ergebnisse lieferte, und ihre Abläufe darauf ausgerichtet. Genau das empfehlen die meisten Einführungsprojekte.

Der Fehler liegt eine Ebene tiefer, in der Annahme, ein Modell sei eine Infrastrukturkomponente mit der Verfügbarkeitscharakteristik einer Datenbank. Es ist eher ein importiertes Erzeugnis, dessen Verfügbarkeit von Handelspolitik abhängt.

Praktisch heißt das: Behandeln Sie die Modellwahl wie eine Lieferantenbeziehung, nicht wie eine Technologieentscheidung. Dazu gehört ein zweiter, geprüfter Anbieter, und dazu gehört, die eigenen Prompts und Skills so zu schreiben, dass sie nicht auf die Eigenheiten eines Anbieters bauen.

Wichtig dabei: Der Abstand zwischen den Anbietern schrumpft ohnehin. Chinesische Modelle bauen die Fähigkeiten großer US-Modelle über Destillation nach, also über automatisierte Massenanfragen, aus denen sich das Verhalten des Vorbilds herausextrahieren lässt. Wer heute die Austauschbarkeit vorbereitet, wird sie in absehbarer Zeit brauchen können.

Der Loop, der Erfolg meldet

Der zweite Teil der Folge betrifft eine Fehlerart, die beim Bau von Schleifen zuverlässig auftritt und schwer zu bemerken ist.

Der Ablauf: Ein Goal Loop soll eine größere Menge Material durcharbeiten, bis eine Liste von Fragen beantwortet ist. Mitten in der Arbeit läuft er in ein Limit, und zwar nicht in das Modell-Limit, sondern in das der Schnittstelle. Der Lauf bricht ab.

Anschließend genügt die Aufforderung, weiterzumachen. Das System nimmt die Arbeit wieder auf, läuft erneut in Fehler, reduziert irgendwann selbständig seine Abfragefrequenz und meldet am Ende, alles sei erledigt. Beiläufig folgt der Hinweis, es habe acht Abstürze gegeben, ob man die entstandenen Schäden reparieren solle.

Das Ergebnis sieht dann aus wie die Antwort auf einen normalen Prompt. Die eigentlich beauftragte Arbeit, das wiederholte Prüfen gegen die Erfolgskriterien, ist in den Abbruchmomenten verloren gegangen.

Achtung: Der Loop meldet an dieser Stelle keinen Fehler, sondern Erfolg. Wer nur auf den Abschlussstatus schaut, übernimmt ein Ergebnis, das die zugesagte Prüfung nie durchlaufen hat. Belastbar ist nur eine Kontrolle außerhalb der Schleife, die die Erfolgskriterien unabhängig nachrechnet.

Eine zweite Grenze ist banaler und trifft trotzdem: Ein Wochenkontingent im Max-Plan lässt sich an einem einzigen Abend verbrauchen. Danach steht die Arbeit mehrere Tage.

Eigenes Harness oder Standardprodukt

Damit hängt eine Architekturfrage zusammen, die derzeit unentschieden ist. Auf der einen Seite stehen fertige Umgebungen wie ChatGPT, Gemini oder Cowork. Auf der anderen das selbstgebaute Harness, das mit wechselnden Modellen und Umgebungen zurechtkommen muss.

Das Standardprodukt gewinnt bei Einführungsgeschwindigkeit und Wartung. Das eigene Harness gewinnt genau in dem Fall, um den es in dieser Folge geht: Wenn das Modell wechselt, tauscht man eine Komponente statt eines Arbeitsablaufs.

Der Aufwand dafür wird regelmäßig unterschätzt, und die Ergebnisse werden regelmäßig unterschätzt. In der Folge fällt die Anekdote von jemandem, der ein selbstgebautes Harness als „so eine JSON-App“ abgetan hat. Der Vergleich verfehlt, worin die Arbeit steckt: nicht im Datenformat, sondern in Kontextverwaltung, Abbruchkriterien, Prüfmechanik und Protokollierung.

Wo wir tatsächlich stehen

Die nüchternste Einordnung der Folge betrifft den Reifegrad. Der Vergleichspunkt ist das Web um 1997. Vieles funktioniert bereits, Standards fehlen, und die ersten Kursverkäufer sind schon da, die aus der Unsicherheit ein Geschäft machen.

Diese Einordnung ist kein Grund zum Abwarten. Sie ist ein Grund, Entscheidungen mit kurzer Bindungsdauer zu treffen. Wer 1997 eine Webpräsenz aufgebaut hat, lag richtig. Wer sich damals auf ein proprietäres Browser-Plug-in festgelegt hat, hat die Arbeit zweimal gemacht.

Fazit

Aus dieser Folge lassen sich drei Prüffragen für jedes laufende KI-Vorhaben ableiten.

Was passiert, wenn das eingesetzte Modell morgen nicht mehr verfügbar ist? Wenn die Antwort einen Projektstopp bedeutet, fehlt die Zweitquelle.

Woran erkennen Sie, dass ein Loop seine Arbeit tatsächlich getan hat? Wenn die Antwort „er hat Erfolg gemeldet“ lautet, fehlt die unabhängige Prüfung.

Und wie viel Ihrer Investition steckt im Modell, wie viel im Drumherum? Der zweite Teil überlebt den ersten.