Zwei Ankündigungen von OpenAI zeigen in dieselbe Richtung: ChatGPT soll nicht länger primär ein Dialogfenster für einzelne Nutzerinnen und Nutzer sein, sondern eine Plattform, auf der Teams gemeinsam arbeiten und auf der Software dauerhaft im Hintergrund läuft. Auf dem DevDay wurde ChatGPT zur Teamplattform geöffnet. Parallel wurden mit Dots Agenten vorgestellt, die permanent aktiv bleiben.
Gemeinsame Arbeitsbereiche statt Einzelchats
Zentrales Element der Plattformöffnung sind gemeinsame Arbeitsbereiche, bei OpenAI "Space" genannt. Dazu kommen kollaborative Dokumente und Slides, also Präsentationen, die mehrere Personen gemeinsam bearbeiten können. Der Unterschied zum bisherigen Modell ist weniger technisch als organisatorisch: Ergebnisse entstehen nicht mehr nur im privaten Chatverlauf einer Person, sondern an einem Ort, an dem ein Team sie wiederfindet.
Ergänzt wird das um ein offenes Plugin-System. Es setzt auf MCP auf, ein Protokoll, über das Sprachmodelle standardisiert auf externe Werkzeuge und Datenquellen zugreifen. Neu ist dabei die Automatisierung über MCP-Events: Abläufe können also durch Ereignisse ausgelöst werden und nicht nur durch eine manuelle Eingabe. Damit verschiebt sich die Rolle des Modells von der Antwortmaschine zum Auslöser von Prozessen.
Integration in die bestehende Kommunikation
Beide Meldungen nennen dieselben Einstiegspunkte: Slack und Microsoft Teams. Das ist bemerkenswert, weil damit nicht erwartet wird, dass Teams ihre Arbeitsumgebung wechseln. Die Funktionen wandern stattdessen dorthin, wo ohnehin kommuniziert wird. Für die Einführung im Unternehmen senkt das die Hürde erheblich, verlagert die Governance-Frage aber gleichzeitig in Kanäle, in denen bislang eher informell gearbeitet wurde.
Auf der kommerziellen Seite wird ein Enterprise-Marketplace mit 32 Partnern genannt sowie ein neuer Pro-500-Plan. Details zu Konditionen oder Verfügbarkeit gehen aus den Quellen nicht hervor, weshalb hier Zurückhaltung angebracht ist. Erkennbar ist lediglich die Absicht, ein Ökosystem aus Drittanbietern aufzubauen, statt jede Integration selbst zu liefern.
Dots: Agenten, die nicht auf eine Frage warten
Der zweite Baustein geht einen Schritt weiter. Dots sind laut OpenAI dauerhaft aktive Agenten, die auf eigenen Cloud-Rechnern arbeiten. Genannte Beispiele sind das Beheben von Bugs oder das Versenden vergessener Rechnungen. Entscheidend ist der Zusatz, dass dies teilweise geschieht, bevor jemand danach fragt.
Technisch dahinter steht ein einfaches, aber folgenreiches Muster: Bei Inaktivität suchen die Agenten mit Leserechten im Hintergrund nach möglichen Arbeitsansätzen. Die Beschränkung auf Leserechte in dieser Phase ist die interessanteste Angabe der Meldung, denn sie trennt Beobachtung von Ausführung. Angesprochen werden die Agenten wiederum über ChatGPT, Slack und Teams. Positioniert wird Dots gegen Metas Muse, was zeigt, dass Dauer-Agenten offenbar kein Einzelansatz bleiben.
Wie die beiden Meldungen zusammenpassen
Die Quellen berichten unabhängig, beschreiben aber zwei Hälften derselben Entwicklung. Die Plattformöffnung liefert den Rahmen: gemeinsame Arbeitsbereiche, standardisierte Anbindung über MCP, ereignisbasierte Auslöser und Präsenz in den Kommunikationstools. Die Dauer-Agenten liefern den Akteur, der diesen Rahmen nutzt. Ohne Ereignis-Automatisierung und Werkzeugzugriff wäre ein permanent laufender Agent weitgehend wirkungslos.
Abweichende Angaben enthalten die beiden Meldungen nicht. Sie unterscheiden sich im Detailgrad: Die Plattformmeldung ist konkret bei Funktionen und Plänen, die Agentenmeldung bei der Arbeitsweise. Was in beiden Fällen fehlt, sind Aussagen zu Rechteverwaltung im Detail, Protokollierung oder Datenhaltung. Genau diese Punkte entscheiden in der Praxis darüber, ob ein solches Setup in einem mittelständischen Unternehmen tragfähig ist.
Naheliegende Anwendungsfälle rund um die Website
Überträgt man die beschriebenen Muster auf den Alltag, ergeben sich Felder, in denen ereignisgetriebene Automatisierung bereits heute Sinn ergibt:
- Redaktion: Hinweise auf veraltete Inhalte, fehlende Alternativtexte oder inkonsistente Metadaten, ausgelöst durch Änderungen im Content-Management-System.
- Support: Vorstrukturierung eingehender Anfragen samt Verweis auf bestehende Dokumentation, angestoßen durch ein neues Ticket.
- Betrieb: Aufbereitung von Fehlermeldungen und Log-Auffälligkeiten mit Vorschlag zur Einordnung, bevor jemand manuell nachsieht.
- Verwaltung: Erinnerungen an offene Vorgänge, wie im Beispiel der vergessenen Rechnungen.
Der gemeinsame Nenner: Es geht um Aufgaben mit klarem Auslöser, überprüfbarem Ergebnis und begrenztem Schadenspotenzial bei Fehlern.
Was vorab geklärt werden sollte
Wer Dauer-Agenten einsetzen will, braucht eine belastbare Antwort auf drei Fragen. Erstens: Welche Systeme darf ein Agent lesen und welche ändern? Die in den Quellen erwähnte Trennung zwischen Lesen im Hintergrund und aktivem Handeln ist ein sinnvolles Vorbild. Zweitens: Wo wird dokumentiert, was automatisiert passiert ist? Drittens: Wer prüft Ergebnisse, bevor sie nach außen wirken, etwa auf der Website oder gegenüber Kundinnen und Kunden?
Für Web- und Softwareprojekte verschiebt sich damit der Fokus von der Frage, welches Modell verwendet wird, zur Frage, wie saubere Schnittstellen und klare Rechte aussehen. Systeme wie TYPO3 profitieren davon, wenn Inhalte, Workflows und Statusinformationen über definierte APIs zugänglich sind, statt nur über die Oberfläche. Wer diese Grundlagen jetzt schafft, kann Automatisierung schrittweise ergänzen, ohne die eigene Architektur an einen einzelnen Anbieter zu binden.
