Code-Execution oder Domain-Specific Language (DSL)?

Enterprise-Ready Agentic AI braucht ein Netz und einen doppelten Boden

Seit über 25 Jahren entwickeln wir bei adesso Enterprise-Applikationen, genauer gesagt Individualentwicklungen von (Informations-) Systemen, die nah an der Wertschöpfungskette unserer Kunden und ihren Kerngeschäftsprozessen liegen. Wir haben den Wandel von Monolithen zu Modulithen und Microservices, von Applikationsservern zu Containerisierung, von On-Premises zu Cloud-Native und Serverless, von Server-Side-Rendering zu Single-Page-Applications sowie von nativen zu hybriden Apps nicht nur erlebt, sondern aktiv mitgestaltet. Vielversprechende technologische Weiterentwicklungen von Hypes zu trennen und den richtigen Zeitpunkt für das jeweilige Unternehmen zu bestimmen, eine Modernisierung vorzunehmen, gehört zu dem Kern unserer Beratungskompetenz.

Dabei bestätigt sich immer: Hypes kommen und gehen. Robuste Software-Architekturprinzipien jedoch bestehen und entwickeln sich evolutionär und nicht revolutionär weiter.

Aktuell rollt die nächste Welle über die Branche: Agentic AI, also AI-gestützte Agenten, die Werkzeuge autonom orchestrieren. Eine Vielzahl von Standards wie Model Context Protocol (MCP) und Agent-to-Agent-Communication (A2A) wurden definiert. Im Python-Ökosystem sind Frameworks wie LangChain, LangGraph und Microsoft Autogen sowie im Java-Ökosystem LangChain4j, Spring AI und LangGraph4j entstanden. Im Low-Code-Bereich gibt es Agentic-Workflow-Plattformen wie n8n und br.ai.n. Doch wie so oft werden Architektursünden begangen.

Ein wesentlicher Baustein dieser neuen Welt ist der Standard MCP von Anthropic. Dabei registrieren Entwicklerinnen und Entwickler ihre Tools (APIs, Datenbanken, Services) über ein Schema und das Large Language Model (LLM) kann diese Tools “selbständig” aufrufen. Technisch basiert MCP vollständig auf klassischen Technologien wie JSON-RPC 2.0 und Server Side Events (SSE). Der Mechanismus ist sehr mächtig, führt jedoch dazu, dass der Kontext mit einer potenziell großen Zahl an Aufrufdefinitionen, Tool-Beschreibungen und Zwischenergebnissen gefüllt wird. Dies kann zu Performanceeinbußen, hohen Kosten, sinkender Antwortqualität und Halluzinationen führen. Es erschwert auch die Kontrolle darüber, was dem Modell an Informationen zur Verfügung gestellt wird im Sinne von Compliance und Datenschutzanforderungen.

Anthropic hat mit seinem Blog-Artikel „Code Execution with MCP: Building more efficient agents“ vorgeschlagen, statt jeden Tool-Aufruf als eigenen Schritt auszuführen und alle Zwischenergebnisse in den Modellkontext zu übernehmen, LLMs Code generieren zu lassen. Hierdurch werden mehrere Aufrufe kombiniert, Rohdaten gefiltert und nur das Endergebnis in den Modellkontext zurückgegeben. Damit können sehr starke Einsparungen beim Tokenverbrauch erreicht werden. Anthropic spricht von 98 Prozent.

Cloudflare berichtet in „Code Mode: the better way to use MCP“, dass dieses Konzept starke Effizienzgewinne bringt und man MCP bisher „falsch“ genutzt habe. Die Autoren beobachteten, dass LLMs deutlich besser darin sind, Code zu schreiben, der MCP-Tools aufruft, als in der traditionellen Methode, bei der das Modell jeden Zwischenschritt im Kontext – mitsamt Hunderttausenden Tokens – bekannt sein muss.

