LLM-Funktionsaufrufe skalieren nicht; Code-Orchestrierung ist einfacher und effektiver

• Die Methode, bei der ein LLM das vollständige Ergebnis eines Tool-Aufrufs verarbeitet, ist langsam, teuer und schlecht skalierbar
• Stattdessen wird ein Ansatz vorgeschlagen, bei dem das LLM die Orchestrierung übernimmt, sodass strukturierte Daten auf Basis eines Ausgabeschemas per Code verarbeitet werden
• Dieser Ansatz ist für die Verarbeitung großer Datenmengen geeignet, da Funktionsverkettung per Code und speicherartige Variablenverwaltung genutzt werden
• Die datenverarbeitende Methode auf Basis von Codeausführung ist besonders genau und skalierbar, da das LLM die Daten nicht selbst rekonstruieren muss
• Der Aufbau einer sicheren AI-Laufzeitumgebung entwickelt sich zu einer neuen Herausforderung; benötigt wird eine nachhaltige und zustandsbehaftet nutzbare Ausführungsumgebung

---

LLM function calls don't scale; code orchestration is simpler, more effective.

Grenzen des bisherigen Ansatzes, Tool-Aufrufergebnisse wieder an das LLM zurückzugeben

• Bei der Nutzung von MCP(Machine Context Protocol)-Tools werden die Ausgaben eines Tools dem LLM üblicherweise als Nachricht übergeben, um den nächsten Schritt anzustoßen
• In realen Anwendungsfällen liefern die MCP-Server von Linear und Intercom große Antworten im JSON-Format zurück
• JSON ähnelt einer API, jedoch entsteht ohne definiertes Ausgabeschema die Last, dass das LLM den gesamten Text parsen muss
• Zum Beispiel ist das Ergebnis einer Abfrage der Linear-Issue-Liste mit 50 Einträgen, 70.000 Zeichen und rund 25.000 Tokens sehr groß
• Viele id-Felder haben keine inhaltliche Bedeutung, verbrauchen aber Tokens, und wenn das LLM sie unverändert reproduzieren soll, steigen Kosten und Fehlerrisiko

Warum Datenverarbeitung und Orchestrierung getrennt werden sollten

• Der aktuelle Ansatz vermischt Datenverarbeitung und Orchestrierung in einer einzigen Chat-Sitzung
• Manche erzeugen dafür als „Agent“ andere Threads, doch bei strukturiertem JSON ist das ineffizient
• Ein besserer Ansatz besteht darin, strukturierte Daten direkt per Code zu verarbeiten
  • Beispiel: Statt dass das LLM die Ausgabe erzeugt, wird zum Sortieren von Issues per Code sort ausgeführt und nur das Ergebnis-Array zurückgegeben

Datenverarbeitung auf Basis von Codeausführung

• AI-Berechnungen per Codeausführung werden bereits in verschiedenen AI-Interpretern eingesetzt
• Dieser Ansatz ermöglicht eine einfache Struktur, bei der das LLM die Daten nicht selbst ausgibt, sondern nur entscheidet, wie Tools verwendet werden

Zentrale Konzepte

• Variablen als Speicher nutzen: Wertzuweisung = Speichern, Ausgabe = Abrufen, Übergabe bei Funktionsaufrufen als Argument
• Unterstützung für Funktionsverkettung: Mehrere Funktionsaufrufe parallel oder sequenziell kombinieren, Abhängigkeiten werden als natürlicher Ablauf im Code ausgedrückt
• Skalierbare Verarbeitung großer Datenmengen: In Kombination mit NumPy, pandas usw. lassen sich auch Tausende bis Zehntausende Datensätze leicht verarbeiten
• Auch andere LLM-Aufrufe sind möglich: Innerhalb des vom LLM geschriebenen Codes kann ein weiteres LLM aufgerufen werden, um unstrukturierte Daten zu verarbeiten

Ist MCP darauf vorbereitet?

• Die MCP-Spezifikation definiert bereits ein Eingabeschema, und vor Kurzem wurde auch ein PR für ein Ausgabeschema eingereicht
• Wenn sich Ausgabeschemata allgemein durchsetzen, werden folgende Anwendungen möglich:
  • Dashboard zum Issue-Status
  • Wöchentlicher Bericht über abgeschlossene Tickets
  • AI überwacht feststeckende Tickets und stößt Benachrichtigungen an

Herausforderungen der Code-Ausführungsumgebung

