Eskaliere Knoten, nicht Aufgaben: Eine sechsstufige Leiter für die Kosten im LLM-Arbeitsablauf

Viele Teams, die Pipelines mit LLMs entwickeln, beginnen bei jeder neuen Funktion mit einer einzigen architektonischen Frage: Soll dies als feste DAG oder als autonomer Agent ausgeführt werden? Das klingt nach einer sinnvollen Designprüfung, doch die Beantwortung auf Ebene der gesamten Aufgabe festlegt stillschweigend die Kosten des unsichersten Schritts für alle anderen Schritte. Dieser Artikel erläutert, wie das geschieht, und stellt anschließend eine sechsstufige Eskalationsleiter vor, bei der jeder Knoten auf dem günstigsten machbaren Niveau beginnt und nur dann weiter steigt, wenn ein expliziter Vertrag fehlschlägt. Am Ende sollten Sie in der Lage sein, Ihre eigenen „Agenten“-Aufgaben zu zerlegen, zu erkennen, wie viel davon tatsächlich deterministisch ist, und strenge Grenzen für die Ausgaben der übrigen Schritte festzulegen.

Im gesamten Szenario wird ein Produkt verwendet, das zwei Funktionen erfüllt: Es konvertiert alltägliche Dateiformate und führt Workflows mit Eingangs- und Ausgangsdateien durch – sowohl als One-Click-Pipelines als auch über ein Tool, das auf der Grundlage einer in Alltagssprache verfassten Anfrage einen Pipeline erstellt. Der Konvertierungsanteil funktioniert zuverlässig. Bei den Workflows tauchte ständig die Frage auf, ob eine DAG oder ein Agent verwendet werden sollte, und es dauerte fast ein Jahr, bis klar wurde, dass die Frage an sich das Problem darstellte.

Der Ausgangspunkt: Jede Aufgabe im Voraus klassifizieren

Der anfängliche Prozess für jeden One-Click-Workflow war methodisch strukturiert. Zunächst wurde der Anwendungsfall untersucht, eine Spezifikation verfasst, und anschließend entschied eine Person, ob die Pipeline als DAG oder als Agent implementiert werden sollte.

Aufgaben mit offenen Enden kamen an einen Agent

Als wirklich offene Aufgaben eingestufte Aufgaben wurden als einzelner ReAct-Agent auf LangGraph umgesetzt. Der Referenzfall war die Stellensuche anhand eines Lebenslaufs. Ein Benutzer lädt einen CV hoch, und das System muss passende Stellen finden sowie für jede davon einen individuell angepassten Lebenslauf erstellen. Dazu gehören Lebensläufe in mehreren Sprachen, die Abgleich von Kandidaten mit Stellen anhand von Aspekten, die durch Schlüsselwortsuche nicht erfasst werden können (Reisezeit von zu Hause, Zusammensetzung des Teams, tägliche Aufgaben des Jobs, Gehaltsbereich), sowie schließlich die Erstellung eines maßgeschneiderten Dokuments. Niemand kann im Voraus sagen, wie viele Schritte dafür benötigt werden, wodurch es sich um den klassischen Fall für einen Agenten handelte.

Vorhersehbare Aufgaben kamen zu einem statischen DAG

Die sequenzielle, vorhersehbare Arbeitsabläufe bildeten ein festes Diagramm. Der Referenzfall bestand darin, ein Video in Untertitel umzuwandeln: den Audiotrack extrahieren, Spracherkennung durchführen, die Transkription in zeitlich abgeteilte Segmente aufteilen und die Untertiteldatei erstellen. Selbst die optionalen Schritte konnten im Voraus aufgelistet werden, wie beispielsweise die Aufbereitung der wortgetreuen Transkription zur besseren Lesbarkeit oder die Überprüfung, ob die in der Präsentation gemachten Aussagen zutreffen. Da jede Entscheidung bereits vor Beginn der Ausführung getroffen werden kann, lässt sich das gesamte Diagramm bereits vor dem Start erstellen.

Die Gliederung schien prinzipiell fundiert zu sein, und das Projekt wurde umgesetzt. Das Problem war jedoch, dass die Kosten nie sanken.

Warum die „Agentensteuer“ niemals verschwindet

Der Mechanismus hinter der flachen Kostenkurve ist banal – genau deshalb wird er leicht übersehen.