Simon Willison (Board-Mitglied der Python Software Foundation) lobte den Ansatz als „eine sehr sinnvolle Weise, die großen Nachteile der klassischen MCP-Toolchains zu adressieren“. Gleichzeitig stellen viele Entwicklerinnen und Entwickler aber Sicherheitsfragen: Code-Execution bietet eine große Angriffsfläche, erfordert aufwendiges Sandboxing und lässt sich nur schwer statisch testen. Beiträge auf Hacker News und Reddit kritisierten, MCP mache alles komplizierter – und schlagen stattdessen vor CLI-Tools zu nutzen oder REST-APIs direkt anzusprechen.

Wir schlagen hier eine neue Lösung vor, die die gleichen Effizienzgewinne bietet, ohne einem LLM zu erlauben mobilen Code direkt in einer Produktionsumgebung auszuführen. Das würden wir auch einer menschlichen Entwicklerin oder einem Entwickler niemals erlauben. Unser Ansatz setzt auf Expression Languages und eine Workflow-DSL (Domain-Specific Language).

Wir sehen dies als Bestandteil unserer Lösungsarchitektur für die Integration von GenAI-Komponenten in Individualentwicklungen. Sie hebt agentische Systeme auf Enterprise-Niveau und basiert auf zehn Prinzipien. Bevor wir darauf eingehen, vergleichen wir Anthropics Code Mode-Vorschlag mit unserem DSL Mode-Ansatz an dem Beispiel aus Anthropics Blogpost.

Beispiel: „Sales-Meeting-Notizen nach Salesforce“ – Code Mode vs. Workflow-DSL

Anthropics Vorschlag (und die Diskussion darum) zielt auf einen sehr konkreten Engpass: Zwischenergebnisse sollen keinen Roundtrip durch den Modellkontext machen. Stattdessen werden mehrere Tool-Aufrufe „außerhalb“ kombiniert, Rohdaten dort gefiltert und nur ein kompaktes Endergebnis kommt zurück ins Modell.

Diese Effizienzidee lässt sich auf zwei Arten umsetzen: Code generieren und ausführen – oder einen Workflow als Datenstruktur erzeugen und interpretieren.

Variante A: Code-Execution („Code Mode“)

Das LLM erzeugt Code (zum Beispiel Typescript), der Tools aufruft, Daten zusammenführt und das Ergebnis reduziert:

	
	// generated by the LLM, executed in a sandbox
	const doc = await gdrive.getDocument({ documentId: "abc123" });
	await salesforce. updateRecord({ 
	  objectType: "SalesMeeting", 
	  recordId: "00Q5f000001abcXYZ", 
	  data: { Notes: doc.content }
	}) ;
	// only minimal result returns to the model 
	return { ok: true, updatedId: "00Q5f000001abcXYZ" };
	

Die größte Stärke dieses Ansatzes liegt in seiner Ausdrucksfähigkeit – nahezu jede beliebige Logik lässt sich damit realisieren. Allerdings ergibt sich daraus ein Spannungsfeld: Selbst, wenn Sandboxing eingesetzt wird, bleiben die prinzipiellen Probleme der Codegenerierung bestehen. Das bedeutet, es können weiterhin Imports, externe Bibliotheken, unerwünschte Nebenwirkungen oder auch unerwartete Kontrollflüsse auftreten, wenn die Sandbox hier nicht perfekt ist. Statische Garantien zu schaffen, ist entsprechend aufwendig, da das System im Zweifel jede mögliche Kombination von Programmiersprachelementen korrekt einschränken und absichern muss.

Variante B: Workflow-DSL („DSL Mode”)

