Was das aktuelle 2.x-Release für kontrollierte Agenten-Workflows im Mittelstand bringt
Zielgruppe: Entwickler, DevOps- und IT-Praktiker im Mittelstand
Lesezeit: ca. 3 Minuten
Tags: [n8n, human-in-the-loop, automation]
Wer KI-Agenten in n8n produktiv betreibt, kennt den Zielkonflikt: Der Agent soll selbständig Tools aufrufen, aber keine Gutschrift buchen, kein Ticket schließen und keine Kundenmail versenden, ohne dass ein Mensch dafür geradesteht. In der Praxis endet das häufig in Workarounds: Agenten laufen dauerhaft im Testbetrieb, oder ganze Tool-Gruppen bleiben deaktiviert.
Ursache: Agenten entscheiden situativ (fachlich: nicht-deterministisch), Freigabeprozesse sind vorher festgelegt
Ein Agent entscheidet zur Laufzeit, welches Tool er mit welchen Parametern aufruft. Klassische Workflow-Engines arbeiten dagegen auf festen Pfaden. Drei Änderungen im aktuellen 2.x-Zyklus adressieren diese Lücke: Anbindung, Kontrolle, Identität. Stand 15.08.2026 ist 2.34.6 die stabile Version, 2.35.2 läuft als Beta (Release Notes).
1. MCP-Server ohne separaten Client-Node
Ein Agent lässt sich an ausgewählte MCP-Server anbinden, ohne dafür einen MCP Client-Node zu konfigurieren: Server im Nodes-Panel auswählen, anmelden, fertig. Abgedeckt sind zunächst Apify, Linear, monday.com, Todoist, Notion und PostHog; für alles andere bleibt der MCP Client-Node der Weg. Das Anbinden externer Werkzeuge wird damit zur Konfiguration statt zum Integrationsprojekt. (Changelog, Eintrag „Connect to MCP servers with less setup", n8n 2.22)
2. Human-in-the-Loop vor dem Tool-Aufruf
Einzelne Tools lassen sich so absichern, dass ein Agent sie erst nach ausdrücklicher menschlicher Freigabe ausführt. Eingerichtet wird das über den Tools-Connector des Agent-Nodes (im Tools-Panel den Abschnitt „Human review" wählen), einen Freigabekanal konfigurieren, unter anderem Slack, Microsoft Teams, Telegram, Gmail, Outlook, Google Chat oder das eingebaute n8n-Chat-Interface und die betroffenen Tools an dessen Tool-Connector hängen. Beim Aufruf pausiert der Workflow und sendet eine Anfrage mit Tool-Name und Parametern. Bei Ablehnung wird die Aktion abgebrochen und der Agent darüber informiert. Risikoreiche Aktionen werden so deterministisch, während der Rest des Agenten autonom bleibt. (Doku · Changelog, Eintrag „Human-in-the-loop for AI tool calls", n8n 2.6)
3. Microsoft-Agent-365-Trigger
Der Microsoft Agent 365 Trigger-Node lässt n8n-Agenten als Mitglieder eines Teams in Microsoft-365-Anwendungen auftreten. Der Agent erhält eine eigene Identität im Microsoft-Tenant samt E-Mail-Adresse, ansprechbar per @-Mention in Teams, per Mail oder über SharePoint-Berechtigungen. Chat-Modelle, Memory, Tools und Sub-Workflows lassen sich wie gewohnt anhängen. Wo ohnehin in M365 gearbeitet wird, entfällt der Bruch zwischen Automatisierung und Arbeitsplatz. (Changelog, Eintrag „Microsoft Agent 365 Trigger node", n8n 2.20)
Hinweise und Fallstricke
- Der System-Prompt muss den Review-Schritt erwähnen, sonst geht der Agent mit der Pause und der Ablehnung nicht sauber um.
- Das Verhalten bei Timeout einer Freigabeanfrage ist in der Doku nicht spezifiziert, also vor dem Produktivbetrieb selbst testen.
- Der
Microsoft Agent 365 Triggersetzt einen Microsoft-365-Tenant voraus. Die Identität ist ein Objekt in Entra ID und gehört in den regulären Lifecycle- und Berechtigungsprozess. - Die drei Funktionen stammen aus mehreren Releases, nicht aus einem Update: Freigaben ab 2.6, Agent-365-Trigger ab 2.20, MCP-Direktanbindung ab 2.22 (Versionsstand vorher prüfen).
Zwei Einstiegsszenarien
Support-Triage. Eingehende Support-Mails werden klassifiziert und mit Kontext aus dem angebundenen Notion-Workspace angereichert. Antwortentwürfe entstehen selbständig, der Versand nach außen und Ticket-Abschluss laufen über einen Freigabe-Schritt in Teams.
Fehlermeldungs-Triage mit DevOps-Anbindung. Eine eingehende Fehlermeldung aus dem Monitoring, Ticketsystem oder Postfach wird analysiert: Stacktrace und Log-Auszug werden normalisiert, über den angebundenen Repository- oder Wissens-Kontext lassen sich die wahrscheinlich betroffenen Code-Stellen benennen, und der Agent formuliert ein bis drei Bearbeitungsvorschläge mit kurzer Begründung. Das Anlegen des Work Items im Backlog hängt mit der Freigabe zusammen. Für Azure DevOps existiert kein dedizierter Node, denn das Work Item wird per HTTP Request gegen die REST-API erzeugt, so wie in der Community-Vorlage dazu. Im Backlog landet damit eine vorstrukturierte Aufgabe statt einer rohen Fehlermeldung und kein Ticket wird ohne Bestätigung erzeugt.
Fazit
Der Nutzen entsteht in beiden Fällen nicht durch mehr Autonomie, sondern durch klar gezogene Grenzen. Die Analyse und Vorbereitung erfolgen automatisch, der wirksame Schritt nach Freigabe.
Wer einen solchen Ablauf für den eigenen Betrieb bewerten oder aufsetzen möchte, findet den Weg dorthin über die Kontaktseite.
Quellen:
n8n Release Notes
n8n Changelog
Human-in-the-loop for tools | n8n Docs
n8n Vorlage: Create an automated workitem in Azure DevOps
