Entscheidungs-LLMs: Wann ein Modell entscheiden sollte – und wann es nicht sollte

Fragt Praktiker, was in Agentensystemen kaputtgeht, und die Antwort ist selten die Leistungsfähigkeit. Das Versagen ist stiller: Das Modell trifft eine Entscheidung, und niemand kann verlässliches von bloß flüssigem unterscheiden.

Die Ausgabe eines Modells ist eine Stichprobe. Eine Entscheidung hingegen besitzt Eigenschaften, die eine Stichprobe nicht hat – Determinismus für einen festen Eingabewert, Invarianten, die sie erfüllen muss, und eine Prüfungsroute, die erklärt, warum diese und nicht die alternative Option gewählt wurde. Wenn diese Eigenschaften fehlen, ist die „Entscheidung“ nur eine Vermutung mit hoher Gewissheit, die den Mantel einer solchen trägt.

Dieser Artikel behandelt diese Lücke mechanisch: eine Taxonomie von fünf Entscheidungsfunktionen, eine Regel zur Zuteilung jeder Entscheidung an das kleinste dafür kompetente Modell und den Verifikationsmechanismus, der aus „Der Agent hat X entschieden“ etwas macht, das man später als sound beweisen kann. Er schließt mit einem Kriterienkatalog ab, den man gegen jede Aktion im eigenen System durchlaufen lassen kann.

„Bei lokalen Agenten ist die Lücke, auf die ich immer wieder stoße, nicht die Leistungsfähigkeit, sondern die Verifikation. Der Agent sagt, er habe eine Datei gelesen, ein Tool aufgerufen oder eine Entscheidung getroffen…“ — r/LocalLLaMA, „Beste lokale Agenten — Juni 2026“

„Wenn ein LLM-Agent fehlschlägt, ist es eine Blackbox und niemand weiß warum. Die eigentliche Flaschenhals für die Akzeptanz ist nicht, ein Modell von 92 % auf 96 % Genauigkeit zu bringen — [es ist zu wissen, warum es X entschieden hat].“ — r/AI_Agents, „Die Lücke zwischen Entscheidung und Ausführung“

Die Community hat sich auf drei Instinkte geeinigt: Das Modell nicht mit dem endgültigen Urteil beauftragen, die Entscheidung an das kleinste kompetente Modell routen und die Entscheidung erklärbar machen. Was fehlte, war das Framework, das alle drei gleichzeitig handhabbar macht.

Warum „es antwortet, aber entscheidet es?“

Eine Modell-Ausgabe ist eine Token-Verteilung, die zu einer einzigen Sequenz kollabiert ist, und derselbe Prompt, zweimal ausgeführt, kann zwei Sequenzen erzeugen, die genau bei dem entscheidenden Token divergieren. Eine Entscheidung hingegen ist für eine feste Eingabe deterministisch, erfüllt explizite Invarianten und hinterlässt eine Prüfungsroute, die aufzeichnet, welcher Zweig genommen wurde und warum.

Wenn ein Modell ohne Mechanik darum herum „entscheidet“, existieren keine dieser Eigenschaften. Es gibt keine Invariante, die die Ausgabe einhalten muss, keine Log des genommenen Zweigs, keine Möglichkeit, die Entscheidung zu reproduzieren und zu überprüfen, ob sie gehalten hat. Die Lücke ist nicht die Intelligenz – es ist, dass eine probabilistische Ausgabe in einen Slot gelegt wurde, der für eine deterministische ausgelegt ist.

Der Instinkt der Praktiker ist, das Modell ganz aus der Entscheidung herauszuhalten:

„Das LLM trifft nie endgültige Entscheidungen im System. Seine Rolle ist rein: Logik-Verfeinerung, Stresstesting, Szenario-Generierung, Erklärung.“ — r/AI_Agents, „Ein LLM als ‚reasoning agent‘ zur Validierung von Preisen verwenden…“

Das ist die richtige Haltung, als Maxime formuliert. Um sie anzuwenden, braucht man eine Art zu klassifizieren, welche Rolle das Modell für eine gegebene Aktion einnehmen sollte – das liefert die Taxonomie unten.

Fünf Entscheidungsfunktionen

Jede Entscheidung, die ein System trifft, kann einer von fünf Funktionen zugeordnet werden. Die Funktion bestimmt, wie sehr man dem Modell-Ausgabe vertrauen kann, wie sie auditert wird, wie sie fehlschlägt und ob ein Mensch in den Schleife gehört.

