In vielen Teams ist KI-Arbeit unsichtbar. Eine Person analysiert Kundendaten in einem privaten Chat, eine zweite entwickelt mit einem Coding-Agenten einen brauchbaren Lösungsweg, eine dritte lässt ein Meeting zusammenfassen. Die Ergebnisse wandern in Präsentationen und Tickets. Die verwendeten Quellen, Anweisungen, Korrekturen und verworfenen Wege bleiben dagegen in persönlichen Verläufen zurück.
Das funktioniert, solange KI ein individuelles Hilfsmittel ist. Sobald mehrere Menschen und Agenten an demselben Prozess arbeiten, wird der private Chat zum organisatorischen Risiko. Niemand weiß sicher, welche Version einer Annahme gilt, warum ein Agent eine Entscheidung getroffen hat oder ob ein Ergebnis morgen reproduzierbar ist.
Genau hier setzt die Idee des Shared AI Workspace an. Gemeint ist nicht einfach ein Chatraum mit mehreren Teilnehmern. Ein brauchbarer gemeinsamer KI-Arbeitsraum verbindet vier Dinge: kuratierten Kontext, sichtbaren Arbeitszustand, geregelte Übergaben und dauerhafte Ergebnisse. Erst diese Kombination macht aus einzelnen Prompts einen Teamprozess.
Unsere Einordnung zu persistenter KI-Memory fragt, welche Erinnerungen zwischen Sessions erhalten bleiben dürfen. Hier geht es um die nächste Ebene: Wer im Team darf diesen Kontext sehen, verändern und für welche Agentenläufe wiederverwenden?
Was ein Shared AI Workspace wirklich teilt
Der Begriff wird derzeit für sehr unterschiedliche Produkte verwendet. Manche bündeln Chats und Dateien. Andere bauen Agenten, speichern deren Zustand oder machen KI-generierte Analysen nachvollziehbar. Für die Auswahl hilft eine nüchterne Schichtenlogik.
| Schicht | Was gemeinsam wird | Woran man Reife erkennt |
|---|---|---|
| Projektkontext | Dateien, Quellen, Anweisungen, Entscheidungen | Mitglieder sehen dieselbe kuratierte Grundlage und ihre Änderungen |
| Agenten-State | Aufgabenstatus, Checkpoints, Zwischenergebnisse | Läufe lassen sich unterbrechen, prüfen und kontrolliert fortsetzen |
| Arbeitsartefakte | Dashboards, Reports, Diffs, Tickets, Freigaben | Ein Ergebnis existiert außerhalb des Chats und bleibt reproduzierbar |
| Governance | Rollen, Kosten, Schreibrechte, Logs, Löschung | Der Workspace zeigt nicht nur, was möglich ist, sondern auch, wer verantwortlich ist |
Ein Produkt muss nicht alle vier Schichten abdecken. Es sollte aber klar benennen, welche es tatsächlich beherrscht. Ein gemeinsamer Dateiordner ist noch kein Agenten-State. Ein gespeicherter Chat ist noch kein belastbares Wissenssystem. Und ein Agenten-Dashboard ist keine Governance, wenn jeder Nutzer jede Aktion auslösen darf.
Drei Produktmuster laufen gerade zusammen
1. Projekte machen Chat-Kontext teamfähig
ChatGPT Projects bündelt Chats, Dateien und projektspezifische Anweisungen. In gemeinsam genutzten Projekten können Mitglieder auf denselben Arbeitsbestand zugreifen und mit unterschiedlichen Rechten chatten oder bearbeiten. Das ist für Recherche, Planung und wiederkehrende Dokumentarbeit ein niedriger Einstieg: Das Team muss nicht jedes Briefing neu zusammensetzen.
Claude Projects verfolgt ein ähnliches Prinzip mit Projektwissen und Anweisungen. Eine wichtige Grenze steht in der Anthropic-Dokumentation: Kontext springt nicht automatisch zwischen allen Chats eines Projekts. Wissen, das zuverlässig wiederverwendet werden soll, gehört bewusst in die Projekt-Knowledge. Genau diese kleine Reibung ist gesund. Sie zwingt das Team, zwischen flüchtiger Diskussion und freigegebenem Kontext zu unterscheiden.
Solche Projekträume lösen jedoch nicht automatisch das Problem operativer Agenten. Sie geben Menschen eine gemeinsame Arbeitsgrundlage. Für mehrstufige Abläufe braucht es zusätzlich Zustand und Freigaben.
2. Agenten-Workspaces verbinden Kontext mit Ausführung
Plattformen wie Sim positionieren sich als gemeinsamer Ort, um Agenten zu bauen, auszuführen und zu beobachten. Daten, Dateien und Wissensbasen bilden den Kontext; Integrationen geben den Agenten Werkzeuge; Traces und Kostenanzeigen machen Läufe prüfbar. Das ist eine andere Kategorie als ein geteiltes Chat-Projekt: Der Workspace verwaltet nicht nur Gespräche, sondern laufende Automationen.
BitBoard zeigt ein engeres, aber anschauliches Muster. Eine Analyse aus ChatGPT, Claude oder Cursor soll nicht als einmalige Antwort enden, sondern als Dashboard mit gespeicherten Verbindungen, Abfragen und Code. Ein Kollege sieht dann nicht nur die Grafik, sondern auch, woher die Daten kamen und ob sich die Logik erneut ausführen lässt.
Das ist der entscheidende Sprung: Der Wert steckt nicht im geteilten Prompt, sondern im überprüfbaren Artefakt. Für ein Vertriebsteam kann das ein Pipeline-Report sein, für Engineering ein kleiner Git-Diff samt Tests, für Support eine priorisierte Fallliste mit Quellen.
3. Memory und Werkzeuge werden anbieterübergreifend
Neue Produkte wie scritty versuchen, Sitzungen verschiedener Coding-Agenten in einem durchsuchbaren Bestand zusammenzuführen. Der Anbieter beschreibt einen lokalen Terminal-Layer, der Gespräche von Codex, Claude Code, Copilot und weiteren CLIs erfasst und über Suche, CLI oder MCP wieder verfügbar macht. Das adressiert ein reales Problem: Eine Architekturentscheidung aus Claude ist für OpenAI Codex normalerweise unsichtbar.
Aber gerade hier ist Skepsis angebracht. Ein vollständiges Gesprächsarchiv ist nicht automatisch gutes Teamwissen. Ohne Markierung von Projekt, Vertraulichkeit, Gültigkeit und Owner wird aus geteilter Memory schnell ein durchsuchbarer Misthaufen mit sehr überzeugenden Altlasten.
Auch der Google Workspace CLI zeigt, wie sich die Grenze verschiebt. Das Open-Source-Projekt erzeugt strukturierte Befehle für Drive, Gmail, Calendar, Sheets und weitere Workspace-APIs und bringt Agent Skills mit. Es ist ausdrücklich kein offiziell unterstütztes Google-Produkt. Als Baustein ist es trotzdem interessant: Ein Agent kann auf einen gemeinsamen Arbeitsraum zugreifen, ohne eine menschliche Oberfläche zu imitieren. Genau deshalb müssen OAuth-Scopes, Dry-runs und Schreibrechte enger sein als bei einem normalen Nutzerkonto.
Drei praktische Szenarien
Der wöchentliche Vertriebsbrief. Quellen aus CRM, Kalender und Support werden in einem Projekt gesammelt. Ein Agent erstellt einen Entwurf, aber jede Kennzahl bleibt mit ihrer Quelle verbunden. Der Account Owner korrigiert Ausnahmen und gibt die Version frei. In der nächsten Woche startet der Prozess mit dem freigegebenen Schema, nicht mit einem zufälligen alten Chat.
Die Sicherheitsuntersuchung. Slack Engineering beschreibt für lang laufende Untersuchungen ein System aus Director, spezialisierten Experts und einem Critic. Entscheidend ist nicht die Anzahl der Agenten, sondern die kontrollierte Übergabe von Kontext zwischen Phasen. Evidenz, Hypothesen und Kritik müssen getrennt bleiben, damit ein späterer Agent nicht eine Vermutung als bestätigten Befund übernimmt.
Die Softwaremigration. Ein Team nutzt Claude für die Architekturprüfung, OpenAI Codex für begrenzte Änderungen und GitHub Copilot im Editor. Der gemeinsame Workspace ist hier nicht zwingend ein neues SaaS-Produkt. Er kann aus versionierten Projektregeln, einem Issue, separaten Worktrees, Testprotokollen und einer Entscheidungsliste bestehen. Geteilt werden geprüfte Artefakte, nicht komplette private Sessions.
Mehr Kontext ist nicht automatisch mehr Wissen
Ein Shared AI Workspace verführt dazu, alles zu speichern. Das ist meistens der falsche Reflex. Kontext wird mit der Zeit nicht nur größer, sondern widersprüchlicher. Preise ändern sich, Zuständigkeiten wechseln, ein Architekturentscheid wird zurückgenommen, ein Kunde widerruft eine Einwilligung.
Gute Team-Memory braucht deshalb Metadaten und Pflege:
- Herkunft: Welche Datei, Person oder welcher Toollauf hat die Aussage erzeugt?
- Scope: Gilt sie persönlich, für ein Projekt oder für die ganze Organisation?
- Status: Ist sie Entwurf, überprüfter Fakt, Entscheidung oder verworfene Hypothese?
- Gültigkeit: Wann wurde sie zuletzt geprüft und wann läuft sie ab?
- Rechte: Wer darf lesen, korrigieren, exportieren oder löschen?
Diese Regeln klingen nach Dokumentenmanagement. Genau das ist der Punkt. Sobald Agenten mit geteiltem Kontext Entscheidungen vorbereiten oder Systeme bedienen, wird Memory zu einer Daten- und Governance-Schicht. Unsere Beiträge zu Agent Observability und Agent Security zeigen die technische Konsequenz: Kontext braucht Provenienz, Aktionen brauchen Traces, und Schreibzugriffe brauchen Freigaben.
Vier Rollen reichen für den Anfang
Teams brauchen kein künstliches Organigramm aus zehn Agenten. Für einen ersten produktiven Workspace reichen vier klar benannte Rollen.
| Rolle | Verantwortung | Sichtbares Ergebnis |
|---|---|---|
| Context Owner | Quellen auswählen, veraltetes Wissen entfernen | kuratierte Projektbasis mit Datum und Scope |
| Agent Operator | Auftrag, Werkzeuge, Budget und Abbruchbedingungen setzen | reproduzierbarer Lauf mit Kosten- und Toolgrenzen |
| Reviewer | Quellen, Ergebnis und Nebenwirkungen prüfen | Freigabe, Korrektur oder begründete Ablehnung |
| Process Owner | fachliche Wirkung und Verantwortung tragen | veröffentlichtes Artefakt und Rückbauentscheidung |
Eine Person kann mehrere Rollen übernehmen. Wichtig ist nur, dass sie nicht im Interface verschwinden. Wenn derselbe Agent die Quellen auswählt, arbeitet, sich selbst prüft und veröffentlicht, gibt es zwar einen Workspace, aber keinen kontrollierten Prozess.
LangGraph zeigt auf technischer Ebene, warum expliziter Zustand wichtig ist. Checkpoints speichern den State eines Graphen schrittweise und ermöglichen Unterbrechung, Human-in-the-loop, Wiederaufnahme und Fehlerbehandlung. Das ist weniger glamourös als „gemeinsames Gedächtnis“, aber im Betrieb wertvoller: Ein Team kann sehen, an welchem Punkt ein Lauf steht und welche Schritte nach einer Freigabe noch folgen.
Ein 30-Tage-Pilot ohne Plattformwette
Woche 1: Einen wiederkehrenden Prozess wählen. Gut sind Aufgaben mit mehreren Quellen und einem klaren Ergebnis: Wochenbericht, Support-Triage, Meeting-Vorbereitung oder Review eines kleinen Code-Diffs. Schlecht sind diffuse Ziele wie „macht unser Unternehmen mit Agenten produktiver“.
Woche 2: Gemeinsamen Kontext kuratieren. Legen Sie fünf bis zehn verlässliche Quellen, Projektregeln, ein Ausgabeformat und ein Ablaufdatum fest. Private Chatverläufe bleiben zunächst draußen. Das Team definiert, was als Fakt, Entwurf und Entscheidung gilt.
Woche 3: Einen Agentenlauf mit Freigabe bauen. Der Agent darf lesen, analysieren und einen Entwurf erzeugen. Externe Nachrichten, CRM-Änderungen, Git-Merges oder Dateilöschungen bleiben hinter einer menschlichen Freigabe. Genau dieses Muster nutzt auch WUPHF in seiner aktuellen Produktbeschreibung: Leseaktionen laufen, Schreibaktionen warten auf Zustimmung.
Woche 4: Nicht nur Zeit messen. Prüfen Sie vier Werte: Wie oft musste Kontext neu erklärt werden? Wie viele Aussagen waren auf Quellen zurückführbar? Wie viele Korrekturen wurden in die gemeinsame Basis übernommen? Konnte ein zweiter Kollege den Prozess ohne mündliche Übergabe fortsetzen?
Wenn nur die Antwort schneller wurde, ist der Workspace noch nicht reif. Wenn Übergaben, Wiederholbarkeit und Verantwortlichkeit besser wurden, lohnt die nächste Automationsstufe.
Auswahlfragen vor dem Kauf
- Kann Kontext nach Projekt, Team und Vertraulichkeit getrennt werden?
- Sind Quellen, Änderungen und Agentenläufe exportierbar?
- Gibt es getrennte Rechte für Lesen, Bearbeiten, Ausführen und Freigeben?
- Lassen sich Memory-Einträge korrigieren und wirklich löschen?
- Zeigt das System Kosten, Toolaufrufe und fehlgeschlagene Schritte?
- Kann ein Mensch einen Lauf unterbrechen und ab einem bekannten Zustand fortsetzen?
- Bleiben nützliche Ergebnisse als normale Dateien, Tickets, Dashboards oder Git-Artefakte erhalten?
Bei jungen Anbietern sind diese Fragen wichtiger als eine lange Integrationsliste. Sim, BitBoard, scritty oder WUPHF zeigen interessante Teile der neuen Kategorie, sind aber keine automatische Empfehlung für sensible Produktionsdaten. Testen Sie Export, Rechte, Löschung und Fehlerverhalten mit einem kleinen, reversiblen Prozess.
Fazit: Der gemeinsame Raum muss Arbeit erklären können
Shared AI Workspaces sind ein plausibler nächster Schritt nach dem persönlichen KI-Chat. Ihr Nutzen entsteht aber nicht dadurch, dass mehr Menschen denselben Verlauf sehen. Er entsteht, wenn Kontext kuratiert, Zustand sichtbar, Übergaben geregelt und Ergebnisse außerhalb des Chats belastbar werden.
ChatGPT und Claude machen gemeinsame Projekträume leicht zugänglich. LangGraph zeigt, wie Agenten-State technisch kontrollierbar wird. Neue Plattformen erproben gemeinsame Builder, Memory-Layer und Artefakte. Die richtige Frage lautet daher nicht: „Welcher Workspace hat die meisten Agenten?“ Sondern: Kann ein Kollege morgen verstehen, was geschehen ist, worauf das Ergebnis beruht und wer es freigegeben hat?
Wer mehrere Modelle im selben Prozess einsetzen will, findet im Beitrag Multi-Model Coding Workflows die passende Rollen- und Review-Logik. Der Shared Workspace ist deren organisatorische Verlängerung: nicht mehr Chat, sondern nachvollziehbare Zusammenarbeit.
Quellen und weiterführende Dokumentation
- OpenAI Help: Projects in ChatGPT
- Anthropic Help: What are projects?
- LangGraph Docs: Persistence
- Slack Engineering: Managing context in long-run agentic applications
- Slack Engineering: Agentic Testing - Where Agents Fit in the E2E Testing Stack
- BitBoard: Dashboards built with AI tools
- Sim: AI agent workspace
- WUPHF: Turn manual workflows into AI agents
- scritty: One terminal and searchable memory for AI agents
- Google Workspace CLI on GitHub