Wenn eine Aufgabe mit „Agent“ markiert ist, wird jeder Schritt darin innerhalb der Agentenschleife ausgeführt und kostet entsprechend. Eine ReAct-Schleife kann nur dann eine Aktion wählen, wenn die Schemata ihrer Tools im Kontextfenster vorhanden sind. Man kann das Gespräch komprimieren, den Zwischenzustand zusammenfassen und die abgerufenen Dokumente kürzen – das Team hat all diese Maßnahmen ergriffen – doch die minimale Kosten pro Turn bleibt unverändert, denn diese Mindestkosten entstehen durch die Gruppe der Tool-Schemata, die bei jedem Turn erneut übermittelt wird. Ebenso kann man dem Agenten nicht einfach weniger Tools geben, wenn man möchte, dass er flexibel bleibt: Der Grund, warum es sich ursprünglich um einen Agenten handelt, ist, dass niemand im Voraus weiß, welche Tools bei einem bestimmten Durchlauf benötigt werden.

Eine Lösungsmöglichkeit besteht darin, für jede Aufgabe den relevanten Teilmenge an Werkzeugen vorherzusagen. Das ist eine legitime Forschungsrichtung, erfordert jedoch eigene Investitionen sowie ein Modell, das zuverlässig vorhersagen kann. Stattdessen suchte das Team nach etwas, das konkret festgelegt werden konnte: einer Architektur, deren Kosten durch ihre Konstruktion begrenzt sind und nicht durch die Genauigkeit eines Vorhersagemodells. Falls Sie sich für den Weg der Vorhersage interessieren, wird die schrittweise Werkzeugentdeckung für skalierbare KI-Agenten dieses Thema ausführlich behandelt.

Das erneute Durchlesen der Literatur zusammen mit Monaten an Produktionsprotokollen führte zu einem nahezu peinlich einfachen Schluss:

Die Unsicherheit betrifft die einzelnen Knoten, nicht ganze Aufgaben.

Die Entscheidung zwischen DAG oder Agent wurde pro Aufgabe getroffen. Doch eine Aufgabe ist lediglich eine Sammlung von Schritten, und in fast jeder als „Agent“ klassifizierten Aufgabe waren die meisten Schritte völlig deterministisch. Die Entscheidung auf Aufgabenebene bedeutet, dass jeder Knoten den Preis des unsichersten Knotens im Graphen zahlt.

Wenn man den Arbeitsablauf bei der Stellensuche zerlegt, wird das Muster offensichtlich:

• Die Extraktion strukturierter Felder aus einem PDF-Lebenslauf erfordert keinerlei Modelllogik.
• Die Bestimmung der Sprache des Lebenslaufs ist genauso mechanisch.
• Die Suche nach der Wohnadresse sowie die Berechnung der Fahrzeit erfordern nur einen Aufruf eines Tools.
• Die Abfrage nach freien Stellen bedeutet einen Aufruf einer Jobs-API.
• Die Bewertung, wie gut eine bestimmte Stelle zu einem bestimmten Kandidaten passt, erfordert einen Modellaufruf, eine feste Anfrage und keinerlei Tools.

Nur etwas wie „Erfahren, was dieses spezielle Team kürzlich bereitgestellt hat“ weist keine vorhersehbare Anzahl an Schritten auf.

Die letzte Option besteht aus einem einzigen Knoten. Das gesamte Diagramm musste zu dessen Verarbeitung Agentengebühren zahlen.

Die Eskalationsleiter

Die Lösung bestand darin, nicht mehr im Voraus zu entscheiden. Nach der neuen Regel beginnt jeder Workflow auf dem günstigsten Niveau, das überhaupt funktionieren kann, und nur die einzelnen Knoten, die versagen, steigen weiter auf. Es gibt insgesamt sechs Ebenen.