Hier erstellt das LLM keinen ausführbaren Code, sondern eine Workflow-Instanz in einer DSL. Ein Interpreter führt die wenigen DSL-Operationen aus (Tool-Call, Referenzen, Projektion, Return). Eine Expression-Language wie jq übernimmt die Reduktion der Rückgaben, sodass Zwischenergebnisse ebenfalls keinen Roundtrip durch den Modellkontext machen, sondern serverseitig verdichtet werden:

	
	dsu: enterprise-workflow 
	version: "1.0"
	workflow: sync_sales_meeting_notes 
	steps:
	  - call: gdrive.getDocument 
	    in: {documentId: abc123}
	    as: doc
	    out: {jq: '{transcript:.content}'}
	  - call: salesforce.updateRecord 
	    in:
	      objectType: SalesMeeting 
	      recordId: 0005f000001abcXYZ
	      data: {Notes: {$ref: doc.transcript}}
	    as: sf
	    out: {jq: '{ok:-success, updatedId:. id}'}
	return: {from: sf, jq: .}
	

In diesem Beispiel nehmen wir als Zielsprache YAML (interne DSL). Hier ist genauso JSON oder eine eigene Sprache (externe DSL), die syntaktisch an Typescript oder Python angelehnt ist, möglich. Die Wahl hängt insbesondere von der Ergebnisqualität des LLM für die jeweilige Syntax ab. Wichtig ist, dass eine Validierung vor der Ausführung stattfindet und ein Interpreter eingesetzt wird, der nur die Operationen umsetzen kann, die von der DSL erlaubt werden.

Wir müssen uns vor Augen führen, dass den LLMs erlaubt wird Geschäftslogik zu erzeugen, die direkt in der Produktivumgebung ausgeführt wird. Das würden wir in Enterprise-Anwendungen niemals zulassen. Daher sind die Tools, die dem LLM zur Verfügung gestellt werden auf der Ebene eines Users zur Laufzeit anzusiedeln, wobei dieselben Access-Control-Mechanismen und Eingabevalidierungen zu beachten sind. Dies bedeutet insbesondere keine nativen Admin-Funktionen (das heißt kein Godmode) und keinen direkten Zugriff auf Datenbanken zu ermöglichen. Dazu gehören auch Confirmation-Abfragen für Aufrufe, die größeren Impact haben (zum Beispiel Löschen eines oder mehrerer Geschäftsobjekte).

Der zentrale Unterschied zwischen den Ansätzen liegt weniger darin, ob beispielsweise YAML statt Typescript oder Python verwendet wird, sondern vielmehr in der Art und Weise der Kontrollierbarkeit. Jeder einzelne Schritt ist klar strukturiert und kann gezielt validiert werden. Der Interpreter prüft vor einer Ausführung, ob es sich tatsächlich um Tool-Aufrufe handelt, ob die entsprechenden Tools erlaubt sind, ob die übergebenen Parameter stimmen, ob eine Datenminimierung durch jq erfolgt und ob Größen- sowie Timeout-Limits eingehalten werden. Import-Anweisungen oder beliebige Funktionsaufrufe, wie sie in klassischen Programmiersprachen möglich sind, sind in der Workflow-DSL nicht möglich. Wenn ein Problem bei den Validierungen auftritt, kann das dem LLM mitgeteilt werden und über einen Bounded-Retry-Mechanismus korrigiert werden. Das kann die Ergebnisqualität deutlich erhöhen.

Der Ausführungsraum bleibt dadurch bewusst klein und überschaubar. Im Gegensatz dazu muss diese Freiheit im Code Mode auf technischer Ebene nachträglich eingeschränkt werden, was – abhängig von Laufzeit, Bibliotheken und verwendeter Sprache – nahezu unmöglich sein kann. Der DSL Mode führt zum „Netz-und-doppelter-Boden“-Effekt: Das LLM erstellt einen Plan, die Runtime kontrolliert dessen Ausführung – und das deterministisch.

Tool Discovery: Weniger Kontext, bessere Auswahl – für beide Ansätze

Beide Varianten profitieren, wenn die Toolauswahl nicht über vollständige Schema-Beschreibungen im Modellkontext erfolgt, sondern über Tool Discovery:

