Single LLM Call vs. mehrstufige Agent Chains

Ein einziger, gut konzipierter LLM Call schlägt eine mehrstufige Agent Chain in der Regel bei Kosten, Latenz und Zuverlässigkeit – es sei denn, die Aufgabe erfordert tatsächlich, dass das Modell ein Zwischenergebnis beobachtet, bevor es entscheidet, was als Nächstes zu tun ist. Die meisten „Agenten"-Features, die Gründer uns zu bauen bitten, brauchen das nicht. Sie brauchen einen guten Prompt mit strukturiertem Output.

Warum Chains trotzdem der Standard sind

Mehrstufige Chains sind verführerisch, weil sie widerspiegeln, wie ein Mensch das Problem lösen würde: recherchieren, dann entwerfen, dann überprüfen, dann überarbeiten. Frameworks machen es einfach, vier LLM Calls mit einem Planner davor zu verknüpfen – und in der Demo sieht das gut aus. Wir haben genau diese Struktur selbst gebaut, für unser eigenes Cold-Outreach-System: Unternehmensfakten extrahieren, dann zusammenfassen, dann die E-Mail entwerfen, dann ein separater „Polishing"-Durchlauf – vier Hops, weil ein Mensch es so angehen würde, wenn man ihm die Arbeit Schritt für Schritt übergibt.

Und genau dort bricht die Struktur auseinander. Jeder Hop ist:

• Eine neue Stelle, an der Kontext verloren geht. Unser „Zusammenfassen"-Schritt sah nur den Output des Extraktionsschritts, nicht die ursprünglich gecrawlte Seite – sodass beim Entwurf der E-Mail nur eine verlustbehaftete Zusammenfassung einer Zusammenfassung vorlag.
• Eine neue Latenzsteuer. Vier sequentielle Calls à 2–3 Sekunden bedeuten 10+ Sekunden, bevor ein Nutzer etwas sieht – noch ohne Retries einzurechnen.
• Eine neue Fehlerquelle. In unserer Pipeline hat der „Polishing"-Schritt regelmäßig Details überschrieben, die der Extraktionsschritt korrekt erfasst hatte – weil er keine Sicht darauf hatte, warum der Entwurf das sagte, was er sagte. Er sah nur einen Entwurf und den Auftrag, ihn zu verbessern.

Anthropics eigene Empfehlung dazu ist klar: Beginnen Sie mit der einfachsten Lösung, und fügen Sie agentische Komplexität – mehrstufige Planung, Tool-Loops – nur dann hinzu, wenn ein einzelner Call mit gutem Kontext die Aufgabe wirklich nicht erfüllen kann (Building Effective Agents). Das ist kein Vorbehalt, sondern das Muster, das sich in der Produktion bewährt.

Was wir beim Betrieb unserer eigenen Outreach-Engine gelernt haben

Wir betreiben unser eigenes Cold-Outreach-System: Es crawlt die Website eines Interessenten mit einer selbst gehosteten Firecrawl-Instanz und einem lokalen LLM und schreibt dann eine individuell zugeschnittene E-Mail pro Unternehmen. Unsere erste Version teilte das in Phasen auf – Unternehmensfakten extrahieren, dann zusammenfassen, dann die E-Mail entwerfen, dann ein separater „Polishing"-Durchlauf. Sie war langsamer, kostete mehr Token pro Lead, und der Polishing-Schritt überschrieb regelmäßig Details, die der Extraktionsschritt korrekt erfasst hatte – weil er keine Sicht darauf hatte, warum der Entwurf das sagte, was er sagte.

Wir haben es zu einem einzigen Call zusammengefasst: Fakten extrahieren und die E-Mail in einem Prompt entwerfen, wobei die Extraktionsfelder als strukturierter Output vor dem E-Mail-Body spezifiziert sind. Die Kosten pro Lead sanken, und die Qualität stieg – weil das Modell den vollständigen Kontext hielt: die tatsächlich gecrawlte Seite, keine verlustbehaftete Zusammenfassung davon, und das während des gesamten Schreibvorgangs. Die Lektion lässt sich über Outreach hinaus verallgemeinern: Wenn Ihr „Agent" im Grunde nur Input in Output transformiert, ohne eine Verzweigungsentscheidung in der Mitte, ist die Aufteilung in Schritte reiner Overhead.

Ein einfacher Test, bevor Sie irgendetwas verketten

Fragen Sie sich, ob die Aufgabe einen Entscheidungspunkt enthält, der von Informationen abhängt, die das Modell noch nicht hat. Wenn ja, brauchen Sie wahrscheinlich mindestens einen Loop – das Modell muss handeln, sehen was passiert ist, und dann die nächste Aktion entscheiden. Wenn nein – wenn der Input jedes Schritts vollständig bekannt ist, bevor das Modell läuft – gehört alles in einen einzigen Call mit einem guten Prompt, oder in eine deterministische Code-Pipeline, bei der das LLM einen klar abgegrenzten Teil übernimmt.

Beispiele, die tatsächlich Iteration erfordern:

• Ein Agent, der Code gegen eine fehlschlagende Test Suite debuggt (er muss den Test ausführen, um zu wissen, was als Nächstes zu beheben ist)
• Ein Agent, der eine Website navigiert, bei der der nächste Klick davon abhängt, was auf der aktuellen Seite steht
• Ein Support-Agent, der eine Rückfrage stellen muss, bevor er handeln kann

Beispiele, die das nicht brauchen – egal wie „agentisch" sie sich im Pitch Deck anfühlen:

• Ein Dokument zusammenfassen und strukturierte Felder extrahieren
• Ein Support-Ticket klassifizieren und weiterleiten
• Eine E-Mail, ein Spec oder ein Status-Update auf Basis bekannter Inputs entwerfen

Die übergeordnete Version dieser Entscheidung – wann eine Aufgabe ein Workflow ist versus ein echter Agent – behandeln wir in unserem Vergleich von Agents und Workflows. Wenn Sie zwischen einer Eigenentwicklung und dem Kauf einer Plattform abwägen, deckt Custom Agent vs. Chatbot-Plattform diese angrenzende Frage ab.

Die Kostenkalkulation, die Gründer wirklich interessiert

Chains kosten mehr auf drei Arten, die sich gegenseitig verstärken – unsere eigene Outreach-Pipeline hat alle drei bezahlt, bevor wir sie zusammengefasst haben:

1. Token-Kosten. Jeder Call sendet Kontext erneut (System Prompt, vorherige Outputs), den ein einzelner Call nur einmal bezahlen würde. Unsere vierstufige Version hat bei jedem Hop die Zusammenfassung der gecrawlten Seite erneut gesendet; die Single-Call-Version bezahlt die vollständige Seite einmal.
2. Retry-Kosten. Wenn ein Schritt in der Chain fehlschlägt oder einen fehlerhaften Output zurückgibt, wiederholen Sie entweder diesen Schritt (was Latenz hinzufügt) oder die gesamte Chain (was Kosten hinzufügt). Als unser „Polishing"-Schritt etwas Fehlerhaftes zurückgab, bestand die Lösung darin, ihn erneut auszuführen – aber zu diesem Zeitpunkt waren die Extraktions- und Entwurfsschritte bereits gelaufen und bezahlt worden. Ein einzelner Call schlägt einmal fehl, nicht viermal.
3. Engineering-Kosten. Unsere vierstufige Version benötigte Orchestrierungscode und State-Passing zwischen Extraktion, Zusammenfassung, Entwurf und Polishing – Code, der vollständig verschwand, sobald wir alles in einen Prompt mit strukturiertem Output zusammengefasst hatten. Das ist laufender Wartungsaufwand, nicht nur Build-Kosten.

Wenn Sie schätzen, was ein KI-Feature bei Volumen kosten wird, modellieren Sie beide Architekturen gegen echte Beispiel-Inputs, bevor Sie sich festlegen – lesen Sie dazu unseren Leitfaden zur LLM-Kostenoptimierung. Wir haben auch über die Due-Diligence-Frage geschrieben, die auftaucht, sobald ein Anbieter Ihnen ein Multi-Agent-System pitcht: Fordern Sie ihn auf, jeden Hop zu begründen – so wie wir es in Evals in KI-Vendor-Verträgen beschreiben.

Strukturierter Output erledigt das meiste, was „Planungsschritte" versprechen

Vieles, wofür mehrstufige Chains eingesetzt werden – das extrahieren, dann das formatieren, dann das validieren – lässt sich besser mit strukturiertem Output lösen: einem JSON Schema oder einer Function-Calling-Spezifikation, die das Modell in einem einzigen Durchlauf ausfüllt. Moderne Modelle liefern zuverlässig wohlgeformte strukturierte Daten, wenn Sie das Schema klar spezifizieren – was den Hauptgrund entfernt, aus dem Teams überhaupt nach einem „Validierungsschritt" greifen. Fügen Sie stattdessen eine deterministische Prüfung auf Code-Ebene nach dem einzelnen Call hinzu (lässt sich dieses Feld parsen, liegt dieser Wert im erwarteten Bereich), anstatt einen zweiten LLM Call einzusetzen, um die Arbeit des ersten zu überprüfen.

Unser Fazit

Beginnen Sie mit einem Call. Geben Sie ihm den vollständigen Kontext, den er braucht, fordern Sie strukturierten Output an, und validieren Sie deterministisch. Greifen Sie zu einer Chain – oder einem echten Agent-Loop mit Tool Use – nur dann, wenn die Aufgabe einen tatsächlichen Entscheidungspunkt hat, der von etwas abhängt, das das Modell erst durch Handeln erfahren kann. Das ist eine kleinere Kategorie, als die meisten Agent-Demos suggerieren – und es ist der Unterschied zwischen einem KI-Feature, das günstig und zuverlässig läuft, und einem, das still Budget verbrennt, während es seinen eigenen Output erneut liest.

Wenn Sie ein KI-Feature konzipieren und nicht sicher sind, auf welche Seite dieser Linie es fällt, sprechen Sie uns an.