• L0: Nur Toolaufrufe, kein LLM. Wenn eine Anfrage vollständig durch deterministische Operationen erfüllt werden kann, wird kein Modell gestartet. Im Produkt handelt es sich dabei um den bestehenden schnellen Weg, der weiterhin als separate Option bleibt. Die Kosten betragen lediglich die Kosten für die Toolaufrufe.
• L1: Statische DAG aus mechanischen Knoten. Ein echtes Diagramm mit Verzweigungen und Ausbreitungen, wobei jeder Knoten aus gewöhnlichem Code besteht. Auch hier werden keine Modellaufrufe durchgeführt.
• L2: statische DAG mit Einzelausführungs-LLM-Knoten. Die Graphstruktur bleibt unverändert, doch bestimmte Knoten rufen nun ein Modell einmal auf, wobei der Kontext eng begrenzt ist. In der Praxis erhält der Knoten nur seine direkten Eingaben – keine Konversationsgeschichte, keinen globalen Zustand und vor allem keine Tool-Schemata. Auf dieser Ebene verhält sich das Modell wie eine reine Funktion statt wie ein Agent. Die Kosten betragen O(n) Aufrufe, wobei n bereits vor Beginn der Ausführung bekannt ist.
• L3: begrenzte Verfeinerungszyklen. Ein L2-Knoten kann bis zu einem festgelegten Maximum von N Versuchen gegen einen Vertrag erneut versuchen. Der Vertrag – nicht das Modell – entscheidet, wann die Ausgabe akzeptabel ist. Die Kosten betragen O(n·N), was ebenfalls bereits vor der Ausführung bekannt ist.
• L4: Ein undurchsichtiger Knoten wird zu einem Sub-Agenten. Ein Knoten, der nicht im Voraus festgelegt werden kann, erhält einen echten ReAct-Loop, doch seine Werkzeuge sind auf diesen Knoten beschränkt und er verfügt über ein festes Schrittbudget. Niemand kann vorhersagen, was er ausgeben wird – und genau diese Unvorhersehbarkeit ist der Grund, warum ein expliziter Obergrenze erforderlich ist.
• L5: Vollständige Neuplanung. Der Plan selbst war falsch, daher wird das Graph neu aufgebaut. Dies ist der teuerste mögliche Schritt und sollte selten vorkommen.

Verträge, Umfang und Budgets

Eine Taxonomie allein wäre lediglich eine verbesserte Vokabelnliste. Drei Mechanismen sorgen dafür, dass die Struktur tatsächlich funktioniert:

• Verträge lösen eine Eskalation aus. Jeder Knoten gibt die Form eines akzeptablen Ergebnisses an, und nur ein fehlgeschlagener Prüfversuch gegenüber dieser Angabe rechtfertigt einen Aufstieg auf ein höheres Niveau.
• Scope hält L4 erschwinglich. Die Tool-Schemata eines Unter-Agenten befinden sich im Kontext dieses einen Nodes und tauchen sonst nirgends während der Ausführung auf, sodass die damit verbundenen Kosten lokal entstehen.
• Budgets setzen eine Obergrenze fest. Jede Ebene über L2 verfügt über eine maximale Anzahl an Versuchen oder Schritten; danach gibt der Node entweder auf oder eskaliert weiter.

Eine praktische Sichtweise darauf: Der Vertrag beantwortet die Frage „Ist das gut genug?“, der Scope beantwortet „Was kann dieser Node sehen und aufrufen?“, und das Budget beantwortet „Wie viel darf er zum Versuch ausgeben?“. Fehlt eines dieser drei Elemente, wird die entsprechende Ebene unvorhersehbar. Weitere Informationen zur Kontrolle von Schleifen wie L3 und L4 im Code finden Sie unter bounded agentic loops in TypeScript.

Die Subtitelverarbeitungschain Schritt für Schritt durchlaufen

Die meisten Verarbeitungsvorgänge verlassen nie die Ebene L1. Die Pipeline extrahiert das Audio, führt eine Spracherkennung durch, segmentiert den Inhalt nach Zeitstempeln und erstellt eine SRT-Datei – alles ohne Aufruf eines Modells. Anschließend wird das Ergebnis gegen die festgelegten Kriterien überprüft: Die Untertitelzeilen dürfen sich nicht überschneiden, keine Zeile darf die Zeichenzahlbegrenzung überschreiten und die Lesegeschwindigkeit muss unter einem bestimmten Schwellenwert liegen. Ein typisches Video mit klarem Audio besteht diese Prüfung, und die Verarbeitung kostet nicht mehr als ffmpeg plus ein einziger Erkennungsvorgang.

