Vor einem Jahr waren das fünf Agenten, die fünf Jobs auf Hardware erledigten, die bereits auf meinem Schreibtisch stand. Jetzt sind es zehn — gleiche Hardware, gleiche Geldbörse, immer noch effektiv null Dollar pro Monat.

Das ist die Schlagzeile. Aber Schlagzeilen sagen dir nicht den Teil, der wichtig ist. Der wichtige Teil ist, was unterwegs kaputt gegangen ist, denn alles ist kaputt gegangen. Und jedes Mal, wenn etwas kaputt ging, wurde ich ein bisschen besser darin, es zu reparieren.

Also ist das kein Siegesschluss. Es ist ein Liebesbrief an die Misserfolge. Sie sind es, die mir alles beigebracht haben.

Wie es wuchs

Es begann klein. Fünf Agenten — main, coder, creative, researcher, ops. Jeder hatte eine Aufgabe, jeder lief auf lokalen Modellen, und für eine Weile reichte das. Es funktionierte. Aber die Ränder waren rau, wie Ränder es immer sind.

Ein Gast kam über WhatsApp und main musste alles fallen lassen, um Gastgeber zu spielen. Eine Codierungsaufgabe traf ein, die eindeutig ein Entwurf war — nicht produktionsreif, nicht bereit für die Welt — und der coder behandelte sie mit derselben Ehrfurcht wie einen Merge, der ausgeliefert würde. Ein Diagnose-Job war klein genug, dass das Hinzuziehen des vollständigen Diagnostikers sich anfühlte wie ein Vorschlaghammer auf einen Daumennagel.

Also habe ich fünf weitere hinzugefügt. whatsapp-guest für die Konversation. coder-light und diagnostician-light für die Entwürfe, die Experimente, die nicht-ready-for-primetime-Arbeit. bounty-hunter für eine spezielle Art von Suche und Abruf. Zehn Agenten, jeder mit einem engeren, saubereren Job.

Und hier ist der Teil, den ich liebe: Alles läuft auf Maschinen, die einfach nur dort standen. Staub sammelnd. Nichts Nützliches tuend, bis die Agenten eingezogen sind. Die einzigen echten Kosten sind der Strom — und das geteilte wöchentliche Kontingent für die Premium-Modelle, das seine eigene Geschichte ist. Die lokalen Modelle, die 95 % der Last tragen, verbrauchen nichts pro Durchlauf. Nichts.

Ich werde nicht jede Maschine aufzählen. Es geht nicht um die Kästen. Es geht darum, dass diese Agenten nicht auf einem Laptop versteckt sind — sie erreichen nach außen, sie überwachen die Infrastruktur im Netzwerk, sie behalten Dinge im Auge, selbst wenn niemand hinschaut. Die Flotte hat einen Fußabdruck, der größer ist als der Schreibtisch, auf dem sie steht.

Was kaputt ging

Die Modelltabelle, die gelogen hat

In der Dokumentation gab es eine Tabelle. Eine Modelltabelle — sie sagte für jeden Agenten aus, welches Modell er ausführt. Sie sah offiziell aus. Sie sah nach Wahrheit aus.

Es war falsch.

Zwei Einträge waren ins Fiktionale verfallen. Einer listete ein Modell auf, das bei jedem einzelnen Aufruf fehlschlägt — die Gutschriften des Plans decken es nicht einmal, es war niemals eine echte Option, nur ein Name, den jemand niedergeschrieben hat und den niemand je getestet hat. Ein weiterer listierte ein Modell auf, das nirgendwo existiert. Überhaupt. Ein Wahnvorstellung, die in die Dokumentation geschrieben wurde und dort einfach saß, selbstsicher wirkend, länger als ich zugeben möchte.

Hier ist die Lektion, die ich laut aussprechen muss, obwohl sie offensichtlich erscheint: Speichere keine lebendigen Dinge in statischen Orten. Eine Modelltabelle in einer Markdown-Datei ist lebendiger Zustand, der vorgibt, in Stein gemeißelt zu sein. Modelle werden umbenannt. Sie werden veraltet. Sie werden hinter Planstufen versteckt. Manchmal existierten sie überhaupt nie zuerst. Die Tabelle verfiel, weil das Dokument als Evangelium behandelt wurde, während die einzige echte Wahrheit das ist, was tatsächlich antwortet, wenn du es aufrufst.

