Ausgewählte Arbeit · Featured Case
Die gruenig.com Content-Pipeline.
Ein reales, einsehbares Beispiel dafür, wie ein inhabergeführtes angewandtes KI-System aussieht, wenn es so gebaut wird, wie ich es für Kunden baue — versionierte Prompts, explizite Quality Gates, ein Staging-Verzeichnis und ein übergabereifer operativer Vertrag.
- —Gegenstand: die redaktionelle Pipeline hinter dieser Website selbst.
- —Überprüfbar: jedes unten referenzierte Artefakt existiert als Datei im Repository.
- —Gewählt, weil kein NDA besteht — nichts muss redigiert werden, um es ehrlich zu erzählen.
// Engagement-Form
- Kunde
- G|AI Works — intern (diese Website)
- Rolle
- Alleiniger Inhaber, Betreiber und Entwickler
- Status
- Live im Produktivbetrieb
- Offenlegung
- Vollständig im Repository einsehbar
- Grenzen
- Kein NDA; keine Kundendaten involviert
Kontext
Ein Studio, das Aussagen publiziert, muss die Systeme, die es empfiehlt, selbst betreiben können.
G|AI Works publiziert technische Inhalte über sechs Applied-AI-Pillars in zwei Sprachen. Eine solche Website ist ein laufender Prüfstand für die eigene Disziplin: Lässt sich der Stack nicht sauber von einer Person betreiben, ist das Versprechen gegenüber Kunden rhetorisch.
Das Ausgangsproblem war konkret. Drafting mit einem einzelnen langen Prompt lieferte Output, der flüssig klang, aber driftete — vereinzelte unbelegte Statistiken, inkonsistente SEO-Struktur, sicherheitsrelevante Details, die in sonst unkritische Artikel sickerten, und Abweichungen zwischen EN- und DE-Varianten, die eigentlich identische Bedeutung tragen sollten.
Eine Content-Operation, der man auf Artikel-Ebene nicht trauen kann, lässt sich nicht auf viele Artikel skalieren. Die Korrektur musste aus der Pipeline kommen, nicht aus nachträglicher Redaktion.
Intervention
Vier Entscheidungen, die das System geprägt haben.
-
Ad-hoc-Drafting ersetzt durch eine rollengetrennte Pipeline.
Schreiben, Faktenprüfung, SEO, Security-Review und redaktionelles Gating werden zu eigenständigen Agenten mit versionierten Prompts und expliziten Übergaben. Keine Abkürzung über einen einzelnen "Schreib mir einen Artikel"-Call.
-
Jeder Entwurf durchläuft vier harte Gates vor der Veröffentlichung.
SEO, Security, Sources, Clarity. Jedes Gate hat konkrete Pass-Kriterien, festgehalten im Runbook. Ein einziges Fail blockiert die Publikation.
-
Entwürfe laufen durch eine Staging-Collection, nie direkt in die Live-Site.
Ein _incoming/-Content-Verzeichnis hält jeden Entwurf mit draft: true. Nur der Lead Editor darf Dateien herausbewegen. Sitemap und Routing ignorieren _incoming/.
-
EN und DE werden als ausgerichtete Varianten mit identischer Bedeutung geführt.
EN wird zuerst verfasst. Die DE-Variante entsteht im gleichen Batch, wird separat gegated, und bei nachträglicher EN-Revision erneut auf Bedeutungskonsistenz geprüft.
Was gebaut wurde
Sechs konkrete Artefakte, jedes im Repo überprüfbar.
Jedes Item nennt den Ort im Repository, an dem das Artefakt liegt. Das ist bewusst gesetzt: der Wert einer Case Study ist proportional dazu, wie viel davon der Leser nachprüfen kann.
// Artefakte
- 01
Neun-Agenten-Roster
prompts/agents/ · 9 Dateien
Trend Scout, Tech Writer, Marketing Strategist, Finance Specialist, Engineering Specialist, SEO Architect, Fact & Source Checker, Security Reviewer, Lead Editor — jeder als eigenständiger Prompt mit zugewiesenem Modell (Sonnet für Spezialisten, Opus für den Editor).
- 02
Vier Quality Gates
docs/content-system/runbook.md · §4
Gate 1 SEO, Gate 2 Security, Gate 3 Sources, Gate 4 Clarity. Jedes Gate benennt einen Owner, eine Checkliste und eine Fehler-Aktion. Ziel-Erstdurchlaufquoten werden getrackt.
- 03
Staging-Verzeichnis + Routing-Regeln
app/src/content/_incoming/
Alle Entwürfe landen hier mit draft: true. Bei PASS verschiebt der Lead Editor die Datei nach blog/news/guides/case-studies und setzt draft: false. Bei FAIL kehrt die Revision als -v2 zurück.
- 04
Zweisprachige Content-Collections
app/src/content/*.md und *.de.md
Pillars (6), Use-Cases, Posts — jeder Eintrag in EN und DE. Astro 5 ID-Normalisierung entfernt Punkte aus Dateinamen; die Templates leiten die Slugs entsprechend ab.
- 05
Publishing-Substrat
Astro 5 · Tailwind · Static Output
Statische Builds mit hreflang-Alternaten, Canonical URLs, JSON-LD für Organization und WebSite sowie Sitemap-Generierung, die Staging-Content ausschliesst.
- 06
Redaktionelle Dokumentation
docs/content-system/ · 4 Dateien
content-cadence.md, content-schema.md, editorial-guidelines.md, runbook.md. Das Runbook ist der operative Vertrag, an den die Agenten gebunden sind.
Delivery & Safeguards
Wie das System betrieben wird — nicht nur gebaut.
-
Versionierte Prompts unter Review.
Jeder Agent-Prompt liegt als Datei in prompts/agents/ und verändert sich mit der Repo-Historie. Das zugewiesene Modell steht als Suffix im Dateinamen (_opus / _sonnet).
-
Expliziter Revisions-Loop.
Entwürfe, die ein Gate nicht bestehen, kommen als -v2, -v3 in _incoming/ zurück. Eine Obergrenze von drei Revisionszyklen ist definiert, bevor zur menschlichen Review eskaliert wird.
-
Safe-Default-Sicherheitshaltung.
Das Security-Gate blockiert Schritt-für-Schritt-Exploit-Reproduktion, waffenfähige PoCs, echte Credentials und nicht offengelegte Schwachstellen. Platzhalter-Credentials und gehärtete Defaults sind die Regel.
-
Quellen-Policy mit messbarer Integrität.
Trend- und Analyse-Artikel verlangen 3–6 Quellen, Tier-1- oder Tier-2-Glaubwürdigkeit, innerhalb von 24 Monaten, in fixem Zitationsformat. Fabrizierte URLs fallen direkt durchs Gate.
Ergebnis
Zuverlässigkeit als Produkt — nicht Durchsatz.
Der Fall beansprucht keinen Traffic-Lift oder eine Kostenersparnis. Er beansprucht eine operative Eigenschaft: das Content-System ist für einen Inhaber lesbar und verhält sich unter Revision vorhersehbar.
- ✓ Art des Ergebnisses: operative Zuverlässigkeit eines kleinen, aber realen Multi-Agenten-Systems.
- ✓ Jede öffentliche Seite dieser Website entstand in dieser Pipeline — oder ist eine bewusste Ausnahme, die daneben dokumentiert ist.
- ✓ Änderungs-Latenz ist messbar: EN → DE Verzug-Ziel ≤ 2 Tage; Brief → Veröffentlichung ≤ 5 Arbeitstage.
- ✓ Das System ist durch einen einzelnen Inhaber betreibbar, weil die Verträge zwischen den Rollen explizit sind — nicht implizit.
Grenzen
Was dieser Fall nicht ist.
Die Grenzen zu benennen, ist Teil des Falls. Der Leser soll genau wissen, welche Schlüsse dieses Beispiel trägt und wo das Material aufhört.
- — Keine Kundendaten, keine Client-Systeme, keine Integration in Dritt-Infrastruktur sind in diesem Fall involviert.
- — Traffic-, Engagement- und Conversion-Zahlen werden auf dieser Seite nicht offengelegt — der Fall handelt von Architektur und Delivery-Disziplin, nicht von Marketing-Performance.
- — Interne Kosten- und Token-Spend-Zahlen werden nicht offengelegt. Sie informieren das Budget für Kunden-Engagements; sie werden hier nicht als Claim-Material verwendet.
- — Dies ist ein gearbeiteter Beispielfall. Er ersetzt keinen benannten Kundenfall — solche existieren unter NDA und sind auf Anfrage verfügbar.
Stack & Artefakte
Die konkrete Oberfläche.
// Publishing
- Astro 5
- Tailwind CSS
- Static Output
- JSON-LD
- Hreflang
// Content-System
- 9 versionierte Agent-Prompts
- 4 Quality Gates
- _incoming/ Staging
- Zweisprachige Collections
// Modelle
- Claude Opus (Editor)
- Claude Sonnet (Spezialisten)
// Artefakte
- docs/content-system/runbook.md
- prompts/agents/
- app/src/content/_incoming/README.md
Nächster Schritt
Ein System dieser Art — angewendet auf eure Inhalte, Daten oder Workflows.
Das architektonische Muster oben — Rollentrennung, versionierte Prompts, explizite Quality Gates, staged Publication — ist dasselbe, das ich auf Kunden-Engagements anwende. Anderer Gegenstand, gleiche operative Disziplin.