Kritiker-Agenten und Team-Rollen: So werden KI-Ergebnisse wirklich gut

Das Qualitätsproblem von KI-Outputs

KI-Agenten können beeindruckend schnell arbeiten. Aber Geschwindigkeit allein reicht nicht. Wer KI-Outputs ohne Prüfung übernimmt, handelt sich Probleme ein: Halluzinationen, logische Fehler, fehlender Kontext, blinde Flecken.

Die naheliegende Lösung – dem Agenten sagen „prüfe dein eigenes Ergebnis” – funktioniert schlecht. Sprachmodelle neigen dazu, ihre eigenen Outputs zu bestätigen. Selbstkritik ist keine Stärke von LLMs. Sie erkennen Fehler in fremdem Text zuverlässiger als in eigenem.

Die Lösung ist so einfach wie kontraintuitiv: Ein separater Agent, der nur kritisiert.

Das Prinzip: Designer und Kritiker

Das Muster stammt aus der Softwareentwicklung (Code Review), dem Journalismus (Gegenleser) und der Wissenschaft (Peer Review). In jedem dieser Felder gilt: Wer erstellt, ist schlecht darin, die eigenen Fehler zu finden.

Übertragen auf KI-Agenten:

Der Designer-Agent erstellt. Der Kritiker-Agent hat eine andere Perspektive, andere Instruktionen und einen anderen Fokus. Er sucht gezielt nach Schwächen, Lücken und Widersprüchen.

Warum das funktioniert:

• Der Kritiker hat keinen „Ownership Bias” – er hat den Text nicht selbst geschrieben
• Unterschiedliche Prompts erzeugen unterschiedliche Perspektiven
• Die Iterationsschleife erzwingt Verbesserung
• Qualitätskriterien werden explizit geprüft statt implizit erhofft

Der Kritiker-Agent in der Praxis

Aufbau

Ein Kritiker-Agent braucht drei Dinge:

1. Klare Bewertungskriterien – Was genau soll er prüfen?
2. Strukturiertes Feedback-Format – Nicht „das ist schlecht”, sondern konkrete Punkte
3. Begrenzte Iterationen – Sonst dreht sich die Schleife endlos

Beispiel: Code-Review

Kritiker-Agent Instruktion:

Prüfe den folgenden Code auf:
1. Logische Fehler und Edge Cases
2. Sicherheitslücken (SQL Injection, XSS, etc.)
3. Performance-Probleme
4. Lesbarkeit und Wartbarkeit
5. Fehlende Error-Handling-Fälle

Gib für jeden Punkt eine Bewertung (OK / Warnung / Kritisch)
und konkrete Verbesserungsvorschläge.

Der Designer-Agent schreibt den Code. Der Kritiker prüft. Der Designer überarbeitet. Nach 2-3 Runden ist die Qualität deutlich höher als bei einem einzelnen Durchlauf.

Beispiel: Content-Erstellung

Kritiker-Agent Instruktion:

Prüfe den folgenden Artikel auf:
1. Sachliche Richtigkeit der Aussagen
2. Logische Konsistenz der Argumentation
3. Zielgruppenpassung (Entscheider in KMU)
4. Vollständigkeit (fehlen wichtige Aspekte?)
5. Überflüssiges (was kann weg?)

Antworte in diesem Format:
- STÄRKEN: Was gut ist
- SCHWÄCHEN: Was verbessert werden muss
- KONKRETE ÄNDERUNGEN: Nummerierte Liste

Beispiel: Architektur-Entscheidungen

Kritiker-Agent Instruktion:

Analysiere die vorgeschlagene Architektur:
1. Skaliert die Lösung bei 10-facher Last?
2. Welche Single Points of Failure gibt es?
3. Wie hoch ist die Vendor-Abhängigkeit?
4. Was passiert, wenn Komponente X ausfällt?
5. Gibt es einfachere Alternativen?

Bewerte: Risiko (Gering/Mittel/Hoch) + Begründung

Wann sich der Overhead lohnt – und wann nicht

Der Kritiker-Agent kostet zusätzliche Token und Zeit. Zwei bis drei Iterationen verdoppeln den Aufwand. Das lohnt sich nicht für jede Aufgabe.

Kritiker lohnt sich bei:

• Content, der veröffentlicht wird
• Code, der in Produktion geht
• Analysen, auf deren Basis Entscheidungen fallen
• Kommunikation mit Kunden oder Partnern
• Architektur-Entscheidungen mit langfristiger Wirkung

Kritiker lohnt sich nicht bei:

• Internen Notizen und Entwürfe
• Brainstorming und Ideensammlung
• Einmalige Recherchen ohne Weitergabe
• Prototypen und Wegwerf-Code

Faustregel: Wenn der Output von jemand anderem gelesen oder genutzt wird, lohnt sich ein Kritiker.

Vom Einzelkritiker zum Agenten-Team

Der Kritiker ist die wichtigste Rolle – aber nicht die einzige. Für komplexere Aufgaben braucht es ein Team aus spezialisierten Agenten. Vier Rollen decken dabei fast jedes Business-Szenario ab.

Die 4 Rollen, die in fast jedem Business funktionieren

Rolle 1: Recherche-Agent

Aufgabe: Informationen sammeln, strukturieren, bewerten.

Was er tut:

• Durchsucht Quellen (Web, Datenbanken, interne Dokumente)
• Filtert relevante von irrelevanter Information
• Strukturiert Ergebnisse in einem standardisierten Format
• Bewertet die Zuverlässigkeit der Quellen

Typische Einsätze:

• Wettbewerbsanalyse
• Marktrecherche
• Technologie-Evaluation
• Regulatorische Updates

