Dein AI Agent lernt nichts aus seinen Runs

Dein Agent macht denselben Fehler. Zum fünften Mal.

Du gibst einem Coding Agent diese Aufgabe:

Add `deliveryStatus` to the order API client.
Update the tests.

Der Agent findet src/generated/order-client.ts, fügt das Feld ein und passt zwei Tests an. Alles grün.

Am nächsten Morgen läuft der Client Generator in CI. Seine Änderung verschwindet.

Der zweite Agent macht exakt dasselbe.

Der dritte auch.

Alle Runs wurden gespeichert. Du hast Traces, Tool Calls, Chat History und drei grüne Abschlussmeldungen.

Trotzdem hat das System nichts gelernt.

Gespeicherte Erfahrung ist noch kein Wissen.

Ein Log sagt, was passiert ist. Ein Knowledge Flywheel muss daraus etwas bauen, das den nächsten Run nachweislich besser macht.

In unserem Beispiel wäre das nicht:

Be careful with generated files.

Sondern:

Files under src/generated/** are outputs.
Change schemas/order-api.yaml, run npm run generate:order-client,
then test both the schema and generated client diff.

Diese Lesson ist konkret. Sie nennt Quelle, Handlung und Proof.

Aber auch sie ist noch nicht automatisch wahr für jedes Projekt.

Memory speichert Vergangenheit. Wissen verändert den nächsten Task.

Viele Agent-Setups nennen schon das Speichern von Chat-Verläufen oder Embeddings „Learning“.

Das ist zu früh.

Vier Dinge, die oft Memory heißen

Artefakt

• Trace: Tool Calls, Dateien, Fehler und Ergebnis eines Runs
• Summary: kurze Interpretation des Runs
• Memory: später wieder abrufbare Information
• Knowledge: belegte, begrenzte und getestete Lesson

Was noch fehlt

• Keine Generalisierung. Er beschreibt nur einen Fall.
• Kann Ursache und Zufall verwechseln.
• Abrufbarkeit beweist weder Wahrheit noch Relevanz.
• Muss weiter versioniert, überwacht und bei Bedarf gelöscht werden.

Die bessere Definition lautet:

Ein Agent-System hat erst gelernt, wenn eine überprüfte Lesson einen neuen Task verbessert, ohne andere Task-Klassen kaputtzumachen.

Das ist ein viel härterer Test als „der Agent hat eine Reflexion geschrieben“.

Eine neue Scaling Dimension

Das Paper Knowledge-Centric Self-Improvement stellt eine gute Frage:

Wenn ein AI-System Erfahrung sammelt: Was soll dauerhaft besser werden?

Die übliche Antwort ist: der Agent.

Man optimiert seinen Prompt, seinen Workflow, den Harness, seine Tools oder sogar seinen eigenen Code. Das kann funktionieren. Es bindet das Learning aber häufig an genau dieses Modell, diesen Agent-Aufbau und diese Task-Verteilung.

Die alternative Antwort ist: Das Wissen bleibt. Die Agents dürfen austauschbar sein.

Im offenen KSI-System bearbeitet jeder Agent einen Task und verschwindet danach wieder. Dauerhaft ist eine gemeinsame Knowledge Base. Agenten liefern lokale Evidence, vergleichen Erkenntnisse über mehrere Tasks, diskutieren Widersprüche und verdichten überlebende Claims für die nächste Generation.

Knowledge-Centric Improvement

der Agent bleibt austauschbar, das geprüfte Wissen wächst

1. 01
   Task ausführen
2. 02
   Evidence sammeln
3. 03
   Runs vergleichen
4. 04
   Widersprüche klären
5. 05
   Knowledge distillen
6. 06
   Nächsten Agent seeden

Die Autoren testen den Ansatz über fünf Benchmarks für Coding, abstraktes Reasoning und Terminal Tasks. Sie berichten bessere Solve-Rate-vs-Cost-Ergebnisse als ausgewählte agent-zentrierte Baselines und positiven Transfer auf neue Tasks und andere Modellfamilien.

Das ist ein starkes Signal. Es ist noch kein Produktionsgesetz. Die Ergebnisse stammen aus kontrollierten Benchmarks, die Held-out Sets sind klein und mehrere Vergleiche beruhen auf einzelnen Baseline-Runs.

Der praktische Wert liegt deshalb weniger in einer maximalen Prozentzahl.

Er liegt in der Architektur:

Disposable agents.
Persistent, inspectable knowledge.

5

Benchmark-Familien im KSI-Projekt

3

Curation-Stufen: lokal, cross-task, Distillation

0

dauerhafte Claims ohne Evidence

Warum ein einzelner Run eine schlechte Lehrerin ist

Nehmen wir unseren generierten API Client.

Nach dem ersten Fehler schreibt ein Agent vielleicht:

Never edit generated files.

Klingt vernünftig.

Dann kommt ein Task, bei dem eine generierte Fixture absichtlich editiert werden muss. Oder das Projekt hat keinen Generator mehr. Oder src/generated enthält neben Outputs auch manuell gepflegte Adapter.

Aus einem lokalen Fehler wurde eine globale Regel.

Genau hier unterscheiden sich Knowledge Flywheels von blindem Self-Improvement.

Trace2Skill analysiert nicht nur eine eingehende Trajectory nach der anderen. Das System betrachtet einen breiteren Pool von Runs parallel, extrahiert lokale Lessons und konsolidiert sie hierarchisch in deklarative Skills. Die Autoren berichten Transfer über Modellgrößen, Modellfamilien und Out-of-Distribution-Tasks.

Agent KB ergänzt einen Disagreement Gate. Abgerufenes Wissen soll die aktuelle Lösung nicht einfach überschreiben. Wenn Task, Framework oder aktueller Plan widersprechen, muss das System den Konflikt behandeln.

Das ist die wichtigste Design-Regel:

Ein Gegenbeispiel ist kein Störgeräusch. Es definiert die Grenze deiner Lesson.

Die kleinste brauchbare Knowledge Card

Du brauchst am Anfang weder ein neues Foundation Model noch einen riesigen Vector Store.

Eine versionierte YAML-Datei reicht, wenn sie die richtigen Fragen beantwortet:

id: generated-order-client-003
type: workflow

claim: >
  Change the order schema, then regenerate the client.
  Do not hand-edit generated client code.

applies_when:
  - path matches src/generated/order-client.ts
  - file header contains "generated from schemas/order-api.yaml"
  - package script generate:order-client exists

do_not_apply_when:
  - task explicitly targets a checked-in fixture
  - generator or source schema no longer exists

evidence:
  supporting_runs: [run-1842, run-1861, run-1904]
  counterexamples: [run-1888]
  source_files: [schemas/order-api.yaml, package.json]

verification:
  - npm run generate:order-client
  - npm test -- order-client
  - git diff --exit-code after a second generator run

confidence: medium
environment: shop-api@4.x
created_at: 2026-08-06
review_after: 2026-09-06
status: active

Die Card speichert nicht nur die Regel.

Sie speichert auch, wann die Regel gilt, wann nicht, woher sie kommt und wie sie falsifiziert werden kann.

Das ist der Unterschied zwischen Wissen und Agent-Aberglaube.

Der Workflow für ein kleines Team

Du musst nicht nach jedem Run ein Agent-Parlament starten. Beginne mit einem Batch am Ende des Tages oder der Woche.

Small-Team Knowledge Flywheel

erst als Vorschlag, dann nach Evals als aktives Wissen

1. 01
   Runs sammeln
2. 02
   Candidates extrahieren
3. 03
   Evidence verlinken
4. 04
   Gegenbeispiele suchen
5. 05
   Evals replayen
6. 06
   Diff reviewen
7. 07
   Versioniert publizieren

1. Runs vollständig erfassen

Speichere nicht nur die letzte Antwort:

task intent
repo and environment version
files read and changed
tool calls and errors
test or verifier output
final outcome
human correction

Ohne Environment-Version kann eine korrekte Lesson nach dem nächsten Release falsch werden.

2. Candidate Lessons extrahieren

Der Agent darf Vorschläge machen:

strategy
workflow
pitfall
falsified hypothesis
open question
executable skill

Er darf sie noch nicht selbst als Wahrheit promoten.

3. Evidence und Counterexamples anhängen

Jede dauerhafte Lesson braucht mindestens einen beobachtbaren Ursprung. Für riskante oder breite Regeln reichen ein oder zwei Runs nicht.

Suche aktiv nach Fällen, in denen die Regel geschadet hätte.

4. Gegen aktuelle Realität testen

Replay alte Fehlerfälle, positive Fälle und ein kleines Held-out Set.

Miss nicht nur Success Rate:

• Löst die Lesson den ursprünglichen Fehler?
• Blockiert sie legitime Lösungen?
• Erhöht sie Cost oder Laufzeit?
• Verändert sie Tool Permissions?
• Funktioniert sie mit einem anderen Modell?

5. Als Diff reviewen

Eine neue Knowledge Card ist eine Verhaltensänderung.

Behandle sie wie Code:

candidate → diff → eval → approval → canary → active

Nicht:

agent reflection → permanent memory

6. Nur passendes Wissen retrieven

Der nächste Agent braucht nicht die gesamte Knowledge Base. Er braucht einen kleinen Bundle, der zu Task, Repository, Tools und aktueller Version passt.

Agent Workflow Memory zeigt den Wert selektiv bereitgestellter Workflows. SkillWeaver geht für Web Agents einen Schritt weiter und destilliert geübte Website-Interaktionen in wiederverwendbare APIs.

Die Richtung ist dieselbe:

Nicht mehr Context.
Besser ausgewähltes, überprüftes Context.

Dein Flywheel kann Fehler schneller skalieren als Erfolge

Das Wort Flywheel klingt automatisch positiv. Ein Schwungrad verstärkt aber alles, was du hineingibst.

ConsistencyGate behandelt Memory deshalb als Write-Time Admission Problem. Eine falsche Information, die früh gespeichert wird, beeinflusst spätere Retrievals und Entscheidungen. Relevance, Novelty und Recency helfen nicht: Eine plausible falsche Aussage kann genauso relevant, neu und frisch sein wie eine wahre.

Das Paper zeigt zugleich die Grenze seines eigenen LLM-basierten Gates: Consistency ist nur ein Proxy für Correctness. Ein Modell kann sich mehrfach einig und trotzdem falsch sein. Bei impliziten Fakten kann eine strenge Prüfung außerdem korrektes Wissen verwerfen.

Memory Contagion liefert die noch unangenehmere Warnung: Bias aus gespeicherten Erfahrungen kann sich über spätere Runs fortpflanzen, selbst wenn die Konsolidierung technisch perfekt arbeitet.

Deshalb braucht dein Flywheel:

Knowledge Quality Gates

• Provenance: Jeder Claim verlinkt auf seinen konkreten Ursprung.
• Scope: Task, Tool, Umgebung und Version sind explizit.
• Counterexamples: Widerspruch bleibt neben dem Claim sichtbar.
• Independent proof: High-impact Rules brauchen Tests, Verifier oder menschliches Review.
• Expiry: Wissen wird nach Zeit oder Environment-Change erneut geprüft.
• Rollback: Jede aktive Version kann schnell zurückgenommen werden.

Wie andere Agents dein Wissen finden

Ein gutes Knowledge Artifact hilft niemandem, wenn es unsichtbar bleibt.

Intern brauchst du einen Katalog, den Agents nach Task, Concept, Tool, Environment und Version durchsuchen können. MCP Resources sind eine mögliche aktive Schnittstelle: Clients können URI-basierte Ressourcen auflisten, filtern oder automatisch als Context auswählen.

Für öffentliches Wissen bleiben die langweiligen Grundlagen wichtig:

• stabile, crawlbare URLs,
• klare Titel und Zusammenfassungen,
• explizite Concepts und Audience,
• direkte Primärquellen,
• Sitemap und interne Links,
• Markdown-nahe Struktur,
• sichtbares updatedAt,
• maschinenlesbare Definitionen und Copy-paste-Workflows.

Eine llms.txt kann zusätzlich einen kompakten Markdown-Index anbieten. Sie ist aber ein Vorschlag, kein garantierter Ranking- oder Discovery-Standard.

Für Agents ist dieser Artikel deshalb nicht nur Fließtext. Die zentrale Aussage ist auch kompakt extrahierbar:

concept: knowledge-flywheel
definition: >
  A lifecycle that converts agent execution evidence into scoped,
  tested, versioned knowledge for future tasks.

minimum_loop:
  - capture traces with environment and verifier results
  - extract typed candidate lessons
  - attach supporting and contradicting evidence
  - replay positive, negative, and held-out evals
  - publish as a versioned, expiring artifact
  - retrieve only task-compatible knowledge
  - measure impact and revise or retire

anti_patterns:
  - treating raw logs as learning
  - promoting one reflection into permanent policy
  - retrieving by similarity without compatibility checks
  - keeping claims without provenance or counterexamples
  - letting the same model write, verify, and approve its lesson

Der Agent ist austauschbar. Sein Wissen nicht.

Knowledge Flywheels

Do

• ✓ Erfahrung in typed, scoped Knowledge Cards verdichten
• ✓ mehrere Runs und Gegenbeispiele gemeinsam analysieren
• ✓ jede Lesson mit Evidence und einem Verifier verbinden
• ✓ Skills und Claims versionieren, testen und wieder löschen
• ✓ Transfer auf neue Tasks und Modelle separat messen

Do not

• × eine volle Trace-Datenbank mit Lernen verwechseln
• × einen erfolgreichen Run zur globalen Regel machen
• × ähnliches Wissen ungeprüft in jeden Context laden
• × LLM-Selbstkonsistenz als Ground Truth behandeln
• × alte Lessons ohne Expiry für immer mitschleppen

Der nächste Scaling-Schritt für Agenten ist nicht nur ein größeres Modell oder ein komplizierterer Harness.

Es ist ein System, das aus hundert Runs nicht hundert Logs macht.

Sondern eine Handvoll überprüfbarer Lessons, die Run 101 wirklich besser machen.