Coworker statt Copilot: Die Architektur hinter dem Rebranding der Enterprise-KI

Innerhalb eines Sommers haben sich die Plattformen, die Fragen zu Unternehmensdaten beantworten, auf denselben Begriff geeinigt. Glean nennt sich nun "the enterprise AI coworker". Snowflake hat Intelligence in CoWork umbenannt. Databricks brachte Genie One als "all-new agentic coworker" heraus, am selben Tag, an dem Microsoft Copilot Cowork allgemein verfügbar wurde. Danach folgten die Konnektoren: Genie One wurde in Excel und Google Sheets integriert, und Snowflakes eigener Weg nach Teams und Microsoft 365 Copilot stand bereits bereit. Dieselben Anbieter, die ihre Produkte rund um den Begriff "Coworker" umbenennen, bauen zugleich die technische Infrastruktur, um diese Produkte dorthin zu bringen, wo ihre Nutzer bereits arbeiten. Nicht nur in Excel und Teams, sondern in jedem Werkzeug, in dem die eigentliche Aufgabe stattfindet. "Coworker" verkauft sich derzeit offenbar besser als "Intelligence". Das ist jedoch kein Grund, dieses Muster als reine Marketingfloskel abzutun, denn es liefert erhebliche Einblicke in die technischen Aspekte der Umsetzung und der Governance insgesamt.

Nachschlagen versus Handeln

Das "Intelligence"-Branding, in dessen Tradition Salesforce Einstein Analytics, IBM Watson Analytics und Snowflakes eigenes Produkt vor Juni standen, beschrieb eine intelligentere Form des Nachschlagens: eine Frage in einer eigenen Oberfläche stellen und eine bessere Antwort erhalten als zuvor. Der gesamte Vorgang findet innerhalb dieser Oberfläche statt. Ein Nutzer besucht die Anwendung, stellt eine Frage, liest die Antwort und verlässt sie wieder; das Werkzeug muss nirgendwo sonst existieren. "Coworker" deutet auf eine andere Aufgabe hin. Databricks beschreibt Genie One als ein System, das Dokumente entwirft, Berichte erstellt und Aufgaben plant, nicht nur Fragen zu einer Tabelle beantwortet. Erst die Konnektoren für Excel und Google Sheets machen aus "entwirft Dokumente und erstellt Berichte" mehr als eine bloße Ankündigung. Snowflake, das das Teams-Äquivalent bereits Monate zuvor gebaut hatte, musste nur noch darauf verweisen.

Das erklärt auch, warum das Modell der eigenständigen Ziel-Anwendung, das den Großteil des vergangenen Jahrzehnts dominiert hat, jetzt und nicht früher endet. Es ging nie allein darum, dass eine bessere Chat-Oberfläche das Adoptionsproblem gelöst hätte. Das Modell ging davon aus, die größte Herausforderung bestehe darin, eine Oberfläche zu bauen, die attraktiv genug ist, damit Nutzer ihre Gewohnheiten ändern und sie aufsuchen. Diese Annahme funktioniert für ein Nachschlage-Werkzeug durchaus. Sie scheitert bei einem Werkzeug, dessen Aufgabe das Handeln ist, denn ein Agent, der eine Aktion ausführt, kann das Ergebnis nirgendwo anders ablegen als in dem Werkzeug, in dem die Arbeit tatsächlich stattfindet. Sowohl der Wandel im Branding als auch der Wandel in der Distribution folgen demselben Fähigkeitsanspruch: Werkzeuge, die nur antworten, können in ihrem eigenen Raum bleiben, Werkzeuge, die handeln, können das nicht.

Die Governance-Rechnung, die mit dem Handeln kommt, nicht nur mit dem Antworten

Der Anspruch, dass ein Produkt handelt und nicht nur antwortet, erhöht die Anforderungen, die es erfüllen muss, sobald es seine native Oberfläche verlässt. Die Berechtigungen, die normalerweise eine Abfrage kontrollieren, Row-Level-Security, Column-Masking, die grundsätzliche Sichtbarkeit einer Tabelle, müssen zum Zeitpunkt der Abfrage innerhalb eines Werkzeugs durchgesetzt werden, das die Plattform nicht vollständig kontrolliert. Das funktioniert nur, weil die Berechtigungsprüfung zum Abfragezeitpunkt tatsächlich stattfindet. Das Databricks-Excel-Add-in authentifiziert sich per SSO, und Genie setzt Unity-Catalog-Berechtigungen über eine On-behalf-of-User-Authentifizierung durch, sodass dieselbe Zugriffskontrolle, die Genie Ones native Oberfläche regelt, identisch gilt, wenn die Anfrage aus einer Excel-Zelle stammt. Die Cortex-Agents-Integration von Snowflake in Teams und Copilot läuft über ein OAuth-Service-Principal für die Bot-Anwendung selbst, unterlegt mit Row-Level-Security, sodass der Bot zwar mit Snowflake kommunizieren kann, die Row-Level-Richtlinie ihn aber weiterhin daran hindert, etwas zurückzugeben, das der anfragende Nutzer nicht sehen darf.