Falls eine bestimmte Untertitelzeile die Regeln zur Zeilenlänge oder Lesbarkeit verletzt, gelangt nur diese Zeile in die Ebene L2. Dort wird ein einzelner Modellaufruf durchgeführt, wobei als Kontext diese Zeile sowie ihre unmittelbaren Nachbarn herangezogen werden. Die vollständige Transkription, die Video-Metadaten sowie alle Tool-Schemata bleiben außerhalb des Anfragenkontexts, und der Rest des Verarbeitungsgraphen bleibt unberührt.

L3 wird durch die Terminologie gerechtfertigt. In einem technischen Vortrag mit Glossar können Terminologiekontrollen nach einer einzigen Korrekturanweisung weiterhin fehlschlagen, wodurch der zugehörige Knoten seine Ausgabe genau zweimal verbessern kann, wobei die Überprüfung mit dem Glossar entscheidet, wann das Ergebnis akzeptabel ist.

L4 tritt nur an einem Ort auf: bei der Überprüfung, ob die in dem Vortrag gemachten Behauptungen korrekt sind. Dafür ist eine Suche erforderlich, und niemand kann sagen, wie viele Suchen nötig sind. Dadurch wird dieser einzelne Knoten zu einem Unteragenten, dessen Werkzeuge auf Suchen und Abrufen beschränkt sind und dessen Schritte begrenzt sind. Der darum herumliegende Untertitel-Verarbeitungspfad bleibt mechanisch.

L5 kümmert sich um den Fall, in dem der Plan von Anfang an falsch war. Angenommen, die Datei ist eigentlich ein Screencast, bei dem die Bedeutung im Text auf dem Bildschirm liegt und der Ton nur sekundär ist. Keine Anzahl an Optimierungen einzelner Knoten kann einen um Spracherkennung aufgebauten Plan retten, weshalb der Graph stattdessen um OCR neu aufgebaut wird.

Schritt für Schritt die Karriereleiter hinauf

Das ist das Beispiel, das die Denkweise des Teams veränderte, weil es offensichtlich wie ein Agent strukturiert war.

L1 umfasst mehr als erwartet: das Parsen des Lebenslaufs, die Erkennung der Sprache, die Geokodierung sowie die Berechnung der Fahrzeit und das Abrufen von Stellenangeboten. All das sind reiner Code.

L2 kümmert sich um die Abgleichung. Für jede potenzielle Stelle erfolgt ein einziger Aufruf des Modells, der eine strukturierte Bewertung entlang der relevanten Dimensionen zurückgibt, wobei die Zusammenfassung des Lebenslaufs sowie die jeweilige Stellenbeschreibung als gesamter Kontext dienen. Das sind O(n) Aufrufe an ein preiswertes Modell ohne jegliche Tool-Schemata, und es ersetzt einen Agenten, der mit dem vollständigen Toolset bei jedem Schritt neu geladen wurde, um über dieselbe Liste nachzudenken.

L3 ist für die Überarbeitung des Lebenslaufs zuständig, wobei Verträge hier von einer Kosteneinschränkung zu einer Sicherheitsmaßnahme werden. Der Vertrag verlangt, dass jede Angabe im überarbeiteten Lebenslauf auf den ursprünglichen zurückverfolgt werden kann, verbietet das Erfinden von Arbeitgebern oder Daten sowie legt eine Längengrenze fest. Wenn ein Entwurf diese Regeln verletzt, wird er höchstens zweimal überarbeitet, danach endet der Prozess. Dies ist ein nützliches Muster jenseits von Kosten: Ein Vertrag, der die Herkunft überprüft, stellt einen kostengünstigen, deterministischen Schutz dagegen dar, dass ein Modell die Karrieregeschichte einer Person verfälscht.

L4 besteht aus einem einzigen Knoten: der Erforschung des Teams des jeweiligen Unternehmens sowie seiner aktuellen Ausrichtung. Er ist von Natur aus offenen Charakters, wird aber durch seine Struktur begrenzt.

L5 tritt ein, wenn die Kategorien selbst nicht passen. Stellen Sie sich einen Physiker vor, der sich auf Stellen in der quantitativen Finanzwelt bewirbt: Die analysierten Jobkategorien passen kaum zum tatsächlichen Hintergrund des Kandidaten, wodurch der Abgleichplan neu erstellt statt nur angepasst werden muss.

