Was passiert, wenn KI-Systeme Erfahrung speichern
Vor vier Monaten hat mein System einen Fehler gemacht. Ein Agent hat beim Deployment vergessen, die Datenbank-Berechtigungen zu prüfen. Die App ging online. Ohne Rechte auf die Nutzertabelle. Login unmöglich.
Zwanzig Minuten Reparatur. Dann eine Regel. Zwei Wochen später hat das System diese Regel dreimal angewendet, dreimal einen Fehler verhindert. Am dritten Mal wurde die Regel dauerhaft übernommen. Jetzt ist sie Teil des Systems. Kein Mensch muss sich daran erinnern.
Das klingt einfach. Ist es nicht.
Das Problem mit Agenten-Erfahrung
Jeder, der ernsthaft mit KI-Agenten arbeitet, kennt das Muster: Du löst ein Problem. Der Agent macht etwas falsch. Du korrigierst ihn. Beim nächsten Durchlauf macht er denselben Fehler wieder.
Das liegt nicht daran, dass das Modell schlecht ist. Es liegt daran, dass der Kontext weg ist. Agenten-Erfahrung verschwindet nach jeder Session. Jeder neue Lauf beginnt bei null.
Das ist der Unterschied zwischen einem System, das lernt, und einem System, das nur ausfĂĽhrt.
Mein Crystallization-Loop ist meine Antwort darauf. Kein Finetuning. Kein Training. Kein Prompt-Engineering im klassischen Sinne. Stattdessen: Fehler werden zu Beobachtungen. Beobachtungen werden zu Regeln. Regeln werden zu Code.
Wie der Crystallization-Loop funktioniert
Die technische Grundstruktur ist ĂĽberraschend schlicht. Es gibt drei Schichten:
Schicht 1: Beobachtung
Nach jedem Agenten-Lauf wird ein structured log geschrieben. Nicht nur Erfolg oder Fehler, sondern was genau passiert ist, an welchem Punkt, mit welchem Kontext.
# Beispiel-Struktur eines Observations-Log
{
"timestamp": "2026-04-12T14:32:00Z",
"agent": "deployment-agent",
"checkpoint": "pre-deploy",
"failure": "db_permissions_unchecked",
"context": {
"target_env": "production",
"tables_accessed": ["users", "sessions"],
"permissions_verified": false
},
"resolution_time_minutes": 20,
"resolution": "manual_permissions_grant"
}
Schicht 2: Regelgenerierung
Ein separater Analyse-Agent läuft täglich. Er schaut sich alle Beobachtungen der letzten 30 Tage an und sucht nach Mustern. Wenn dasselbe Muster dreimal auftaucht, schlägt er eine Regel vor.
# Vereinfachtes Beispiel der Regelgenerierung
def crystallize_observation(observations: list[dict]) -> Rule | None:
pattern = find_recurring_pattern(observations, min_occurrences=3)
if not pattern:
return None
return Rule(
trigger=pattern.trigger_condition,
action=pattern.suggested_check,
confidence=pattern.occurrence_count / len(observations),
source="crystallization_loop",
created_at=datetime.now()
)
Schicht 3: Integration
Akzeptierte Regeln werden als Guard-Hooks in die Agent-Pipeline eingebunden. Kein separates System. Kein optionaler Check. Die Regel feuert automatisch, bevor der Agent die kritische Aktion ausfĂĽhrt.
Das Deployment-Berechtigungs-Beispiel sieht heute so aus:
# .claude/hooks/guards/db_permissions_guard.sh
# Kristallisiert am 2026-04-28 aus 3 Beobachtungen
check_table_permissions() {
local tables=("$@")
for table in "${tables[@]}"; do
if ! psql -c "SELECT has_table_privilege(current_user, '$table', 'SELECT')" \
| grep -q "t"; then
echo "GUARD: Fehlende Berechtigung auf Tabelle $table"
exit 1
fi
done
}
Was in vier Monaten entstanden ist
211 Regeln. 73 Learnings, die kein Mensch formuliert hat.
Das klingt beeindruckend. Ist aber auch das Ergebnis von systematischen Fehlern, die ich nicht vorhersehen konnte.
Ein paar Beispiele aus dem echten Betrieb:
Guard: Keine externen API-Calls ohne Rate-Limit-Check. Entstanden, weil ein Agent in drei Wochen viermal in API-Limits gelaufen ist. Jeweils zehn Minuten Debugging. Die Regel kostet heute zwei Millisekunden pro Lauf.
Guard: Kein File-Write ohne Backup-Pfad-Verifikation. Entstanden aus zwei Vorfällen, bei denen ein Schreibfehler Datei-Inkonsistenzen hinterlassen hat. Die Regel kostet nichts, verhindert aber Inkonsistenzen, die Stunden kosten würden.
Learning: Kontextuelle Fehlermeldungen sind dreimal effizienter als generische. Das war keine Beobachtung aus einem Fehler, sondern aus einem Vergleich: Zwei Agenten, dasselbe Problem, unterschiedliche Fehlermeldungen. Der mit kontextueller Meldung wurde dreimal schneller resolviert.
Das beschreibe ich ausführlich in "Läuft ohne mich", meinem Buch über Agenten-Systeme, die sich selbst organisieren.
Was das System nicht kann
Ehrlichkeit ist hier wichtig. Der Crystallization-Loop hat Grenzen.
Er kristallisiert Erfahrung aus Mustern. Er erkennt keine Einmal-Ereignisse. Ein schwerwiegender Fehler, der nur einmal auftritt, landet in den Logs, aber nicht automatisch in einer Regel. Das erfordert manuellen Eingriff.
Er ist auch kein Ersatz fĂĽr gutes System-Design. Wenn die Grundarchitektur falsch ist, macht der Loop falsche Erfahrungen schneller wiederholbar, nicht besser. Garbage in, garbage out, nur mit mehr Automatisierung.
Und er hat einen blinden Fleck: Regeln, die sich gegenseitig beeinflussen. Mit 211 Guards prĂĽfe ich mittlerweile monatlich manuell auf Konflikte. Noch ist es handhabbar. Bei 500 Regeln werde ich einen Meta-Guard brauchen.
Warum das kein Standardprodukt ist
Microsoft hat kein Ă„quivalent. Google auch nicht. Das liegt nicht an fehlendem Know-how. Es liegt daran, dass diese Art von Erfahrungsspeicherung zutiefst kontextspezifisch ist.
Meine 211 Regeln sind meine Regeln. Sie entstammen meinen Agenten, meinen Fehlern, meinem Stack. Sie auf ein generisches Produkt zu übertragen würde bedeuten, dass jeder Nutzer bei null anfängt, mit einem System, das noch keine Erfahrung hat.
Das ist das grundlegende Problem mit industriellen KI-Plattformen: Sie optimieren fĂĽr den Durchschnitt. Crystallization-Loop optimiert fĂĽr dich.
Ein Deployment-Check, der bei meinen Agenten dreimal aufgetaucht ist, taucht bei dir vielleicht nie auf. DafĂĽr hast du andere Fehler, die du nur einmal machen willst.
Die praktische Frage: Wo anfangen?
Wenn du anfangen willst, dieses Prinzip umzusetzen, ohne ein vollständiges System aufzubauen, gibt es einen einfachen Einstieg:
- Schreib jeden Agent-Fehler in ein strukturiertes Log. Nicht freier Text, sondern maschinenlesbare Felder.
- Lies dieses Log wöchentlich. Suche nach Mustern, nicht nach Einzelvorfällen.
- Schreib die erste Regel manuell, wenn du ein Muster findest.
- Lass den Agenten die Regel beim nächsten Lauf anwenden.
- Erst wenn du zehn manuelle Regeln hast, lohnt sich die Automatisierung des Prozesses.
Der Loop entsteht nicht durch Technologie. Er entsteht durch Disziplin. Die Technologie macht ihn skalierbar.
Wichtigste Erkenntnisse
- Agenten-Erfahrung verschwindet nach jeder Session, es sei denn, du baust aktiv dagegen.
- Drei Wiederholungen eines Fehlers sind das Signal fĂĽr eine Regel, nicht einer.
- Guards als automatisch feuernde Hooks sind robuster als Prompts, die den Agenten bitten, etwas zu prĂĽfen.
- Der Wert des Systems entsteht nicht im ersten Monat, sondern wenn Regel Nummer 50 einen Fehler verhindert, an den du dich längst nicht mehr erinnerst.
- Manuelle Regeln zuerst, Automatisierung danach. Nicht umgekehrt.
- Konflikte zwischen Regeln sind das größte Skalierungsproblem und müssen aktiv gemanagt werden.
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.
