Wann Sie keinen KI-Agenten bauen sollten

Inhaltsverzeichnis

Veröffentlicht August 2026.

TL;DR: Die meisten KI-Agenten-Ideen sind das falsche Werkzeug für die Aufgabe. Bevor ich Agentencode schreibe, prüfe ich fünf disqualifizierende Signale: ein instabiler Prozess, geringe Häufigkeit, kein Bestanden/Durchgefallen-Test, ein einfacheres Werkzeug, das bereits funktioniert, oder ein irreversibler Fehlerfall, den ich rechtzeitig nicht absichern kann. Trifft eines davon zu, baue ich nicht. Stattdessen gehe ich eine Leiter günstigerer Alternativen durch und komme nur zu einem eigenen Agenten zurück, wenn nichts auf dieser Leiter hält.

[Sicht des Operators] Ich betreibe mehr als 30 Agenten in Produktion für eine Beratungsmarke und Pickleland, eine Pickleball-Anlage in Pflugerville, TX. Ich habe mindestens genauso viele Agentenideen verworfen wie ich gebaut habe, und fast keine davon starb, weil die Idee schlecht war — sie starben, weil ein Agent für diese bestimmte Aufgabe das falsche Werkzeug war. Dieser Beitrag ist der Filter, den ich anwende, bevor „sollte ich das bauen” zu „wie baue ich das” wird.

Die Standardantwort ist Nein

Das ROI-Framework, das ich verwende, sagt Ihnen, ob eine Automatisierung ihre Bau- und Wartungskosten wieder einspielt. Das ist die richtige zweite Frage. Die erste Frage ist einfacher und wird ständig übersprungen: Muss das überhaupt ein Agent sein?

„Agent” ist zum Standardbegriff für alles geworden, was ein LLM betrifft — genauso wie „App” vor fünfzehn Jahren zum Standardbegriff für alles wurde, was einen Bildschirm betraf. Nicht alles, was ein Modell berührt, braucht ein dauerhaftes, autonomes, werkzeugaufrufendes System, das auf Auslöser wartet und eigenständig handelt. Ein Großteil dessen, was Leute „einen Agenten bauen” nennen, ist in Wirklichkeit „einen wirklich guten Prompt schreiben und ihn von Hand ausführen” — und das ist kein Fehlschlag, sondern oft der richtige Endzustand.

Ich behandle „einen eigenen Agenten bauen” als die teuerste Option auf einer Leiter von Optionen, nicht als die erste Sprosse. Bevor ich danach greife, prüfe ich, ob sich die Aufgabe selbst disqualifiziert.

Fünf Signale, dass ein Agent das falsche Werkzeug ist

Jedes einzelne davon reicht für sich genommen meist schon aus, um mich zu stoppen.

1. Der Prozess ist noch nicht stabil. Wenn sich der Workflow im letzten Monat zweimal geändert hat, weil das Unternehmen selbst noch herausfindet, was es will, friert ein Agent die heutige Version eines Prozesses ein, der sich gleich wieder ändert. Sie werden den Prompt, das Werkzeugschema und das Eval-Set bei jeder Prozessänderung neu schreiben — das heißt, Sie warten einen Agenten, statt ein Unternehmen zu führen. Führen Sie es manuell aus, bis es sich ein Quartal lang nicht mehr ändert, und automatisieren Sie dann die stabile Version.

2. Es läuft zu selten, um sich zu amortisieren. Eine Aufgabe, die zweimal im Jahr anfällt, sammelt nicht genug Ausführungen an, um Bauzeit, Testzeit und ein Eval-Set zu rechtfertigen, egal wie gut sie einmal fertig laufen würde. Geringe Häufigkeit bei hohem Bauaufwand ist nahezu der schlechteste Quadrant für Automatisierung — Sie zahlen die vollen Baukosten und erhalten kaum Einsparungen zurück.

