OpenClaw in Microsoft Teams: Azure-Bot statt Seitenkanal

OpenClaw kann Microsoft Teams als Bot-Kanal anbinden. Das ist interessant, wenn ein Agent nicht in einem weiteren Experimentier-Chat landen soll, sondern dort, wo Supportfälle, Freigaben und Projektfragen ohnehin auftauchen.

Der Nutzen ist klar, der Einstieg aber kein Selbstläufer. Bot-Registrierung, ein öffentlich erreichbarer Endpoint, App-Manifest und Microsoft-Graph-Rechte müssen zusammenpassen. Wer diese Punkte erst klärt, wenn der Bot schon im Tenant sichtbar ist, verliert schnell Zeit an Berechtigungen statt an der eigentlichen Agentenlogik.

Teams ist kein Pflichtbestandteil eines OpenClaw-Setups. Der Kanal lohnt sich, wenn ein Assistent bewusst im Microsoft-365-Arbeitsfluss erreichbar sein soll und das Betriebsteam die zusätzliche App- und Berechtigungslogik tragen kann.

Vom lokalen Test zum Teams-Kanal

In aktuellen OpenClaw-Installationen ist die Teams-Integration als Plugin vorgesehen. Ältere oder bewusst schlanke Paket-Builds können das Paket mit openclaw plugins install @openclaw/msteams ergänzen.

Der größere Aufwand beginnt bei der Teams-App. Für den schnellen Einstieg kann @microsoft/teams.cli Registrierung, Manifest und Credentials vorbereiten. Weil sich Befehle und Flags in Preview-Releases ändern können, sollte das Team die verwendete Version zusammen mit dem Setup dokumentieren.

Lokale Tests brauchen außerdem einen öffentlich erreichbaren Bot-Endpoint. Teams kann einen Dienst auf localhost nicht direkt ansprechen. Ein Dev Tunnel kann Port 3978 veröffentlichen; der Bot-Endpunkt liegt dann unter einer devtunnels.ms-Adresse mit /api/messages.

Das ist kein Nebendetail. Der Entwicklungsweg erlaubt anonyme Zugriffe auf den Tunnel, weil Teams sich dort nicht wie ein normaler Client authentifizieren kann. Eingehende Bot-Requests werden weiterhin durch das Teams SDK validiert. Für einen kleinen Test ist das handhabbar. Vor einem produktionsnahen Einsatz würde ich Endpoint, Request-Validierung, erlaubte Nutzer und den Rückweg bei Störungen schriftlich festziehen.

Was im Alltag trägt

Für einen begrenzten Pilot reichen Textnachrichten und DMs. Damit lässt sich prüfen, ob Antworten im richtigen Kontext ankommen, ob der Agent nur die vorgesehenen Personen erreicht und ob der Endpoint stabil bleibt.

Dateien sind der Punkt, an dem Teams deutlich komplexer wird. Ein Agent kann in einer Direktnachricht mit Anhängen umgehen und trotzdem in einem Teamraum an Berechtigungen scheitern. Für Dateiübertragungen in Channels und Gruppenchats braucht die Integration zusätzliche Microsoft-Graph-Rechte sowie eine sharePointSiteId. Das gehört früh in die Architekturentscheidung, nicht ans Ende des Projekts.

Adaptive-Card-Polls sind eine sinnvolle spätere Ausbaustufe, wenn ein Agent Entscheidungen einsammeln soll. Ich würde sie erst aktivieren, nachdem Text- und DM-Flüsse stabil laufen.

Teams bleibt dabei ein normaler OpenClaw-Messaging-Kanal. Die Agentenlogik ist nicht grundsätzlich anders als bei anderen Kanälen; Identität, App-Paket, Netzwerk und Berechtigungen machen den Unterschied.

Reality Check

• Sinnvoll für: kontrollierte Pilot-Setups, in denen OpenClaw in DMs oder wenigen ausgewählten Teams-Räumen erreichbar sein soll.
• Typisches Fehlerbild: Der Bot funktioniert im Einzelchat, scheitert aber beim Gruppen-Dateiversand an fehlender sharePointSiteId oder Graph-Berechtigung.
• Vor dem Test prüfen: Ist der Endpoint öffentlich erreichbar? Stimmen Bot-Registrierung und Manifest? Sind nur die vorgesehenen Nutzer und Räume freigegeben?
• Offen: Ein produktiver Tenant-Rollout, die tatsächlich benötigten Graph-Scopes und die Verteilung über das Admin Center brauchen einen eigenen Testplan.
• Sicherheitsrisiko: mittel, weil der Kanal einen Eingang für Bot-Nachrichten schafft.
• Recovery: Bei Fehlern zuerst Tunnel beziehungsweise Hosted-Endpoint, Request-Validierung und Berechtigungen prüfen; danach den Pilot auf DMs zurücknehmen.

Die Einschätzung stützt sich auf die OpenClaw-Referenz und Microsoft Learn. Ein eigener Tenant-Test steht noch aus.

Wann sich Teams lohnt

Für ein kleines OpenClaw-Experiment sind Telegram, Slack oder Discord meist schneller. Teams lohnt sich, wenn der Zielkontext bereits Microsoft 365 ist: etwa für interne Assistenz, Helpdesk-Fragen, Projektstatus oder Freigaben.

Die entscheidende Frage lautet nicht, ob sich ein Bot registrieren lässt. Entscheidend ist, welche Arbeit er übernehmen soll. Reicht ein DM-Kanal? Muss der Agent in Channels antworten? Sollen Dateien in Gruppen verarbeitet werden? Erst daraus ergibt sich, ob ein einfaches Text-Setup genügt oder ob SharePoint und Graph zum Projekt gehören.

Mein pragmatischer Start wäre ein enger Pilot: wenige erlaubte Nutzer, ein dokumentierter Tunnel oder Hosted-Endpoint und zunächst Text plus DMs. Wenn das stabil läuft, lässt sich mit realen Nutzungssignalen entscheiden, ob Gruppen-Dateien, Polls und weitere Teams-Räume den zusätzlichen Betriebsaufwand rechtfertigen.