In der AI-Szene endet fast jeder Demo-Lauf mit dem Satz „fertig“. In echten Umsatzprozessen beginnt genau dort das Risiko: unvollständige Recherche, weiche Priorisierung, falscher Ton in der Kundenmail, ein Call-Skript, das die Kriterien verfehlt. Workbase baut deshalb nicht auf Hoffnung, sondern auf Architektur: Nach jedem Task Run greifen zusätzliche Agenten-Schichten, bevor Arbeit als erledigt gilt.
Dieser Text zerlegt den Review-Agent und den Improvement-Loop so, dass Tech- und Ops-Entscheider die Mechanik bewerten können, ohne Marketingnebel.
Das Problem mit Single-Agent-Ausführung
Ein Worker-Agent bekommt einen Auftrag, zum Beispiel:
Recherchiere und strukturiere 1.000 Leads nach ICP, Intent und nächstem Schritt.
Er hat Knowledge, Tools, CRM-Context. Er versucht selbst zu prüfen. Trotzdem passiert typischer AI-Drift:
- Kriterien werden weich interpretiert
- Teilergebnisse wirken „vollständig“
- Unsicherheit wird als Fakt formuliert
- Effizienz leidet (zu viele Schritte, falsche Tool-Reihenfolge)
Menschen finden solche Fehler teuer: in der Inbox, im Call, im verlorenen Deal. Ein zweiter, spezialisierter Prüfer ist deshalb keine Spielerei. Er ist Produktionsqualität.
Schicht 1: Worker-Agent
Der Worker erledigt den Task. Rolle, Ziel, Daten, Kanäle, Done-Kriterien. In Workbase sitzt er im Workspace-Context: CRM, Inbox, Knowledge, Tasks, Automations, je nach Setup.
Wichtig: Der Worker ist nicht „das ganze System“. Er ist der Ausführende.
Schicht 2: Review-Agent (automatisch nach jedem Run)
Nach dem Lauf startet automatisch ein separater Review-Agent. Seine Aufgabe ist eng und hart:
- Was war der Task?
- Was liegt als Ergebnis vor?
- Match: ja oder nein?
Bei Nein
- zurück an den Worker
- Nacharbeit / Retry
- der fehlerhafte Zwischenstand bleibt oft außerhalb deiner Aufmerksamkeit
Bei Ja
- Ergebnis geht weiter in den Freigabe-Pfad
- Human Approve oder Auto-Approve nach Regel
Das ist der „fast keine sichtbaren Fehler“-Effekt, den Teams spüren: nicht weil AI perfekt ist, sondern weil Murks in der Schleife stirbt, bevor er Manager oder Kunde erreicht.
Was der Review-Agent wirklich prüft (praktisch)
Je nach Task-Typ unterschiedlich, logisch immer gleich:
| Task-Typ | Review-Fokus |
|---|---|
| Lead-Recherche | Vollständigkeit, Felder, ICP-Fit, Quellenlogik |
| Priorisierung | Ranking-Kriterien vs. Output-Reihenfolge |
| Mail-/Follow-up-Entwurf | Context aus CRM/Call, Tonalität, verbotene Claims |
| Call-Vorbereitung | Ziel, nächster Schritt, fehlende Pflichtinfos |
| Report | Struktur, KPIs, Widersprüche |
Der Review-Agent ist damit näher an QA als an kreativem Co-Author.
Schicht 3: Improvement-Agent (nach erfolgreichem Durchlauf)
Wenn der Task die Qualitätsgate passiert hat, kommt der Improvement-Agent. Er bewertet nicht nur das Ergebnis, sondern den Arbeitsweg:
- War der Worker effizient?
- Wo ist er hängen geblieben?
- Welche Tool-Lücke kostet Schritte?
- Welche Instruction war zu vage oder zu eng?
- Welche Permission fehlte?
Output an Menschen / Manager, zum Beispiel:
- „Gib diesem Agenten Tool X dauerhaft.“
- „Schärfe den Prompt um Kriterium Y.“
- „Ergänze Knowledge-Doc Z (Einwandliste).“
- „CRM-Feld-Zugriff freischalten.“
Das ist der Unterschied zu reinem Output-QA: das System lernt Betriebsverbesserungen, nicht nur ein einzelnes Dokument wird korrigiert.
Warum die Reihenfolge zählt
Manche bauen zuerst „Agent verbessern“ und hoffen auf weniger Fehler. Workbase-Logik ist strenger:
- erst Ergebnis schützen (Review/Retry)
- dann System verbessern (Improvement)
- dann optional Auto-Approve ausweiten, wenn stabil
Ohne Review optimierst du im Blindflug. Mit Review darfst du Automations aggressiver fahren, weil das Sicherheitsnetz trägt.
Einbettung in Channel, Tasks und Automations
Der Loop lebt nicht isoliert:
- Im Channel planst du mit dem Agenten („starte 500 Research-Tasks“).
- Tasks laufen in der Breite.
- Automations triggern Worker (Event/Schedule).
- Jeder Run bekommt Review.
- Improvement speist Prompt, Tools, Knowledge, Permissions.
So wird aus Chat nicht nur Gespräch, sondern ein geschlossener Produktionskreislauf.
Abgrenzung zu „der Agent reviewed sich selbst“
Self-check im selben Modell-Lauf hilft. Es ersetzt keinen zweiten Agenten mit Prüfer-Rolle:
- andere Instruction
- andere Anreize (Match vs. „fertig wirken“)
- separate Fehlerklasse
Wer ernsthaft skaliert, trennt Execution und QA. Workbase macht genau diese Trennung zum Default nach dem Task Run.
Für wen dieser Loop den Kauf entscheidet
Besonders wertvoll, wenn:
- Outputs Kunden oder CRM berühren
- Volumen hoch ist (hunderte Tasks)
- mehrere Agenten-Rollen parallel laufen
- Compliance und Marken-Ton zählen
Weniger spürbar, wenn:
- du nur gelegentlich einen Prompt testest
- niemand Improvement-Vorschläge umsetzt
- Tasks keine klaren Done-Kriterien haben
Auch der beste Review-Agent scheitert an unklaren Aufträgen. Klarheit im Task Brief bleibt Pflicht.
Fazit
Der unterschätzte Kern von Workbase ist nicht „wir haben Agents“. Es ist der geschlossene Lauf: Worker liefert, Review prüft und schickt bei Bedarf zurück, Improvement macht den nächsten Lauf besser, Mensch oder Regel gibt final frei. Genau deshalb kann man im Channel mutig planen und in der Breite starten, ohne jede Zeile selbst zu QA-en.
Mehr zum Gesamt-Workspace: Workbase Review- und Agenten-Workspace.
Gastbeitrag für techkrafts.de. Mechanikbeschreibung aus Produktlogik/Positionierung; Implementierungsdetails können je Release variieren.