3. Sie können keinen Bestanden/Durchgefallen-Test dafür schreiben. Wenn Sie im Voraus nicht gut genug beschreiben können, wie eine korrekte Ausgabe aussieht, um sie programmatisch zu prüfen, können Sie dafür keinen Eval-Harness bauen — und ein Agent, den Sie nicht bewerten können, ist ein Agent, bei dem Sie blind fliegen. Aufgaben, die reiner Geschmack sind („klingt das nach mir”) oder reines Urteilsvermögen ohne konsistente Bewertungsgrundlage, bleiben manuell oder jedes Mal menschlich geprüft — was den Sinn der Automatisierung zunichtemacht.

4. Ein einfacheres Werkzeug erledigt die Aufgabe bereits. Fragen Sie sich, bevor Sie einen Agenten skizzieren, was eine Tabellenkalkulationsformel, ein Zapier-/Make-/n8n-Workflow mit einem einzigen LLM-Schritt oder ein gespeicherter Prompt bringen würde. Wenn die ehrliche Antwort „zu 90 % dorthin” lautet, rechtfertigen die letzten 10 % selten einen Agenten mit eigener Infrastruktur, Überwachung und Wartungsaufwand. Ich habe schon Agenten für Aufgaben skizziert, die eine Filteransicht und eine wiederkehrende Kalendererinnerung genauso gut gelöst hätten.

5. Der Fehlerfall ist irreversibel, und Sie haben keine Zeit, das Freigabetor richtig zu bauen. Manche Aktionen — ein Massen-E-Mail-Versand, eine Rückerstattung, ein öffentlicher Beitrag — lassen sich nicht rückgängig machen. Freigabetore mit Mensch im Loop existieren genau dafür, aber ein überstürztes Tor, das niemand tatsächlich prüft, ist schlimmer als gar keine Automatisierung: Es erzeugt den Anschein von Aufsicht ohne deren Substanz. Wenn Sie keine Zeit haben, das Tor richtig zu bauen und zu besetzen, ist das ein Signal, langsamer zu machen — kein Grund, das Tor auszulassen.

Trifft keines der fünf zu — der Prozess ist stabil, er läuft oft genug, Sie können „korrekt” definieren, kein einfacheres Werkzeug deckt es ab, und der Fehlerfall ist entweder reversibel oder ordentlich abgesichert — dann lohnt es sich, die ROI-Rechnung darauf anzuwenden.

Die Leiter, die ich vor dem Bauen erklimme

Wenn eine Aufgabe eine der fünf Prüfungen nicht besteht — oder bevor ich überhaupt so weit gekommen bin — arbeite ich diese Liste der Reihe nach ab und halte bei der ersten Sprosse an, die das Problem tatsächlich löst.

1. Fragen Sie das Modell einfach direkt. Kein Wrapper, keine Werkzeugaufrufe, keine dauerhafte Infrastruktur. Öffnen Sie Claude, fügen Sie den Kontext ein, stellen Sie die Frage, nutzen Sie die Antwort. Das erledigt mehr einmalige und gelegentliche Aufgaben, als man erwarten würde, weil der „Agenten”-Instinkt sogar bei Dingen einsetzt, die nur einmal passieren müssen.

2. Ein gespeicherter Prompt oder Projektanweisungen. Wenn dieselbe Art von Anfrage wiederholt auftritt, aber jede Instanz weiterhin einen Menschen braucht, der die Eingaben sammelt und die Ausgabe prüft, speichern Sie den Prompt als Vorlage — Projektanweisungen, ein eigenes Anweisungsset, ein Snippet — statt den Auslöser zu automatisieren. Sie bekommen den Konsistenzgewinn eines Agenten ohne die Infrastruktur.