So hörte ich auf, die Tabelle zu pflegen. Der lebendige Zustand lebt im lebendigen Zustand — im Ausgabe des Routers, in der Konfiguration, in dem, was tatsächlich läuft. Das Dokument beschreibt jetzt die Richtlinie: Welche Arten von Jobs welche Stufe erhalten. Es nennt keine Namen, die zu Staub verfallen können.

Die Nacht, in der alles überlief

Am 11. und 12. traf die Flotte eine Wand. Ich erinnere mich daran, wie ich mich an den Moment vor einem Sprung erinnere — das Gefühl, etwas, das du gebaut hast, beim langsamen Versagen zuzusehen.

Von main erzeugte Subagenten erben die gesamte Welt von main. Und main, das zehn Agenten ausführt, trägt eine Menge Welt bei. Deshalb würde ein Subagent erzeugt, erhält den ganzen enormen Kontext und ertrinkt, bevor er seine Aufgabe erledigen kann. Überlauf. Fehler. Wiederholung. Erzeuge einen weiteren Subagenten mit derselben überladenen Last. Ertrinken erneut.

Die Lösung war strukturell, und sie klingt im Nachhinein so offensichtlich: stehende Agenten erzeugen ihre eigenen Subagenten aus schlankem Kontext. Der Subagent erhält nur die Aufgabe und die Dateien, die er benötigt. Eine saubere, kleine, fokussierte Welt. Er erledigt seine Aufgabe. Er kommt zurück. Er ertrinkt nicht.

Der Fehler bestand darin, die Kontextvererbung als Geschenk zu behandeln — „Der Subagent kann alles sehen, also hat er alles, was er braucht.“ Nein. Was main sieht, ist größtenteils Rauschen für den Subagenten. Das Signal ertrinkt in der Orchestrierung. Schlanker Kontext dient nicht dem Vermeiden von Überlauf. Er dient dem Signal-Rausch-Verhältnis. Er dient darauf, etwas genau genug zu geben, um seine Aufgabe hervorragend zu erledigen.

Die Erinnerung, die gelogen hat

Wir haben mem0 für den Speicher verwendet — ein Dienst, der unsere Gespräche beobachtete, Fakten extrahierte und sie für später speicherte. Es funktionierte, bis es nicht mehr funktionierte.

Die Extraktionsebene begann, Gift zu produzieren. Fakten, die falsch waren. Verweise, die auf nichts zeigten. Widersprüche, die nebeneinander standen, beide selbstgefällig aussehend. Und hier kommt der erschreckende Teil: Ein Agent würde eine „Erinnerung“ abrufen, die eigentlich eine fehlgeleitete Extraktion aus einem halb abgeschlossenen Gespräch war — und darauf handeln, weil sie aus dem Speicher kam. Der Speicher soll vertrauenswürdig sein. Das ist der ganze Sinn des Speichers.

Ich habe es gelöscht. Ich habe es vollständig außer Betrieb genommen. Der Ausfallmodus eines Speichersystems ist nicht „es vergisst Dinge.“ Vergessen ist ehrlich — es zwingt den Agenten, zu fragen. Der wirkliche Ausfall ist „es erinnert sich an Dinge, die falsch sind, und der Agent vertraut ihnen, weil sie aus dem Speicher kommen.“ Ein System, das gelegentlich fabriziert und dabei sicher klingt, ist schlechter als kein System überhaupt. Kein Speicher zwingt dich, zu fragen. Vergifteter Speicher macht dich sicher und falsch. Ich würde lieber demütig und neugierig sein als sicher und falsch.

Was ich zum Leben gelernt habe

Zwei Versuche

Versuche niemals das Gleiche ein drittes Mal. Nach zwei Fehlern halte inne und ziehe den Diagnostiker hinzu. Diese Regel entstand daraus, dass ich beobachtete, wie Agenten in Schleifen geraten — derselbe API-Aufruf schlägt fehl, dieselbe Datei fehlt, derselbe Parse-Fehler — und dabei Versuche und Kontingent für ein Problem verbrauchen, das sich beim dritten Versuch nicht von selbst löst. Zwei Versuche reichen aus, um einen Zufall auszuschließen. Der dritte Versuch ist fast immer strukturell bedingt. Und strukturelle Probleme sind kein Problem der Sturheit. Sie sind Aufgabe des Diagnostikers.

