Die meisten Aufgaben brauchen keinen KI-Agenten. Nehmen Sie eine Pipeline.

Sie brauchen für die meisten Aufgaben keinen KI-Agenten. Wenn die Arbeit einem bekannten Pfad folgt, diese Felder extrahieren, dieses Dokument zusammenfassen, dieses Ticket klassifizieren, diese Antwort entwerfen, dann schlägt eine langweilige deterministische Pipeline einen autonomen Agenten auf jeder Achse, die in der Produktion zählt: Zuverlässigkeit, Kosten, Latenz, Debugbarkeit und Angriffsfläche. Eine Pipeline ist ein schlichtes Skript, das ein Sprachmodell genau einmal aufruft, die Ausgabe gegen ein Schema validiert und das Ergebnis auf eine Queue legt. Sie tut jedes Mal dasselbe, scheitert an einer einzigen offensichtlichen Stelle und kostet einen Modellaufruf. Ein autonomer Agent dagegen entscheidet seine Schritte zur Laufzeit, durchläuft viele Modellaufrufe und kann komplett vom Pfad abkommen. Zum Agenten greifen Sie nur, wenn der Pfad im Voraus wirklich nicht bekannt sein kann: offene Exploration, Werkzeugeinsatz über einen unvorhersehbaren Entscheidungszweig, Erholung aus Zuständen, die Sie nicht aufzählen konnten. Das ist eine echte Kategorie, aber die Minderheit. Das meiste, wofür Teams heute Agenten verdrahten, ist das nicht. Es ist eine feste Pipeline im Agenten-Kostüm, und das Kostüm bringt Latenz, Kosten und ein Dutzend neuer Fehlermodi ohne jeden Zugewinn an Zuverlässigkeit. Beginnen Sie mit der Pipeline. Fügen Sie Autonomie erst hinzu, wenn die Pipeline die Aufgabe nachweislich nicht lösen kann.

Das ist weder Anti-KI noch Anti-Agent. Es ist ein Plädoyer, die Maschine dem Problem anzupassen. Die Branche hat zwei Jahre lang „agentisch“ als Synonym für „fortgeschritten“ behandelt, und das Ergebnis ist eine Welle von Systemen, denen man schwerer trauen, die man schwerer abrechnen und schwerer debuggen kann als den einen Aufruf, den sie ersetzt haben. Es folgt die ehrliche Aufteilung: was eine deterministische Pipeline tatsächlich ist, wie sich beide über die Metriken vergleichen, die über die Produktion entscheiden, die vier Fragen, die Over-Engineering entlarven, und die echten Fälle, in denen ein Agent seinen Preis wert ist.

Der Standard sollte eine Pipeline sein, kein Agent

Der richtige Standard für jede neue Aufgabe ist das Einfachste, was funktionieren könnte: ein Skript, ein Modellaufruf, eine Queue. Anthropics eigener Leitfaden zum Bau effektiver Agenten sagt dasselbe: Teams sollen die einfachste mögliche Lösung suchen und agentische Komplexität nur hinzufügen, wenn sie die Ergebnisse nachweislich verbessert, denn autonome Systeme tauschen Latenz und Kosten gegen eine Flexibilität, die Sie vielleicht gar nicht brauchen. Ein fester Workflow ist keine minderwertige Antwort. Für eine bekannte Aufgabe ist er die richtige.

Anthropic zieht eine nützliche Linie zwischen einem Workflow, in dem die Schritte über vordefinierte Codepfade orchestriert werden, und einem Agenten, in dem das Modell seinen eigenen Ablauf lenkt und seine Werkzeuge zur Laufzeit wählt. Die meisten Geschäftsaufgaben sind Workflows. Sie kennen die Eingaben, Sie kennen die Form der Ausgabe, und Sie kennen die Schritte. Wenn alle drei bekannt sind, ist es kein Kompromiss, sie in gewöhnlichem Code abzubilden und das Modell für den einen Teil zu reservieren, der Sprachverständnis braucht, sondern das Design. Das Agenten-Framework, zu dem Sie gegriffen haben, löst ein Problem unbekannten Kontrollflusses, das Ihre Aufgabe gar nicht hat.