• Sicherheit ist das Kernproblem: Da von AI/Nutzern erzeugter Code ausgeführt wird, muss verhindert werden, dass API-Schlüssel und Daten offengelegt werden
• Im Fall von Lutra ist die Ausführungsumgebung als Sandbox aufgebaut, und dem Modell wird nur die API-Aufrufdokumentation bereitgestellt
• Zustandsbehaftete Ausführungsumgebungen (wie Jupyter) sind teuer, und für Langzeitsitzungen werden Eigenschaften wie zustandslos (stateless) + persistent benötigt
• Dadurch entsteht eine neue Kategorie namens AI-Runtime, deren Design noch aktiv weiterentwickelt wird

Fazit

• Der bisherige Ansatz, Tool-Aufrufergebnisse in das LLM einzuspeisen und dort verarbeiten zu lassen, hat Grenzen bei Kosten und Genauigkeit
• Codebasierte Orchestrierung ermöglicht eine einfache, skalierbare und genaue Verarbeitung
• AI-Code-Ausführungsumgebungen rücken als Laufzeit der nächsten Generation in den Fokus und müssen Sicherheit, Persistenz und Skalierbarkeit bieten

[GN⁺]

Hacker-News-Kommentare

• Jemand teilt die Erfahrung aus den letzten zwei Jahren, dass „hinreichend fortgeschrittene Agenten von einer DSL nicht zu unterscheiden sind“. Statt vom Agenten zu verlangen, Algorithmen zu internalisieren, sei es deutlich geeigneter, ihm APIs beizubringen, ihn Algorithmen auf Basis dieser APIs entwerfen zu lassen und diese dann im Userspace auszuführen. Algorithmen in ein LLM hineinzupacken, sei außer in sehr wenigen Fällen (etwa bei Kosten oder Genauigkeit) ineffizient. Der Vergleich: Es ist, als würde man Entwickler auffordern, Funktionsausführung im Kopf zu erledigen.
  • Das wird als Hinweis darauf interpretiert, dass der Weg zu ASI nicht in der Erweiterung der Fähigkeiten von LLMs liegt, sondern eher darin, Selbstverbesserungsalgorithmen extern als symbolische Anwendungen zu extrahieren und zu kompilieren.
  • Es wird nach Belegen oder Beispielen gefragt, dass der Begriff „agent“ in genau diesem Kontext schon seit zwei Jahren breit verwendet wird.
• Eigene Erfahrung beim direkten Aufbau agentischer Systeme im E-Commerce. smolagents wurde evaluiert: elegant und attraktiv, aber mit dem Nachteil deutlich höherer Systemkomplexität. Für Umgebungen ohne Schema, etwa dynamisches Reporting mit Sortieren und Aggregieren von Daten, ist das perfekt, für die meisten Aufgaben aber Overkill. Gemini und OpenAI bieten Python-Interpreter-Funktionen, die einen großen Teil der Arbeit von Code-Agenten abdecken können. Ein Ansatz, bei dem endlos Tool-Call-Nachrichten auf den Stack gelegt werden, skaliert schlecht und wird nicht empfohlen. Tatsächliche agentische Workflows sind kurzlebig und verwalten Komplexität über Struktur und Disziplin. Die Lehren aus klassischer Softwareentwicklung gelten unverändert: Das Skalieren von Funktionsaufrufen und das Vermeiden von Chaos waren schon immer dieselben Probleme. Der Schlüssel zu guten Systemen ist das Management der kognitiven Last für Entwickler; einfache, aber ausreichend gut funktionierende Lösungen sind leistungsstarken, kunstvollen Ansätzen überlegen. Die Komposition von Funktionsaufrufen ist ein Beispiel für eine solche einfache Lösung, und auch strukturierte Daten lassen sich mit traditionellen Parsing- und Transformationsmethoden ausreichend verarbeiten. Ist die Struktur unbekannt, liefern selbst günstige Modelle hervorragende Parsing-Leistung. Das Management der Komplexität agentischer Systeme lässt sich letztlich auf eine sorgfältige Verwaltung des Anwendungszustands reduzieren. Durch Manipulation des Message-Stacks lässt sich der aktive Kontext, den man dem Modell gibt, flexibel zusammenstellen – ähnlich wie Speicherverwaltung in eingeschränkten Umgebungen.
  • Eine Zusammenfassung, die die Trade-offs agentischer Systeme sehr präzise trifft. Auch beim Aufbau einer konversationellen Produktsuche für den E-Commerce (IsarTech) habe man mit denselben Problemen gerungen. Funktionskomposition und strukturierte Daten seien zentral für die Kontrolle von Komplexität. Aus Erfahrung erhöhe eine Ausgabe auf Basis klarer Typschemata die Skalierbarkeit von Tool-Calls deutlich. Dank Typschemata lassen sich sowohl kognitive Last als auch Systemkomplexität beherrschen. Man sollte sich möglichst auf deterministisches Verhalten stützen und LLMs nur bei schemafreien Daten oder Mehrdeutigkeit einsetzen. Für das Mapping von mehrdeutigen Anfragen auf deterministische Systeme seien LLMs sehr effektiv. Allerdings müsse man zwischen Komplexitätsreduktion bei hochentropischen (unstrukturierten) Eingaben und Komplexitätszunahme durch Ketten von Tool-Calls abwägen. In realen Commerce-Umgebungen sei ein einzelner Ansatz selten ausreichend, und strukturierte Ausgaben stoßen bei mehrdeutigen Intentionen an Grenzen, sodass zusätzliche Strategien nötig sind.
