OpenClaw in Microsoft Teams: Azure-Bot statt Seitenkanal

OpenClaw behandelt Microsoft Teams inzwischen als eigenen Bot-Kanal. Laut OpenClaw-Doku ist das Paket @openclaw/msteams für Bot-Konversationen gedacht; die Teams-Seite nennt Textnachrichten, Direct-Message-Anhänge und Adaptive-Card-Polls als unterstützte Oberfläche.

Damit wird Teams für Agenten-Setups interessant, die nicht im Entwickler-Chat bleiben sollen. In vielen Organisationen ist Teams ohnehin der Ort für Support, Projektarbeit und interne Freigaben. Ein OpenClaw-Agent braucht dort aber mehr Sorgfalt als in einem privaten Messenger-Test: Bot-Registrierung, öffentlich erreichbarer Endpoint, Manifest und Microsoft-Graph-Rechte gehören zum Setup.

Microsoft beschreibt diesen Praxispfad in einem Learn-Sample vom 2. Juni 2026. Das Sample stellt openclaw-dev als Entwicklerwerkzeug vor, das OpenClaw mit Azure OpenAI als gehosteten Assistenten bereitstellt. Der Browser-Chat ist dort Standard, Microsoft Teams wird als optionales Add-on genannt. Die Einordnung ist wichtig: Teams ist kein Pflichtweg für OpenClaw, sondern ein Kanal für Umgebungen, die Agenten bewusst in Microsoft 365 testen wollen.

Vom lokalen Bot zum Teams-Kanal

Nach Angaben der OpenClaw-Doku ist Microsoft Teams in aktuellen OpenClaw-Releases als gebündeltes Plugin enthalten. Für normale Paket-Builds ist deshalb keine separate Installation nötig. Nur ältere oder bewusst abgespeckte Installationen sollen das npm-Paket direkt installieren; die Doku nennt dafür openclaw plugins install @openclaw/msteams.

Der eigentliche Aufwand liegt nicht beim Plugin, sondern bei Teams selbst. Die OpenClaw-Doku verweist für den schnellen Einstieg auf @microsoft/teams.cli. Diese CLI soll Bot-Registrierung, Manifest-Erstellung und Credential-Erzeugung in einem Schritt abdecken. Gleichzeitig markiert die Doku die Teams CLI als Preview und weist darauf hin, dass Befehle und Flags zwischen Releases wechseln können.

Für lokale Tests braucht Teams außerdem einen erreichbaren Bot-Endpoint. Laut OpenClaw-Doku kann Teams localhost nicht direkt erreichen. Der empfohlene Entwicklungsweg führt deshalb über Microsoft Dev Tunnels: ein Tunnel wird erstellt, Port 3978 wird veröffentlicht, und der Bot-Endpoint liegt anschließend unter einer devtunnels.ms-Adresse mit /api/messages.

Das ist kein kosmetisches Detail. Wer Teams an OpenClaw hängt, öffnet einen Eingang für Bot-Nachrichten. Die Doku nennt für den Tunnel --allow-anonymous, weil Teams sich gegenüber Dev Tunnels nicht authentifizieren kann. Gleichzeitig steht dort, dass eingehende Bot-Requests weiterhin durch das Teams SDK validiert werden. Für Tests ist das handhabbar; für produktionsnahe Umgebungen bleibt es ein Betriebs- und Sicherheitsdetail, das dokumentiert werden sollte.

Was Teams konkret kann

Die Teams-Doku von OpenClaw beschreibt den aktuellen Status knapp: Text und Direct-Message-Anhänge werden unterstützt. Polls laufen über Adaptive Cards. Für Dateiübertragung in Channels und Gruppenchats braucht OpenClaw dagegen zusätzliche Microsoft-Graph-Berechtigungen und eine sharePointSiteId.

Diese Grenze ist im Alltag schnell entscheidend. Ein Agent, der in einer Direktnachricht eine Datei annehmen oder senden kann, ist noch nicht automatisch ein Datei-Bot für Abteilungskanäle. In Teams hängt Gruppen-Dateiversand an SharePoint. Wer das nicht einplant, landet leicht bei einem Setup, das im Einzelchat funktioniert und im Teamraum an Berechtigungen scheitert.

Die Plugin-Referenz nennt die Oberfläche schlicht als channels: msteams. Das hilft bei der Einordnung: Teams ist in OpenClaw kein Sonderfall mit eigener Agentenlogik, sondern ein Messaging-Kanal neben anderen Kanälen. Der Unterschied liegt vor allem im Microsoft-Setup drumherum.

Microsofts openclaw-dev-Sample setzt denselben Akzent. Laut Microsoft Learn deployt das Werkzeug OpenClaw als gehosteten Assistenten, nutzt Azure OpenAI in Foundry Models als Backend und nennt gpt-5-mini als Default-Modell. Teams erscheint dort als optionale Erweiterung, damit der Assistent auch vom Smartphone aus in Teams erreichbar ist. Zugleich enthält das Sample den klaren Alpha-Hinweis und keine Produktionsgarantie.

Reality Check

• Getestet mit: nicht selbst getestet; Quellenstand OpenClaw-Doku und Microsoft Learn, 2026-06-04
• Funktioniert gut für: interne Pilot-Setups, bei denen OpenClaw in Teams-DMs oder ausgewählten Teams-Räumen erreichbar sein soll
• Bricht wahrscheinlich bei: Gruppen-Dateiversand ohne sharePointSiteId und passende Graph-Berechtigungen; lokalen Tests ohne öffentlich erreichbaren Endpoint
• Nicht getestet: produktiver Tenant-Rollout, tatsächliche Graph-Scopes, Teams-App-Verteilung über Admin Center
• Sicherheitsrisiko: mittel
• Betriebsaufwand: mittel
• Recovery: unklar

Für wen sich der Kanal lohnt

Für kleine OpenClaw-Experimente ist Teams nicht der bequemste Startpunkt. Telegram, Slack oder Discord sind oft schneller eingerichtet, weil weniger Microsoft-Tenant- und App-Registrierungslogik im Weg steht. Teams lohnt sich eher dort, wo der Zielkontext bereits Microsoft 365 ist: Helpdesk, interne Assistenz, Projektstatus, Freigaben oder ein Agent, der keinen weiteren Chat-Ort erzeugen soll.

Für Agenten-Builder bedeutet das: Nicht mit dem Bot-Manifest anfangen, sondern mit dem Nutzungsschnitt. Soll der Agent nur per DM erreichbar sein? Muss er in Channels sprechen? Soll er Dateien in Gruppen verschicken? Braucht er Polls? Diese Fragen entscheiden, ob das einfache Text-Setup reicht oder ob SharePoint- und Graph-Themen Teil des Projekts werden.

Die starke Seite der Integration liegt in der Nähe zum Arbeitsfluss. Ein OpenClaw-Agent in Teams kann dort antworten, wo viele Teams Aufgaben verteilen. Die schwache Seite ist dieselbe: Microsofts Umgebung bringt Identität, Berechtigungen, App-Pakete und Netzwerk-Erreichbarkeit mit. Wer Teams als OpenClaw-Kanal einführt, baut also nicht nur einen Bot ein, sondern übernimmt ein Stück Microsoft-365-Betrieb.

Der realistische Einstieg ist ein enger Pilot: eine kontrollierte Umgebung, wenige erlaubte Nutzer, ein sauber dokumentierter Tunnel oder Hosted-Endpoint und zunächst Text plus DMs. Danach lässt sich entscheiden, ob Gruppen-Dateien, Adaptive-Card-Polls und breitere Teams-Räume den zusätzlichen Betriebsaufwand tragen.