Was tatsächlich gebaut wurde
Der Kern war ein lokaler Control-Tower für einen Recherche-bis-Listing-Workflow. Statt nur einzelne Prompts zu testen, gab es eine kleine Bedienoberfläche mit Statusübersicht, Startprüfung, Aufgabenliste und Laufprotokoll. Darüber konnten einzelne Worker kontrolliert gestartet werden: Trend Research, Listing Operator, Winner Feedback Loop, Ops Orchestrator und Autopilot-Chain. Zusätzlich wurden Repair- und Feedback-Schleifen getestet, damit schwache Ergebnisse erkannt, nachgebessert und als Lernsignal für den nächsten Lauf genutzt werden konnten.
- Dashboard-Buttons und Cronjobs starteten definierte Worker und aktualisierten danach Status und Run-Historie.
- Jeder Lauf hatte einen sichtbaren Job-Status, Zeitstempel, Ergebnisstatus und begrenzte Ausgabe statt unkontrollierter Blackbox.
- Self-Healing bedeutete hier: Fehler oder schwache Outputs markieren, Repair-Schritt starten und Ergebnis erneut prüfen.
- Self-Learning bedeutete hier: Feedback aus vorherigen Läufen als bessere Vorgabe für den nächsten Durchlauf nutzen.
- Unbekannte oder nicht freigegebene Workflows wurden gestoppt, statt externe Schritte auszulösen.
Wie der Prozess gedacht war
Der Workflow lief nicht nach dem Motto "Agent macht alles", sondern als Kette aus Vorbereitung, Prüfung und Entscheidung. Research sammelt Signale und Produktideen, Listing bereitet Struktur und Inhalte vor, Winner Feedback bewertet Ergebnisse, der Orchestrator führt den Stand zusammen. Externe Publishing-Schritte blieben an Startprüfung, sichtbare Blocker und menschliche Freigabe gebunden.
- Vor einem Start wurden Voraussetzungen, fehlende Angaben und offene Entscheidungen geprüft.
- Der Orchestrator zeigte Blocker und nächste Schritte, statt den fehlenden Go-Zustand zu überspielen.
- Digitale Listing-Schritte blieben blockiert, solange notwendige Konfiguration und Freigabe fehlten.
Rollen, Status und Qualitätsprüfung
Der stärkste Teil ist die Systemdenke: Rollen, Zuständigkeiten, Status, Fehler und Go/No-Go wurden sichtbar gemacht. Das ist näher an realer AI Operations als eine Autonomie-Story. Zusätzlich gab es einen SEO-Repair-Strang, in dem ein Operator schwächere Seiten identifizierte, reparierte und danach gegen Qualitätskriterien geprüft hat.
- Agenten wurden nicht als freie Magie dargestellt, sondern als Worker mit klarer Aufgabe, Grenze und Prüfpunkt.
- Laufprotokoll, Statusübersicht und Startprüfungen machten sichtbar, ob ein System gerade nutzbar, blockiert oder riskant war.
- Qualitätsreparaturen wurden nicht nur behauptet, sondern erneut geprüft, bevor sie als stabil eingeordnet wurden.