Lesen Sie die Tabelle als Einschränkung, nicht als Speisekarte. Die meisten kaputten Systeme teilen einen Defekt: Ein einzelnes Modell füllt alle fünf Funktionen gleichzeitig aus, so dass eine Funktion, die Determinismus verlangt (Entscheider), von einer Komponente bedient wird, die für Flüssigkeit optimiert ist (Generator). Wenn das Modell als Generator agiert, wird keine der Entscheidungsmaschinerie benötigt – nur Inhaltsprüfung. Zu vermeidender Fehler ist, diese zu verwechseln: „Der Agent hat entschieden, die Umgebung zu löschen“ ist normalerweise ein fehlendes Freigabegate, kein Qualitätsproblem der Entscheidung.

Die Entscheidung an das kleinste kompetente Modell routen

Sobald die Funktion festgelegt ist, lautet die Routing-Frage, welche Modellebene sie bedient. Praktiker berichten den Nutzen direkt:

„Model Routing: Haiku für Klassifizierungs-/Routing-Entscheidungen, Sonnet für Ausführung, Opus nur für Design/Planung. Die Kosten sanken um etwa 60 %, als ich aufhörte, Opus für alles zu verwenden.“ — r/AI_Agents, „Was ist Ihr kompletter AI-Agent-Stack in 2026“

Diese Zahl kommt daher, dass die Modellauswahl als eine pro-Funktions-Entscheidung und nicht als eine pro-System-Entscheidung behandelt wird. Ein Routing-Aufruf – „Ist das eine E-Mail-Triage oder eine Rückerstattungsfreigabe?“ – ist eine Klassifizierung, und Klassifizierung braucht kein Frontier-Modell; es braucht ein kleines, schnelles, niedrig-temperaturiertes Modell, weil es tausendfach ausgeführt wird. Die Ebenenmechanik – leistungsbasierte, kostenbewusste und latenzbewusste Auswahl, plus Fallback-Ketten – wird in Model Routing: Hör auf, ein Modell für alles zu verwenden behandelt; die Orchestrierungsmuster um mehrere Modelle herum finden sich in Multi-Model System Design.

Der Zusatz, den der Entscheidungsrahmen beiträgt, ist die konfidenzbasierte Eskalation, die „kleinstes kompetentes“ messbar macht, statt es anzunehmen. Beginne auf der kleinsten Ebene. Wenn das Modell eine kalibrierte Konfidenz – oder eine strukturierte Selbsteinschätzung – ausstößt und diese eine Schwelle überschreitet, stoppe. Wenn nicht, eskaliere eine Ebene und protokollisiere die Eskalation. Kompetenz ist dann eine pro Aufruf verifizierte Eigenschaft, nicht eine pro Modell angenommene.

Eine Einschränkung bleibt absolut, unabhängig von der Ebene: Die Router-Funktion selbst darf kein freier Sprachmodell-Aufruf sein. Ein deterministisches Rückgrat – Regeln zu Aufgabentyp, Payload-Größe, Kostenbudget – wählt den Zweig, und das Modell füllt nur die Blatt-Entscheidungen innerhalb davon. Das Rückgrat ist prüfbar und einheiten-testbar; das Modell ist auf das beschränkt, was es wirklich gut kann.

Die Entscheidung überprüfbar machen

Hier schließt sich die Lücke, dass „der Agent sagt, er habe X gemacht“. Die Lösung ist, die Entscheidung zu einem erstklassigen, strukturierten Artefakt und nicht zu einem Nebeneffekt einer Chat-Runde zu machen:

1. Ein strukturierter Entscheidungsspeicher. Jede Entscheidung, die das Modell treffen darf, wird in eine Tabelle geschrieben, nicht in eine Log-Zeile: die Eingabe, die Funktion, das Modell und die Ebene, die Konfidenz, die betrachteten Alternativen, der Zeitstempel. Eine Entscheidung ist etwas, das man später mit SELECT abfragen kann. Wenn sie nur in einem Gesprächstranskript existiert, ist sie eine Vermutung.
2. Ein Entscheidungs-Log, getrennt vom Ausführungs-Log. Das Ausführungs-Log sagt, was geschah; das Entscheidungs-Log sagt, was entschieden wurde und auf welcher Grundlage. Die Trennung ist wichtig, weil das Versagen normalerweise in der Entscheidung liegt, nicht in der Ausführung – der Agent führte die Löschung perfekt aus; der Fehler war die Entscheidung zur Löschung. Die Mechanik der strukturierten, nur-anfügbaren Protokollierung ist dieselbe, die für Compliance-Prüfungen in LLM Guardrails in Practice verwendet wird.
3. Invarianten und Assertions. Für Entscheider- und Evaluierer-Funktionen muss die Entscheidung Invarianten erfüllen, die nach dem Modell-Ausstoß in deterministischem Code geprüft werden. Ein Preisempfehler kann alles ausstoßen; die Invariante „empfohlener Preis muss innerhalb von [Untergrenze, Obergrenze] liegen“ wird durch Code erzwungen. Das Modell schlägt vor; die Invariante entscheidet.
4. Menschliche Freigabegates an der Irreversibilitätsgrenze. Das Gate ist eine Eigenschaft der Wirkungsbreite der Aktion, nicht der Modellkonfidenz. Eine Rückerstattung unter einer Schwelle ist automatisch freigabefähig; eine darüber ist es nicht. Ein Modell mit 99 % Konfidenz kann eine irreversible Aktion ohne Prüfungsprotokoll dennoch nicht freigeben.

