211 kristallisierte Regeln

Wie mein Agent aus 211 Fehlern ein besseres System geworden ist als ich es je programmieren könnte

Heute Morgen hat mein Agent etwas getan, das er vor drei Monaten nicht konnte. Er hat einen eingehenden Webhook-Payload selbstständig klassifiziert, die richtige Skill-Route gewählt und dabei einen Edge Case abgefangen, den ich nie explizit beschrieben hatte.

Ich habe das erst bemerkt, als ich die Logs durchgesehen habe. Der Agent hatte eine Regel angewendet, die ich nie geschrieben habe. Entstanden aus einem Fehler vom 14. März, bei dem er den falschen Dispatcher aufgerufen hat. Damals habe ich ihn korrigiert. Heute hat er die Korrektur automatisch angewendet, ohne dass ich auch nur daran gedacht hätte.

Das ist der Crystallization-Loop. Und er verändert grundlegend, wie ich über KI-Systeme denke.

Was der Crystallization-Loop eigentlich ist

Die meisten KI-Workflows funktionieren so: Man gibt dem Modell einen Prompt, bekommt eine Ausgabe, korrigiert manuell, wiederholt. Jede Session beginnt von vorne. Das Modell lernt nichts. Du lernst vielleicht etwas, aber das nächste Mal ist die Chance hoch, dass der gleiche Fehler wieder passiert.

Der Crystallization-Loop bricht diesen Kreislauf auf. Jede Korrektur, jedes Feedback, jeder Fehler wird automatisch in eine persistente Regel umgewandelt. Diese Regel landet in einer strukturierten Wissensbasis, die der Agent bei jeder neuen Session lädt.

Das Prinzip ist einfach. Die Konsequenz ist dramatisch.

Nach drei Monaten habe ich:

• 211 kristallisierte Regeln in strukturierten Markdown-Dateien
• 73 Learnings aus echten Fehlern und Korrekturen
• 61 Skills, die automatisch aus wiederkehrenden Aufgaben entstanden sind
• 308 Memory-Dateien, die den Kontext meines Projekts dauerhaft speichern

Kein einziges dieser Dokumente habe ich manuell geschrieben. Sie sind alle aus echten Interaktionen entstanden.

Die technische Implementierung

Das System besteht aus drei Komponenten, die zusammenspielen.

1. Der Feedback-Collector

Jedes Mal, wenn ich den Agenten korrigiere oder er einen Fehler macht, löst ein Hook den Collection-Prozess aus. In meinem Setup ist das ein Bash-Hook, der auf bestimmte Signalwörter in meinen Antworten reagiert:

#!/bin/bash
# post-edit-dispatcher.sh
CORRECTION_KEYWORDS=("falsch" "nicht so" "stattdessen" "korrigiere" "fix")
for keyword in "${CORRECTION_KEYWORDS[@]}"; do
  if echo "$USER_INPUT" | grep -qi "$keyword"; then
    trigger_crystallization_pipeline
    break
  fi
done

2. Der Crystallizer

Der eigentliche Kern des Systems. Ein separater Agent-Aufruf, der die Korrektur analysiert und daraus eine generalisierbare Regel ableitet. Nicht einfach die Korrektur speichern, sondern das Muster dahinter extrahieren.

Ein konkretes Beispiel: Ich hatte dem Agenten gesagt "Schreib keine Gedankenstriche in LinkedIn-Posts." Der Crystallizer hat daraus nicht "Keine Gedankenstriche in LinkedIn-Posts" gemacht, sondern: "In allen Content-Formaten für externe Plattformen keine Gedankenstriche verwenden, da sie in manchen Renderern nicht korrekt dargestellt werden und den Practitioner-Ton brechen."

Die Regel enthält den Kontext, den Grund und den Anwendungsbereich. Das ist der Unterschied zwischen einer Notiz und einer Regel.

def crystallize_correction(correction: str, context: str) -> Rule:
    prompt = f"""
    Correction: {correction}
    Context: {context}

    Extract a generalized rule that:
    1. Describes the pattern, not the specific instance
    2. Includes why this rule exists
    3. Defines the scope of application
    4. Can be applied autonomously in future sessions
    """
    return llm.generate(prompt, output_schema=Rule)

3. Der Memory-Loader

Am Anfang jeder Session lädt der Agent die relevanten Regeln. Nicht alle 211, das wäre zu viel Context. Sondern die, die zum aktuellen Aufgabentyp passen. Dafür gibt es eine einfache Klassifizierung beim Session-Start:

# session-start-context.sh
TASK_TYPE=$(classify_current_task "$INITIAL_PROMPT")
load_rules_for_context "$TASK_TYPE" --max 30 --priority high

