Drei Typen von KI-Agenten
Eine praktische Taxonomie von dialogischer Unterstützung über delegierte Aufgaben bis zu organisationalen Workflows.
Warum eine Taxonomie hilfreich ist
In Gesprächen über KI-Agenten fällt mir häufig auf, dass sehr unterschiedliche Systeme unter demselben Begriff diskutiert werden. Ein Assistent im Browser, ein Coding-Agent in einem Repository und ein Automatisierungsworkflow, der auf eingehende Kundenanfragen reagiert, können alle als “Agenten” bezeichnet werden. Das ist nicht grundsätzlich falsch. Es hilft aber nur begrenzt, wenn wir verstehen wollen, welche Art von System wir kaufen, bauen, einsetzen oder steuern.
Der Begriff KI-Agent wird unterschiedlich verwendet. In diesem Beitrag nutze ich ihn pragmatisch: Ein KI-Agent ist ein System, in dem ein Sprachmodell mit Kontext, Gedächtnis, Tools und Kontrolllogik verbunden wird, sodass es ein Ziel verfolgen kann, das über eine einzelne Textantwort hinausgeht. Das bedeutet nicht, dass ein Agent vollständig autonom ist. In den meisten sinnvollen Anwendungen wird Autonomie durch Nutzeranweisungen, verfügbare Tools, Berechtigungen, Budgets und Review-Schritte begrenzt.
Auf architektonischer Ebene ist das Grundmuster relativ stabil, wie Abbildung 1 zeigt. Das Modell erhält Anweisungen und ein Ziel, ruft Kontext aus einem Gedächtnis ab oder aktualisiert ihn und handelt über Tools oder APIs. Das Ergebnis ist kein einzelner Modellaufruf, sondern eine Schleife: Das System zieht Schlüsse, handelt, beobachtet das Ergebnis und fährt fort, bis das Ziel erreicht ist oder eine Stoppbedingung greift.
Forschung und Engineering-Arbeiten zu LLM-basierten Agenten betonen häufig wiederkehrende Komponenten wie Planung, Gedächtnis, Tool-Nutzung, Interaktion mit einer Umgebung und Evaluation (Wang u. a. 2023; Yao u. a. 2022). Aktuelle Entwickler-Frameworks machen dasselbe Muster in der Praxis sichtbar. OpenAI (2026) beschreibt Agenten beispielsweise als Sprachmodelle mit Anweisungen und Tools und ergänzt Konzepte wie Guardrails, Sessions, Handoffs, Tracing und Human-in-the-Loop-Mechanismen. Model Context Protocol (2026) adressiert ein ähnliches Integrationsproblem, indem ein offener Standard definiert wird, um KI-Anwendungen mit externen Systemen wie Dateien, Datenbanken, Tools und Workflows zu verbinden.
Diese technische Perspektive ist wichtig, reicht für praktische Orientierung aber nicht aus. Für Beratung, Implementierung und organisationale KI-Strategie sind aus meiner Sicht vier einfachere Fragen hilfreich:
- Wo arbeitet der Agent?
- Wie viel Arbeit wird an ihn delegiert?
- Welche Tools und welches Gedächtnis kann er nutzen?
- Wie eng wird er durch Menschen beaufsichtigt?
Aus dieser Perspektive sind drei breit gefasste Typen besonders nützlich: Conversational Agents, Task-Agenten und Prozess-Agenten. Abbildung 2 fasst diese Taxonomie als Kontinuum vom Gespräch bis zur organisationalen Automatisierung zusammen. Ich verstehe sie als praktische Taxonomie und nicht als abschließende wissenschaftliche Klassifikation. Die Unterscheidung ist konzeptionell, nicht empirisch. Sie soll Design- und Einführungsentscheidungen klären, nicht behaupten, dass jedes reale System sauber in genau eine Schublade passt.
Conversational Agents
Conversational Agents sind die vertrauteste Form agentischer KI. Sie erscheinen als dialogische Systeme wie ChatGPT, Claude, Gemini, Microsoft-Copilot-Erfahrungen oder speziell konfigurierte Assistenten für einzelne Fachdomänen. Auf den ersten Blick ähneln sie klassischen Chatbots. Der Unterschied besteht darin, dass moderne Systeme zunehmend Zugriff auf Tools, Dateien, Suche, Codeausführung, Bilder, verbundene Apps oder persistente Nutzerpräferenzen haben.
Das definierende Merkmal ist nicht allein die Nutzeroberfläche, sondern das Verhältnis zwischen Mensch und System. Der Mensch bleibt nah an der Interaktion. Er fragt, korrigiert, gibt frei, lenkt um, ergänzt fehlenden Kontext und entscheidet, wann eine Antwort ausreichend ist. Der Agent kann recherchieren, eine Datei analysieren, ein Dokument zusammenfassen, Code schreiben oder einen Entwurf vorbereiten. Die Arbeit entfaltet sich aber weiterhin als Gespräch.
Das bedeutet, dass Conversational Agents besonders für Arbeit geeignet sind, bei der das Problem zu Beginn noch nicht vollständig spezifiziert ist. Sie unterstützen beim Denken, Schreiben, Analysieren und Vorbereiten von Entscheidungen. Eine Fachabteilung kann einen Conversational Agent nutzen, um Varianten für ein Kundenanschreiben zu vergleichen. Ein Analyst kann ihn nutzen, um eine Fehlermeldung oder einen Datenbefund einzuordnen. Eine Führungskraft kann ihn nutzen, um Notizen aus einem Meeting zu strukturieren. In diesen Fällen übernimmt der Agent kognitive Vorarbeit, während der Mensch direkt in Steuerung und Prüfung eingebunden bleibt.
Conversational Agents können bereits sehr leistungsfähig sein. Über MCP oder ähnliche Connector-Muster können sie auf lokale Dateien, Kalender, Datenbanken oder spezialisierte Tools zugreifen (Model Context Protocol 2026). Der zentrale Auslöser bleibt aber meist eine Nutzereingabe, teilweise ergänzt durch geplante Prompts oder wiederkehrende Erinnerungen. Der wichtigste Kontrollmechanismus ist die direkte Aufsicht im Gespräch.
Das erklärt auch ihre Grenzen. Ein Conversational Agent kann eine komplexe Entscheidung unterstützen, besitzt den gesamten Arbeitsprozess aber normalerweise nicht. Er kann einen Plan erzeugen, dessen Ausführung oder Validierung aber häufig beim Menschen bleibt. Er kann eine Datei prüfen, arbeitet aber nicht ohne passende Produktumgebung über Stunden hinweg in Repository, Browser und Terminal.
Task-Agenten
Task-Agenten gehen einen Schritt weiter. Sie sind auf delegierte Arbeit ausgelegt. Der Nutzer fragt nicht nur nach einer Antwort, sondern gibt dem Agenten ein Ziel: Analysiere dieses Repository, behebe diesen Fehler, bereite diesen Bericht vor, vergleiche diese Dokumente, erstelle die Folien oder untersuche, warum der Build fehlschlägt.
Der praktische Unterschied besteht darin, dass ein Task-Agent über mehrere Schritte arbeitet. Er kann Kontext inspizieren, eine Handlungsfolge planen, Tools nutzen, Ergebnisse beobachten, seinen Ansatz korrigieren und fortfahren, bis die Aufgabe erledigt ist oder menschliche Eingabe erforderlich wird. Coding-Agenten sind derzeit das klarste Beispiel: Systeme wie Codex, Claude Code oder OpenCode arbeiten mit Dateien, Terminals, Tests, Browsern und Versionskontrollkontext. Dasselbe Muster findet sich aber auch bei Dokumentenarbeit, Tabellenanalysen, Rechercheunterstützung und Datenworkflows.
Die zentrale Idee ist Delegation. Der Mensch definiert weiterhin das Ziel und prüft das Ergebnis, aber der Agent übernimmt mehr Zwischenarbeit. Das erfordert ein anderes Kontrollmodell. Berechtigungen, Sandboxing, Bestätigungen und Nachvollziehbarkeit werden wichtiger, weil der Agent Dateien ändern, Befehle ausführen, APIs aufrufen oder mit externen Systemen interagieren kann.
OpenAI (2026) verdeutlicht diese Verschiebung auf Framework-Ebene: Es umfasst eine verwaltete Agentenschleife, Tool-Ausführung, Sessions als Gedächtnis, Handoffs zwischen Agenten, Tracing und Human-in-the-Loop-Fähigkeiten. Diese Konzepte sind wichtig, weil Task-Delegation nicht einfach ein längerer Chat ist. Sie ist ein Laufzeitproblem. Das System muss entscheiden, welche Aktion erlaubt ist, welcher Kontext verfügbar ist, wie Zwischenergebnisse behandelt werden und wann die Kontrolle zum Menschen zurückkehrt.
Aus meiner Sicht sind Task-Agenten für Unternehmen besonders wichtig, weil sie verändern, was kompetentes Delegieren bedeutet. Beschäftigte müssen nicht nur Prompts schreiben. Sie müssen Agentenspuren prüfen, Tool-Nutzung bewerten, erzeugte Artefakte verstehen und entscheiden, ob der Arbeitsprozess angemessen war. Ein Coding-Agent, dessen Tests erfolgreich durchlaufen, kann trotzdem die falsche Anforderung umgesetzt haben. Ein Recherche-Agent mit einer gut lesbaren Zusammenfassung kann trotzdem schwache Quellen nutzen. Ein Daten-Agent, der eine Analyse ausführt, kann trotzdem Informationen zwischen Trainings- und Testdaten vermischen.
Deshalb brauchen Task-Agenten Vertrauen und Skepsis zugleich. Sie können Routineaufwand reduzieren und komplexe Arbeit zugänglicher machen. Gleichzeitig erleichtern sie es, ein plausibles Ergebnis zu akzeptieren, ohne den Prozess zu verstehen, der es erzeugt hat.
Prozess-Agenten
Prozess-Agenten betten agentische KI in wiederholbare Workflows und organisationale Prozesse ein. Sie werden nicht primär in einem Eins-zu-eins-Chat oder auf einem einzelnen persönlichen Computer genutzt. Stattdessen arbeiten sie über Systeme, Teams und Geschäftsprozesse hinweg.
Beispiele sind KI-gestützte Workflows in n8n, Microsoft Copilot Studio, Power Automate, Make, Zapier und vergleichbaren Automatisierungsumgebungen. n8n (2026) zeigt, wie Sprachmodellkomponenten innerhalb von Workflows genutzt werden können. Microsoft (2026) beschreibt Copilot Studio als grafisches Low-Code-Werkzeug zum Erstellen von Agenten und Agent Flows mit vorgefertigten oder eigenen Connectors. Die Produkte unterscheiden sich, aber die architektonische Richtung ist ähnlich: Sprachmodelllogik wird mit Workflow-Logik, App-Connectors, Datenzugriff und Ereignisauslösern verbunden.
Der zentrale Auslöser ist häufig kein Prompt. Ein Prozess-Agent kann starten, wenn eine E-Mail eingeht, ein Formular abgeschickt wird, ein Datenbankeintrag sich ändert, ein Support-Ticket erstellt wird oder ein Zeitplan erreicht ist. Der Agent kann Informationen klassifizieren, Kundendaten abrufen, eine Antwort entwerfen, ein CRM aktualisieren, ein Ticket erstellen, ein Team benachrichtigen, eine Freigabe anfordern oder dokumentieren, was geschehen ist.
Der entscheidende Unterschied besteht darin, dass der Agent Teil eines operativen Systems wird. Das erhöht den potenziellen Nutzen, verändert aber auch das Risikoprofil. Ein Fehler bleibt nicht mehr auf eine Antwort oder eine lokale Datei beschränkt. Er kann Kunden, Beschäftigte, Datensätze, Berechtigungen oder Folgesysteme betreffen. Governance ist deshalb kein Zusatz, sondern Teil des Systemdesigns.
Bei Prozess-Agenten verschiebt sich die menschliche Rolle meist von enger Gesprächssteuerung zu Governance. Menschen definieren Regeln, geben sensible Aktionen frei, überwachen Logs, prüfen Eskalationen und auditieren Ergebnisse. Der Agent wird also nicht einfach in einem unklaren Sinn “autonomer”. Vielmehr wird Autonomie anders verteilt: Routineentscheidungen können automatisiert werden, während risikoreichere Fälle Eskalation oder menschliche Freigabe benötigen.
Ein Kontinuum, keine drei Schubladen
Die drei Typen sollten als Kontinuum verstanden werden. Ein Conversational Agent kann aufgabenähnlicher werden, wenn er Zugriff auf Dateien, Tools und persistentes Gedächtnis erhält. Ein Task-Agent kann in einer dialogischen Oberfläche starten, dann aber für eine Weile in einer kontrollierten Umgebung arbeiten. Ein Prozess-Agent kann dialogische Elemente enthalten, seine Hauptrolle besteht aber darin, einen Workflow über Systeme hinweg zu koordinieren.
Dieses Kontinuum ist wichtig, weil dasselbe Sprachmodell in allen drei Fällen eingesetzt werden könnte. Was sich verändert, ist das umgebende System: der verfügbare Kontext, die aufrufbaren Tools, der Auslöser der Arbeit, die Dauer der Aktivität, der Grad der Autonomie und die Kontrollmechanismen.
Vereinfacht gesagt:
- Conversational Agents helfen Nutzerinnen und Nutzern beim Denken, Schreiben, Analysieren und Entscheiden.
- Task-Agenten helfen dabei, konkrete Arbeitspakete zu delegieren.
- Prozess-Agenten helfen Organisationen, wiederkehrende Workflows zu automatisieren und zu koordinieren.
Die Grundidee ist in allen drei Fällen dieselbe: Ein Sprachmodell wird nützlicher, wenn es mit Gedächtnis, Tools und Handlungsmöglichkeiten verbunden wird. Dieser Nutzen skaliert aber nicht automatisch mit Autonomie. Mehr Tool-Zugriff bedeutet auch mehr Fehlermöglichkeiten. Mehr Integration bedeutet mehr organisationale Folgen. Mehr Automatisierung bedeutet mehr Bedarf an Logging, Monitoring, Berechtigungen und klarer Verantwortlichkeit.
Das passt zu aktuellen Arbeiten zur Evaluation und Zuverlässigkeit von Agenten. Kapoor u. a. (2024) argumentieren, dass bestehende Agenten-Benchmarks häufig zu stark auf Genauigkeit fokussieren und Kosten, Reproduzierbarkeit und praktischen Nutzen zu wenig berücksichtigen. Rabanser u. a. (2026) argumentieren ähnlich, dass Zuverlässigkeit von Agenten nicht auf eine einzelne Erfolgsmetrik reduziert werden kann; Konsistenz, Robustheit, Vorhersagbarkeit und Sicherheit müssen getrennt betrachtet werden. Diese Fragen werden wichtiger, je weiter wir uns von dialogischer Unterstützung über delegierte Aufgaben hin zu organisationalen Workflows bewegen.
Was sich entlang des Kontinuums verändert
Die sichtbarste Veränderung ist Autonomie. Conversational Agents handeln meist innerhalb eines einzelnen Gesprächsrahmens. Task-Agenten arbeiten über mehrere Schritte hinweg, häufig mit Zugriff auf Dateien, Terminals, Browser oder Anwendungen. Prozess-Agenten können über Systeme und Teams hinweg arbeiten und werden teilweise automatisch durch Ereignisse ausgelöst.
Die zweite Veränderung betrifft den Umfang. Conversational Agents unterstützen meist eine Person in einem Gespräch. Task-Agenten bearbeiten ein begrenztes Arbeitspaket. Prozess-Agenten betreffen wiederholbare Workflows, die mehrere Systeme, Rollen und Datenquellen einbeziehen können.
Die dritte Veränderung betrifft die menschliche Rolle. Bei Conversational Agents bleiben Menschen nah an der Interaktion. Bei Task-Agenten delegieren und prüfen sie. Bei Prozess-Agenten definieren sie Regeln, überwachen Verhalten und greifen über Eskalationspfade ein. Menschliche Urteilskraft wird dadurch nicht weniger wichtig. Sie wird an anderen Stellen angewendet.
Die vierte Veränderung betrifft Governance. Bei einem Conversational Agent bedeutet gute Praxis unter anderem Quellenprüfung, Schutz sensibler Daten und Review der Ergebnisse. Bei einem Task-Agenten kommen Berechtigungen, Sandboxing, Versionskontrolle, Testnachweise und Handlungsspuren hinzu. Bei einem Prozess-Agenten braucht es organisationale Kontrollen: Zugriffsrechte, Logs, Monitoring, Rollback-Verfahren, Eskalationsregeln und Compliance-Anforderungen.
Konsequenzen für Unternehmen und Use Cases
Für Unternehmen hilft diese Taxonomie, einen typischen Implementierungsfehler zu vermeiden: “KI-Agenten” als eine einheitliche Technologiekategorie zu behandeln. Der bessere Ausgangspunkt ist die Art der Arbeit, die unterstützt oder automatisiert werden soll. Explorative Wissensarbeit, delegierte Expertenaufgaben und wiederholbare operative Workflows erfordern unterschiedliche Produkte, Kontrollmechanismen und organisationale Fähigkeiten.
Die Auswahlkarte in Abbildung 3 fasst diese Entscheidungslogik zusammen. Sie schreibt kein Tool vor, hilft aber, einen Use Case einzuordnen, bevor Anbieter oder Architekturen diskutiert werden: Je wiederholbarer und integrierter die Arbeit wird, desto stärker verschiebt sich der Fokus von individueller Produktivität zu Prozessverantwortung und Governance.
Conversational Agents sind meist ein sinnvoller Ausgangspunkt, wenn viele Beschäftigte flexible Unterstützung in der Wissensarbeit benötigen. Typische Use Cases sind das Entwerfen und Überarbeiten von Texten, das Zusammenfassen von Dokumenten, die Vorbereitung von Meetings, Datenexploration, das Übersetzen zwischen technischer und nicht-technischer Sprache sowie Ad-hoc-Recherche. Der organisationale Fokus sollte auf guter Adoption liegen: klare Nutzungsregeln, Datenschutzgrenzen, Quellenprüfung, Prompt- und Review-Praktiken sowie geeigneter Zugriff auf domänenspezifisches Wissen.
Task-Agenten werden relevant, wenn ein Unternehmen nicht nur Gespräche unterstützen, sondern begrenzte Arbeitsergebnisse delegieren möchte. Das ist besonders plausibel in Softwareentwicklung, Analytics, Reporting, Dokumentenvorbereitung, Qualitätsprüfung und internen Recherche-Workflows. Der Fokus sollte auf kontrollierter Ausführung liegen: Berechtigungen, Sandboxing, Review-Schritte, Versionskontrolle, Testnachweise und Spuren dessen, was der Agent getan hat. Task-Agenten sind vor allem dort nützlich, wo das Unternehmen das Ziel klar definieren und das Ergebnis bewerten kann.
Prozess-Agenten sind geeignet, wenn wiederkehrende operative Koordination über Systeme hinweg das Ziel ist. Beispiele sind Kundenservice-Triage, Lead-Qualifizierung, Rechnungs- oder Dokumentenrouting, Ticket-Anreicherung, interne Anfragenbearbeitung, HR-Onboarding-Schritte, Compliance-Vorprüfungen und wissensbasierte Workflow-Automatisierung. Entscheidend ist hier nicht, ob das Sprachmodell isoliert eine gute Antwort erzeugen kann. Entscheidend ist, ob der Workflow zuverlässig betrieben, überwacht, eskaliert und auditiert werden kann.
Weitere Einordnungsdimensionen
Die Taxonomie in diesem Beitrag ordnet Agenten nach ihrer agentischen Rolle ein: Conversational Agent, Task-Agent oder Prozess-Agent. Das ist die zentrale Unterscheidung. In Unternehmenskontexten sind jedoch drei weitere Einordnungsdimensionen hilfreich, weil sie erklären, warum zwei Systeme mit derselben agentischen Rolle sich dennoch deutlich in Implementierungsaufwand, Governance-Anforderungen und geschäftlicher Wirkung unterscheiden können:
- Einbettung in Enterprise-Anwendungen,
- operative Integrationstiefe und
- KI-Wirk- und Reifeebene.
Einbettung in Enterprise-Anwendungen
Die erste Dimension betrifft die Integration von KI in Enterprise-Anwendungen wie CRM, ERP, HR, Service-Management, Procurement oder Business-Intelligence-Plattformen. Diese Integrationen sind wichtig, weil viele wirtschaftlich relevante Workflows bereits in solchen Systemen stattfinden. Kundendatensätze, Aufträge, Verträge, Rechnungen, Bestandsdaten, Support-Tickets, Freigaben und Audit Trails sind kein externer Kontext. Sie sind die operative Umgebung, in der Arbeit koordiniert wird.
Dabei ist es hilfreich, zwei Aspekte zu trennen, die leicht vermischt werden. Einbettung in Enterprise-Anwendungen beschreibt, wo die KI-Fähigkeit platziert ist: zum Beispiel in einem CRM-, ERP-, HR-, Service-Management-, Procurement- oder BI-System. Operative Integrationstiefe beschreibt, was die KI innerhalb oder über diese Systeme hinweg tun darf: Kontext lesen, begrenzte Aktionen vorbereiten, Datensätze aktualisieren, Folgeschritte auslösen oder wiederkehrende Workflows koordinieren. Die vierte Ebene, die KI-Wirk- und Reifeebene, beschreibt, ob die Fähigkeit vor allem individuelle Produktivität, Gruppenproduktivität, Geschäftsprozesseffizienz oder Geschäftsmodelltransformation unterstützt. Die Taxonomie gilt weiterhin, aber diese zusätzlichen Ebenen erklären, warum dieselbe agentische Rolle sehr unterschiedliche organisationale Folgen haben kann.
Aktuelle Anbieterbeispiele zeigen diese Bandbreite. Salesforce (2026) positioniert Agentforce als KI-Agenten-Plattform rund um CRM, Service, Sales, Marketing, Commerce, Slack, Data 360 und Branchen-Clouds. Microsoft (2024) beschreibt autonome Agenten in Dynamics 365 für Sales-, Service-, Finance- und Supply-Chain-Teams, etwa Sales-Qualification-, Supplier-Communication- und Customer-Knowledge-Agenten. SAP (2026) beschreibt Joule als KI-Assistenten, der in SAP-Business-Anwendungen eingebettet ist und Arbeit in Unternehmensprozessen unterstützen soll, statt außerhalb dieser Systeme zu stehen. ServiceNow (2026) beschreibt KI-Agenten als in die Plattform eingebettet und mit Workflows, Daten, Tools und Bereichen wie IT, HR und CRM verbunden. Diese Beispiele unterscheiden sich in der Produktarchitektur. Gemeinsam ist ihnen, dass agentische Fähigkeiten nahe an System-of-Record-Daten und operativen Workflows platziert werden.
Ein KI-Assistent in einem CRM kann beispielsweise als Conversational Agent funktionieren, wenn er einem Vertriebsmitarbeiter hilft, einen Account zusammenzufassen, eine E-Mail zu entwerfen oder aktuelle Aktivitäten einzuordnen, während der Mensch die Kontrolle behält. Dieselbe CRM-Integration kann zum Task-Agenten werden, wenn der Nutzer ein begrenztes Arbeitsergebnis delegiert, etwa ein Account-Briefing, eine Dublettenprüfung, Lead-Anreicherung oder eine Forecast-Erklärung zur Prüfung. Sie wird zum Prozess-Agenten, wenn CRM-Ereignisse koordinierte Folgeschritte auslösen: Lead Scoring, Account-Zuweisung, Ticketerstellung, Datensatzaktualisierung, Eskalation, Benachrichtigung und Dokumentation.
Dieselbe Logik gilt für ERP-Systeme. Ein dialogischer Assistent, der eine Bestellung erklärt oder offene Rechnungen zusammenfasst, ist eher ein Conversational Agent. Eine delegierte Prüfung, die Rechnungsdaten vergleicht, Inkonsistenzen markiert und eine Review-Notiz vorbereitet, ist eher ein Task-Agent. Ein Workflow, der auf eine eingehende Rechnung reagiert, sie mit Bestellungen abgleicht, Ausnahmen routet, Datensätze aktualisiert und Entscheidungen protokolliert, ist eher ein Prozess-Agent.
Die Einbettung in Enterprise-Anwendungen schneidet daher quer durch die Taxonomie. Sie macht Agenten oft nützlicher, weil sie strukturierte Daten, Domänenkontext und Handlungsflächen bereitstellt. Die operative Integrationstiefe bestimmt, wie weit dieser Nutzen in tatsächliche Arbeitsausführung hineinreicht. Sobald ein Agent Datensätze in Kernsystemen lesen oder aktualisieren kann, werden rollenbasierter Zugriff, Datenherkunft, Freigabeschwellen, Auditierbarkeit, Rollback und Verantwortlichkeit für Ausnahmen relevant.
Operative Integrationstiefe
Damit ergeben sich für Unternehmen zwei Priorisierungsdimensionen: die agentische Rolle und die operative Integrationstiefe. Ein Conversational Agent mit geringer Integration kann häufig als breites Produktivitätstool eingeführt werden, auch wenn er gelegentlich Unternehmenskontext nutzt. Ein Task-Agent in einem CRM- oder ERP-System benötigt bereits klarere Berechtigungsgrenzen und Review-Prozesse. Ein Prozess-Agent, der Kerndatensätze aktualisiert oder Workflows über Systeme hinweg koordiniert, braucht von Beginn an Prozessverantwortung, Monitoring, Eskalation und Auditierbarkeit.
Die Leiter zur operativen Integration in Abbildung 4 macht diese zweite Dimension explizit. Sie trennt risikoärmere Standalone-Nutzung von kontextuellem Zugriff, begrenzter Handlungsfähigkeit und Einbettung auf Workflow-Ebene. Diese Unterscheidung ist wichtig, weil die Governance-Anforderungen meist mit der operativen Integrationstiefe steigen, auch wenn die zugrunde liegende Sprachmodellfähigkeit ähnlich wirkt.
KI-Wirk- und Reifeebene
Diese dritte zusätzliche Dimension verbindet die Agentenfrage mit einer breiteren Wertperspektive. He und Puranam (2026) beschreiben eine AI Maturity Pyramid, die bei individueller Produktivität beginnt, über Gruppenproduktivität und Geschäftsprozesseffizienz führt und erst dann Geschäftsmodelltransformation erreicht. Das ist keine Agenten-Taxonomie. Sie beschreibt die Ebene, auf der eine KI-Fähigkeit Wert schafft. Viele Conversational Agents wirken vor allem auf individueller Produktivität. Task-Agenten können individuelle oder Gruppenproduktivität unterstützen, je nachdem, ob die delegierte Arbeit persönlich bleibt oder Teil von Teamworkflows wird. Prozess-Agenten verschieben die Diskussion meist in Richtung Geschäftsprozesseffizienz, weil sie in wiederkehrende operative Arbeit eingebettet sind.
Abbildung 5 fasst diese Wertperspektive als Pyramide zusammen. Entscheidend ist dabei nicht, dass jedes Unternehmen die Stufen in einer festen Reihenfolge durchlaufen muss. Die Abbildung hilft vielmehr, zwei Fragen zu trennen: welche agentische Rolle ein System übernimmt und auf welcher organisationalen Ebene die KI-Fähigkeit Wert schaffen soll.
Die folgende Tabelle fasst die vier Ebenen zusammen. Das Hauptthema dieses Beitrags bleibt die erste Ebene: die agentische Rolle. Die anderen Ebenen helfen zu verstehen, wo ein Agent eingebettet ist, wie tief er in operative Arbeit integriert ist und auf welcher Wert- bzw. Reifeebene die KI-Fähigkeit Wirkung erzeugt.
| Einordnungsebene | Leitfrage | Typische Skala | Was sich praktisch verändert |
|---|---|---|---|
| Agentische Rolle | Welche Art von Arbeit übernimmt der Agent? | Conversational Agent -> Task-Agent -> Prozess-Agent | Auslöser, Autonomie, Umfang und menschliche Aufsicht |
| Einbettung in Enterprise-Anwendungen | Wo ist die KI-Fähigkeit platziert? | CRM, ERP, HR, Service Management, Procurement, BI | Verfügbarer Geschäftskontext, Systemberechtigungen und Passung zum Nutzerworkflow |
| Operative Integrationstiefe | Was darf die KI in operativer Arbeit tun? | Standalone -> Kontextuell -> Handlungsfähig -> Workflow-eingebettet | Datenzugriff, Schreibrechte, Auditierbarkeit, Rollback und Prozessverantwortung |
| KI-Wirk- und Reifeebene | Auf welcher Wertschöpfungsebene erzeugt die KI-Fähigkeit Wirkung? | Individuelle Produktivität -> Gruppenproduktivität -> Prozesseffizienz -> Geschäftsmodelltransformation | Individuelle Unterstützung, Teamkoordination, Prozessverbesserung oder strategische Transformation |
Unterschiedliche Unternehmen werden deshalb an unterschiedlichen Punkten der Taxonomie starten. Kleine Organisationen oder Teams am Anfang ihrer KI-Adoption profitieren häufig am meisten von guter Nutzung von Conversational Agents und wenigen sorgfältig ausgewählten Task-Agent-Piloten. Unternehmen mit reifem Datenzugriff, API-Infrastruktur und klarer Prozessverantwortung können schneller in Richtung Prozess-Agenten gehen. Stark regulierte Organisationen sollten meist langsamer vorgehen und mit internen, risikoarmen Workflows sowie expliziter menschlicher Freigabe für folgenreiche Aktionen starten.
Die Taxonomie unterstützt auch Beschaffungsentscheidungen. Wenn ein Anbieter primär eine dialogische Oberfläche anbietet, sollte das Produkt als Conversational Agent bewertet werden, auch wenn es die Sprache der Autonomie nutzt. Wenn ein Werkzeug Dateien inspizieren, Befehle ausführen und Artefakte erzeugen kann, müssen Ausführungskontrollen und Review-Qualität in die Bewertung einbezogen werden. Wenn eine Plattform CRM, ERP, E-Mail, Ticketing und Datenbanken verbindet, sollten Prozessverantwortliche, IT, Security, Legal und Operations von Anfang an beteiligt sein.
Aus meiner Sicht ist der wichtigste Punkt, dass “Agent” nicht als Produktetikett behandelt werden sollte. Es ist eine Designfrage. Relevant ist, was delegiert wird, welcher Kontext verfügbar ist, welche Tools handeln können, wer das Ergebnis prüft und was passiert, wenn der Agent falsch liegt. Diese Fragen sind nützlicher als die Frage, ob ein System intelligent genug wirkt, um das Agentenlabel zu verdienen.
Für Unternehmen ergibt sich daraus eine einfache Anwendung der Taxonomie. Erstens sollte geklärt werden, ob ein Use Case individuelle Arbeit unterstützt, eine begrenzte Aufgabe delegiert oder einen wiederkehrenden Prozess koordiniert. Zweitens ist zu bestimmen, wie tief das System in bestehende Anwendungen wie CRM, ERP, Service Management oder Analytics-Plattformen eingebettet werden soll. Drittens sollte das Governance-Modell festgelegt werden, bevor ein Agent sensible Daten lesen, Datensätze aktualisieren, Workflows auslösen oder folgenreiche Empfehlungen geben darf. Diese drei Fragen ersetzen keine technische Evaluation, machen sie aber konkreter.
Fazit
Conversational Agents, Task-Agenten und Prozess-Agenten beschreiben drei hilfreiche Punkte auf einem Kontinuum vom Gespräch bis zur organisationalen Automatisierung. Sie bestehen aus ähnlichen Zutaten: einem Sprachmodell, Kontext, Gedächtnis, Tools und Kontrolllogik. Unterschiede bestehen darin, wo der Agent arbeitet, wie viel Autonomie er erhält, wodurch er ausgelöst wird und wie menschliche Aufsicht organisiert ist.
Die praktische Konsequenz ist klar. Wir sollten einen Agenten nicht nur anhand der Qualität seiner finalen Antwort bewerten. Bewertet werden muss die gesamte Arbeitsanordnung: Tools, Berechtigungen, Spuren, Review-Punkte, Fehlermodi und organisationale Folgen. Je stärker sich ein Agent vom Gespräch in Richtung Prozessautomatisierung bewegt, desto wichtiger wird diese Systemperspektive.