Braucht ihr wirklich einen Agent oder reicht ein Endpoint?

Das Meeting, in dem das Wort fällt

Irgendwann in jedem AI-Projekt sitzt ein Team in einem Raum, jemand zeichnet Kästchen an ein Whiteboard, und dann fällt der Satz: „Wir brauchen einen Agenten.“ Niemand widerspricht, weil es klug klingt. Dabei ist es selten eine Anforderung, sondern ein Reflex. Hinter dem Wunsch steckt fast immer eine sehr konkrete Aufgabe: ein Dokument verarbeiten, eine Antwort aus einer Wissensbasis ziehen, einen Prozess anstossen. Ob diese Aufgabe wirklich einen Agenten braucht oder ob ein schlichter Endpoint reicht, entscheidet nicht der Trend, sondern die Struktur des Problems. Dieser Beitrag gibt dir das Vokabular und die Mathematik, um das ehrlich zu beurteilen, bevor du Wochen in eine Architektur steckst, die fragiler ist, als sie sein müsste.

Was hinter den Begriffen steckt

„Agent“ ist zu einem Marketingwort verkommen, das vom simplen Function-Call bis zum vollautonomen System alles meint. Bevor du abwägen kannst, brauchst du saubere Definitionen, denn die Mechanik dahinter ist sehr unterschiedlich, und genau sie entscheidet über Aufwand und Risiko.

Am einen Ende steht der Endpoint: ein zustandsloser Aufruf, Eingabe rein, Antwort raus. Du schickst einen Prompt, vielleicht angereichert mit Kontext aus deiner Datenbank (RAG), und bekommst genau ein Ergebnis zurück. Keine Schleife, kein Speicher zwischen den Aufrufen, keine Entscheidung des Modells über den nächsten Schritt. Das macht ihn vorhersehbar und testbar: Dieselbe Eingabe führt zu vergleichbarem Verhalten, und du kannst die Ausgabe gegen erwartete Resultate prüfen. Die allermeisten produktiven AI-Features sind genau das, auch wenn sie sich raffiniert anfühlen.

Am anderen Ende steht der Agent: eine Schleife. Er plant einen Schritt, ruft ein Werkzeug auf, liest dessen Ergebnis (die Beobachtung), bewertet, ob er dem Ziel näher gekommen ist, und entscheidet selbst, was als Nächstes kommt. Dieses Muster aus Gedanke, Aktion und Beobachtung nennt man ReAct: Das Modell „denkt laut“, handelt, beobachtet das Resultat und korrigiert sich, oft über mehrere Runden mit eigenem Gedächtnis. Diese Autonomie ist seine Stärke und zugleich die Quelle jedes Problems, denn jeder Schritt ist eine neue Gelegenheit zu scheitern.

Der grösste Denkfehler ist, die Welt in diese beiden Extreme zu teilen. Dazwischen liegen zwei wichtige Stufen, die viel zu oft übersprungen werden. Ein einzelner Tool-Call (Function-Calling) lässt das Modell genau ein Werkzeug aufrufen, ohne einen offenen Loop zu eröffnen: Frage rein, ein Funktionsaufruf, Antwort raus. Und ein Workflow mit festen Schritten ist ein vorgegebener Graph, in dem du die Reihenfolge bestimmst und das Modell nur die einzelnen Knoten füllt. Beides nutzt Sprachmodelle für mehr als reines Text-rein-Text-raus, behält aber die Kontrolle bei dir statt beim Modell, und löst erstaunlich viele Fälle, für die Leute reflexhaft zum vollen Agenten greifen.

Warum Autonomie die Zuverlässigkeit frisst

Der unbequeme Kern ist eine Rechnung, die niemand gern an die Wand schreibt: Zuverlässigkeit multipliziert sich über Schritte, sie addiert sich nicht. Selbst wenn jeder einzelne Schritt fast immer klappt, sinkt die Wahrscheinlichkeit, dass die ganze Kette gelingt, mit jeder Stufe. Nimm an, jeder Schritt gelingt mit 95 Prozent, das klingt solide. Über mehrere Schritte hinweg sieht es so aus:

• 3 Schritte: 0,95³ ≈ 0,86, schon nur noch 86 Prozent.
• 5 Schritte: 0,95⁵ ≈ 0,77, fast jede vierte Aufgabe scheitert.
• 10 Schritte: 0,95¹⁰ ≈ 0,60, ein Münzwurf mit leichtem Vorteil.

Und 95 Prozent pro Schritt ist optimistisch. Mit 90 Prozent kippt es brutal: 0,9⁵ ≈ 0,59 und 0,9¹⁰ ≈ 0,35. Ein zehnstufiger Agent, dessen Einzelschritte „meistens funktionieren“, liefert dann in zwei von drei Fällen Murks. Das ist keine Schwäche eines bestimmten Modells, sondern reine Wahrscheinlichkeitsrechnung. Genau deshalb sind echte Agenten nie nur „das Modell in einer Schleife“. Sie brauchen Guardrails, die unsinnige Aktionen abfangen, Validierung jeder Tool-Ausgabe, bevor sie weiterverarbeitet wird, Retries für einzelne Schritte und idempotente Werkzeuge, damit ein wiederholter Aufruf keinen Schaden anrichtet. All das ist Arbeit, die im „wir bauen schnell einen Agenten“ nie eingeplant ist, und wer die Fehlerfortpflanzung ignoriert, baut ein System, das in der Demo glänzt und in Produktion zerfällt.

Der Preis, den niemand einrechnet