Warum eine eigene Rolle? Recherche braucht Breite. Der Recherche-Agent muss möglichst viele Quellen abdecken, ohne sich in Details zu verlieren. Das ist eine andere Denkweise als Erstellung oder Kritik.

Rolle 2: Erstellungs-Agent (Designer)

Aufgabe: Aus den Recherche-Ergebnissen konkrete Outputs erstellen.

Was er tut:

• Verarbeitet die Recherche-Ergebnisse
• Erstellt den eigentlichen Output (Text, Code, Analyse, Plan)
• Folgt Formatvorgaben und Stilrichtlinien
• Liefert einen vollständigen ersten Entwurf

Typische Einsätze:

• Texte und Reports schreiben
• Code implementieren
• Angebote und Präsentationen erstellen
• Datenanalysen aufbereiten

Warum eine eigene Rolle? Erstellung braucht Fokus und Tiefe. Der Designer-Agent arbeitet konzentriert an einem Output, statt gleichzeitig zu recherchieren und zu prüfen.

Rolle 3: Kritik-Agent

Aufgabe: Outputs prüfen, Schwächen identifizieren, Verbesserungen vorschlagen.

Was er tut:

• Prüft auf sachliche Richtigkeit
• Identifiziert logische Fehler und Lücken
• Bewertet Qualität anhand definierter Kriterien
• Gibt strukturiertes, umsetzbares Feedback

Warum eine eigene Rolle? Wie oben beschrieben: Selbstkritik funktioniert bei LLMs schlecht. Ein separater Kritiker mit eigenen Instruktionen liefert besseres Feedback.

Rolle 4: Integrations-Agent

Aufgabe: Die Ergebnisse der anderen Rollen zusammenführen und das Endergebnis liefern.

Was er tut:

• Führt überarbeitete Outputs zusammen
• Prüft Konsistenz über mehrere Teilaufgaben hinweg
• Formatiert das Endergebnis
• Stellt sicher, dass nichts verloren gegangen ist

Typische Einsätze:

• Mehrteilige Reports zusammenführen
• Code-Module integrieren
• Präsentationen aus verschiedenen Quellen zusammenstellen
• Qualitätssicherung über das Gesamtergebnis

Warum eine eigene Rolle? Einzelne Agenten optimieren ihren Teil. Niemand achtet auf das Gesamtbild – es sei denn, es gibt eine Rolle dafür.

Wie die 4 Rollen zusammenarbeiten

Die Iteration zwischen Designer und Kritiker läuft 2-3 Mal. Der Integrations-Agent greift am Ende ein, wenn mehrere Teilaufgaben zu einem Gesamtergebnis werden.

Konkretes Szenario: Wöchentlicher Marktbericht

1. Recherche-Agent sammelt Neuigkeiten aus 20 Quellen, filtert nach Relevanz, strukturiert nach Themen
2. Erstellungs-Agent schreibt pro Thema eine Zusammenfassung mit Einordnung
3. Kritik-Agent prüft auf sachliche Fehler, fehlende Perspektiven, Redundanzen
4. Erstellungs-Agent überarbeitet auf Basis des Feedbacks
5. Integrations-Agent erstellt den finalen Bericht mit Executive Summary, Inhaltsverzeichnis und Handlungsempfehlungen

Manueller Aufwand: 30 Minuten Qualitätskontrolle statt 6 Stunden Erstellung.

Konkretes Szenario: Feature-Entwicklung

1. Recherche-Agent analysiert das bestehende Codebase und relevante Patterns
2. Erstellungs-Agent implementiert das Feature
3. Kritik-Agent reviewt Code, prüft Edge Cases, identifiziert Sicherheitslücken
4. Erstellungs-Agent fixt die gefundenen Issues
5. Integrations-Agent prüft, ob das Feature sauber in die bestehende Architektur passt

Kommunikation zwischen Agenten

Agenten-Teams funktionieren nur, wenn die Übergaben klar sind. Das heißt: Strukturierte Formate statt Freitext.

Recherche → Erstellung:

## Recherche-Ergebnis
- Thema: [...]
- Quellen: [nummerierte Liste]
- Kernaussagen: [3-5 Punkte]
- Widersprüche: [falls vorhanden]
- Datenlücken: [was nicht gefunden wurde]

Kritik → Erstellung:

## Review-Feedback
- Gesamtbewertung: [1-5]
- Stärken: [...]
- Kritische Punkte: [nummeriert, priorisiert]
- Konkrete Änderungen: [was genau wo ändern]
- Offene Fragen: [was unklar ist]

Je strukturierter die Übergabe, desto besser das Ergebnis. Freitext-Feedback führt zu Interpretationsspielraum – und damit zu Qualitätsverlust.

Wie viele Iterationen sind sinnvoll?

Zwei bis drei Runden zwischen Designer und Kritiker sind in den meisten Fällen optimal.

• Runde 1: Grundlegende Fehler und Lücken werden behoben
• Runde 2: Feinschliff und Edge Cases
• Runde 3: Nur wenn Runde 2 noch signifikante Probleme zeigt

Ab Runde 4 sinkt der Grenznutzen stark. Der Kritiker findet dann vor allem Stilfragen und Marginalien, die den Output nicht wesentlich verbessern.

Abbruchkriterium: Wenn der Kritiker in einer Runde nur noch Punkte mit Bewertung „Gering” findet, ist der Output fertig.

Im nächsten Teil geht es um die technische Seite: Was muss Software können, damit Agenten sie überhaupt nutzen können? Spoiler: Schöne Oberflächen reichen nicht.