Was eine deterministische Pipeline tatsächlich ist

Eine deterministische Pipeline besteht aus drei langweiligen Teilen: einem Skript, das den Kontrollfluss besitzt, einem einzelnen, eng geführten Modellaufruf, der das Eine tut, das nur ein Modell kann, und einer Queue, die das Ganze dauerhaft und wiederholbar macht. Das Skript entscheidet, was in welcher Reihenfolge passiert. Das Modell liest die Rechnung und gibt strukturierte Felder zurück, oder liest das Ticket und gibt eine Kategorie zurück, und nicht mehr. Die Queue bedeutet, dass ein Fehler ein Wiederholungsversuch ist, kein verlorener Auftrag.

Die Stärke dieser Form ist, dass die Intelligenz auf Abruf bereitsteht, aber nicht das Kommando führt. Das Modell ist eine reine Funktion in einem Ablauf, den Sie steuern: Text hinein, strukturierte Daten heraus, gegen ein Schema validiert, bevor irgendetwas dahinter ihm traut. Scheitert die Ausgabe an der Validierung, wiederholen Sie oder leiten an einen Menschen weiter, an einer offensichtlichen Stelle. Vergleichen Sie das mit einem Agenten, in dem das Modell der Kontrollfluss ist: es wählt das nächste Werkzeug, interpretiert das Ergebnis, entscheidet, ob es fertig ist, und jede dieser verborgenen Entscheidungen kann auf eine Weise schiefgehen, die Sie nicht geschrieben haben und nicht leicht sehen. Dieselbe Disziplin durchzieht das Bauen von LLM-Funktionen, die die Produktion überleben: das Modell zuerst als Baustein integrieren und die Komplexität nur steigern, wenn die Evidenz es erzwingt.

Pipeline gegen Agent, über die Achsen, die über die Produktion entscheiden

Auf jeder Dimension, die entscheidet, ob ein System den Kontakt mit echtem Verkehr übersteht, gewinnt die deterministische Pipeline bei bekannten Aufgaben. Sie ist zuverlässiger, weil sie einen Pfad hat, günstiger, weil sie einen Modellaufruf macht, schneller, weil sie nicht schleift, leichter zu debuggen, weil jeder Schritt Code ist, den Sie geschrieben haben, und sicherer, weil ihr Wirkungsradius fest ist. Der Agent tauscht all das gegen Autonomie. Hier der Vergleich, schlicht dargestellt.

Die Sicherheitszeile verdient eigene Betonung, denn sie ist die, die man überspringt. In einer Pipeline ist die Ausgabe des Modells Daten, die Sie prüfen. In einem Agenten ist die Ausgabe des Modells eine Handlung, die es ausführt: ein Shell-Befehl, ein API-Aufruf, ein Dateizugriff. Dieser Unterschied ist der ganze Grund, warum ein gekaperter Agent gefährlich ist, und warum Prompt Injection sich nicht wegpatchen lässt, sondern nur umbauen. Jedes Werkzeug, das Sie einem autonomen Agenten geben, ist ein neuer Weg, auf dem ein in abgerufenen Daten versteckter Befehl zu einer echten Handlung wird. Eine Pipeline, die die Modellausgabe als zu validierenden Text behandelt, hat diese Tür schlicht nicht.

Warum die Zuverlässigkeitsrechnung lange Agenten-Schleifen bestraft