Das wichtigste Ergebnis ist, dass eine Aufgabe, die ursprünglich als Agentenarbeit eingestuft wurde, in Wirklichkeit zu etwa 80 Prozent aus L1- und L2-Arbeit besteht. Das betrifft nicht nur die Anpassung einer Anweisung; es verschiebt den gesamten Arbeitsablauf auf eine völlig andere Kostenkurve.

Was das „Ladder“-Produkt für Datei-zu-Datei-Prozesse bietet

Die Workflows für Dateieingang und -ausgang überschneiden sich stark. Die ersten 80 Prozent fast jeder beiden Pipelines sehen nahezu identisch aus. Doch die Qualität, die die Nutzer bemerken, liegt ausschließlich in den verbleibenden 20 Prozent – und dieser Teil unterscheidet sich jedes Mal. Das ist die Anpassungsfalle: Entweder entwickeln Ingenieure die Details für jede Aufgabe manuell, wodurch das Produkt nie skaliert, oder die Details werden übersprungen, was zu mittelmäßigen Ergebnissen führt.

„The Ladder“ ist ein Ausweg aus dieser Falle. Anpassungen finden weiterhin statt, doch sie erfolgen durch Eskalationsentscheidungen auf der Grundlage von Verträgen statt durch Arbeitsstunden der Ingenieure. Das Ergebnis ist eine an jede Aufgabe angepasste Optimierung ohne zusätzliche menschliche Anstrengung pro Aufgabe.

Eine offensichtliche Vergleichsmöglichkeit sind die allgemein einsetzbaren Agenten von Anthropic und OpenAI, die vermutlich strukturell ähnliche Aufgaben erledigen. Diese Systeme sind geschlossen, sodass es sich dabei um Inferenz statt um Wissen handelt. Es ist jedoch plausibel anzunehmen, dass ein großer Teil ihrer Anstrengungen darauf ausgerichtet ist, konsistente Strukturen über verschiedene Aufgaben hinweg zu schaffen, und sie verfügen über weitaus mehr Daten dafür. Ladder erreicht eine vergleichbare Struktur durch die Gestaltung des Arbeitsablaufs und nicht durch riesige Datensätze, wodurch es eine erschwinglichere Variante derselben Idee darstellt.

Wann Ladder nicht sinnvoll ist

Der Ansatz setzt voraus, dass man sinnvolle Verträge erstellen kann. Wenn die Ausgabequalität eines Knotens nur von einem Menschen beurteilt werden kann, gibt es keinen zuverlässigen Auslöser für eine Eskalation, und das System degeneriert zu Spekulationen. Zudem werden Orchestrierungsmechanismen hinzugefügt; bei einem Pipeline-Prozess mit zwei oder drei Schritten und geringem Volumen kann ein einziger gut abgegrenzter Modellaufruf einfacher und kostengünstig genug sein.

Zuerst die unterste Stufe bereitstellen

Wenn jeder Workflow Dateien entgegennimmt und Dateien zurückgibt, befindet sich die Dateiverarbeitungsschicht unter allem anderen. Jede der oben beschriebenen Stufen reduziert sich letztendlich auf etwas Mechanisches: Den Container öffnen, den Text extrahieren, die Tabellen unverändert lassen. In dieser Schicht gibt es nichts Ungewisses, weshalb die Bezahlung für Berechnungen dort reine Verschwendung wäre. Zudem macht ihre Vorhersehbarkeit sie zur offensichtlichen ersten Komponente, die veröffentlicht werden sollte.

Es wurde als Open-Source-Python SDK veröffentlicht, auf PyPI unter der Apache-2.0-Lizenz bereitgestellt und kann als MCP-Server innerhalb von Claude Code verwendet werden. Die Installation erfolgt mit einem einzigen Befehl über uv oder pip.

uv add convilyn          # or: pip install convilyn

Das SDK wandelt Dokumente in Markdown um, konvertiert Bilder zwischen 26 Formaten und ordnet PDF-Seiten neu an – alles lokal, ohne Account und ohne Netzwerkzugang. Wenn eine Aufgabe tatsächlich ein Modell zum Lesen von Inhalten wie einer gescannten Seite, einem Foto oder einer Audiodatei benötigt, wird diese Aufgabe an einen gehosteten Cloud-Dienst weitergeleitet, und ab dort wird die Nutzung berechnet.

