OpenAI lässt ganze Teams einen einzigen Agenten teilen

OpenAI öffnet ChatGPT für gemeinsame Agenten-Teams

OpenAI hat in ChatGPT eine neue Agentenklasse eingeführt, die nicht mehr einer einzelnen Person gehört. „Today, we’re introducing workspace agents in ChatGPT“, schreibt das Unternehmen im Ankündigungsbeitrag vom 18. August 2026. Bislang blieb ein ChatGPT-Agent meist an eine einzelne Konversation und eine einzelne Person gebunden. Workspace Agents durchbrechen genau diese Grenze.

Angetrieben werden die neuen Agenten von Codex, OpenAIs Modell für Programmieraufgaben. Laut Unternehmen übernehmen sie „many of the tasks people already do at work—from preparing reports, to writing code, to responding to messages“. Das ist eine breite Ansage: Reports, Code und Nachrichten sind drei unterschiedliche Arbeitsformen, die bislang selten von derselben Automatisierung abgedeckt wurden.

Der Mythos lautet, ein Agent könne im Unternehmen praktisch jede Aufgabe übernehmen. Die Realität ist enger. OpenAI bindet den Aktionsradius ausdrücklich an bestehende Organisationsrechte, dazu weiter unten mehr. Wer glaubt, ein Team-Agent handle automatisch mit denselben Freiheiten wie ein Einzelnutzer im privaten Chat, irrt.

Für Business-, Enterprise-, Edu- und Teachers-Kunden ist das ein Rollenwechsel: ChatGPT hört auf, nur Antwortmaschine für eine Person zu sein, und wird zu einer Art internem Werkzeug, das ein Team gemeinsam besitzt. Diese Verschiebung betrifft weniger die Technik selbst als die Frage, wer künftig für das Verhalten eines Agenten verantwortlich zeichnet.

Der eigene Aufbau der Ankündigung folgt dabei einer klaren Reihenfolge: Erst die Neuigkeit, dann die Fähigkeit, danach die Grenze. Diese Reihenfolge ist selbst ein Signal, denn OpenAI stellt die Einschränkung durch Organisationsrechte nicht als Fußnote hinten an, sondern nennt sie im selben Absatz wie die neue Funktion.

Ein Agent, viele Hände: Wie geteilte Workflows entstehen

Der eigentliche Unterschied zu einem gewöhnlichen ChatGPT-Assistenten liegt in der Bauweise. „Teams can now create shared agents that handle complex tasks and long-running workflows, all while operating within the permissions and controls set by their organization“, heißt es in der Ankündigung. Ein Agent wird also nicht mehr für eine einzelne Sitzung gebaut, sondern als wiederverwendbares Werkzeug für ein ganzes Team.

Noch deutlicher wird das im nächsten Satz der Ankündigung: „They’re also designed to be shared within an organization, so teams can build an agent once, use it together in ChatGPT or Slack, and improve it over time.“ Ein Team baut den Agenten einmal, nutzt ihn gemeinsam und verbessert ihn schrittweise. Das klingt nach klassischer Softwareentwicklung, nur eben für Automatisierungslogik statt für Code.

Für IT-Abteilungen bedeutet dieser Ansatz weniger Wildwuchs. Statt zwanzig Kolleginnen und Kollegen, die zwanzig eigene Prompt-Varianten pflegen, entsteht im besten Fall eine einzige gepflegte Version. Ob das in der Praxis funktioniert, hängt davon ab, wer den Agenten pflegt, wenn die ursprüngliche Autorin das Team verlässt. Dazu sagt OpenAI in der Ankündigung nichts.

Genau an dieser Stelle trennt sich Anspruch von Alltag. Ein geteilter Agent braucht einen Besitzer, eine Versionshistorie und im Zweifel eine Person, die eine fehlerhafte Anpassung wieder zurückrollt. Ohne diese Rollenklärung wird aus dem Gemeinschaftswerkzeug schnell wieder ein Wildwuchs, nur unter neuem Namen.

Wie stabil ein solcher Teamagent tatsächlich bleibt, zeigt sich meist erst nach Wochen, wenn die ursprüngliche Aufgabenstellung längst nicht mehr die einzige ist, für die ihn jemand einsetzt. Ein Werkzeug, das ursprünglich für Berichtsentwürfe gebaut wurde, wandert in der Praxis erfahrungsgemäß schnell in Nachbaraufgaben, für die es nie geprüft wurde.

Rechte begrenzen den Aktionsraum