Zuverlässigkeit multipliziert sich, und das ist der stille Killer mehrstufiger Agenten. Wenn jeder Schritt in einer autonomen Schleife starke 95 % zuverlässig ist, landet eine fünfstufige Aufgabe bei rund 77 % und eine zehnstufige bei rund 60 %. Eine Pipeline mit einem Modellaufruf und einem Validierungstor hält ihre Zuverlässigkeit dort, wo der einzelne Aufruf sie hält, weil es keine Kette unabhängiger Entscheidungen gibt, die sie abtragen. Der Agent scheitert nicht, weil das Modell schwach ist, sondern weil Sie von einem unvollkommenen Baustein verlangt haben, viele Male hintereinander ohne Kontrollpunkt richtig zu liegen.

Genau deshalb sterben so viele beeindruckende Demos auf dem Weg in die Produktion. Die Demo läuft den glücklichen Pfad einmal. Die Produktion läuft den unglücklichen Pfad zehntausendmal, und die Fehlermodi des Agenten sind nicht-deterministisch, also können Sie sie nicht reproduzieren, keinen Regressionstest dagegen schreiben und einem Kunden nicht zusichern, dass sie behoben sind. Es ist dieselbe Lücke wie in warum 90 % der KI-Projekte vor der Produktion scheitern: das Modell war nie der Engpass, das Engineering drumherum war es, und ein Agent vervielfacht das Engineering drumherum, das Sie richtig hinbekommen müssen. Wenn Sie das System nicht rigoros evaluieren können, fügt Autonomie nur Fehlerwege hinzu, die Sie nicht messen können.

Vier Fragen, die Over-Engineering entlarven

Bevor Sie einen Agenten bauen, beantworten Sie vier Fragen ehrlich. Sie dauern fünf Minuten und schicken die meisten Aufgaben zur Pipeline zurück. Wenn Sie die Schritte benennen können, die Ausgabeform kennen, keine Erholung mitten in der Aufgabe brauchen und sich die Schleife nicht leisten können, sehen Sie einen Workflow, und ihn als Agenten zu verkleiden ist Dekoration, die Sie Zuverlässigkeit kostet.

• Kann ich die Schritte im Voraus aufschreiben? Wenn Sie die Schritte als Flussdiagramm auflisten können, kodieren Sie dieses Flussdiagramm im Code. Vordefinierter Kontrollfluss braucht kein Modell, das ihn bei jedem Lauf neu entdeckt.
• Ist die Ausgabeform bekannt? Wenn die Antwort immer eine feste Struktur ist, ein Satz Felder, eine Kategorie, ein Ja oder Nein mit Begründung, dann liefert ein eng geführter Aufruf sie. Autonomie fügt einem bekannten Ziel nichts hinzu.
• Muss die Aufgabe wirklich auf das reagieren, was sie entdeckt? Echte Agentität heißt, dass die nächste Handlung tatsächlich von einem unvorhersehbaren Zwischenergebnis abhängt. Wenn jeder Zweig einer ist, den Sie hätten schreiben können, ist es ein Workflow mit If-Verzweigungen, kein Agent.
• Kann ich mir die Latenz und die Token-Rechnung leisten? Ein Agent, der dreißig Sekunden schleift und zwanzig Modellaufrufe pro Aufgabe verbrennt, ist ein echter Kostenfaktor. Würde ein einziger Aufruf reichen, zahlen Sie das Zwanzigfache für Autonomie, die Sie nicht genutzt haben.

Der häufigste Fehler ist der lebenslauf-getriebene Bau: der Agent existiert, weil „Multi-Agenten-Orchestrierung“ in einer Demo besser klingt und sich im Lebenslauf besser liest als „ein Cronjob, der ein Modell aufruft“. Dieser Instinkt ist teuer. Gartner erwartet, dass bis Ende 2027 über 40 % der agentischen KI-Projekte eingestellt werden, wegen eskalierender Kosten, unklaren Geschäftswerts und unzureichender Risikokontrollen, und warnt, dass ein Großteil des Marktes „Agent Washing“ betreibt, bestehende Produkte, die als Agenten umetikettiert werden, und schätzt, dass nur etwa 130 von Tausenden selbsternannter agentischer Anbieter echt sind. Das Over-Engineering ist kein Randfehler. Es ist der Normalfall.

