KI-Agenten-Plattformen im Vergleich: Low-Code, Framework oder Eigenentwicklung?

Wer einen KI-Agenten einführen möchte, steht früh vor einer Grundsatzentscheidung: auf eine fertige Plattform setzen oder selbst entwickeln? Zwischen dem Agenten-Baukasten einer Office-Suite und einer Eigenentwicklung auf Modell-APIs liegen mehrere Zwischenstufen. Dieser Ratgeber ordnet die vier wichtigsten Wege ein und vergleicht sie nach Integration, Hosting, Kontrolle, Evaluation, Lock-in, Kosten und benötigter Kompetenz.

Worum es bei der Plattformwahl geht

Die Plattform legt fest, wo ein Agent läuft, wie er an Ihre Systeme angebunden wird, wer sein Verhalten ändern kann und wie gut sich prüfen lässt, was er tut. Das Sprachmodell ist dabei austauschbarer, als oft angenommen wird. Schwerer zu wechseln sind Integrationen, Berechtigungskonzepte und die Betriebsprozesse, die um einen Agenten entstehen. Wie Agenten technisch aufgebaut sind, erklärt der Ratgeber Wie funktionieren KI-Agenten?.

Dieser Artikel behandelt die Frage, auf welcher Basis ein einzelner Agent oder eine Gruppe von Agenten gebaut wird. Wie mehrere Agenten koordiniert und gesteuert werden, ist ein eigenes Thema; dazu gibt der Beitrag AI Agent Orchestration Platforms einen Überblick.

Vier Wege zum eigenen KI-Agenten

Die Matrix ordnet die vier Kategorien nach zwei Achsen: wie viel Aufwand der Einstieg erfordert und wie viel Kontrolle und Flexibilität Sie über das Verhalten des Agenten erhalten. Das Feld rechts unten ist bewusst als Warnung gesetzt: Wer eine Plattform mit hohem Aufwand über ihre Grenzen hinaus anpasst, zahlt den Preis einer Eigenentwicklung, ohne deren Kontrolle zu erhalten.

Agenten in einer bestehenden Suite: Microsoft Copilot Studio

Copilot Studio ist nach Herstellerangaben eine grafische Low-Code-Umgebung, in der Agenten und Workflows erstellt, mit Unternehmensdaten verbunden und in Kanälen wie Microsoft Teams, Microsoft Copilot oder auf Websites bereitgestellt werden. Systeme werden über vorgefertigte oder eigene Konnektoren angebunden; laut Dokumentation lassen sich auch bestehende MCP-Server als Werkzeuge hinzufügen. Für Betrieb und Governance nennt Microsoft Analysefunktionen, Evaluationen mit Testsätzen, ein Agenteninventar mit rollenbasiertem Zugriff sowie Data-Loss-Prevention-Richtlinien, die Administratoren im Power Platform Admin Center festlegen. Die Abrechnung ist je nach Agententyp lizenz- oder verbrauchsbasiert.

Der Vorteil liegt in der Nähe zu Identitäten, Dokumenten und Berechtigungen, die in Microsoft 365 bereits gepflegt werden. Die Grenze liegt dort, wo Daten außerhalb der Microsoft-Cloud bleiben müssen oder der Agent ein Verhalten braucht, das die Plattform nicht vorsieht. Typische Kandidaten sind interne Assistenten, die Richtlinien, Projektunterlagen oder Vorlagen aus Microsoft 365 durchsuchen und daraus Entwürfe erstellen. Je mehr Systeme außerhalb der Suite beteiligt sind, desto mehr Aufwand fließt in eigene Konnektoren, und desto genauer sollten Sie prüfen, ob die Plattform noch der kürzeste Weg ist.

Workflow- und Low-Code-Automatisierung mit KI-Knoten: n8n und Make

Workflow-Werkzeuge verbinden Systeme über grafisch modellierte Abläufe und ergänzen diese um KI-Bausteine. n8n bietet nach Herstellerangaben einen AI-Agent-Knoten, Knoten für lokal betriebene Modelle über Ollama, einen MCP-Client-Knoten zur Nutzung externer MCP-Server und einen MCP-Server-Trigger, der eigene Workflows als MCP-Werkzeuge bereitstellt. Für Tests gibt es eine Evaluationsfunktion, die Ausgaben gegen bekannte Testfälle vergleicht. n8n lässt sich selbst hosten, etwa per Docker auf eigener Infrastruktur, oder als n8n Cloud nutzen. Die Software steht als „fair-code“ unter der Sustainable Use License und der n8n Enterprise License, also nicht unter einer klassischen Open-Source-Lizenz.

