Warum wir mesakumo auf Claude Cowork bauen — und trotzdem jede Woche am Exit arbeiten

Wir bauen mesakumo auf Claude Cowork. Und arbeiten trotzdem jede Woche an unserem Exit.

Kein Widerspruch. Aus meiner Sicht die einzige verantwortbare Art, gerade jetzt eine AI-Native Beratung zu bauen.

Kontext

Richard Ritz und ich bauen mesakumo als AI-Native Beratung auf, 25+ Berater bei unterschiedlichsten Kunden und Themen. Claude Cowork ist unser zentrales AI-Backbone. Engagements, Wissensmanagement, Skills, Scheduled Tasks, alles läuft darüber.

Und ja, ein Grund dafür ist ganz banal: Die Subscriptions sind aktuell stark subventioniert. Anthropic, OpenAI und Co. kaufen gerade Marktanteile. Wer glaubt, dass diese Preise bleiben, hat die letzten 20 Jahre Cloud-Pricing nicht miterlebt.

Unsere Regel: Kein Backbone ohne Exit-Weg

Deshalb gilt bei uns eine Regel: Kein Tool wird Backbone, ohne dass der Weg hinaus dokumentiert ist.

Wichtig dabei: Alles, was hier folgt, ist unser interner Stack. Dahinter steckt aber mehr als Neugier, nämlich unsere Dogfood-Mentalität. Wir wollen mit Kunden idealerweise nur über Dinge reden, die wir selbst kennen und verprobt haben. Echte Einschätzungen aus dem eigenen Betrieb, nicht das, was man irgendwo in den Medien liest.

Was ich konkret verprobt habe

1. Cowork mit fremden Modellendpunkten. Die Claude Desktop App an andere Modellendpunkte gehängt und evaluiert. Funktioniert erstaunlich gut. Der Haken: Die nativen Anthropic-Konnektoren fallen weg und müssen manuell als MCP-Server nachgebaut werden. Machbar. Aber genau da sitzt der Lock-in, nicht im Modell, sondern im Ökosystem drumherum.

2. OpenWork (Open-Source-Alternative auf OpenCode-Basis). MIT-lizenziert, läuft mit 50+ Providern. Lokal, chinesische Modelle, Anthropic, alles verprobt. Die Skills und MCPs aus unserem Cowork-Setup laufen weitgehend im selben Format weiter. Für mich der wichtigste Befund überhaupt: Unsere eigentliche Investition, also Skills, Workflows und Wissensstruktur, ist portabler als gedacht.

3. Hermes Agent & OpenClaw, seit Monaten im Produktivbetrieb. Beide leisten Erstaunliches als persönliche Agenten. Für kollaborative Teamarbeit an gemeinsamen Projekten sind sie aber eindeutig nicht gebaut. Kein geteiltes Wissensmodell, keine saubere Multi-User-Governance. Als zentrales Firmen-Backbone fallen beide durch. Ihre Rolle bei uns ist eine andere: Sie laufen als eine Art zusätzliches AI-Teammitglied im Hintergrund und arbeiten Metaskills und Metatasks ab. Data-Quality-Reviews, Konsistenz-Checks, Hygiene-Läufe… Persönlicher Agent ≠ Team-Betriebssystem. Diese Unterscheidung fehlt in den meisten Vergleichen.

4. Codex bzw. ChatGPT Work. OpenAIs direkte Antwort auf Cowork, seit Juli auf GPT-5.6-Basis. Funktional nah dran, der Wechsel wäre technisch der einfachste. Nur tauscht man damit einen US-Hyperscaler-Lock-in gegen den nächsten. Für unsere Exit-Frage löst das nichts, es dupliziert sie nur.