Der zentrale Satz der Ankündigung fällt fast nebenbei: Agenten arbeiten „within the permissions and controls set by their organization“. Das ist keine Kleinigkeit, sondern die eigentliche Leitplanke des gesamten Produkts. Ein Agent bekommt nicht automatisch Zugriff auf alles, was ein Unternehmen an Daten und Systemen besitzt.

Praktisch heißt das: Wer als Administratorin restriktive Rechte vergibt, bekommt auch einen entsprechend eingeschränkten Agenten. Wer großzügig Zugriffe freigibt, riskiert einen Agenten mit entsprechend großem Radius. Die Verantwortung verschiebt sich damit nicht von OpenAI weg, sondern direkt zurück ins eigene Rechte- und Rollenmanagement.

Das widerspricht der verbreiteten Sorge, ein Agent könne sich in einer Organisation unkontrolliert ausbreiten. Belegt ist das bislang nur durch die Ankündigung selbst, nicht durch eine unabhängige Prüfung der tatsächlichen Rechtevergabe im Betrieb. Genau das sollte jedes Unternehmen vor einem breiten Rollout selbst nachvollziehen, statt sich allein auf eine Produktbeschreibung zu verlassen.

Für Sicherheitsteams bedeutet das eine vertraute Aufgabe in neuem Gewand: Rechtevergabe prüfen, bevor eine neue Automatisierung produktiv geht. Wer Zugriffe für Agenten genauso sorgfältig plant wie für menschliche Mitarbeiter, reduziert das Risiko einer unbeabsichtigten Datenfreigabe deutlich, unabhängig davon, wie vertrauenswürdig der Anbieter das eigene Produkt beschreibt.

Ein Beispiel macht die Grenze konkret: Erhält ein Vertriebsagent Lesezugriff nur auf CRM-Daten, kann er Leads bewerten, aber keine Rechnungen aus einem Finanzsystem ziehen, selbst wenn ein Nutzer im Chat danach fragt. Diese Trennung entscheidet in der Praxis darüber, ob ein Agent im schlimmsten Fall nur einen kleinen Fehler produziert oder Zugriff auf Daten bekommt, die außerhalb seines eigentlichen Zwecks liegen.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptAt sunset in a modern meeting lounge, four colleagues pass unmarked task cards through ownership permission and review stations with laptops showing only blurred light. A documentary composition emphasizes practical consequences; every surface is blank and unbranded, with no readable text, words, numbers, labels, logos, screens, user interfaces, dashboards, or signs. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Cloud-Agenten laufen weiter, auch wenn Sie es nicht tun

Ein zweites Merkmal trennt Workspace Agents von einem klassischen Chatfenster: „They run in the cloud, so they can keep working even when you’re not“, schreibt OpenAI. Ein Agent muss also nicht in einer offenen Browser-Registerkarte auf weitere Anweisungen warten.

Das eröffnet Aufgaben, die Stunden oder länger dauern, etwa eine Recherche über mehrere Quellen, eine mehrstufige Datenaufbereitung oder eine Kette aus Rückfragen an verschiedene Systeme. Genau solche Abläufe beschreibt OpenAI mit dem Begriff long-running workflows, den das Unternehmen bereits im ersten Absatz der Ankündigung verwendet.

Wie schnell ein Agent mit weitreichenden Rechten und langer Laufzeit zum Sicherheitsthema werden kann, zeigt unsere Einordnung der Governance-Debatte um automatisierte Agenten-Zugriffe. Wer einem Cloud-Agenten stundenlange Autonomie einräumt, sollte vorher genau wissen, welche Systeme dieser Agent während dieser Zeit erreichen kann.

Ein still im Hintergrund laufender Prozess ist bequem, solange er tut, was er soll. Bricht er dagegen mitten in einer mehrstufigen Aufgabe ab, etwa weil eine externe Schnittstelle nicht antwortet, bleibt ein halb erledigter Vorgang zurück, den jemand manuell zu Ende bringen muss. Wie gut OpenAI solche Abbrüche protokolliert und meldet, verrät die Ankündigung nicht.

Vom Call-Notizen zum Follow-up: OpenAIs eigenes Vertriebsbeispiel

OpenAI liefert ein konkretes Beispiel aus dem eigenen Betrieb: „our sales team at OpenAI uses an agent to pull together details from call notes and account research, qualify new leads, and draft follow-up emails right in a rep’s inbox.“ Vier Arbeitsschritte in einem Agenten gebündelt: Notizen sichten, Recherche zusammenführen, Leads bewerten, E-Mail entwerfen.