Der rote Faden: Der Drang von 92 % auf 96 % Genauigkeit ist nicht die Flaschenhals – Erklärbarkeit ist es. Ein System mit 92 %, bei dem jede Entscheidung protokolliert, invariantengeprüft und an der Grenze geatet wird, ist sicher, weil die 8 % falscher Entscheidungen auffindbar sind, bevor sie Schaden anrichten. Ein System mit 99 % mit einem Blackbox-Entscheidungsprozess ist es nicht, weil die 1 % ein Live-Vorfall ohne forensisches Protokoll ist. Wo das Gate selbst in einem Assistenten lebt – welche Komponente die Freigabegewalt hält und wie Anfragen es erreichen – ist in KI-Assistenten-Architektur: LLM, Speicher, Tools, Routing, Beobachtbarkeit dargelegt.

Durchgerechnete Beispiele

Drei Systeme, je eine Funktionszuordnung.

Preisvalidierung – das Modell als Empfehler, nie als Entscheider. Ein Agent prüft eine Lieferantenpreisänderung und erzeugt eine gerankte Liste: akzeptieren, bei X verhandeln, ablehnen. Das endgültige Urteil ist ein Entscheider-Slot, gefüllt durch deterministische Regeln: unterhalb der Kostenuntergrenze, automatisch akzeptieren; oberhalb der Obergrenze, an einen Menschen routen; dazwischen, die Invariante anwenden „verhandelter Preis muss den letzten akzeptierten um Y % schlagen.“ Das Modell genehmigt nie seine eigene Empfehlung, und die Empfehlung sitzt im Entscheidungsspeicher mit ihrem Rubriksverlauf, falls etwas schiefgeht.

Agenten-Aufgaben-Routing – das Rückgrat als Entscheider, das Modell an den Blättern. Eine eingehende Anfrage (E-Mail, Ticket, Befehl) wird nach Payload-Form und Intent-Kategorie einen Pfad zugewiesen – deterministisch, einheiten-testbar. Ein kleines Modell füllt nur die Blatt-Entscheidung innerhalb des Zweigs. Ein Falschrouting ist ein Wirkungsbreiten-Ereignis, weshalb die Zweigwahl deterministisch sein muss.

LLM-as-Judge – das Modell als Evaluierer, die Rubrik als Einschränkung. Ein Modell bewertet die Ausgabe eines anderen gegen eine versionierte Rubrik, und der Score plus der Rubriksverlauf werden gespeichert, nicht nur die Zahl. Der bekannte Fehlerschlag ist der Selbsteinsschätzungs-Bias – ein Modell bewertet den eigenen Generierungsstil höher – und die Abmilderung ist strukturell: die Rubrik so versionieren, dass ein Modell nie stillschweigend gegen Kriterien bewertet, die es selbst geformt hat.

Die ehrliche Grenze

Es gibt eine Klasse von Entscheidungen, die ein LLM nicht treffen darf, und es ist keine Frage der Skalierung: Aktionen, die irreversibel, von hoher Bedeutung und ohne Fallback sind – Datenlöschung, Geldbewegung, externe Verpflichtungen. Verifikation ist unmöglich für eine Aktion, die man nicht rückgängig machen kann, weshalb „autonomer Agent“ immer an derselben Wand scheitert, unabhängig von der Modellqualität.

Der Mensch in der Schleife, der keine Farce ist, sitzt genau an dieser Grenze und nirgendwo sonst. Ein Mensch, der jede niedrig bedeutsame Entscheidung prüft, fügt Reibung hinzu und keine Sicherheit; ein Mensch, der von jeder hoch bedeutsamen Entscheidung abwesend ist, ist der Vorfall. Dasselbe Prinzip erscheint in engerer Form im Agentenspeicher: sich selbst verstärkende Speicher-Schleifen setzen künftige Speicher-Schreibvorgänge hinter eine explizite menschliche Freigabe, bevor sie einen dauerhaften Zustand erreichen – das Gate wird an das angepasst, was der Schreibvorgang brechen kann. Für Multi-Agenten-Systeme lautet die entsprechende Frage, wer im Namen wessen handeln darf, und die Mechanik für Identität, Delegation und Prüfungsroute dazu findet sich in A2A und MCP Agent Security.

Das Entscheidungs-Kriterienkatalog