Das zentrale Versprechen der semantischen Schicht ist eine einzige, governance-konforme Antwort, konsistent über jede Oberfläche hinweg, auf der die Frage gestellt wird. Die Vervielfachung der Oberflächen, Excel, Sheets, Teams, Slack, Copilot, das native Chatfenster, ist ein direkter Belastungstest für dieses Versprechen, und dieser Test fällt für ein handelndes Werkzeug härter aus als für ein Werkzeug, das nur antwortet. Ob die Governance diesem Belastungstest tatsächlich standhält, lässt sich durch keine Ankündigung allein klären, aber die Architektur selbst liefert erste Antworten. Es ist zudem nicht der einzige Test, der gerade läuft. Zu diesem Zeitpunkt des Sommers wurde dasselbe Governance-Modell bereits mit einem Aufrufer konfrontiert, für den niemand eine Tabellenkalkulationszelle vorgesehen hatte.

Ein zweiter Typ von Besucher

Databricks überführte Genie One in die Beta-Phase als Managed-MCP-Server, erreichbar unter /api/2.0/mcp/genie. Etwa zeitgleich veröffentlichte das Unternehmen databricks/databricks-agent-skills, ein offiziell gepflegtes GitHub-Repository, das Databricks-spezifisches Wissen als Agent Skills verpackt, einem offenen Standard, ergänzt um eine neue CLI-Befehlsgruppe databricks aitools. An dieser Stelle lässt sich das eingangs formulierte Argument weiterführen: Ein Produkt, das handeln und nicht nur antworten soll, muss überall dort erreichbar sein, wo die Handlung tatsächlich stattfindet, nicht nur über eine eigene Oberfläche, die zum Besuch gedacht ist. Für einen menschlichen Mitarbeiter bedeutete das, in Excel und Teams präsent zu sein statt in einem eigenständigen Chatfenster. Für einen KI-Agenten, der innerhalb einer IDE, eines Orchestrators oder der Tool-Aufruf-Schleife eines anderen Agenten läuft, bedeutet es genau dasselbe: erreichbar zu sein, wo immer dieser Agent bereits arbeitet, nicht nur über Genies eigenen Eingang.

Die technische Infrastruktur, die dies auf menschlicher Seite erforderte, SSO für das Excel-Add-in, On-behalf-of-User-Authentifizierung für Genie, ein OAuth-gestützter Cortex-Agents-Bot in Teams, hat hier ein direktes Gegenstück, das sich an einen anderen Aufrufer richtet. Während der Excel-Konnektor einer Person erlaubt, Genie in eine Tabelle zu holen, ohne Genie selbst zu öffnen, erlaubt der MCP-Server einem Agenten, der innerhalb von Cursor, Claude Desktop oder einem eigenen Orchestrator läuft, Genie in das einzubinden, was er gerade baut, ohne dass ein Entwickler zuvor eine maßgeschneiderte Integration bauen muss. Das gelöste Distributionsproblem ist dasselbe, nur eine Ebene höher im Stack angesiedelt.

Zwei Richtungen durch dieselbe Tür

Model Context Protocol, der offene Standard, den Anthropic zur Anbindung von KI-Systemen an externe Werkzeuge eingeführt hat, hat für eine Plattform wie Databricks schon immer Datenverkehr in beide Richtungen unterstützt. Genie One unterstützt seit einiger Zeit ausgehende, benutzerdefinierte MCP-Verbindungen, die es den eigenen Agenten einer Organisation erlauben, externe Werkzeuge über das Unity AI Gateway aufzurufen. Neu ist, dass die umgekehrte Richtung nun zu einem vollwertigen, von Databricks verwalteten Produkt wird: Genie One selbst, als aufrufbares Werkzeug bereitgestellt, für Clients, die Databricks weder betreibt noch entwickelt hat.