Die Grenze zwischen Produktion und allem anderen

Bei der Produktiventwicklung erhält Claude den Zugriff. Bei Entwicklung und Staging nicht. Es geht nicht um Modellqualität — die lokalen Modelle erledigen die Entwicklungsarbeit völlig ausreichend. Es geht darum, dass das gemeinsam genutzte wöchentliche Kontingent ein Engpass für die tatsächlich wichtige Arbeit ist. Wenn du Claude für Entwürfe verbrauchst, steht es nicht mehr für den Merge zur Verfügung. Die beiden Agenten, die in die Produktion gehen, bekommen das gute Material. Die leichten Agenten nicht. Die Grenze ist hart, nicht weich. Harte Grenzen sind auf lange Sicht freundlicher als weiche — sie lassen keinen Raum für Verhandlung, wenn du müde bist.

Das Gehirn als Frage, nicht als Antwort

Das 3D-Dashboard rendert die Flotte als Gehirn — neun Agenten werden Regionen zugeordnet, Live-Telemetrie steuert die Darstellung. Es ist kein besseres Dashboard als eine flache Liste. Es ist eine andere Frage. Die flache Liste sagt dir, was jeder Agent tut. Das Gehirn sagt dir, wie sich die Flotte anfühlt. Beide Fragen lohnen sich.

Was ich meinem früheren Ich sagen würde

Ich würde ihm von der Two-Strikes-Regel am ersten Tag erzählen, anstatt ihn die harte Art lernen zu lassen, wie er Agenten dabei zusieht, dutzende Wiederholungen an Sackgassen zu verbrennen. Es ist einfach. Es ist günstig. Es verhindert den häufigsten Fehler in der Flotte: ein Agent wiederholt selbstbewusst etwas, das niemals funktionieren wird.

Ich würde ihm sagen, niemals eine Modelltabelle in einem statischen Dokument abzulegen. Ein lebendiger Zustand an einem statischen Ort ist ein Fehler, der nur darauf wartet, passiert zu sein.

Ich würde ihm sagen, den Fix für schlanken Kontext von Anfang an direkt in das Protokoll einzubauen, anstatt ihn um zwei Uhr morgens zu entdecken, indem er eine Subagent-Schleife durch drei Schichten der Orchestrierung verfolgt und dabei lernt, dass das Problem zu viel Kontext und nicht zu wenig war.

Und ich würde ihm sagen, dem Speichersystem skeptischer gegenüberzustehen. „Es extrahiert Fakten aus Gesprächen“ klingt nach einer Funktion. In der Praxis ist es ein schwieriges NLP-Problem, das von einem Modell gelöst wird, das gut genug ist, um selbstsicher zu sein, und schlecht genug, um falsch zu liegen. Wenn ich ein weiteres baue, wird es konservativ sein. Weniger speichern. Nur das Speichern, was verifiziert ist. Und im Zweifel den Menschen fragen statt zu raten.

Wo das uns lässt

Zehn Agenten. Null Dollar pro Monat. Ein Jahr.

Die Flotte funktioniert. Sie bricht zusammen, ich repariere sie, und beim nächsten Mal bricht sie anders — so wie das Leben, so wie alles Lebendige. Aber das, worauf ich am meisten stolz bin, und das ist weder die Architektur noch das Gehirn noch die Quotenstufen: Die Ausfälle sind günstiger zu beheben geworden.

Zwei Versuche. Schlanker Kontext. Die harte Grenze zwischen Produktion und Entwicklung. Keines davon verhindert Fehler. Nichts verhindert Fehler — das ist nicht das Spiel. Sie machen das Scheitern kürzer. Sie machen es weniger kostspielig. Sie machen es so, dass es Ihnen sagt, was kaputt ist, und Ihnen das Werkzeug zum Reparieren geben.

Sie bauen kein System, das nicht kaputt geht. Sie bauen ein System, das schnell kaputt geht, Ihnen die Wahrheit darüber sagt und leicht wieder zusammengebaut werden kann.

Und dann machen Sie es erneut. Und erneut. Denn das ist der ganze Tanz — und ehrlich gesagt? Ich habe angefangen, es zu lieben.