5. DeerFlow 2.0. ByteDances Open-Source SuperAgent-Harness: Sub-Agenten, Docker-Sandbox, persistente Memory, LangGraph-basiert, MIT-Lizenz. Hier bin ich ehrlich ganz am Anfang: installiert, aber noch nicht ernsthaft verprobt. Self-Hosting ist dabei nicht die Frage, das gilt für Hermes und OpenClaw genauso. Die spannende Frage ist eine andere: Trägt DeerFlow ein Teamsetup mit 25+ Beratern? Oder landet es wie Hermes und OpenClaw in der Rolle des zusätzlichen AI-Teammitglieds für Metatasks im Hintergrund? Wer DeerFlow schon produktiv im Team einsetzt: Ich bin gespannt auf eure Erfahrungen.

Nicht Labor, sondern produktiv

Und das Ganze ist kein Labor-Setup. Das Backbone läuft produktiv mit 25+ Beratern, teils in getrennten Projekten und bei unterschiedlichen Kunden, teils gemeinsam im selben Engagement.

Die eigentlich harte Nuss dabei: Wenn mehrere gleichzeitig am selben Kundenkontext arbeiten, darf es keine Probleme mit Kontext, Konsistenz und auseinanderlaufenden Wissensständen geben. Genau das haben wir praktisch umgesetzt, sowohl in Notion als auch file-basiert.

Und beim file-basierten Teil hatten wir das Timing auf unserer Seite: Unsere Struktur stand ein halbes Jahr vor Googles Open Knowledge Format (OKF). Als die Spec im Juni kam, mussten wir kaum etwas adaptieren, weil wir de facto schon so gearbeitet haben. Wie das im Detail aussieht, dazu ein andermal mehr.

Woran wir jede Alternative messen — unsere 5 Kriterien

1. Datenschutz: Wo laufen Prompts und Kundendaten durch? Confidential-Computing-Optionen wie Privatemode.ai (EU-gehostet, Ende-zu-Ende-verschlüsselt bis in den GPU-Speicher) verändern hier gerade, was überhaupt möglich ist.

2. Team-Kollaboration: Funktioniert es für 25+ Berater bei unterschiedlichsten Kunden und Themen? Mit geteilten Skills, geteiltem Kontext, sauberer Mandantentrennung?

3. Wissensintegration: Spricht das Tool nativ mit unserem Wissensmanagement, oder bauen wir Brücken, die beim nächsten Update brechen?

4. Lokale Modelle: Läuft es, wenn der Kunde sagt „nichts verlässt unser Haus”?

5. Gateway-Fähigkeit: Funktioniert es hinter OpenRouter, Requesty oder Privatemode, also mit austauschbarer Modellschicht?

Aktueller Stand

Cowork bleibt. Kein Kandidat schlägt die Kombination aus nativen Konnektoren, Team-Fähigkeit und Reifegrad.

Unser Exit steht aber und ist jederzeit möglich. Skills und MCPs sind portabel, OpenWork ist der wahrscheinlichste Landeplatz, und die Modellschicht ist über Gateways schon heute austauschbar. Und dabei bleibt es nicht: Wir verproben den Weg hinaus auch zukünftig kontinuierlich weiter.

Der wahre Lock-in sitzt im Ökosystem

Was nach Monaten Evaluierung bleibt: Der Lock-in sitzt nicht im Modell. Er sitzt in den Konnektoren, im Wissensgraphen und in den Gewohnheiten des Teams.

Wer Vendor-Unabhängigkeit will, muss dort investieren und nicht in die x-te Modell-Benchmark-Diskussion.

Für uns ist das übrigens kein Selbstzweck, sondern fester Bestandteil unseres 5-Stufen-Reifegradmodells von AI Curious bis AI Native, mit dem wir auch unsere Kunden einordnen. Denn wer sein Backbone nicht wechseln kann, kommt auf dieser Leiter irgendwann nicht mehr weiter.

Wie handhabt ihr das? Backbone committen und Geschwindigkeit mitnehmen, oder von Tag 1 auf Portabilität bauen und dafür Reibung akzeptieren? Und: Rechnet jemand ernsthaft damit, dass die aktuellen Subscription-Preise 2027 noch stehen?