Make ist ein cloudbasierter Automatisierungsdienst. Nach Herstellerangaben bietet Make eigene AI Agents, ein MCP-Client-Modul, mit dem Szenarien Werkzeuge auf externen MCP-Servern aufrufen, sowie einen von Make gehosteten MCP-Server. Beide Werkzeuge spielen ihre Stärke aus, wenn ein Agent in einen klar strukturierten Ablauf mit vielen Systemschritten eingebettet ist.

Die Grenzen zeigen sich, wenn der Agent selbst den größten Teil der Logik trägt. Lange, verzweigte Abläufe mit vielen Ausnahmen werden im grafischen Editor schnell unübersichtlich. Versionierung, Code-Reviews und automatisierte Tests sind meist weniger ausgeprägt als in der Softwareentwicklung üblich. Prüfen Sie außerdem, wo Zugangsdaten zu Ihren Systemen gespeichert werden und wer im Team Workflows ändern darf, denn ein Workflow mit KI-Knoten hat dieselben Rechte wie die hinterlegten Zugangsdaten.

Agent-Frameworks und SDKs: LangGraph, OpenAI Agents SDK, Claude Agent SDK

Frameworks sind Programmbibliotheken, mit denen Entwickler Agenten im eigenen Code bauen und auf eigener Infrastruktur betreiben. LangGraph beschreibt sich als Orchestrierungs-Framework und Laufzeit für langlaufende, zustandsbehaftete Agenten. Nach Herstellerangaben unterstützt es dauerhafte Ausführung mit Wiederaufnahme nach Fehlern, Unterbrechungen für menschliche Prüfung und Kurz- sowie Langzeitspeicher. Es steht unter MIT-Lizenz für Python und JavaScript bereit; Tracing, Evaluation und Deployment bietet die separate Plattform LangSmith.

Das OpenAI Agents SDK, ebenfalls MIT-lizenziert und für Python und TypeScript verfügbar, stellt Agenten, Übergaben zwischen Agenten (Handoffs), Guardrails zur Prüfung von Ein- und Ausgaben, Sessions als Arbeitsspeicher und eingebautes Tracing bereit. MCP-Werkzeuge lassen sich einbinden, und laut Dokumentation ist das SDK nicht auf OpenAI-Modelle beschränkt.

Das Claude Agent SDK von Anthropic stellt nach Herstellerangaben dieselben Werkzeuge, dieselbe Agenten-Schleife und dasselbe Kontextmanagement bereit, die Claude Code nutzt, programmierbar in Python und TypeScript. Dazu gehören eingebaute Werkzeuge für Dateien, Befehle und Websuche, Hooks, Subagenten, MCP-Anbindung, Berechtigungen und Sessions. Die Nutzung unterliegt den kommerziellen Nutzungsbedingungen von Anthropic, und das SDK ist auf Claude-Modelle ausgerichtet.

Die drei Ansätze setzen unterschiedliche Schwerpunkte. LangGraph eignet sich, wenn Sie den Ablauf als expliziten Graphen mit Zuständen und Unterbrechungspunkten modellieren möchten. Das OpenAI Agents SDK arbeitet mit wenigen, schlanken Grundbausteinen und lässt sich mit verschiedenen Modellen kombinieren. Das Claude Agent SDK bringt viele fertige Werkzeuge und Berechtigungsfunktionen mit und ist auf die Modelle von Anthropic ausgelegt; prüfen Sie, ob das zu Ihrer Modellstrategie passt. Allen gemeinsam ist, dass Hosting, Verwaltung von Zugangsdaten, Monitoring und eine Bedienoberfläche für Fachanwender nicht automatisch enthalten sind und eingeplant werden müssen.

Eigenentwicklung auf Modell-APIs oder lokalen Modellen

Bei einer Eigenentwicklung schreibt das Team die Agenten-Schleife selbst: Modellaufruf, Werkzeugausführung, Speicher, Protokollierung und Freigaben. Das Modell kommt über die API eines Anbieters oder läuft als Open-Weight-Modell im eigenen Rechenzentrum. Dieser Weg bietet die größte Freiheit bei Datenhaltung und Ablauf und ist häufig die einzige Option, wenn Daten das Unternehmen nicht verlassen dürfen. Unsere Seite zur lokalen KI beschreibt, was dafür nötig ist.

Der Preis dieser Freiheit ist Verantwortung. Alles, was Plattformen und Frameworks mitbringen, von der Wiederaufnahme nach Fehlern bis zum Tracing, muss selbst gebaut oder aus Einzelbausteinen zusammengesetzt werden. Sinnvoll ist dieser Weg deshalb vor allem, wenn der Agent ein dauerhafter Bestandteil eines eigenen Produkts oder Kernprozesses ist und ein Team ihn langfristig weiterentwickelt.

Die Kriterien im direkten Vergleich

Die Tabelle fasst die vier Kategorien entlang der Kriterien zusammen, die in Auswahlprojekten den Ausschlag geben. Sie beschreibt typische Eigenschaften der Kategorie; einzelne Produkte können davon abweichen.