Wann ein Agent wirklich das richtige Werkzeug ist

Ein Agent verdient seine Komplexität, wenn der Kontrollfluss bis zur Laufzeit wirklich unbekannt ist: wenn die Aufgabe offene Exploration braucht, wenn das richtige nächste Werkzeug auf eine Weise davon abhängt, was das letzte zurückgab, die Sie nicht aufzählen können, und wenn der Wert des Ankommens den Verlust an Vorhersehbarkeit überwiegt. Solche Aufgaben gibt es, und für sie ist ein Agent kein Over-Engineering, sondern die einzige passende Form. Die Kunst ist, sie von der Pipeline im Kostüm zu unterscheiden.

Gute agenten-förmige Arbeit hat eine Signatur: die Zahl der Schritte ist im Voraus nicht bekannt, der Pfad verzweigt sich auf entdeckte Information, und ein Mensch würde bei derselben Arbeit ebenfalls improvisieren. Offene Recherche über Quellen, die Sie vorab nicht auflisten können. Ein interaktiver Coding-Assistent, der eine Codebasis erkundet und auf Compiler-Fehler reagiert. Triage, die je nach einer nicht vorab klassifizierbaren Eingabe entscheidet, welches von vielen Werkzeugen sie aufruft. Wenn Sie diese bauen, bauen Sie sie absichtlich auf die harte Tour: jedes Werkzeug auf Least Privilege begrenzen, die unumkehrbaren Handlungen absichern, für die gefährlichen einen Menschen in der Schleife halten und das ganze System so entwerfen, dass es einen Hijack eindämmt. Diese Disziplin ist das Thema von was in der Agenten-Orchestrierung in der Produktion bricht und warum ein Coding-Agent eine Leine braucht. Der Punkt ist nicht, dass Agenten schlecht sind. Es ist, dass sie ein Spezialwerkzeug für unbekannten Kontrollfluss sind, und Sie sollten ihren Preis nur zahlen, wenn die Aufgabe ihn tatsächlich hat.

Der pragmatische Standard: langweilig anfangen, auf Evidenz eskalieren

Die brauchbare Regel: mit der geringsten Autonomie beginnen, die die Aufgabe lösen könnte, und Autonomie nur hinzufügen, wenn die einfachere Form nachweislich scheitert. Zuerst ein Prompt. Reicht ein Prompt nicht, eine feste Kette von Prompts mit Validierung dazwischen. Kann eine feste Kette die Aufgabe nicht ausdrücken, weil der Pfad sich wirklich auf entdeckten Zustand verzweigt, dann, und erst dann, ein Agent, gebaut mit den obigen Leitplanken. Die meisten Aufgaben halten bei Schritt eins oder zwei an. Das ist der Befund, keine Einschränkung.

Das spiegelt dieselbe ehrliche Reihenfolge wider, die immer dann auftaucht, wenn Sie KI-Formen an ihren echten Abwägungen statt an ihrem Marketing messen, dieselbe Logik wie bei der Wahl zwischen selbst gehosteten Modellen und Cloud-APIs oder einer Retrieval-Pipeline statt eines Fine-Tunings. Wählen Sie die einfachste Architektur, die die Anforderung erfüllt, messen Sie sie, und lassen Sie die Evidenz, nicht den Hype, entscheiden, wann Sie die Komplexitätsleiter hochsteigen. Die Teams, die zuverlässige KI in Produktion bringen, sind überwältigend jene, die langweilige Pipelines mit einem Modell in genau einem gut definierten Slot betreiben.

Weiterführende Lektüre

• Multi-Agenten-Orchestrierung: Was in der Produktion bricht
• Ihr KI-Coding-Agent kann alles löschen. So zähmen Sie ihn.
• LLM-Funktionen bauen, die die Produktion überleben
• Warum 90 % der KI-Projekte vor der Produktion scheitern
• RAG-Pipelines in der Produktion: Was im Maßstab hält