Ramons Stores brauchten keine identischen, von Ordner zu Ordner kopierten Assistenten. Sie brauchten ein gemeinsames Fundament, das Gelerntes erhält und zugleich Anweisungen, Zugangsdaten und Kundenkontext jeder Marke sauber trennt.
Belegstand bei Veröffentlichung: mindestens drei Shopify-Stores im Betriebskontext; sechs konfigurierte Agenten und 40 Anbindungen am 30. Mai 2026 verifiziert; Gmail-, Shopify-, Track123-, Meta-Ads- und Drive-Verbindungen auf Store-Ebene blieben anbieterbereit und wurden nicht als live ausgegeben.
Das Unternehmen
Ramon Gloor baute und betrieb mehrere Schweizer/deutsche E-Commerce-Marken, mit mindestens drei Shopify-Stores und weiteren geplanten Marken. Jeder Store hatte eigene Kundenanfragen, Produkte, Launch-Arbeit und Kreativentscheidungen.
Allein der Support ging über mehrere Systeme: Jemand musste das richtige Gmail-Postfach öffnen, die passende Shopify-Bestellung finden, Tracking über Track123 oder eine storespezifische App prüfen und im ursprünglichen Thread antworten. Unvollständige Schweizer oder deutsche Adressen erzeugten einen weiteren Entscheidungsweg über Rechnungsdaten, Kundendaten und Verzeichnisquellen.
Der Engpass
Jeder Store lebte in einem isolierten Automatisierungssetup. Anweisungen, Korrekturen, Supportlogik, Launch-Schritte und Kreativwissen wurden vervielfacht. Löste eine Marke ein wiederkehrendes Problem, erbten die anderen diese Erkenntnis nicht sicher.
Der Kernengpass war fragmentiertes Gedächtnis. Eine gemeinsame Schicht konnte Duplikation reduzieren; eine unbedachte Zentralisierung hätte jedoch Marken, Zugangsdaten und Kundendaten vermischt. Die Architektur brauchte Wiederverwendung und Trennung zugleich.
Warum die vorhandenen Tools nicht ausreichten
Shopify hielt Bestellungen, Gmail Gespräche, Tracking-Tools den Versandstatus. Kreativ- und Launch-Wissen lag anderswo. Kein einzelnes Produkt definierte, welches Wissen global gilt, welche Regel nur zu einem Store gehört oder wie ein neuer Markenarbeitsbereich bewährte Skills übernehmen kann, ohne den privaten Zustand einer anderen Marke mitzunehmen.
Die fehlende operative KI-Schicht brauchte einen gemeinsamen Wissensspeicher, Store-Konfigurationen, Fachrollen und einen wiederholbaren Weg zu einem neuen isolierten Markenbereich. Anbieterzugänge mussten anschließend Store für Store aktiviert werden - nicht aus der Architektur heraus als live gelten.
Transformationskarte
Vorher
Marke-A-Assistent | Marke-B-Assistent | Marke-C-Assistent -> duplizierte Korrekturen -> Ramon gleicht Wissen ab
Nachher - anbieterbereite Architektur
Gemeinsame Skills und Gedächtnis -> Markenrouter -> isolierte Store-Konfiguration -> Fachagent -> Freigabe oder Anbieteraktion -> markenspezifischer Nachweis
Globales Wissen lässt sich wiederverwenden. Kundendatensätze, Zugangsdaten und Store-Entscheidungen bleiben in ihrer Grenze.
Ein Ablauf von Anfang bis Ende
Der folgende Ablauf beschreibt den vorgesehenen Supportweg nach Aktivierung der jeweiligen Store-Anbieter. Die Quelle behauptet nicht, dass diese Anbieteraktionen bei Veröffentlichung live waren.
- Eingang: Eine Kunden-E-Mail trifft im storespezifischen Gmail-Konto ein.
- Markenauflösung: Das System bestimmt den passenden Markenarbeitsbereich und lädt dessen Store-Konfiguration.
- Bestellkontext: Der Support-Bereich ruft die zugehörige Shopify-Bestellung und die erlaubte Tracking-Quelle dieses Stores ab.
- Entscheidungsunterstützung: Gemeinsames Supportwissen und storespezifische Richtlinien werden angewandt, ohne Kundenkontext anderer Marken offenzulegen.
- Menschliche Freigabe: Der Betreiber prüft sensible Adressänderungen, Ausnahmen oder ausgehende Antworten, bis jeder Aktionsbereich separat belegt ist.
- Ausgabe: Antwortentwurf oder Adressklärung wird im richtigen Markenkontext vorbereitet.
- Nachweis: Die wiederverwendbare Erkenntnis kann in das gemeinsame Gedächtnis einfließen; Zugangsdaten und kundenspezifische Informationen bleiben isoliert.
Was sich verändert hat
- Gebaut: Gemeinsames Gedächtnis, wiederverwendbare E-Commerce-Skills, Store-Konfigurationsordner, Wissensspeicher, sechs Fachagenten, Mission-Control-Struktur und Brand-Agent-Factory.
- Verbunden: OpenClaw-Laufzeit, Command Center, gbrain, Modellrouting und Agenten-/Arbeitsbereichsanbindungen waren in der verifizierten Umgebung vorhanden.
- Getestet: Am 30. Mai 2026 wurden sechs Agenten, 40 Anbindungen und die erwarteten Arbeits- und Skill-Strukturen beobachtet.
- Fundament verifiziert: Betriebsfundament und Agentenrouting liefen live. Anbieterbereite Store-Adapter werden dadurch nicht zu verifizierten End-to-End-Commerce-Abläufen.
- Aktiv genutzt: Routinenutzung Store für Store ist in den Quellen nicht belegt und wird nicht behauptet.
- Verbleibende Anbieter- oder Kundenabhängigkeit: Gmail, Shopify, Track123, Meta Ads, Google Drive und storespezifische Zugangsdaten müssen pro Marke aktiviert und bewiesen werden.
- Vom Kunden berichtetes Finanzergebnis: Keines hinterlegt.
Belege
- Betriebskontext: Mindestens drei Shopify-Stores, weitere Marken erwartet.
- Agentennachweis: Sechs konfigurierte Agenten - main/Ava, Support, Operations, Launch, Creative und Strategy.
- Routing-Nachweis: 40 Anbindungen am 30. Mai 2026 beobachtet.
- Architekturnachweis: Getrennte Arbeitsbereiche, Store-Konfigurationen und gemeinsame Skill-Strukturen vorhanden.
- Ehrlicher Status: Das Fundament ist anbieterbereit; Store-Integrationen werden ohne Store-spezifischen Beleg nicht als live bezeichnet.
Technologie - bewusst zuletzt
Das Fundament läuft auf einem nativen VPS mit OpenClaw, Caddy, live laufendem Command Center, Billing-Proxy, gbrain, OpenRouter-Routing, Apify, Kie.ai und E-Commerce-Skills. Jeder Arbeitsbereich enthält eigene Betriebsanweisungen, Tools, Projekte und Store-Konfiguration. Der gemeinsame Wissensspeicher strukturiert Marken, Support, Betrieb, Marketing, Produktrecherche, Runbooks und Kreativstrategie. Anbieteradapter sind für Store-für-Store-Verbindungen zu Gmail, Shopify, Track123, Meta Ads und Google Drive ausgelegt.
Kundenstimme
Für diesen Fall liegt kein belastbarer wörtlicher Kundenkommentar vor. Die Belege bestehen aus verifizierter Systemarchitektur, Agenten- und Routing-Zahl; RECAST macht aus einer Projektzusammenfassung keine Kundenstimme.
Nächste Transformation
Lesen Sie, wie Scaling Webinars acht operative Bereiche über einen gemeinsamen Geschäftskontext koordiniert hat. Beide Systeme trennen Facharbeit und teilen Gedächtnis, jedoch mit unterschiedlichen Betriebsgrenzen.
Ihren KI-Umsetzungsplan erhalten
Wenn jede neue Marke dieselben fragilen Automatisierungen kopieren muss, lautet die erste Architekturfrage: Was darf geteilt werden, was muss isoliert bleiben? Buchen Sie ein kostenloses KI-Audit, bevor Sie einen weiteren Store-Bot hinzufügen.
Quellennachweis
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, Seite 1.RECAST_WEBSITE_MASTER_BLUEPRINT.md, Abschnitte 6.5, 10.4, 11 und 58.- Ramon erscheint nicht in
RECAST_CASE_STUDIES_2026_UPDATED.pdf; das Deep-Case-Dokument ist die maßgebliche Fallquelle.