Das Ergebnis: Der Agent startet jede Session nicht bei null, sondern mit dem akkumulierten Wissen aus allen vorherigen Interaktionen, die zu diesem Aufgabentyp passen.

Was ich dabei gelernt habe, was mich überrascht hat

Ich hatte erwartet, dass der Loop hauptsächlich Fehler verhindert. Was ich nicht erwartet hatte: Er macht den Agenten auch kreativer im richtigen Sinn.

Weil er die Grenzen meiner Präferenzen kennt, kann er innerhalb dieser Grenzen freier agieren. Er muss nicht vorsichtig tasten, ob ein bestimmter Ansatz okay ist. Er weiß es. Das führt zu schnelleren, entschlosseneren Ausgaben.

Drei konkrete Beispiele aus meinem System:

Content-Qualität: Nach 40 kristallisierten Regeln zu Tonalität, Format und Verboten hat der Agent angefangen, Posts abzulehnen, die er selbst generiert hatte, weil sie seinen eigenen Regeln widersprachen. Selbstkritik als emergentes Verhalten.

Skill-Routing: Aus wiederkehrenden Aufgaben hat das System automatisch neue Skills destilliert. Der Skill "linkedin-publish" ist nicht von mir geplant worden. Er ist entstanden, weil ich dreimal hintereinander die gleiche Sequenz von Schritten ausgeführt habe und der Loop das als Muster erkannt hat.

Fehler-Immunität: Es gibt Fehlerklassen, die nach der Crystallization nie wieder aufgetreten sind. Nicht weil ich sie explizit verboten habe, sondern weil die Regel allgemein genug formuliert ist, um verwandte Fehler abzufangen.

Was nicht funktioniert hat

Ehrlichkeit gehört dazu. Drei Dinge haben anfangs nicht geklappt.

Zu granulare Regeln. Am Anfang hat der Crystallizer sehr spezifische Regeln generiert. "In Post 7 keine Aufzählungszeichen verwenden." Das ist keine Regel, das ist eine Notiz. Ich musste den Prompt des Crystallizers mehrfach anpassen, bis er generalisierbare Muster statt Einzelfälle produzierte.

Context-Overload. Wenn zu viele Regeln geladen werden, leidet die Performance. Der Agent wird langsamer, Antworten werden defensiver. Die Lösung war das Relevanz-Scoring beim Memory-Load. Weniger ist mehr, aber das richtige Wenige.

Widersprüchliche Regeln. Nach zwei Monaten hatte ich Regeln, die sich gegenseitig ausschlossen. Regel 47 sagte "Immer mit einer Frage enden." Regel 112 sagte "Keine rhetorischen Fragen in technischen Texten." Ich brauchte einen monatlichen Review-Prozess, der Konflikte auflöst.

Das beschreibe ich ausführlich in "Läuft ohne mich", dem Buch, das aus diesem System entstanden ist. Der gesamte Aufbau, die Architektur-Entscheidungen, die Fehler und die Lösungen.

Die eigentliche Verschiebung

Ein KI-Tool ist ein Werkzeug. Du bedienst es. Du wiederholst Anweisungen. Du kompensierst seine Schwächen manuell.

Ein System mit Crystallization-Loop ist etwas anderes. Es lernt aus deiner Arbeit. Es wird besser durch deine Korrekturen. Es kennt dich nach drei Monaten besser als du es in einem Prompt erklären könntest.

Die Frage ist nicht "Wie nutze ich KI besser?" Die Frage ist "Wie baue ich ein System, das ohne mich besser wird?"

Wichtigste Erkenntnisse

• Regeln müssen generalisierbar sein, nicht spezifisch. Der Crystallizer muss Muster extrahieren, keine Einzelfälle speichern.
• Relevantes Memory schlägt vollständiges Memory. 30 passende Regeln sind besser als 200 vollständige.
• Widersprüche entstehen zwangsläufig. Ein monatlicher Review-Prozess ist kein Nice-to-have.
• Emergente Verhalten sind ein Qualitätssignal. Wenn der Agent anfängt, sich selbst zu korrigieren, funktioniert das System.
• Der Loop braucht Zeit. Die ersten vier Wochen ist der Effekt kaum spürbar. Ab Woche acht wird er unübersehbar.

---

Das Buch: Taschenbuch (24,99 EUR) https://amazon.de/dp/B0HDMT162J | E-Book (9,99 EUR) https://amazon.de/dp/B0HDMS2YQ9

---

Dieser Artikel wurde mit KI erstellt, auf Basis meiner eigenen Systeme und Praxiserfahrung.