• Directory-Ansatz (Verzeichnisdienst): Tools liegen in einer Registry mit Kurzprofil (Name, Zweck, wichtige Felder, Policies). Das Modell erhält nur relevante Einträge „on demand“.
• RAG / semantische Suche: Das Modell formuliert Absicht und Randbedingungen. Eine Vektorsuche liefert passende Tools nach einer definierten Strategie (zum Beispiel Top-k). Erst anschließend wird der konkrete Plan als DSL-Instanz erzeugt.

So sinken Kontextlast und Kosten, und die Halluzinationsrate fällt typischerweise, ohne dass dynamische Tool-Orchestrierung via MCP verloren geht.

Zwischenfazit

Anthropics Code Mode Vorschlag fokussiert darauf, dass das LLM Typescript oder Python generiert, um MCP-Tools zu kombinieren, Daten zu filtern und erst dann ein Ergebnis ins Kontextfenster zu laden. Das spart Token und vermeidet, dass große Mengen an Daten durch das Modell verarbeitet werden müssen.

Gleichzeitig steigt damit die Komplexität der Sandbox: Der Code hat Zugriff auf Bibliotheken, muss sicher und isoliert begrenzt werden. Eine LLM-generierte Schleife kann unabsichtlich eine Denial of Service (DoS) auslösen, Daten exfiltrieren oder schlicht aufgrund syntaktischer Fehler abbrechen. Die von uns vorgeschlagene Verschiebung von „Code ist Freiheit“ zu „DSL ist kontrollierte Ausdrucksstärke“ im DSL Mode ermöglicht Auditierbarkeit, Datenminimierung und Reproduzierbarkeit – sie macht Agentic AI effizient und enterprise-ready.

Die Ausdrucksstärke kann mit einer Workflow-DSL gezielt konfiguriert werden:

• DSL als Stellhebel: Wir können die DSL bewusst um weitere Sprachelemente erweitern (zum Beispiel if/else, switch, foreach, parallel, retry, compensation) oder sie schlank halten. Ausdrucksstärke wird damit zu einer Architekturentscheidung – nicht zu einem Nebenprodukt von „wir führen Code aus“.
• Expression Language als separater Stellhebel: jq lässt sich einschränken oder Alternativen wie JMESPath verwenden. Formal hat jq die gleiche Ausdruckskraft wie eine generische Programmiersprache – damit ist sehr viel möglich. Genau deshalb ist es sinnvoll, jq nicht einfach „voll“ freizuschalten, sondern erlaubte Teilmengen festzulegen (zum Beispiel nur reine Projektionen/Filter, keine ungebundenen Konstrukte, Größenlimits).
• Statisch prüfbar vor Ausführung: Weil der Workflow eine Datenstruktur ist, lassen sich diese Regeln vorab und deterministisch validieren: erlaubte Step-Typen, erlaubte Tools, maximale Schrittanzahl, Referenz-Graph ohne Zyklen, jq-Subset/Regeln, Timeouts, Output-Größen, syntaktische Korrektheit, usw.

Den Hebel zur Steigerung der Effizienz teilen sich die Ansätze Code Mode und DSL Mode:

• Tool Discovery statt “MCP-Server-Definition im Kontext”
• Ausführung mehrerer Tools und Logik in einem Schritt, ohne Zwischenergebnisse in den Kontext zu laden.
• Aufbereitung und Filterung von Toolausgaben vor der Rückgabe an das Modell.

Dadurch werden AI-Agenten sicherer, performanter, verlässlicher und günstiger. An dieser Stelle hören wir jedoch noch nicht auf.

MCP ist kein Allheilmittel