Diese Aufteilung stellt die Leiter dar, die als Produktdesign statt als interne Architektur ausgedrückt wird. Der freie lokale Pfad ist L0: Wenn reiner deterministischer Code eine Aufgabe abschließen kann, wird kein Modell geladen, und die Arbeit wechselt erst auf einen bezahlten Pfad, nachdem der günstige Weg eindeutig fehlgeschlagen ist. Laut dem Projekt benötigt der Offline-Converter weder ein Konto noch einen Schlüssel oder eine Quotenbegrenzung und sendet keine Telemetriedaten; prüfen Sie die aktuelle README-Datei des Repositoriums für Installationsdetails sowie den genauen Funktionsumfang, da sich beide wahrscheinlich weiterentwickeln werden.

Aktueller Status des Workflow-Engines

Zum Zeitpunkt der Erstellung wurden die Workflow- und Builder-Funktionen noch weiter stabilisiert, während unter ihnen die hier beschriebene Neukonstruktion abgeschlossen wurde; das Team erwartet, dies in etwa einem Monat zu beenden. Die Begründung ist erwähnenswert: Es ist besser, einen Workflow-Engine zurückzuhalten, von dem bekannt ist, dass er veraltet wird, anstatt ihn voranzutreiben und die Benutzer zweimal migrieren zu müssen.

Bisherige Arbeiten und verwandte Projekte

Niemand der einzelnen Bestandteile ist neu, und jeder wurde bereits zuvor beschrieben. Was offenbar noch nicht veröffentlicht wurde, ist diese spezifische Kombination: Eskalation pro Knoten durch Verträge, der Tool-Bereich als Kostentreiber, rekursive Erweiterung ist erlaubt, aber budgetiert, angewandt auf eine Datei-zu-Datei-Arbeitslast. Die folgenden Arbeiten behandeln die einzelnen Komponenten.

Fangen Sie einfach an und fügen Sie Komplexität nur dann hinzu, wenn es notwendig ist

• Building effective agents, veröffentlicht von Anthropic im Dezember 2024, unterscheidet Arbeitsabläufe von Agenten und empfiehlt die einfachste praktikable Lösung, wobei Komplexität nur dann hinzugefügt wird, wenn sie erforderlich ist. Der „Ladder“-Ansatz weicht dadurch ab, dass er dieses Prinzip während der Ausführung Schritt für Schritt anwendet, anstatt es bereits bei der Planung einmal pro Aufgabe zu berücksichtigen.

Escalieren Sie nur den fehlgeschlagenen Komponenten

• Das ADaPT-Papier, dessen Name für as-needed decomposition and planning steht (Findings of NAACL 2024), beginnt mit einem übergeordneten Plan und zerlegt eine Unteraufgabe rekursiv weiter, nur nachdem deren Ausführung fehlgeschlagen ist – erfolgreiche Teile bleiben unberührt. Es handelt sich um die detaillierteste veröffentlichte Beschreibung des L4-Triggers, obwohl sie nicht im Hinblick auf Kosten formuliert ist.

Verträge, begrenzte Wiederherstellungsmechanismen und Eskalationsregeln

• Ein schematheoretisches Rahmenwerk zur Ausführung von LLM-Agenten als strukturierte Graphen, das im April 2026 auf arXiv veröffentlicht wurde, verwendet einen statischen DAG mit Ausgabeverträgen pro Knoten sowie ein dreistufiges Wiederherstellungsprotokoll aus erneuter Ausführung, lokaler Korrektur und vollständiger Neuplanung, wobei explizite Eskalationsinvarianten vorgesehen sind. Die These lautet, dass Knoten, die auf Modellen basieren, hinsichtlich der Verträge überprüft werden sollten, da Typüberprüfungen allein nicht ausreichen, und dass das Erneuten von nicht-idempotenten Schritten begrenzte Budgets erforderlich sind. Absichtlich wird die rekursive Erweiterung von Untergraphen ausgeschlossen, in der sich L4 befindet.

