Ein Live-Kern mit zwei Agenten und ein gehostetes Agency OS schaffen die zentrale Oberfläche für ein größeres, arbeitsbereichsübergreifendes Fachteam.

Full Stack Agency brauchte eine gemeinsame Betriebsoberfläche über viele Orte hinweg, an denen Arbeit bereits stattfand. Die Lösung war nicht, jeden Kunden in denselben Chat zu verschieben. Atlas erhielt eine zentrale Sicht, während Arbeitsbereichs- und Abteilungsgrenzen bestehen blieben.

Belegstand bei Veröffentlichung: Agency OS, Caddy, Deployment-Webhook und OCW Bridge wurden am 30. Mai 2026 als aktiv verifiziert. Zwei Agenten – Atlas und ein Licensing-Agent – liefen live mit 54 Anbindungen. Die breitere Architektur für Copy, Data, Strategy, Operations, Finance, PA und Customer blieb für weitere Verkabelung vorbereitet.

Das Unternehmen

Louis Appert führt Full Stack Agency. Die Betriebsoberfläche reicht über Discord, mehrere interne und kundenseitige Slack-Workspaces, Strategie, Copywriting, Daten, Operations, Finanzen, persönliche Assistenz, Kundensupport und ein separates Dashboard-Repository.

Diese Struktur ist für eine Agentur mit echten Kundenkonten normal: Kunden behalten ihre Kommunikationsräume, während interne Entscheidungen und Produktarbeit anderswo stattfinden. Die Koordinationslast entsteht zwischen diesen Oberflächen.

Der Engpass

Kundenkontext lag in Slack-Workspaces. Agenturstrategie lebte in anderen Kanälen. Dashboard- und Produktarbeit befanden sich in einem Repository mit eigenem Deployment-Zyklus. Ohne gemeinsame Betriebsschicht musste Louis oder ein anderer Operator Kontext zwischen den Bereichen tragen und den zuständigen Spezialisten wählen.

Die architektonische Ambition war größer als die verifizierte Live-Laufzeitumgebung. Jeden geplanten Spezialisten als live darzustellen, hätte die nützliche Wahrheit verdeckt: Kerndienste und zwei Agenten waren aktiv, während ein Großteil der Abteilungs- und Kundenkanal-Topologie für die nächste Verbindungsstufe konfiguriert war.

Warum die vorhandenen Tools nicht ausreichten

Slack, Discord, GitHub, Kie.ai und Loom deckten jeweils einen Teil der Arbeit ab. Keines schuf ein agenturweites Betriebsmodell oder machte den Systemstatus an einem Ort sichtbar. Ein allgemeiner Assistent in jedem Workspace hätte Kontext dupliziert und Berechtigungen schwerer kontrollierbar gemacht.

Die fehlende Schicht brauchte einen zentralen Agenten, eine gehostete Ansicht, kontrollierte Workspace-Anbindungen und einen Deployment-Weg, der Oberfläche und zugrunde liegendes System synchron hält.

Transformationskarte

Vorher

Kunden-Slack-Räume | Discord | Transkripte | Kreativtools | Dashboard-Repository → Louis gleicht Kontext ab → Abteilung handelt

Nachher – Live-Kern, breitere anbieterbereite Topologie

Gebundene Workspace-Anfrage → Atlas/Live-Agent → erlaubter Kontext oder Tool → Sichtbarkeit im Agency OS → menschliche Prüfung → workspace-spezifische Ausgabe

Vorbereitete Fachbereiche können aktiviert werden, ohne Konfiguration als abgeschlossene Kundenarbeit auszugeben.

Ein Ablauf von Anfang bis Ende

Dieser Ablauf beschreibt den geplanten arbeitsbereichsübergreifenden Weg und hält die Anbieterbereitschaft ausdrücklich sichtbar.

1. Eingang: Eine erlaubte Anfrage geht in einem internen oder kundenseitigen Slack-Kanal mit konfiguriertem Socket-Mode-Konto und Anbindung ein.
2. Workspace-Auflösung: Die Kanalzuordnung bestimmt Kundenkontext und vorgesehenen Agentenbereich.
3. Routing: Atlas koordiniert zentral oder weist die Anfrage der vorbereiteten Verantwortung für Copy, Data, Strategy, Operations, CFO, PA oder Customer zu.
4. Kontext: Wo die erforderliche Quelle verfügbar ist, kann das System installiertes gbrain-Wissen oder Loom-Transkriptionswerkzeuge nutzen.
5. Produktion: Der aktive Agent bereitet Analyse, operatives Artefakt oder Kreativanfrage über erlaubte Tools vor.
6. Kontrolle: Folgenreiche kundenorientierte Arbeit wird von einem Menschen geprüft; ein noch nicht verkabelter Bereich stoppt an seiner Anbieter- oder Kanalabhängigkeit.
7. Sichtbarkeit: Agency OS zeigt den Betriebsstatus; GitHub-Push-Webhooks bauen das gehostete Dashboard nach Codeänderungen neu und starten es neu.