Obwohl das Model Context Protocol eine mächtige Mechanik ist, ist es aus unserer Sicht nicht für jedes Problem die passende Lösung. In manchen Szenarien bietet sich an, direkt GraphQL-Queries zu generieren und diese von der deterministischen Geschäftslogik ausführen zu lassen. Ein GraphQL-Endpoint liefert oder ändert genau die angefragten Daten in der gewünschten Struktur und lässt sich ähnlich wie ein MCP-Tool kapseln. Auch Access Control lässt sich umsetzen. Entscheidend ist: Wir geben die Rohdaten nicht oder nur pseudonymisiert an das LLM zurück. Das LLM erzeugt zwar DSL-Schritte und jq-Expressions oder sogar GraphQL-Queries, doch es führt sie nicht selbst aus. Stattdessen interpretiert der Orchestrator diese Definitionen deterministisch, holt die Daten aus den Backends und verarbeitet sie weiter. So stellen wir sicher, dass keine ungewollten Informationen in Richtung LLM abfließen und dass sich das Sandbox-Problem signifikant reduziert. Die Flexibilität, direkt GraphQL zu nutzen, bedeutet also keinen Verzicht auf unsere Prinzipien, sondern ist eine Ergänzung, wenn ein MCP-Schema nicht ausreicht oder zu starr wäre. GraphQL eignet sich auch für Legacy-Anwendungen, da ein GraphQL-Server als Zugriffsschicht vor beliebige Dienste geschaltet werden kann.

Zehn Enterprise-Prinzipien für Agentic Systeme

Für eine sinnvolle Integration von GenAI-Komponenten in Enterprise Applikationen sind, abseits der Wahl zwischen DSL Mode und Code Mode, weitere Prinzipien entscheidend. Diese stellen wir im Folgenden vor.

Um AI-Agenten in geschäftskritische Anwendungen zu integrieren, haben wir zehn architektonische Grundprinzipien formuliert. Sie sind das Ergebnis aus unseren Erfahrungen und dienen als Leitplanken für Architektur und Betrieb:

• 1. Not a Hammer, but a Scalpel: AI wird nur dort eingesetzt, wo sie einen klaren Mehrwert liefert. Standardfunktionen bleiben konventionell implementiert. Für Nebenläufigkeit, Datenabfragen, Transaktionen, Zugriffskontrolle, mathematische Operationen, Fehlerbehandlung, Messaging, Templating, usw. nutzen wir konsequent klassische, deterministische Mechanismen.
• 2. Divide und Conquer: Aufgaben werden in kleine, klar abgegrenzte Teilschritte mit eindeutiger Verantwortung zerlegt. Jeder Teilschritt erhält einen eigenen Kontext sowie einen passenden Prompt und wird an spezialisierte AI-Services oder Agents geroutet. Unabhängige Teilschritte werden nebenläufig ausgeführt, mit begrenzter Parallelität. Ergebnisse werden validiert und bei Bedarf mit Backoff erneut ausgeführt.
• 3. Separation of Concerns: GenAI-Komponenten werden als eigene Services in Microservice-Architekturen oder als Module in Modulithen umgesetzt. Sie verwenden Metadaten wie GraphQL-Schemas oder OpenAPI-Definitionen, um Abfragen zu generieren. Retrieval und Verarbeitung erfolgen soweit möglich in deterministischer Anwendungslogik, und an das LLM gehen nur die unbedingt notwendigen, anonymisierten oder pseudonymisierten Daten.
• 4. Domain-Specific Languages (DSL): Statt von der AI generierten Code auszuführen, setzen wir auf Metamodelle und konfigurative DSLs. Sie sind statisch validierbar, auditierbar und werden von deterministischem Code interpretiert. Für Datentransformationen nutzen wir Expression Languages wie jq. Dieses Prinzip gilt nicht nur für MCP und Tool-Calls, sondern auch für die Erzeugung von Automationen, für dynamische User Interfaces und weitere Anwendungsfälle. Wir lassen insbesondere keinen mobilen Code generieren oder ausführen, weil das ein unnötiges Sicherheitsrisiko ist. Das LLM erzeugt stattdessen Instanzen der Metamodelle, die wir strikt validieren und anschließend klassisch interpretieren. Dadurch sind sie weniger generisch, es erhöht jedoch Kontrolle, Nachvollziehbarkeit und Sicherheit.
• 5. Deterministic Control Layer: Ein deterministischer Workflow steuert, wann welches AI-Modul oder welcher Agent aktiv wird. Wir bevorzugen klar definierte, agentische Workflows statt generischer Feedback-Loops. Die klassische, deterministische Geschäftslogik entscheidet über Ausführung, Validierung, Retries und nächste Schritte. Sie behält damit die Kontrolle.
• 6. Deep Integration: AI wird gezielt tief in die Anwendungsarchitektur integriert. Low-Code oder Scripting setzen wir nur dort ein, wo es Mehrwert liefert. Je enger AI und Geschäftslogik verzahnt sind, desto höher wird sonst der Übergabeaufwand zwischen Scripting und Anwendung. Low-Code ist zwar schnell zu Beginn, skaliert aber nicht so gut und wird mit der Zeit fragil, unsicher und schwer zu warten. Deshalb steuert ein Orchestrator alle Aufrufe und hält die Interaktion kontrolliert und nachvollziehbar.
• 7. Testing und Policies: Tests, Metriken, Filter und Safeguards sind fester Bestandteil jeder AI-Integration. Da AI nicht deterministisch ist, testen und stress-testen wir die Komponenten und überwachen ihr Verhalten über Policies im Betrieb. Eingaben und Ausgaben werden zur Laufzeit gefiltert und abgesichert. Wo Fehler nicht akzeptabel sind, kommt keine AI zum Einsatz.
• 8. Async or Stream: Längere Vorgänge werden asynchron ausgeführt oder als Stream bereitgestellt. Bei direkter Interaktion zwischen User und LLM liefern wir bei synchronen Aufrufen einen eng getakteten Status- und Ergebnisstream, damit der Dialog flüssig bleibt. Die Ausführung läuft weiter und wird nicht abgebrochen, nur weil der User die App, die Seite oder den Fokus verlässt.
• 9. Entscheidungen über unsichere Informationen vermeiden: Das System fragt nach, wenn Informationen fehlen, oder liefert Teilergebnisse mit klaren Unsicherheitshinweisen. Es soll keine selbstsicheren Entscheidungen auf Basis erfundener Annahmen treffen.
• 10. Respektiere Domain Driven Design (DDD): DDD definiert die fachlichen Kommunikations- und Verantwortungsgrenzen. Diese Grenzen müssen nicht identisch mit den Microservice-Schnitten sein. In Multi-Agenten-Systemen wird jedoch konsequent aus DDD und Bounded Contexts abgeleitet, wann Agenten innerhalb eines Services laufen und wann als separate Services, die über A2A kommunizieren.