Neben der Zuverlässigkeit kostet Autonomie auch direkt Geld und Zeit, und zwar überproportional. Ein Endpoint ruft das Modell einmal. Ein Agent ruft es viele Male: einmal zum Planen, einmal pro Werkzeugschritt, oft zusätzlich zur Reflexion zwischendurch. Eine Aufgabe, die als ein Request gedacht war, wird so zu einer Sitzung mit acht, zehn oder mehr Aufrufen. Schon das vervielfacht die Latenz, weil die Schritte seriell aufeinander warten: Schritt drei kann erst beginnen, wenn Schritt zwei beobachtet wurde.

Der teurere Effekt ist subtiler. Damit der Agent weiss, was er bisher getan hat, schleppt er die ganze Historie in jedem Aufruf mit. Schritt eins schickt 1000 Token, Schritt zwei die 1000 plus die neue Beobachtung, Schritt drei alles davor, und so weiter. Die Token-Kosten wachsen damit nicht linear, sondern eher quadratisch über die Länge der Sitzung. Acht Aufrufe mit wachsendem Kontext kosten leicht das Fünf- bis Zehnfache von acht gleich grossen Single-Calls. Was das in deiner konkreten Rechnung bedeutet, haben wir in den Kosten eigener LLMs aufgeschlüsselt; bei Agenten triffst du diesen Multiplikator besonders hart.

Wann ein Endpoint reicht, und wann der Agent sich lohnt

Die ehrliche Mehrheit der Fälle kommt mit einem Endpoint aus. Eine E-Mail zusammenfassen, ein Ticket klassifizieren, strukturierte Felder aus einem Dokument extrahieren, eine Frage über deine Wissensbasis beantworten (RAG-Q&A): das sind Aufgaben mit definierter Eingabe und definierter Ausgabe. Ein Endpoint mit gutem Prompt und passendem Kontext löst sie zuverlässiger als jeder Agent, weil es nichts gibt, das mehrstufig schiefgehen könnte. Du hast einen einzigen Punkt, an dem du die Qualität misst, statt einer Kette. Und sobald du garantieren musst, was das System tut, spielt diese Berechenbarkeit ihre ganze Stärke aus. Du kannst den Endpoint mit einer Testsuite gegen reale Beispiele prüfen und sein Verhalten einklammern, während ein planender Agent bei gleicher Eingabe einen anderen Pfad wählen kann. Für alles, was in einen Geschäftsprozess eingebettet und auditierbar sein muss, ist das Gold wert.

Es gibt aber echte Fälle, in denen Autonomie ihren Preis wert ist, und sie teilen ein Muster: Der Lösungsweg steht vorab nicht fest. Wenn nicht vorhersehbar ist, wie viele Schritte nötig sind und welche, spielt ein Agent seine Stärke aus, etwa eine Recherche, die abhängig vom Zwischenergebnis weitersucht, oder ein Diagnoseprozess, der je nach Befund verzweigt. Hier wäre ein starrer Endpoint das falsche Werkzeug, weil du die Verzweigungen nicht alle im Voraus verdrahten kannst; die Autonomie ersetzt eine Fallunterscheidung, die du sonst nie vollständig hinbekämst. Ähnlich, wenn das System mehrere Werkzeuge orchestrieren muss, also Datenbank abfragen, Ergebnis prüfen, je nachdem eine weitere API rufen, dann etwas schreiben, und die Reihenfolge vom Inhalt der Zwischenergebnisse abhängt. Aber prüfe vorher ehrlich, ob sich der Ablauf nicht doch als fester Workflow-Graph zeichnen lässt. Den vollen autonomen Loop rechtfertigt erst die echte Unvorhersehbarkeit des Pfades, nicht schon die Tatsache, dass mehrere Tools im Spiel sind.

Die Stufenleiter als Entscheidungsregel

Statt „Endpoint oder Agent“ denkst du besser in Stufen und nimmst immer die niedrigste, die dein Problem löst:

1. Prompt-Endpoint: ein Modellaufruf, sonst nichts.
2. + RAG: derselbe Aufruf, angereichert mit Kontext aus deinen Daten.
3. + einzelner Tool-Call: das Modell darf genau ein Werkzeug aufrufen, ohne Loop.
4. Fester Workflow-Graph: du gibst die Schritte vor, das Modell füllt die Knoten.
5. Autonomer Agent: das Modell entscheidet selbst über Reihenfolge und Anzahl der Schritte.

Jede Stufe nach oben kauft dir Flexibilität und kostet dich Vorhersehbarkeit, Geld und Testbarkeit. Die meisten Teams landen viel zu schnell auf Stufe fünf, obwohl Stufe drei oder vier ihre Aufgabe stabiler und billiger erledigt hätte. Steig nur dann eine Stufe höher, wenn die darunterliegende nachweislich nicht reicht.

Unser ehrliches Fazit

Fang immer unten an. Frag dich: Lässt sich die Aufgabe in einen, höchstens zwei feste Schritte zerlegen? Dann bleib beim Endpoint. Erst wenn der Pfad echt variabel ist und mehrere Systeme dynamisch orchestriert werden müssen, ist der Sprung zum autonomen Loop gerechtfertigt, und dann mit Guardrails, Validierung und Retries von Anfang an, nicht als Nachgedanke. Wir bauen Agents genau für die Fälle, in denen sich die Autonomie auszahlt. Und wir sagen dir ehrlich, wenn ein schlichter Endpoint dich schneller, billiger und stabiler ans Ziel bringt, denn das ist häufiger der Fall, als der Hype glauben macht.