Das ist eine deutlich weiterreichende Zusage als das Hinzufügen eines Chatfensters. Eine Ziel-Oberfläche kann so leistungsfähig oder eingeschränkt sein, wie ein Anbieter es festlegt, denn jede Anfrage trifft über den eigenen Eingang dieses Anbieters ein. Ein über MCP bereitgestelltes Werkzeug muss sich hingegen korrekt gegenüber Aufrufern verhalten, deren Verhalten der Anbieter nicht vollständig vorhersehen kann, von Clients, die die interaktive MCP-Apps-Erweiterung unterstützen und Diagramme sowie Quellenangaben direkt einbetten, bis hin zu reinen Text-Clients, die nur eine Antwort sehen.

Die Governance-Frage stellt sich hier auf dieselbe Weise wie zuvor, und Databricks beantwortet sie auf dieselbe Weise: Der verwaltete Proxy vor dem MCP-Server stellt jeden Aufruf mit dem eigenen OAuth-Token des authentifizierten Nutzers, sodass eine Anfrage aus Cursor oder Claude Desktop vom Unity Catalog exakt so bewertet wird wie eine native Abfrage, nicht über ein lockereres, separates Zugriffsmodell für externe Aufrufer.

Skills als der stillere Teil der Wette

Das gleichzeitig veröffentlichte Agent-Skills-Repository adressiert ein enger gefasstes, aber verwandtes Problem: Ein externer Coding-Agent darf Genie zwar möglicherweise aufrufen, weiß aber deshalb noch nicht, wie er Databricks gut nutzt. Skills als Kategorie verpacken prozedurales Wissen, Konventionen und übliche Arbeitsabläufe, nicht den live Zugriff auf Daten. Microsoft ging im Juni eine vergleichbare Wette ein mit Fabric Skills für GitHub Copilot, Claude und CLI, einem Open-Source-Toolkit, das Coding-Agenten erlaubt, Power-BI-Semantikmodelle und andere Fabric-Assets direkt zu erstellen und abzufragen. Keines der beiden Unternehmen stellt lediglich eine API bereit. Beide bringen externen Agenten bei, sich innerhalb der eigenen Plattform kompetent zu bewegen, ohne dass ein Entwickler zuvor selbst zum Experten werden muss.

Zusammengenommen führen der MCP-Server und das Skills-Repository dasselbe Argument einen Schritt weiter. Die Arbeit an Excel und Teams hat gezeigt, dass ein Produkt, das handeln soll, überall dort erreichbar sein muss, wo die Handlung stattfindet, nicht nur über den eigenen Eingang. Der MCP-Server und das Skills-Repository etablieren etwas Verwandtes: Erreichbarkeit allein macht einen Aufrufer noch nicht kompetent. Ein externer Agent, der Genie zum ersten Mal aufruft, kennt die Konventionen von Databricks nicht automatisch, wofür genau das Skills-Repository gedacht ist. Databricks hat damit beide Hürden beseitigt, die den eigenen Coworker bislang an die eigene Oberfläche gebunden hatten: wohin man gehen muss, um ihn zu nutzen, und was man bereits wissen muss, um ihn gut zu nutzen.

Der Test, der tatsächlich läuft

Nichts davon ist durch Ankündigungen bereits entschieden, und jede Aussage in diesem Beitrag ist letztlich die Selbstauskunft eines Anbieters über die eigene Architektur: Ein Managed MCP Server liegt weiterhin hinter einem Workspace-Preview-Flag, und On-behalf-of-User-Authentifizierung lässt sich leichter beschreiben als in großem Maßstab prüfen. Das Design selbst ist jedoch, wie beschrieben, in sich konsistent. Excel, Teams und MCP sind drei getrennte Oberflächen, von unterschiedlichen Teams zu unterschiedlichen Zeitpunkten gebaut, für zwei unterschiedliche Aufrufer, einen Menschen und einen Agenten. Jede greift dennoch auf dasselbe Grundprinzip zurück: kein separates, großzügigeres Credential für den externen Aufrufer, sondern derselbe OAuth-Token und dieselbe Unity-Catalog- beziehungsweise Row-Level-Prüfung, die bereits die native Oberfläche regelt. Diese Art von Konsistenz zeigt sich typischerweise dann, wenn die zugrunde liegende Durchsetzung von Anfang an dafür gebaut wurde, von überall aus aufgerufen zu werden. Ob sie einer gegnerischen Prüfung im großen Maßstab standhält, ist eine andere Frage, die nur die Governance-Logs beantworten können. Aber nach den hier zusammengetragenen Belegen scheint das Berechtigungsmodell tatsächlich intakt zu bleiben, statt an den Rändern auszudünnen, und "Coworker" erweist sich damit als mehr als nur ein Wort der Marketingabteilung.