Skip to main content
ai-automationmulti-agentorchestrators

Subagenten ohne Modellauswahl verbrennen das Budget

Das Problem ist einfach: Wenn ein Subagent das schwere Modell des Orchestrators erbt und kein eigenes wählen kann, explodieren die Kosten. Für die KI-Automatisierung ist das kritisch, weil es die Pipeline-Ökonomie bricht und die flexible Balance von Qualität, Geschwindigkeit und Preis verhindert. Eine versteckte Token-Verschwendung, die ohne Analyse des Call-Graphen schwer zu erkennen ist.

Technischer Kontext

Ich konzentriere mich hier nicht auf die Debatte selbst, sondern auf eine Lücke in der Architektur: Der Orchestrator erzeugt einen Subagenten, und dieser schleppt das Elternmodell ohne nativen Umschalter mit. Für die KI-Automatisierung ist das eine schlechte Sache, denn selbst ein einfaches Tool läuft plötzlich auf einem teuren Modell, wo eine Mini-Klasse ausreichen würde.

An dieser Stelle bremse ich normalerweise das Projekt und tauche in die Mechanik ein. Wenn ein Tool keine Modellauswahlparameter hat, wird keine noch so schöne Prompt-Anweisung zu echtem Routing. Ein Agent kann „wissen“, dass er sparen sollte, aber technisch gibt es nichts auszuwählen.

Aus der Diskussion geht hervor, dass das Problem nicht die Modellqualität an sich ist, sondern das Fehlen einer Konfigurationsverwaltungsschicht beim Spawnen von Subagenten. Das ist ein wichtiger Unterschied. Wenn die Modellauswahl nur auf Elternebene existiert, wird das Kind zu einer teuren Kopie und nicht zu einem spezialisierten Ausführenden.

Solche Dinge teste ich normalerweise sehr pragmatisch: Ich nehme ein und dasselbe Szenario, in dem der Orchestrator entscheidet, ob Recherche, Zusammenfassung oder Formatierung benötigt wird, und schaue, welche Aufrufe tatsächlich an die API gehen. Wenn jeder Kind-Schritt zum Heavy-Modell geht, verbrennen die Token nicht, weil die Aufgabe komplex ist, sondern weil die KI-Integration ohne ordentliches Routing erfolgt ist.

Die Suche in offenen Materialien hilft hier ehrlich gesagt wenig: In den allgemeinen Übersichten zu LangChain, AutoGen und CrewAI wird viel über Flexibilität gesprochen, aber eine richtige Antwort darauf, wie man diese Vererbung in echter Produktion vermeidet, findet man kaum. Man muss also nicht auf das Marketing des Frameworks schauen, sondern auf den konkreten Agenteninitialisierungscode, die Node-Level-Modellbindung und die Subagentenfabriken.

Was sich für Unternehmen und Automatisierung ändert

Der erste Schlag ist offensichtlich: das Budget. Wenn Support, Recherche und Validierung alle über ein einziges schweres Modell laufen, steigen die Pipeline-Kosten ohne Nutzen.

Der zweite Schlag ist leiser, aber schmerzhafter: Sie verlieren die Vorhersagbarkeit. Man kann die Unit Economics nicht richtig berechnen, wenn Subagenten nicht zwischen günstigem und starkem Modus je nach Aufgabe wechseln können.

Gewinnen werden diejenigen, die KI-Lösungen für Unternehmen mit expliziter Modellkontrolle an jedem Knoten bauen. Verlieren werden Teams, die darauf vertrauen, dass der Orchestrator es „irgendwie schon verstehen“ und die Kosten ohne Parameter optimieren wird.

Wir bei Nahornyi AI Lab räumen genau diese Engpässe auf: Wir zerlegen die Orchestrierung nach Rollen, setzen explizites Modellrouting ein und entfernen versteckte Tokenfresser. Wenn Ihre KI-Implementierung bereits läuft, aber die Rechnungen schneller steigen als der Nutzen, lassen Sie uns den Aufrufgraph ansehen und eine KI-Automatisierung so aufbauen, dass das System dort nachdenkt, wo es nötig ist, und nicht bei jedem Niesen.

Wir haben uns zuvor mit der Verwendung paralleler Claude Code-Agenten befasst, um Race Conditions in Pull Requests zu erkennen – ein Ansatz, der die Orchestrierung mehrerer Agenten umfasst. Die Technik von Sol Ultra, Subagenten ohne Modellparameter zu spawnen, führt dieses Konzept in eine andere Richtung und wirft neue Fragen zur Zuverlässigkeit der Orchestrierung auf.

Diesen Artikel teilen