Diese Prinzipien schaffen Klarheit, wenn wir neue GenAI Technologien wie LLMs integrieren. Sie helfen, Gefahren zu vermeiden, die wir aus den letzten Technologiezyklen kennen: ungetestete Orchestrierung, Datenüberschuss, fehlende Fachlichkeit und mangelnde Governance.

Fazit und Ausblick

Die Veränderungen, die durch AI und GenAI im Speziellen auf uns zukommen, ziehen sich durch alle Bereiche und machen vor Informationssystemen sicher nicht halt. Wir sehen darin große Chancen und neue Möglichkeiten aber auch Risiken. Daher bedarf es einer soliden Grundlage, auf der Lösungen im Kerngeschäft unserer Kunden aufbauen. Dabei sollen Möglichkeiten ausgeschöpft werden, während Technologien mit gesundem Menschenverstand eingesetzt werden. Für Anwendungsfälle mit hohen Anforderungen an Zuverlässigkeit und Sicherheit gelten andere Maßstäbe als für einen einfachen Chatbot. Welche Variante und Technologie gewählt wird, hängt vom konkreten Business-Case ab – ein Kernprinzip von adesso.

Wir wenden diese Ansätze bereits bei Kunden aus unterschiedlichen Branchen an – von Medien und Entertainment über Handel bis hin zur fertigenden und produzierenden Industrie. Unseren Anspruch der Software-Exzellenz haben wir in das AI-Zeitalter übertragen und sind bereit, die Veränderungen, die da kommen, aktiv zu gestalten.