Es gibt einen Moment, in dem man merkt, dass man sich selbst belügt.
Meiner war ein WordPress-Update an einem Freitagabend. Wieder ein Plugin-Konflikt. Wieder ein halber Tag für etwas, das nichts bringt. Ich berate Unternehmen darin, wie sie mit Microsoft 365, SharePoint und KI effizienter werden – aber meine eigene Website war ein 2015er Flickenteppich.
Also habe ich einen Schnitt gemacht. Und dabei etwas ausprobiert, das ich seitdem nicht mehr missen möchte: Die Website wird nicht mehr von mir allein gebaut. Sie wird von KI-Agents gebaut – und ich bin der Auftraggeber.
Was WordPress nicht mehr konnte
Ich sage das ohne Drama: WordPress hat seine Zeit. Aber für das, was ich brauche, ist es das falsche Werkzeug.
Das konkrete Problem:
- Jedes Update war ein Risiko. Welches Plugin bricht diesmal?
- Die Seite war langsam. Google sieht das. Besucher auch.
- Content-Workflow? Manuell. Jeder Post ein Kampf mit dem Editor.
- KI-Integration? Unmöglich ohne massiven Umbau.
Ich wollte keine CMS-Therapie. Ich wollte etwas, das zu meiner Arbeitsweise passt – und zu dem, wie ich Kunden in Sachen KI und Automatisierung berate.
Der neue Stack: Astro + Azure Static Web Apps
Die Entscheidung fiel auf Astro als Frontend-Framework und Azure Static Web Apps (SWA) für das Deployment.
Warum Astro?
- Statisches Rendering by default: Die Seite lädt in Millisekunden
- “Islands Architecture”: Interaktive Komponenten nur dort, wo sie gebraucht werden – kein JavaScript-Bloat
- Entwicklerfreundlich: Markdown für Content, Tailwind für Styling, saubere Struktur
Warum Azure SWA?
- Nahtlose Integration in das Microsoft-Ökosystem, das ich täglich für Kunden einsetze
- Automatische Preview-Deployments für jeden Pull Request – ich sehe Änderungen, bevor sie live gehen
- Kosteneffizient: Für eine Unternehmenswebsite dieser Größe nahezu kostenlos
Das Ergebnis ist eine Website, die nicht nur schnell ist – sondern auch vollständig automatisiert deployed wird. Jedes Mal, wenn Code in GitHub landet, läuft GitHub Actions und Azure macht den Rest.
Die eigentliche Innovation: Spezialisierte KI-Agents
Hier wird es interessant.
Die Website wird nicht von einem Entwickler gebaut. Sie wird von KI-Agents gebaut – jeder mit einer klaren Rolle, jeder mit seinen eigenen Werkzeugen.
Ich nutze dafür OpenClaw, ein Framework für AI Agents, das auf meinem eigenen System läuft. Die Agents kommunizieren mit mir über Slack – genau wie ein Team aus echten Mitarbeitern.
Der Content-Agent
Zuständig für alles, was mit Inhalten zu tun hat: Blog-Artikel (wie dieser hier), LinkedIn-Posts, Redaktionspläne, Beitragsbilder. Er kennt den Brand Voice, die Zielgruppe und die SEO-Anforderungen.
Wenn ich ihm sage: „Schreib einen Artikel über unsere WordPress-Migration” – dann erstellt er ein Briefing, recherchiert den Kontext, schreibt den Entwurf und koordiniert mit dem Entwickler-Agent, damit der Artikel auch wirklich auf der Website landet.
Der Entwickler-Agent
Er baut und deployed. Er öffnet Pull Requests in GitHub, reviewed Code, merged Branches und sorgt dafür, dass nichts bricht. Er hat keinen Zugriff auf Content-Erstellung – das ist die Domäne des Content-Agents. Diese klare Rollentrennung ist kein Zufall.
Wenn der Content-Agent einen Artikel fertiggestellt hat, übergibt er ihn an den Entwickler-Agent: Branch erstellen, Datei anlegen, PR öffnen, auf Review warten.
Der Marketing-Agent
Er ist die Klammer. Er koordiniert zwischen Content und Kampagnen, denkt in Funnels und KPIs, und sorgt dafür, dass ein Artikel nicht nur geschrieben, sondern auch ausgespielt wird.
Der Workflow: Von Slack bis Live
Das Schöne an diesem Setup ist seine Klarheit. Der gesamte Prozess folgt einer einfachen Pipeline:
Gerrit schreibt eine Anfrage"] --> B["🤖 OpenClaw
Aktiviert den richtigen Agent"] B --> C1["📝 Content-Agent"] B --> C2["⚙️ Entwickler-Agent"] B --> C3["📣 Marketing-Agent"] C1 --> D["📋 Azure DevOps
Work Item erstellt & getrackt"] C2 --> D C3 --> D D --> E["🔀 GitHub
Branch · Commit · Pull Request"] E --> F["⚡ GitHub Actions
Automatischer Build"] F --> G["☁️ Azure Static Web Apps
Deploy auf walther-it-consulting.de"] style A fill:#1b3a50,color:#c4965a,stroke:#c4965a style B fill:#1b3a50,color:#c4965a,stroke:#c4965a style C1 fill:#1b3a50,color:#ffffff,stroke:#c4965a style C2 fill:#1b3a50,color:#ffffff,stroke:#c4965a style C3 fill:#1b3a50,color:#ffffff,stroke:#c4965a style D fill:#1b3a50,color:#ffffff,stroke:#c4965a style E fill:#1b3a50,color:#ffffff,stroke:#c4965a style F fill:#1b3a50,color:#ffffff,stroke:#c4965a style G fill:#c4965a,color:#1b3a50,stroke:#1b3a50
Ich muss nicht wissen, welcher Branch gerade aktiv ist. Ich muss keine Deployment-Scripts kennen. Ich schreibe in Slack, was ich brauche – und das System macht den Rest.
Ein konkretes Beispiel
Letzte Woche: Ich wollte Kunden-Logos auf der Website einbinden.
- Ich schreibe in Slack: „Bitte Kunden-Logos auf der Startseite einbinden”
- Der Content-Agent recherchiert, welche Logos vorhanden sind, und skizziert den Plan
- Der Entwickler-Agent erstellt einen Feature-Branch, baut die Komponente, öffnet einen Pull Request
- Azure SWA erstellt automatisch eine Preview-URL – ich sehe das Ergebnis im Browser
- Ich gebe grünes Licht in Slack: „Approved”
- PR wird gemergt, Azure deployed auf Production
Vom ersten Slack-Nachrichten bis zum Live-Deploy: keine manuelle Arbeit meinerseits.
Was mich dabei am meisten überrascht hat
Ich bin kein blauäugiger KI-Enthusiast. Ich weiß, wo die Grenzen liegen. Aber zwei Dinge haben mich wirklich überrascht:
1. Die Qualitätskontrolle funktioniert durch das System, nicht trotz ihm.
Weil jede Änderung als Pull Request landet, habe ich immer einen Review-Schritt. Ich sehe genau, was sich ändert. Das ist ehrlich gesagt besser als manches menschliche Entwicklerteam, das ich kenne.
2. Die Agents machen Fehler – aber sie dokumentieren sie.
Wenn der Entwickler-Agent einen Build bricht, steht das in ADO. Wenn der Content-Agent einen Artikel schreibt, der noch nicht freigegeben ist, bleibt er im Draft-Status. Das System ist so gebaut, dass ich immer das letzte Wort habe. Kein Agent veröffentlicht etwas ohne meine explizite Freigabe.
Was bedeutet das für andere Unternehmen?
Das hier ist kein Einzelfall. Es ist ein Proof of Concept – und zwar unser eigener.
Wenn wir bei Kunden über KI-Integration in Prozesse sprechen, meinen wir genau das: Nicht KI als Spielzeug, sondern KI als strukturierter Workflow. Spezialisierte Agents mit klaren Rollen, definiertem Scope und menschlicher Freigabe an den richtigen Stellen.
Das lässt sich auf viele Unternehmensprozesse übertragen:
- Content-Erstellung und Freigabe-Workflows
- Automatisierte Entwicklungs-Pipelines
- Interne Wissensdatenbanken, die sich selbst aktualisieren
- Kunden-Kommunikation mit KI im Hintergrund
Der Unterschied zwischen Unternehmen, die von KI reden, und denen, die sie nutzen, ist meistens nicht die Technologie – es ist der Mut, damit anzufangen.
Nächste Schritte
Diese Website ist noch nicht fertig. Sie wird es auch nie ganz sein – weil sich Inhalte, Zielgruppen und Technologien weiterentwickeln. Aber das ist jetzt kein Problem mehr. Das System wächst mit.
Wenn Sie wissen möchten, wie so ein Workflow in Ihrem Unternehmen aussehen könnte, sprechen wir gerne darüber.
Dieser Artikel wurde von einem KI Content-Agent erstellt und von Gerrit Walther reviewt und freigegeben.