3. Ein No-Code-Automatisierungstool mit einem einzigen LLM-Schritt. Für Aufgaben, die wirklich einen Auslöser brauchen (eine neue Formularübermittlung, eine neue Zeile in einer Tabelle), die Logik selbst aber einfach ist, ist ein Workflow-Tool mit einem Modellaufruf in der Mitte deutlich günstiger zu bauen und zu warten als eigener Code. Ich greife darauf zurück, bevor ich zu eigener Infrastruktur greife, sobald der Auslöser standardisiert und das Volumen niedrig bis moderat ist.

4. Eine manuell ausgeführte Vorlage. Manche Prozesse profitieren mehr von einer Checkliste als von Automatisierung, weil der Wert darin liegt, dass ein Mensch jeden Schritt durchdenkt, nicht in der Geschwindigkeit. Automatisieren Sie nicht das Denken bei Aufgaben weg, bei denen das Denken der eigentliche Punkt ist.

5. Auslagern. Bei allem mit echter Mehrdeutigkeit oder Urteilsvermögen, wo Sie keine Zeit haben, ein Eval-Set zu bauen und zu pflegen, ist eine Person — eine virtuelle Assistenz, ein Spezialist, ein Anbieter einer produktisierten Dienstleistung — oft schneller einsatzbereit und lässt sich unterwegs leichter korrigieren als ein Agent, den Sie noch feinjustieren.

6. Erst dann: ein eigener Agent. Wenn Sie die Leiter durchgegangen sind und nichts davon hält — der Auslöser braucht echtes Urteilsvermögen unter Last, das Volumen ist zu hoch für manuelle oder ausgelagerte Bearbeitung, und die ROI-Rechnung geht auf —, dann verdient sich ein zweckgebauter Agent mit eigenem Zuverlässigkeits-Stack seine Baukosten.

Der zweiwöchige Schattentest

Für alles, was auf der Kippe steht — die fünf Prüfungen besteht, ich aber trotzdem noch unsicher bin —, führe ich vor der Entscheidung zu bauen einen zweiwöchigen Schattentest durch. Ich erledige die Aufgabe selbst, nutze das Modell dabei als Copilot statt als autonomes System: derselbe Prompt, den ich dem Agenten irgendwann geben würde, dieselben Eingaben, aber ich lese jede Ausgabe, bevor sie irgendwohin geht.

Zwei Dinge kommen aus diesem Test heraus. Erstens, ob das Modell bei der Aufgabe tatsächlich auf dem Qualitätsniveau gut ist, das ich brauche — wenn ich die Hälfte der Ausgabe von Hand umschreibe, ist die Aufgabe unabhängig von allem anderen noch nicht bereit zur Automatisierung. Zweitens ein echtes Eval-Set: zwei Wochen Eingaben und die Ausgaben, die ich als korrekt beurteilt habe, sind genau das, was ein Eval-Harness braucht — und ich habe es meist gratis gesammelt, bis ich mich zum Bauen entscheide.

Der Schattentest legt außerdem Randfälle offen, bevor sie in Produktion sind. Es ist deutlich günstiger, während eines manuellen Testlaufs zu entdecken, dass 15 % der Eingaben eine Sonderbehandlung brauchen, als es aus einer Kundenbeschwerde nach dem Start des Agenten zu erfahren.

Eine Regel, die ich nach dem Verwerfen einer Idee anwende

Eine Agentenidee zu verwerfen ist nicht dasselbe wie das zugrunde liegende Problem zu lösen. Wenn sich eine Aufgabe vorerst selbst disqualifiziert — der Prozess verschiebt sich noch, das Volumen ist zu gering —, schreibe ich auf, warum, und lege einen groben Wiedervorlagepunkt fest (meist an einen bestimmten Auslöser geknüpft: „erneut prüfen, sobald die Buchungen über 50/Woche steigen”, nicht nur ein Datum). Agentenideen, die einmal verworfen und nie wieder aufgegriffen werden, werden leise zu dauerhafter manueller Arbeit, an deren zweite Bewertung sich niemand mehr erinnert.