Der Effekt bleibt laut OpenAI auf einer Ebene messbar: „It helps account teams spend less time stitching together details and more time with customers.“ Weniger Zeit mit dem Zusammensuchen von Informationen, mehr Zeit im direkten Kundenkontakt, das ist die Kernbehauptung, nicht mehr und nicht weniger.

Für ein einzelnes Beispiel aus dem eigenen Haus ist die Aussage naturgemäß nicht unabhängig geprüft. Ein Vertriebsteam bei OpenAI selbst hat andere Anreize und andere Datenzugänge als ein durchschnittliches Vertriebsteam in einem mittelständischen Unternehmen. Wer den Nutzen für die eigene Organisation einschätzen will, kommt an einem eigenen Pilotprojekt kaum vorbei.

Interessant ist trotzdem die Reihenfolge der genannten Schritte. Qualifizierung kommt vor dem E-Mail-Entwurf, nicht danach. Ein Agent, der zuerst bewertet und erst dann formuliert, vermeidet zumindest im Ansatz, dass jeder Lead automatisch dieselbe generische Vorlage erhält, unabhängig davon, wie aussichtsreich er tatsächlich ist.

Auffällig ist außerdem, dass OpenAI ausgerechnet ein Vertriebsbeispiel wählt und nicht etwa Kundensupport oder Personalwesen. Vertrieb ist ein Bereich mit vergleichsweise klaren, wiederholbaren Abläufen, in dem Fehler selten sofort teuer werden. Wer denselben Automatisierungsgrad in einem sensibleren Bereich plant, sollte diesen Unterschied im Blick behalten, bevor er das Beispiel unreflektiert übernimmt.

Slack wird zur zweiten Heimat der Agenten

Workspace Agents bleiben nicht in ChatGPT eingesperrt. Laut Ankündigung lassen sich dieselben Agenten „together in ChatGPT or Slack“ nutzen. Ein Team kann einen Agenten also dort aufrufen, wo es ohnehin schon kommuniziert, statt zusätzlich ein weiteres Fenster zu öffnen.

Diese Slack-Anbindung ist der eigentliche Verteilungshebel. Ein Werkzeug, das nur in ChatGPT existiert, konkurriert um Aufmerksamkeit mit jeder anderen offenen Anwendung. Ein Werkzeug, das direkt im bestehenden Team-Chat auftaucht, muss diese Aufmerksamkeit nicht erst erkämpfen.

Wie sensibel solche tief integrierten Zugänge sein können, zeigt der Fall um den Claude-Code-Quellcode-Leak in Unternehmensumgebungen. Je mehr Kanäle ein Agent gleichzeitig bedient, desto größer wird auch die Fläche, über die im Fehlerfall etwas nach außen dringen kann.

Für Administratorinnen heißt das konkret: Wer Workspace Agents in Slack erlaubt, sollte dieselben Kanal- und Kontoberechtigungen prüfen, die auch für jede andere Slack-Integration gelten. Ein Agent, der in einem öffentlichen Kanal läuft, sieht potenziell alles, was in diesem Kanal jemals gepostet wurde, nicht nur die aktuelle Anfrage.

Wer die Vorschau testen darf – und wie der Einstieg funktioniert

Zugang gibt es aktuell nicht für jeden ChatGPT-Vertrag. OpenAI beschränkt die Funktion ausdrücklich: „Workspace agents are available in research preview in ChatGPT Business, Enterprise, Edu, and Teachers plans.“ Ein persönlicher Plus- oder Free-Account reicht damit nicht aus.

Der Einstieg selbst bleibt niedrigschwellig gehalten: „To get started, click Agents in the ChatGPT sidebar and describe a workflow your team does often.“ Anschließend übernimmt die Software die technische Führung: „ChatGPT will guide you step by step to turn it into an agent.“

Research Preview bedeutet in der Praxis: Funktionsumfang und Verhalten können sich noch ändern, bevor OpenAI die Agenten breiter ausrollt. Teams, die jetzt einsteigen, testen also nicht nur einen Workflow, sondern auch, wie stabil OpenAIs eigene Kontrollversprechen im Alltag tatsächlich bleiben.

Ein sinnvoller erster Test bleibt klein: ein einzelner, klar begrenzter Workflow mit wenigen Beteiligten, bevor der Agent auf ein ganzes Team oder gar mehrere Abteilungen ausgeweitet wird. Wer stattdessen gleich mit den sensibelsten Unternehmensdaten startet, verschenkt genau jenen Vorlauf, den eine Vorschau eigentlich bieten soll.