Eigene Content-Produktion.
Keine feste Kapazität.
Kein Skalierungspfad.
Eigener Content, keine feste Redaktion, kein Skalierungspfad.
Wir betreiben selbst mehrere Content-Kanäle — Journal, Social, Case-Material. Nebenbei geschrieben, wenn Zeit war. Saubere Texte, aber unregelmäßig. Ohne feste Kapazität blieb das System hinter dem zurück, was wir eigentlich für unsere Kunden bauen.
Die naheliegende Antwort wäre gewesen, jemanden fest für Content einzustellen. Das Problem dabei: als Studio mit wechselnder Auftragslage lässt sich eine feste Redaktions-Stelle schwer auslasten — und wir wollten testen, ob unser eigenes Angebot bei uns selbst funktioniert.
Fertige „AI Content Tools” hatten wir vorher schon geprüft — das übliche Marketing-Spiel. Output war messbar generisch. Für uns selbst nicht akzeptabel.
Genau hier setzten wir an. Statt einen weiteren ChatGPT-Wrapper zu bauen, mappten wir unseren eigenen Editorial-Prozess auf einer Wand. Daraus wurde klar: es gab einen impliziten Workflow mit drei klar abgegrenzten Schritten — der nirgends dokumentiert war.
Wir bauten nicht ein Tool. Wir bauten ein Team — aus Software.
Statt ein einzelnes Modell mit einem riesigen Prompt zu erschlagen, modellierten wir den existierenden Editorial-Prozess als Multi-Agent. Jeder Agent bekam eine Rolle, einen begrenzten Tool-Zugriff und eigene Eval-Tests. Keiner sieht den ganzen Prozess — nur seinen Ausschnitt.
Der entscheidende Schritt war das Eval-First-Setup. Bevor wir den ersten Agent gebaut haben, definierten wir eigene Test-Cases: Brand-Voice-Tests, Faktentreue-Tests, SEO-Konformitätstests. Jede Code-Änderung läuft seitdem gegen diese Suite.
Erste Iteration des Writer-Agents fiel bei „Brand-Voice: korrekte Anrede” mehrfach durch. Lösung: Style-Guide expliziter formulieren, plus Review-Agent fängt es als Backup. Nach 2 Iterationen: stabil.
Genauso wichtig: Human-in-the-Loop ist kein Feature, das wir hinzugefügt haben. Es war der Designkern. Vor Publish stoppt das System, die Studio-Leitung bekommt eine HITL-UI mit Diff-View, Quellen, Eval-Scores — und entscheidet. Override jederzeit. Reject mit Begründung füttert die Memory der Agenten.
Acht Wochen. Wöchentliche Demo.
Kein Big-Bang.
Acht Wochen, jede Woche ein abgeschlossener Schritt. Erst die Grundlage, dann die Härtung, dann Agent für Agent.
Infrastruktur.
VPS konfiguriert, OpenClaw installiert, Grundgerüst steht.
Security Audit.
Berechtigungen der Agenten begrenzt, Datenflüsse dokumentiert, Zugang gehärtet. Härtung muss sein, bevor etwas produktiv geht.
Erster Agent.
Deployment und Einarbeitung. Rolle definiert, erste Aufgaben übernommen.
Testszenarien.
Erste Projekte mit dem Agenten. Was funktioniert, was nicht, wo braucht es einen Menschen.
Zweiter Agent.
Deployment, eigene Rolle, eigener Aufgabenbereich.
Orchestrierung.
Dritter Agent deployt, Orchestrator-Rolle vergeben. Aus drei Einzelagenten wird ein System.
Live-Systeme.
Anbindung an die ersten produktiven Systeme.
Produktivbetrieb.
Die Agenten bauen und beurteilen die ersten Websites.
Was passiert, wenn ein Studio sein eigenes Werkzeug nutzt?
Das System ging Ende Februar 2026 live. Drei Monate später zogen wir Bilanz — nicht an Sichtbarkeits-Indizes, sondern an dem, was für uns zählt: läuft das System stabil, ohne dass jemand eingreifen muss?
Der Betrieb läuft seit Go-Live durchgehend. Drei Agenten, orchestriert über CLOUDROCKER AI, produzieren fortlaufend Content-Entwürfe. ~20 Cron-Jobs steuern Recherche- und Publish-Zyklen autonom. Jeder Entwurf durchläuft Eval-Checks, bevor er die Studio-Leitung erreicht.
Der Output ist planbar geworden — nicht mehr abhängig davon, ob nebenbei Zeit war. Die Review-Zeit pro Artikel liegt im niedrigen Minutenbereich, nicht mehr bei mehreren Stunden Eigenschreibzeit.
Nicht weniger wichtig: niemand wurde ersetzt. Die Rolle verschob sich vom Schreiben zum Lenken — Brand-Voice-Updates, Themen-Kuratierung, Review der Agenten-Outputs. Kreativere Arbeit, nicht überflüssige.
Was uns überrascht hat. Was wir mitnehmen.
Erstens: der größte Hebel war nicht das Modell, sondern der Style-Guide. Als wir unseren eigenen Brand-Voice-Guide schrieben, fiel auf: den hatten wir selbst nie explizit dokumentiert. Das Aufschreiben hätte schon ohne KI einen Teil der Probleme gelöst.
Zweitens: Eval-First war die wichtigste architektonische Entscheidung. Ohne Test-Cases vor Tag 1 wären wir in „funktioniert auf meiner Maschine”-Modus gerutscht. Stattdessen hatten wir vom ersten Run an objektive Kriterien.
Drittens: Human-in-the-Loop ist nicht Bremse, sondern Beschleuniger. Anfangs waren wir selbst skeptisch — „das kostet ja immer noch Zeit.” In Praxis: wenige Minuten Review statt Stunden Eigenschreibzeit. Plus: jeder Reject schult das System. Memory + Negative-Examples + Style-Guide-Updates.
Was wir anders machen würden: wir haben Memory zu spät eingebaut (Woche 5). Hätten wir’s in Woche 2 geplant, wären die ersten Drafts deutlich stabiler gewesen. Lerneffekt für nächste Projekte: Memory ist kein Add-on, es ist Foundation.
Wir planen ein zweites Multi-Agent-System für technische Dokumentation im eigenen Studio. Selbe Architektur, andere Domain. Die CLOUDROCKER-AI-Memory ist wiederverwendbar.
Das war CLOUDROCKER AI. Seit Februar 2026 im Dauerbetrieb, 3 Agenten, ~20 Cron-Jobs, 24/7. Wir haben kein „KI-Tool” gebaut. Wir haben unserem eigenen Team Werkzeuge gegeben, die ihm seine Arbeit zurückgeben — die kreative, lenkende, entscheidende Arbeit.