Integration und Datenhaltung zuerst prüfen

Die beiden Kriterien mit der stärksten Filterwirkung sind Integration und Datenhaltung. Liegen die relevanten Daten überwiegend in Microsoft 365, spricht vieles für einen Suite-Agenten. Verteilen sie sich auf zahlreiche SaaS-Werkzeuge, sind Workflow-Plattformen mit vielen fertigen Knoten im Vorteil. Kommen Eigen- oder Altsysteme ohne moderne Schnittstelle hinzu, entsteht ohnehin Entwicklungsaufwand, und ein Framework rückt näher. Dürfen personenbezogene oder vertrauliche Daten nur im eigenen Rechenzentrum verarbeitet werden, bleiben selbst gehostete Werkzeuge, Frameworks auf eigener Infrastruktur und Eigenentwicklungen mit lokalen Modellen übrig.

Evaluation und Betrieb nicht unterschätzen

Ein Agent ist mit dem ersten Einsatz nicht fertig. Jede Änderung an Modell, Anweisungen oder Werkzeugen kann sein Verhalten verändern. Prüfen Sie deshalb früh, wie sich auf der gewählten Plattform Testfälle anlegen, Ergebnisse vergleichen und Protokolle auswerten lassen. Bei Suite- und Low-Code-Plattformen ist das oft eingebaut, aber an die Oberfläche gebunden. Bei Frameworks und Eigenentwicklungen ist es frei gestaltbar, muss aber aufgebaut werden. Wie ein solcher Betrieb aussieht, beschreibt die Leistung Evaluation und Agent Operations.

Lock-in und Kosten realistisch einschätzen

Lock-in entsteht selten durch das Modell, sondern durch plattformspezifische Konnektoren, Workflow-Formate und Verwaltungsfunktionen. Wer Systeme über MCP-Server oder eigene APIs anbindet, kann diese Anbindungen später mit einer anderen Plattform weiterverwenden. Bei den Kosten unterscheiden sich vor allem die Blöcke: Bei Plattformen dominieren laufende Lizenz- oder Verbrauchskosten, bei Eigenentwicklungen Entwicklung und Betrieb. Eine Aufstellung der Kostenblöcke enthält der Ratgeber Was kostet ein KI-Agent?.

Der Entscheidungsweg in fünf Schritten

Statt mit einem Produkt zu beginnen, empfiehlt sich ein Weg vom Anwendungsfall zur Plattform. Die Grafik zeigt die Reihenfolge, in der die Fragen sinnvoll beantwortet werden.

1. Anwendungsfall klären: Welcher Prozess, welches Ziel, welche Ausnahmen? Ohne diese Grundlage lässt sich keine Plattform sinnvoll bewerten. Unterstützung bietet die Prozessanalyse mit Business Case.
2. Daten und Hosting: Dürfen die Daten in eine Public Cloud, in eine bestimmte Region oder nur ins eigene Rechenzentrum? Diese Frage schließt oft schon ganze Kategorien aus.
3. Systemlandschaft: Liegen die relevanten Daten überwiegend in einer Suite, in vielen SaaS-Werkzeugen oder in Eigen- und Altsystemen?
4. Kontrollbedarf: Wie kritisch sind die Aktionen des Agenten, und wie fein müssen Berechtigungen, Freigaben und Protokolle steuerbar sein?
5. Kompetenz und Plattform: Wer baut und betreibt den Agenten dauerhaft? Erst jetzt fällt die Wahl der Kategorie und danach des Produkts.

Kombinationen sind die Regel

Die Entscheidung muss nicht für alle Anwendungsfälle gleich ausfallen. Häufig entsteht eine Arbeitsteilung: Assistenzfunktionen für Mitarbeitende laufen in der Suite, Abläufe mit vielen Systemschritten in einem Workflow-Werkzeug und kritische oder sehr spezielle Agenten im eigenen Code. Damit diese Welten zusammenpassen, lohnt es sich, Systemanbindungen zentral als MCP-Server oder API bereitzustellen, die alle Plattformen nutzen können. Wie das technisch umgesetzt wird, beschreibt die Leistung MCP- und API-Systemintegration.

Ein hypothetisches Beispiel verdeutlicht das. Angenommen, ein Industrieunternehmen nutzt Microsoft 365, ein selbst betriebenes ERP und ein Ticketsystem in der Cloud. Ein interner Wissensassistent entsteht dann sinnvoll in der Suite. Die Vorqualifizierung eingehender Serviceanfragen läuft als Workflow mit KI-Knoten. Ein Agent, der Angebote auf Basis von ERP-Daten vorbereitet, wird mit einem Framework gebaut und auf eigener Infrastruktur betrieben. Alle drei greifen über denselben MCP-Server auf das ERP zu, sodass Berechtigungen und Protokolle an einer Stelle gepflegt werden.