Was sich verändert hat

• Gebaut: Atlas als primärer Agentur-Operator, ein Licensing-Agent, ein gehostetes Agency OS und ein breiteres Abteilungsmodell für Copywriting, Data, Strategy, Operations, CFO, PA und Customer Support.
• Verbunden: Discord, Live-Dashboard, Caddy, Deployment-Webhook und OCW Bridge waren aktiv; Slack-Socket-Mode-Konten wurden über interne und kundenseitige Workspaces konfiguriert.
• Getestet: Dashboard-Deployment, webhook-ausgelöster Rebuild/Neustart, Kerndienste, Agentenkonfiguration und Anbindungsbestand wurden geprüft.
• Verifiziert: Am 30. Mai 2026 waren Agency OS, Caddy, Webhook und Bridge aktiv – mit zwei live konfigurierten Agenten und 54 Anbindungen.
• Aktiv genutzt: Die Akte quantifiziert weder abgeschlossene kundenübergreifende Arbeit noch dauerhafte Abteilungsnutzung. Live-Dienste werden nicht zu unbelegten Outputaussagen hochgestuft.
• Verbleibende Abhängigkeiten: Breiteres Kanal-zu-Agent- und Fachrouting muss Workspace für Workspace aktiviert und belegt werden. Installierte gbrain-, Kie.ai- und Loom-Tools brauchen weiterhin workflowspezifische Nachweise.
• Vom Kunden berichtetes Finanzergebnis: Keines hinterlegt.

Belege

• Laufzeitnachweis: Vier benannte Infrastrukturdienste am 30. Mai 2026 aktiv.
• Agentennachweis: Atlas und Louis AI/Licensing live konfiguriert.
• Routing-Nachweis: 54 Anbindungen in der Umgebung beobachtet.
• Deployment-Nachweis: GitHub-Push-Webhooks lösen Rebuilds und Neustarts des Agency OS aus.
• Aussagegrenze: Die sieben weiteren Fachrollen beschreiben die Architektur; sie werden nicht vollständig als produktive Live-Abteilungen dargestellt.

Technologie - bewusst zuletzt

Der Stack läuft mit OpenClaw 2026.5.7 auf einem Hostinger-VPS und nutzt Discord, mehrere Slack-Socket-Mode-Workspaces, Modell-/Bridge-Routing, gbrain, Kie.ai, Loom-Transkripttools, ein gehostetes Next.js Agency OS, Caddy und GitHub-Webhook-Deployment. Das Dashboard läuft auf der Domain von Full Stack Agency; Kanalbindungen und Anbietertools werden nach Workspace- und Agentenverantwortung aktiviert.

Kundenstimme

Für diesen Fall liegt kein belastbarer wörtlicher Kundenkommentar vor. Die öffentliche Akte trennt den live laufenden Kern von der vorbereiteten Facharchitektur, statt diese Grenze mit einer erfundenen Empfehlung zu verwischen.

Nächste Transformation

Lesen Sie, wie Scaling Webinars acht aktive Fachagenten in einer koordinierten Delivery-Umgebung verifiziert hat. Full Stack Agency zeigt die vorgelagerte anbieterbereite Stufe für eine stärker verteilte Workspace-Topologie.

Ihren KI-Umsetzungsplan erhalten

Wenn jeder Kunden-Workspace zur Insel wird, muss Zentralisierung sie nicht zusammenwerfen. Buchen Sie ein kostenloses KI-Audit, um gemeinsamen Kontext, Agentengrenzen und Freigabewege dazwischen zu entwerfen.

Quellennachweis

• OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, Seite 17.
• Louis erscheint nicht in RECAST_CASE_STUDIES_2026_UPDATED.pdf; das Deep-Case-Dokument ist die maßgebliche Fallquelle.
• RECAST_WEBSITE_MASTER_BLUEPRINT.md, Abschnitte 10.4, 11 und 58.