• Das Problem sei nicht Funktionsaufruf an sich, sondern Design und Nutzung von MCP. Die meisten MCPs seien bloße API-Repliken und erzeugten bedeutungslosen Datenausstoß. Durch wiederholte Verschachtelung von JSON-Formaten werde unnötig viel Eingabekontext verbraucht, zudem sei viel irrelevante Information enthalten. Optimierungen wie Daten-Glättung und das Entfernen unnötiger Felder seien erforderlich. MCP-SaaS übernehme letztlich nur die Rolle eines API-Gateways. Derzeit sei MCP eine Hauptquelle für Rauschen und nicht ausreichend optimiert.
  • GraphQL ist genau für diesen Zweck optimal geeignet. Es ist so entworfen, dass nur die benötigten Felder ausgewählt werden. Es wurde ein Open-Source-Gateway entwickelt, das mehrere GraphQL-Queries in einen MCP-Server umwandelt.
  • Es wird die Frage aufgeworfen, ob nicht vielmehr das Problem sei, dass Modelle komplexe JSON-Schemata nicht zuverlässig einhalten.
  • MCP hilft nicht, aber pauschales Filtern ist auch nicht immer die beste Lösung. Manchmal braucht ein Agent die Verarbeitung großer Datenmengen. Dann ist Codeausführung mit einfacher Datenauswertung und Schemabeschreibung der besser skalierende Ansatz. Natürlich treten ähnliche Probleme auf, wenn das System zu groß wird. Die letztliche Lösung sei, die Präzision deterministischen menschlichen Denkens in Code zu reproduzieren und dieses Entscheidungssystem vom LLM aufrufen zu lassen. Theoretisch einfach, praktisch aber sehr schwer umzusetzen.
  • Beim Testen von Zeichenkettenumkehr mit ChatGPT sei es sehr schwierig gewesen, das LLM dazu zu bringen, nur ein einfaches Ergebnis zurückzugeben, und das Vertrauen darin sei gering gewesen. Seit dieser Erfahrung werde immer mit mehreren LLMs gegengeprüft. In diesem Tempo müsse man vielleicht bald ein eigenes GPU-Rechenzentrum aufbauen, nur um die Anzahl von Zeichen in einer simplen Zeichenkette zu zählen – als Scherz gemeint.
• Das Shopify-Team hat kürzlich Roast als Open Source veröffentlicht. Ein Tool, mit dem sich nichtdeterministische LLM-Aufgaben in Workflows für die Automatisierung riesiger Codebasen einbetten lassen. Unverzichtbar für die Automatisierung komplexer Arbeiten.
  • Großer Eindruck von Roast. Besonders auffällig sei die Harmonie von Determinismus und Nichtdeterminismus. Etwas unklar bleibe, wie das LLM mehrere Tool-Calls orchestriert und ihre Reihenfolge bestimmt. Für Refactoring-Anweisungen scheine es zu funktionieren, aber es gebe Zweifel, ob es auch für komplexere Aufgaben wie „Verbessern → Testen → Wiederholen“ geeignet ist.
  • Es wirkt erfrischend, dass Ruby auch im KI-Zeitalter weiterhin sinnvoll und beständig funktioniert.
  • Schon das Lesen der Dokumentation sei intellektuell anregend; besonders beeindruckend sei die deklarative Verpackung der LLM-Funktionalität.
  • Es wird um konkrete Beispiele gebeten, wie solche Workflows intern bei Shopify tatsächlich verwendet werden.
  • Jemand hat sowohl Claude Code Research Preview als auch ChatGPT 4.5 Pro Deep Research zum Absturz gebracht (mit Belegen) und sucht nun nach Werkzeugen, die zuverlässig funktionieren.