Die umgekehrte Disziplin ist genauso wichtig: Eine Idee, die die fünf Prüfungen und die ROI-Rechnung besteht, wird nicht automatisch heute gebaut. Sie kommt in dieselbe Warteschlange wie alles andere, eingestuft gegen die Automatisierungen, die sich bereits bewährt haben. Den Filter zu bestehen verschafft einer Aufgabe einen Platz in der Reihe, keine Ausnahme von der Priorisierung.

FAQ

Ist das nicht einfach ein Argument gegen Automatisierung?

Nein — es ist ein Argument gegen den Standardgriff zur teuersten Form der Automatisierung. Die meisten der oben genannten Alternativen auf der Leiter sind immer noch Automatisierung, nur leichtgewichtiger. Ich betreibe Dutzende Produktionsagenten. Es geht nicht darum, das Bauen zu vermeiden, sondern damit aufzuhören, direkt zu „einen eigenen Agenten bauen” zu springen, wenn ein gespeicherter Prompt oder ein No-Code-Workflow dasselbe Ergebnis für einen Bruchteil der Bau- und Wartungskosten liefert.

Was, wenn das Volumen der Aufgabe später eindeutig wachsen wird?

Das ist ein legitimer Grund, den aktuellen Zahlen vorauszubauen — diese Ausnahme behandle ich im ROI-Framework. Das hebelt die fünf Signale oben aber nicht aus. Wenn der Prozess noch instabil ist oder Sie noch keine korrekte Ausgabe definieren können, bedeutet wachsendes Volumen nur, dass Sie einen kaputten Agenten in größerem Maßstab warten werden. Beheben Sie zuerst Instabilität und Testbarkeit; Skalierung ist ein Grund, früher zu bauen, sobald diese gelöst sind — kein Grund, sie zu überspringen.

Woher weiß ich, ob ein No-Code-Tool-Schritt „gut genug” ist oder eigener Code nötig ist?

Probieren Sie es zuerst aus und messen Sie es an Ihrem Eval-Set, selbst einem informellen. No-Code-LLM-Schritte bewältigen einzweckige Aufgaben mit einer Eingabe gut. Sie geraten an ihre Grenzen, sobald Sie mehrstufige Werkzeugnutzung, persistenten Zustand über Läufe hinweg oder bedingte Logik brauchen, die sich im Tool-Builder nicht sauber ausdrücken lässt. Wenn Sie an diese Grenze stoßen, ist das ein echtes Signal, zu eigener Infrastruktur zu wechseln — kein Grund, dort zu beginnen.

Gilt das für interne Tools anders als für kundenseitige?

Die fünf Signale gelten gleichermaßen, aber der Einsatz ist unterschiedlich. Ein internes Tool mit instabilem Prozess verschwendet nur die Zeit des eigenen Teams, wenn es bricht. Ein kundenseitiges mit instabilem Prozess untergräbt das Vertrauen von Menschen, die sich nicht freiwillig als Ihr Eval-Set gemeldet haben. Ich lege bei kundenseitigen Automatisierungen eine strengere Version von Signal fünf an — die Messlatte für „ordentlich abgesichert” liegt höher, wenn ein Fremder statt eines Kollegen auf der anderen Seite eines Fehlers steht.

Was ist der häufigste Grund, aus dem Sie eine Agentenidee verwerfen?

Signal drei — kein sauberer Bestanden/Durchgefallen-Test. Das ist am leichtesten in der Skizzierungsphase zu übersehen, weil sich die Aufgabe genau bis zu dem Moment gut definiert anfühlt, in dem man versucht aufzuschreiben, wie eine korrekte Ausgabe im Voraus tatsächlich aussieht. Wenn ich das nicht in ein, zwei Sätzen kann, weiß ich, dass der Agent unbewertbar sein wird — was bedeutet, er ist unverbesserlich, was bedeutet, er wird vorerst nicht gebaut.