Der Agent-Stack spaltet sich in zwei Teile

Der teuerste Fehler im Agentendesign ist derzeit, ein und dasselbe Modell für alles zu verwenden. Sie greifen zu einem Frontier-Modell, um zu entscheiden, ob eine API aufgerufen werden soll, und nutzen dann dasselbe Modell, um den JSON-Payload zu formatieren. Eine dieser Aufgaben verlangt nach einem Physiker, die andere nach einem kompetenten Sachbearbeiter. Physiker-Tarife für Büroarbeit zu zahlen, ist nicht nur Verschwendung – es ist schlechtes Engineering. Es koppelt die Intelligenz Ihres Agenten an seine Betriebskosten, und zwar so, dass beides schlechter wird.

Metas Veröffentlichung von Muse Ember macht diese Trennung konkret. Es ist ein kleines Modell, das speziell für das gebaut wurde, womit Agenten die meiste Zeit verbringen: Tool-Aufrufe, Routing und Datenextraktion [1]. Mit 10 Cent pro Million Input-Token unterbietet es Claude Haiku 5.5 und GPT-6 Luna mit großem Abstand [3]. Meta behauptet, bei diesen repetitiven Aufgaben mehr Intelligenz pro Dollar zu liefern, und räumt gleichzeitig freimütig ein, dass es beim eigentlichen Programmieren zurückfällt [1]. Dieses Eingeständnis ist der interessante Teil. Sie verkaufen kein Modell, das alles kann; sie verkaufen ein Modell, das die langweiligen Teile von Agency extrem günstig erledigt.

Die Ausführungsschicht wird zur Ware

In den letzten zwei Jahren war die Standard-Agentenarchitektur monolithisch. Ein Modell – meist ein Frontier-Modell – übernimmt Planung, Reasoning, Tool-Auswahl und die mechanische Arbeit der Ausgabe-Strukturierung. Das ergab Sinn, solange kleinere Modelle nicht zuverlässig gültige Funktionsaufrufe produzieren oder Routing-Anweisungen befolgen konnten. Aber diese Zuverlässigkeitsschwelle ist überschritten. Muse Ember ist nicht das erste kleine Modell, das Tool-Nutzung kompetent beherrscht, aber seine Preisgestaltung und Metas explizite Positionierung als Agenten-Ausführungs-Engine signalisieren, dass diese Schicht jetzt ein Commodity-Markt ist.

Die Implikation für Entwickler: Die Architektur Ihres Agenten hat jetzt eine offensichtliche Nahtstelle. Die Reasoning-Schicht – wo Sie echte Intelligenz brauchen, um Aufgaben zu zerlegen, mit Mehrdeutigkeiten umzugehen oder Code zu schreiben – bleibt bei einem Frontier-Modell. Die Ausführungsschicht – wo Sie schnelle, zuverlässige, strukturierte Ausgaben nach bekannten Mustern brauchen – wandert zu etwas wie Ember. Die beiden Schichten können unterschiedliche Modelle sein, von unterschiedlichen Anbietern, optimiert für unterschiedliche Dinge.

Was das für die Evaluierung bedeutet

Diese Aufspaltung verkompliziert die Evaluierung auf nützliche Weise. Sie können Ihren Agenten nicht länger als einzelne Blackbox benchmarken und es dabei belassen. Ein Agent, der intelligent routet, aber Tool-Aufrufe schlampig formatiert, hat ein anderes Problem als einer, der perfekt formatiert, aber dumm routet. Wenn die Reasoning- und Ausführungsmodelle von verschiedenen Anbietern stammen, brauchen Sie Evals, die jede Schicht isolieren. Das bedeutet Tests für die Einhaltung von Tool-Call-Schemata, Routing-Genauigkeit bei Prompt-Variationen und Extraktionstreue, die unabhängig von Ihren Planungs-Evals laufen.

Es ändert auch, wie Sie über Fallbacks denken. Wenn Ihr Ausführungsmodell günstig genug ist, können Sie es sich leisten, es mehrfach mit verschiedenen Prompts laufen zu lassen und über die Ausgabe abzustimmen – ein Muster, das mit Frontier-Modellen unerschwinglich teuer ist. Zuverlässigkeit durch Redundanz wird zu einer legitimen Strategie, wenn die redundanten Aufrufe Bruchteile eines Cents kosten.

Die Instagram-Lektion

Es gibt ein zweites Signal, das Beachtung verdient, auch wenn es aus einer anderen Richtung kommt. Instagrams Effect Builder generiert jetzt AR-Filter aus KI-Prompts [2]. Das ist keine Agenten-Infrastruktur – es ist ein Consumer-Feature. Aber es illustriert dasselbe Muster von der anderen Seite: KI bewegt sich in Ausführungsrollen, in denen die Ausgabe ein strukturiertes Artefakt ist, keine Konversation. Ein Prompt produziert einen Filter, keine Chat-Nachricht. Das Modell betreibt Tool-Nutzung, nur verpackt in einer benutzerfreundlichen Oberfläche.

Für Agentenentwickler ist das eine Erinnerung daran, dass strukturierte Ausgaben zur Standarderwartung werden und nicht länger eine spezialisierte Fähigkeit sind. Wenn Consumer-Apps Prompt-zu-Artefakt als normales Feature behandeln, ist die Fähigkeit Ihres Agenten, auf Anhieb gültiges JSON zu produzieren, nicht mehr beeindruckend, sondern Grundvoraussetzung. Die Differenzierung wandert flussaufwärts, zum Reasoning, das entscheidet, welches JSON produziert werden soll und warum.

Die praktische Schlussfolgerung ist einfach. Schauen Sie sich den Token-Verbrauch Ihres Agenten an und trennen Sie ihn in Reasoning-Arbeit und Ausführungsarbeit. Wenn mehr als die Hälfte Ihrer Ausgaben auf strukturierte Ausgabengenerierung, Routing-Entscheidungen oder Schema-Einhaltung entfällt, haben Sie eine Nahtstelle, an die ein Modell wie Muse Ember gehört. Der Kostenunterschied ist nicht marginal – er beträgt eine Größenordnung – und der technische Vorteil der Entkopplung von Intelligenz und Ausführung wird sich verstärken, da sich beide Schichten mit unterschiedlicher Geschwindigkeit weiterentwickeln.