Task-Decoupled Planning (TDP), das in derselben Veröffentlichung untersucht wurde, teilt die Arbeit in ein Graphen aus Unterzielen auf, wobei jedes Unterziel seinen eigenen eng begrenzten Kontext hat, und beschränkt jede Neuplanung auf das derzeit aktive Unterziel. Es weist eine Reduzierung der benötigten Ressourcen um bis zu 82 % aus, was die bisher genaueste veröffentlichte Messung ist, die das Argument zur Einschränkung auf L2 unterstützt.

Der Umfang der Tools als wichtigster Kostentreiber

• Skillflow definiert eine DAG in YAML, die vom Engine und nicht vom Modell durchlaufen wird. Die Eingabe/Ausgabe wird durch die jeweiligen Fähigkeiten gesteuert: Ein Schritt erhält nur den Kontext, den er anfordert, und jedes Tool, das nicht im Vertragsrahmen enthalten ist, erscheint einfach nicht in seinem Schema. Sein Fazit, dass ein kleiner, rollenspezifischer Kontext ausreicht, damit günstige Modelle funktionieren, stimmt mit dem L2-Argument überein.

In der Produktion bereits eingesetzte schrittweise Ladders

• PraisonAI bietet in seinem Agents SDK eine Escalationsfunktion an, die vier schrittweise Stufen definiert: eine direkte Antwort ohne Tools oder Planung, die Verwendung heuristischer Tools ohne zusätzlichen Modellaufruf, einen eingeschränkten Modellaufruf und schließlich einen vollständig autonomen Prozess mit Tools, Unteragenten und Überprüfung. Das entspricht grob L0 bis L4, komprimiert in vier Schritte.
• Der Escalation-Router von NVIDIA NeMo Switchyard wendet dieselbe Struktur auf die Auswahl des Modells an statt auf die Architektur: Es beginnt mit einem schwächeren Modell und wechselt zu einem stärkeren, wenn ein Bewertungssystem anhaltende Probleme erkennt.

Dieselbe Struktur an anderen Stellen

• Agentic Design Patterns (systemdesign.one, April 2026) verwendet den Begriff „Escalation Ladder“ für die Wahl zwischen Workflow und Agent und empfiehlt, standardmäßig die einfachste Lösung zu wählen, die den Auftrag erledigt.
• Vercels Leitfaden zu AI-Agent-Bewertungsframeworks für die Produktion (Juli 2026) wendet ein Prinzip des günstigsten Erstversuchs bei der Bewertung an: Zunächst wird die kostengünstigste Überprüfung durchgeführt, die in der Lage ist, einen bestimmten Fehler aufzudecken; erst wenn diese Überprüfung strukturell nicht in der Lage ist, das Problem zu erkennen, erfolgt eine Eskalation.

Haupterkenntnisse

• Durch die Entscheidung „DAG oder Agent“ pro Aufgabe wird jede Schritt für den am meisten unsicheren Schritt sinnvoll genutzt.

Kostenintensiv ist bei einem Agenten-Loop der Block mit dem Tool-Schema, der bei jedem Schritt erneut übertragen wird und durch Komprimierung der Historie nicht entfernt werden kann.

Starten Sie jeden Knoten auf dem günstigsten Niveau und steigen Sie nur bei einem fehlgeschlagenen, expliziten Vertrag auf ein höheres Niveau auf.

Begrenzen Sie die Tool-Schemata auf den Knoten, der sie benötigt, und weisen Sie jedem Niveau oberhalb von L2 ein festes Budget zu.

Erwarten Sie, dass die meisten „Agenten“-Arbeitlasten nach der Aufteilung größtenteils deterministisch sind; im Fall der Stellensuche entfielen etwa 80 % auf die Ebenen L1 und L2.

Zusätzliche Literatur

• Designing Multi-Agent Systems on A2A: Nodes, Memory and Governance — Eine Referenzarchitektur für Multi-Agent-Systeme, die auf dem A2A-Protokoll basieren, mit Informationen zu Agentenmodulen, Speichertypen, Orchestrierung, Sicherheitsrisiken sowie einer Checkliste für das Design.
• LangGraph in der Praxis: Zustände, Knoten, Kanten und fünf Agent-Muster — Erfahren Sie, wie man Zustände in LangGraph mithilfe von Annotationen und Reduzern definiert, Knoten mit Kanten verbindet sowie alle fünf grundlegenden Agent-Arbeitsablaufmuster in JavaScript umsetzt.