• Die beste Antwort liege nicht an einem der Extreme, sondern in einem Hybridansatz. So viel wie möglich sollte deterministisch gelöst werden, und LLMs sollten für die komplexen Teile genutzt werden, die sich nur schwer spezifizieren oder deterministisch umsetzen lassen.
  • Ein interessanter Ansatz sei, LLMs auf die Erzeugung deterministischer Lösungen (Code) zu fokussieren und diesen Code nach erfolgreicher Verifikation künftig als deterministischen Code wiederzuverwenden.
  • Es wird argumentiert, dass das Ziel darin bestehen sollte, den Einsatz von LLMs innerhalb von Workflows zu minimieren.
• Erstaunen darüber, dass solche komplexen Experimente sich in dem Jahr oder mehr außerhalb der Branche offenbar verbreitet haben.
  • Tatsächlich experimentiere bislang nur eine Minderheit damit; revolutionäre Beispiele gebe es noch nicht, aber einige nützliche Anwendungsfälle schon.
  • Es kommt auch die Ansicht auf, dass man die Branche bald wieder verlässt, wenn man sich jetzt nicht mit solchen Dingen beschäftigt.
  • Die eigene tägliche Arbeit konzentriere sich bereits stark auf die Automatisierung des Entwurfs LLM-basierter KI-Agenten – nicht bewusst geplant, sondern eher unbemerkt so entstanden.
• Es wird gefragt, warum man LLMs zum Sortieren strukturierter Daten verwendet.
  • Das eigentliche Ziel sei komplexere Datenverarbeitung wie Dashboard-Erstellung, automatische Erkennung von Issue-Tickets oder Quartalsreviews. Das Sortieren sei nur ein einfaches Beispiel, das die Größenordnung des Problems leichter verständlich machen soll.
• huggingface smolagent ist ein repräsentatives Beispiel für diesen Ansatz, bringt aber das Problem mit sich, dass Rollback oder Recovery bei realen Ausfällen sehr schwierig werden. Grundsätzlich ließe sich das lösen, indem man den gesamten Ausführungsblock in eine verteilte Transaktion kapselt, in der Praxis passt das jedoch schlecht dazu, dass LLMs robusten Code erzeugen sollen, wodurch Fehlerverfolgung und Ursachenanalyse erschwert werden.
  • Zustimmung, dass die Grundidee von smolagent gut sei, die Realität von Ausführung und Fehlerbehandlung aber problematisch ist. Man möchte zum Beispiel, dass bei einer unterbrochenen Codeausführung direkt vom jeweiligen Zustand aus weitergemacht werden kann. Es habe sich gezeigt, dass LLMs Code zur Zustandswiederherstellung gut schreiben können, und diese Funktion arbeite inzwischen im realen Produkt (Lutra) ziemlich gut.
• Als weiterer Ansatz wird vorgeschlagen, das LLM dazu zu bringen, Code in Form eines Python-Skripts zu schreiben, das MCP wie eine Funktion aufruft. Beispielcode wird geteilt.
  • Als Praxisbeispiel für diesen Ansatz wird Lutra.ai genannt. Entscheidend sei letztlich, wie gut die Code-Runtime entworfen ist.
• Die Beobachtung, dass LLMs insbesondere mit JSON und vor allem mit großem JSON schwach sind. Endpunkte müssten Daten nicht zwingend als JSON zurückgeben. LLMs seien bei XML oft deutlich stärker, und auch eine Aufbereitung als narrativer Text per Template sei möglich.
  • XML ist ein Format mit inhärenter semantischer Information; deshalb wirke es überraschend, dass es nicht viel häufiger als Standard für LLMs verwendet wird. Wo nötig, lasse sich XML deterministisch in JSON umwandeln und dann in die Pipeline einspeisen.
  • Es wird berichtet, dass Markdown-Tabellen bei der Rückgabe von Daten an LLMs ziemlich gute Ergebnisse liefern.
  • Es wird gefragt, ob die bessere Leistung von XML daran liegt, dass es in den Trainingsdaten von LLMs häufiger vorkommt, oder daran, dass es mehr Text-Tokens enthält. Es wird angemerkt, dass größere Textblöcke dem LLM möglicherweise mehr Kontext liefern.