Warum die meisten Systeme schon agentisch sind

  • Veröffentlicht:
  • Autor: Dr. Andreas Kyek
  • Kategorie: Deep Dive
Inhaltsverzeichnis
    Warum die meisten Systeme schon agentisch sind, hero image, Alexander Thamm [at]
    Alexander Thamm [at] 2026

    Vor Kurzem hatte ich eine interessante Unterhaltung mit meinem KI-gestützten Coding-Assistenten. Es ging um eine Anwendung, die für mich eindeutig agentisch war. Mein Coding-Assistent hatte einen kleinen Workflow aufgebaut, in den auch ein LLM-Aufruf eingebunden war. Ich fragte meinen Assistenten: „Warum hast du das nicht als Agent umgesetzt?“ 

    Seine Antwort lautete: „Das ist kein Agent. Das ist nur eine Pipeline. Schließlich gibt es keine Entscheidungslogik.“ 

    Auf den ersten Blick klingt das plausibel. Eine Pipeline arbeitet eine vordefinierte Abfolge von Schritten ab. Ein Agent hingegen entscheidet eigenständig, was als Nächstes zu tun ist. Frage beantwortet. Dachte ich.

    Doch in der Praxis hält diese Unterscheidung nur bedingt stand. Schaut man sich Systeme wie Microsoft 365 Copilot und die dort sogenannten Agents an, zeigt sich schnell ein anderes Bild: Viele von ihnen verfügen gar nicht über eine explizite Verzweigungslogik. Sie sind nicht in komplexe Workflows eingebettet und übernehmen oft eher repetitive Aufgaben. Trotzdem werden sie von allen Beteiligten, einschließlich Microsoft, als Agents bezeichnet. 

    Was ist hier los? In diesem Beitrag gehe ich der Frage nach, warum viele der Systeme, die wir heute entwickeln und nutzen, tatsächlich agentisch sind. Dabei stelle ich heraus, dass unserem gängigen Verständnis von agentischen Systemen ein begriffliches Missverständnis zugrunde liegt. 

    Engineering- versus Produktperspektive

    Die Verwirrung entsteht dadurch, dass hier zwei grundlegend unterschiedliche Perspektiven miteinander vermischt werden. 

    Aus Engineering-Sicht ist ein Agent ein System, das einen Zustand wahrnimmt, Entscheidungen trifft und (meist in einer Schleife) handelt. Im Zentrum dieser Definition steht eine explizite Steuerungslogik: Verzweigungen, Planung, Iteration. 

    Aus Produktsicht hingegen ist ein Agent schlicht eine wiederverwendbare, KI-gestützte Fähigkeit, die im Auftrag eines Nutzers handelt. Ob das System dabei explizite Entscheidungsbäume enthält oder nicht, ist zweitrangig. Entscheidend ist, dass es eine Aufgabe eigenständig ausführt.

    Diese beiden Perspektiven beschreiben nicht dasselbe, werden jedoch häufig synonym verwendet.

    Hilfreicher als eine binäre Unterscheidung zwischen „Agent“ und „kein Agent“ wäre es deshalb, in verschiedenen Stufen von Agency zu denken.

    Agenten anhand ihres Grad an Agency erkennen

    Level 0 — Pipeline 

    • vollständig deterministisch
    • feste Abfolge von Schritten
    • kein modellbasiertes Schlussfolgern

    Level 1 — LLM-gestütztes Tool

    • ein einzelner LLM-Aufruf oder eine feste Kette von Aufrufen
    • das Schlussfolgern findet innerhalb des Modells statt
    • keine explizite Steuerungslogik im Code

    Level 2 — Reaktiver Agent 

    • wählt die nächsten Schritte dynamisch aus
    • entscheidet zwischen Tools oder Verzweigungen 

    Level 3 — Autonomer Agent 

    • plant, iteriert und hält Zustände aufrecht
    • mehrstufiges Schlussfolgern und Ausführen. 

    Diese Abstufung deutet auf etwas Entscheidendes hin: Agency ist kein Schalter, der entweder an oder aus ist. Sie verläuft graduell. Und in dem Moment, in dem ein LLM ins Spiel kommt, entsteht auch implizite Entscheidungslogik. Selbst ein einfacher Extraktions-Prompt ist nicht bloß „Ausführung“. Das Modell entscheidet, was relevant ist, wie mehrdeutige Eingaben zu interpretieren sind und in welcher Form die Ausgabe strukturiert wird. Das ist bereits eine Form von Urteilskraft. 

    Hält man nun an einer engen Engineering-Definition fest, gerät man in eine eigentümliche Lage: Entweder ignoriert man diese implizite Entscheidungsleistung oder man muss einräumen, dass viele Systeme, die wir beiläufig als „Pipelines“ bezeichnen, bereits agentische Eigenschaften haben. Genau in diesem Spannungsfeld landen die meisten Teams. 

    Warum ein System durch den Einsatz eines LLM agentisch wird 

    An diesem Punkt lohnt es sich, eine klare und konsistente Position einzunehmen: Sobald ein LLM beteiligt ist, ist das System agentisch.

    Das mag zunächst radikal klingen, ist aber die beste Herangehensweise. Denn mit einem LLM ist ein System nicht länger vollständig deterministisch. Es interpretiert Kontext, trifft implizite Entscheidungen und beeinflusst Ergebnisse auf eine Weise, die nicht vollständig im Code festgelegt ist.

    Das allein reicht aus, um von einem agentischen System zu sprechen. Bemerkenswert ist zudem, dass diese Sichtweise sehr gut zu dem passt, wie moderne Produkte tatsächlich funktionieren, ganz unabhängig davon, ob sie offiziell agentisch genannt werden oder nicht. Akzeptiert man diesen Punkt, verschiebt sich auch die eigentliche Frage. Dann geht es nicht mehr darum, Systeme schlicht als Agenten oder Nicht-Agenten zu etikettieren. Die entscheidende Frage lautet vielmehr: Wie entwirft man Systeme richtig, wenn man anerkennt, dass sie agentisch sind? Steuerung und Ausführung sollten getrennt werden. Auf der Systemebene bedeutet das zunächst, die Anwendung als agentisch zu begreifen und sie entsprechend zu gestalten: mit Logging, Guardrails, Evaluation und allen operativen Vorkehrungen, die dafür notwendig sind. Gleichzeitig sollte aber nicht jeder Teil des Systems zwanghaft in ein agentisches Muster gepresst werden. Sinnvoller ist es, zwischen zwei Arten von Bausteinen zu unterscheiden:

    • Agent Nodes enthalten LLM-Aufrufe und übernehmen Interpretation, Abwägung oder Schlussfolgern. Sie sind dafür zuständig, Aufgaben zu verstehen, Informationen zu bewerten und Ergebnisse zu formen.
    • Tool Nodes sind rein deterministisch. Sie führen klar definierte Operationen aus, etwa Datenbankabfragen, API-Calls, Dateitransformationen oder regelbasierte Logik ohne eigene interpretative Verantwortung. 

    Daraus ergibt sich ein sehr klares Prinzip: Nicht jeder Knoten im System muss selbst ein Agent sein. Aber sobald ein LLM beteiligt ist, ist das Gesamtsystem agentisch. 

    Diese Unterscheidung verbindet das Beste aus beiden Welten. Sie schafft architektonische Klarheit auf Systemebene und bewahrt zugleich Effizienz, Determinismus und Transparenz dort, wo sie besonders wichtig sind.

    Vor allem aber hilft sie, zwei typische Fehlentwicklungen zu vermeiden. Die erste ist die Illusion, es handle sich „nur um eine Pipeline“. Wer LLM-basierte Systeme weiterhin wie deterministische Abläufe behandelt, unterschätzt ihre Komplexität und verzichtet oft auf essenzielle Schutzmechanismen. Die zweite Fehlentwicklung liegt am anderen Ende des Spektrums: alles zu einem Agenten machen zu wollen. Das führt zu unnötigem LLM-Einsatz, höheren Kosten, mehr Latenz und geringerer Nachvollziehbarkeit und liefert keinen Mehrwert.

    Fazit 

    Die Frage nach der Definition eines Agenten scheint trivial. Doch sie hilft, zu verorten, wo in einem System Kontrolle verortet ist. Eine Pipeline führt vordefinierte Schritte aus. Ein agentisches System hingegen enthält Momente der Interpretation. Und in modernen KI-Systemen beginnt diese Interpretation in dem Augenblick, in dem ein LLM beteiligt ist.

    Damit wird auch der vermeintlich „einfache Extraktionsschritt“ bereits Teil eines agentischen Systems. Die eigentliche Gestaltungsfrage lautet daher nicht mehr: „Ist das ein Agent?“ Entscheidend ist vielmehr: „An welcher Stelle erlauben wir Urteilskraft und wo brauchen wir klassischen Determinismus?“ Wer diese Frage beantworten kann, legt damit bereits die Grundlage für eine tragfähige Architektur.

    Wenn Sie tiefer in das Thema KI-Agenten einsteigen und wissen wollen, wie KI-Agenten im Unternehmen einsetzbar sind, freuen wir uns, Sie auf der NAICE am 15. April 2026 zu begrüßen. Das Event steht im Zeichen von agentischer KI im Businesskontext und bringt Experten aus den verschiedensten Branchen zusammen. Registrierungen sind noch möglich. Ihr Ticket erhalten Sie auf der offziellen NAICE-Website

    Diesen Beitrag teilen:

    Autor

    Dr. Andreas Kyek

    Andreas ist Senior Principal Data Scientist und seit April 2022 bei [at]. Er hat über 20 Jahre Erfahrung in der Fertigung in der Halbleiter-Industrie und ist Experte für Anomalie-Erkennung und prädiktive Wartung. Spätestens seit Large-Language-Modell verfügbar wurden, beschäftigt er sich mehr und mehr mit Agenten, Datenverarbeitung durch Agenten und insbesondere mit dem Entwurf von Multiagentensystemen - auf Basis einschlägiger Bibliotheken, aber auch „from Scratch“.

    X

    Cookie Freigabe

    Diese Website verwendet notwendige Cookies zur Sicherstellung des Betriebs der Website. Eine Analyse des Nutzerverhaltens durch Dritte findet nicht statt. Detaillierte Informationen über den Einsatz von Cookies finden Sie in unseren Datenschutzerklärung.