Diesen gegen jede Aktion im eigenen System durchlaufen lassen:

1. Die Funktion klassifizieren. Entscheider, Empfehler, Evaluierer, Generator oder Router? Eine nicht benannte Funktion ist ein Bug – ein Modell in einem Entscheider-Slot, das die Konfidenz eines Generators trägt.
2. Die Ebene für diese Funktion wählen. Kleinstes kompetentes, mit konfidenzbasierter Eskalation, damit Kompetenz pro Aufruf gemessen wird.
3. Die Verifikation definieren. Welche Invarianten müssen gehalten werden? Was kommt in den Entscheidungsspeicher? Was ist der Prüfungsverlauf? Eine Funktion ohne Verifikationsweg ist per Default ein Entscheider.
4. Das menschliche Gate aus der Wirkungsbreite setzen, nicht aus der Konfidenz. Irreversibel oder hohe Bedeutung → geatet. Sonst → automatisch, mit der Entscheidung protokolliert, damit sie auffindbar ist.

Dasselbe Prinzip, angewendet auf Engineering-Entscheidungen statt Laufzeit-Aktionen, ist es, was Entscheidungsprotokolle tun – Entscheidungsprotokolle für KI-gesteuerte Entwicklung erfasst, warum eine Wahl getroffen wurde, damit sie später geprüft werden kann; der obige Kriterienkatalog tut dasselbe für die Entscheidungen, die ein laufendes System trifft.

Was kommt: der Entscheider als Produkt

Das Framework sagt seine eigene Kommoditisierung voraus: Sobald „die Entscheidung an das kleinste kompetente Modell routen“ zu einem Muster wurde, war der nächste Schritt eine Modellklasse, die nichts anderes tut als entscheiden. Dieser Schritt ist nun eingetroffen.

Im Laufe des Oktobers 2026 veröffentlichten mehrere Anbieter Modelle, die auf einem gemeinsamen Rezept basieren – ein eingefrorener Qwen-Kern, ein LoRA-Adapter mit Rang 256 und ein gemeinsamer Schema-Kopf – die typisierte Entscheidungen in einem einzigen Vorwärtspass ausstoßen: eine Wahl aus einer enumerierten Menge, ein Ja/Nein oder ein Score, mit kalibrierter Wahrscheinlichkeit und ohne Freitext. Es gibt keine Kette des Nachdenkens, auf die man warten muss, weil es keine Generierung gibt. Von den Anbietern berichtete Latenz liegt im Bereich von etwa 8 bis 210 ms über die gesamte Klasse hinweg – von der kleinsten Variante (d1-3B, etwa 8 ms) bis zur größten (d3, etwa 209 ms) – und die Fußabdrücke sind im Bereich kleiner GPUs: d1-3B bei etwa 1,67 GB, d3-flash bei etwa 6,6 GB bei Q4_K_M. Auch die Unterstützung bewegte sich schnell: llama.cpp fusionierte native Architekturstütze für mehrere dieser Modelle innerhalb von etwa zwei Wochen nach der Veröffentlichung.

Zwei Konsequenzen für das obige Framework. Erstens erhält die Routing-Regel eine hardwareseitige Ausprägung, die sie vorher nicht hatte: Die Entscheider-Funktion kann von einem dedizierten kleinen Modell statt von einem Prompt-Modus eines allgemeinen bedient werden, was die Entscheidung der kleinsten kompetenten Ebene teilweise automatisch macht – die Ebene existiert entweder für den eigenen Entscheidungstyp oder nicht. Zweitens ändert sich nichts an der Verifikation. Eine typisierte Entscheidung in 8 ms braucht immer noch den Entscheidungsspeicher, die Invarianten und das Gate an der Irreversibilitätsgrenze; was die Modellklasse entfernt, sind Generierungskosten und Nicht-Determinismus, nicht die Prüfungs-Last. Schnellere Entscheidungen vermehren die Anzahl der zu prüfenden Entscheidungsprotokolle – die Flaschenhals war nie die Geschwindigkeit des Modells, und auch nicht die Intelligenz des Modells.

Die anderen Richtungen, die man im Auge behalten sollte, sind stiller. Die Zuverlässigkeit des Tool-Callings für kleine Modelle nähert sich der Sättigung an – Post-Training im Tool-Einsatz ist der günstigste Schritt mit hoher Wirkung im Stack, was die Aufmerksamkeit auf die Zeilen oben verlagert. Zuverlässige Planungshorizonte erweitern sich kontinuierlich, was die Entscheider-Funktion für längere Aufgaben erreichbar macht und die Verifikationslast mit dem Horizont wachsen lässt. Beide füttern denselben Schluss: die knappe Ressource in Agentensystemen sind Entscheidungen, die man später beweisen kann, sound gewesen zu sein, und alles andere holt auf.