Man baut keine Workflows. Man formuliert Ergebnisse

Warum das Visual-Workflow-Builder-Paradigma die falsche Abstraktion für Enterprise AI ist. 

Die dominante Marketing-Narrative im Enterprise-AI-Markt 2026 hat sich auf eine einzige visuelle Metapher festgelegt. Öffne ein Canvas. Ziehe einen Trigger hinein. Ziehe ein Tool hinein. Ziehe einen Konnektor hinein. Setze einen AI-Schritt in die Mitte. Verbinde alles mit Pfeilen. Teste. Deploye. Microsoft Copilot Studio, Salesforce Agentforce, n8n, Zapier — jeder größere Anbieter in der agentischen KI-Kategorie hat sich auf dasselbe Interface, dasselbe Vokabular, dasselbe Versprechen konzentriert. Das Versprechen ist überall dasselbe: „Nicht-technische Anwender können jetzt ihre eigenen KI-Agenten bauen." Gartner prognostiziert, dass bis 2028 agentische KI in vier von fünf Unternehmen weltweit über Low-Code-Plattformen implementiert wird. Das Versprechen hat die Budget-Kategorie gewonnen. Es ist auch die falsche Abstraktion für das, was die meisten Fachexpertinnen und Fachexperten in regulierten europäischen Unternehmen von ihrer KI-Plattform tatsächlich brauchen — und diese strukturelle Diskrepanz ist das Wichtigste, worüber ernstzunehmende CIO- und CTO-Käufer aktuell nachdenken sollten. Denn sie entscheidet darüber, ob KI in den Händen derer landet, die die fachlichen Probleme besitzen, oder ob sie in den Händen der IT-Poweruser stecken bleibt, die ohnehin schon einen Zapier-Account hatten. 

Dies ist der elfte Beitrag in einer Serie, die ich für neuland.ai schreibe. Das Argument, das sich durch alle Beiträge zieht, ist dasselbe: Im Enterprise-AI-Kontext liegen Wert, Risiko und Moat in der Schicht oberhalb und rund um das Modell — nicht im Modell selbst.1 Frühere Beiträge haben dieses Argument aus unterschiedlichen Blickwinkeln entwickelt: Control Plane und Execution Surfaces, Model Drift und Multi-LLM-Observability, Modell-Topologie, Compliance als Systemeigenschaft, Agent Security, MCP-Protokoll-Governance, die Fast-Follower-Workhorse-These, die neuen Enterprise-Daten-Silos, Flexibilität als Architektur, und zuletzt das Ontologie-Rennen, das SAP, Microsoft, Google und Palantir gemeinsam gestartet haben. Der vorliegende Beitrag schließt einen Faden, den der erste Beitrag im Februar implizit eröffnet hat: Wenn das LLM ein Planer innerhalb eines Systems ist und nicht das System selbst, dann ist wer mit dem System interagiert, und über welches Interface, die architektonische Frage, die das kommende Jahr der Enterprise-AI-Beschaffung definieren wird. 

Der Visual Workflow Builder ist eine mögliche Antwort auf diese Frage. Für die Arbeit, die tatsächlich getan werden muss, ist er nicht die richtige. 

Was Visual Workflow Builder tatsächlich sind — fair beurteilt 

Vor der Kritik das Verdienst. Visual Workflow Builder sind gute Werkzeuge und sie haben sich einen realen Platz im Enterprise-Stack verdient. n8n ist exzellent in dem, was es tatsächlich ist. Ebenso die anderen etablierten Anbieter dieser Kategorie. Sie verfügen über hunderte vorgefertigter Konnektoren, ausgereiftes Error Handling, funktionierende Observability, etablierte Abrechnungsmodelle und große Communities aus Praktikern, die wissen, wie man sie zum Laufen bringt. 

Die Frage ist, was sie sind. 

Die klarste Einzelaussage darüber, was diese Werkzeuge strukturell sind, stammt aus n8ns eigener Positionierung — sinngemäß aus öffentlichen Materialien wiedergegeben: Die KI ist ein Schritt innerhalb einer vordefinierten Automation. Der Workflow definiert die Logik. Die KI ist mächtig, aber sie operiert innerhalb der vorab strukturierten Automation, nicht als entscheidungstreibende Schicht.2 Das ist eine ehrliche Beschreibung und sie ist zutreffend. Sie ist auch das strukturelle Merkmal, das die gesamte Visual-Workflow-Builder-Kategorie zur falschen Abstraktion für ernstzunehmende AI-Agent-Arbeit macht. 

Jeder Visual Builder in dieser Kategorie exponiert dieselben vier Primitive, die der Builder-Nutzer konfigurieren muss: einen Trigger (was den Lauf startet), Instruktionen (den System Prompt — die „am wenigsten investierte Komponente" gemäß der Praktikerliteratur), Tools (die API- und Konnektor-Liste, die der Agent aufrufen kann) und ein Deployment-Ziel.3 Der Visual Builder liefert einen funktionierenden Demo in einem Nachmittag. Er erzeugt zugleich die Sprödigkeit, die die Literatur zum Production-Deployment über 2026 hinweg konsistent dokumentiert hat. 

Eine unabhängige Analyse von Nexus zur Production-Trajektorie von Low-Code-Agent-Buildern in Enterprise-Kunden ist zu einer Zahl gekommen, die inzwischen in der Beschaffungsliteratur breit zitiert wird: Der Visual Builder bringt den Kunden zu 40 Prozent ans Ziel; die verbleibenden 60 Prozent — echte Integrationen, Compliance-Posture, Edge Cases, Production Hardening, Observability, die Fehler tatsächlich sichtbar macht — erfordern Engineering.4 Eine europäische Telekom-Fallstudie, die in derselben Analyse veröffentlicht wurde, zeigte 4 Stunden bis zum ersten produktiven Agenten, aber 6 Monate und länger bis zum Multi-Market-Rollout mit einem führenden Visual Builder. Gartners Prognose für 2026, veröffentlicht Anfang dieses Jahres, lautet: 60 Prozent der 2026 gestarteten Enterprise-AI-Projekte werden aufgegeben, weil die Daten nicht AI-ready sind.5 Der Visual Builder korrigiert das nicht. Er versteckt das Problem hinter einem Drag-and-Drop-Interface, bis die Produktionsumgebung es aufdeckt. 

Das tiefere Problem ist die Diskrepanz im Vokabular. Ein Fachexperte in einer regulierten Branche — eine Rechtsberaterin, ein Financial Controller, eine Verfahrensingenieurin, ein Schadenssachbearbeiter, eine Compliance Officerin, ein Supply-Chain-Analyst — denkt nicht in Triggern und Verzweigungen und JSON-Schemata. Er oder sie denkt in Ergebnissen. „Finde mir alle Kundenverträge im DACH-Raum mit einer Force-Majeure-Klausel, bei denen der Lieferant in einer von einem bestimmten Ereignis betroffenen Region sitzt, und markiere diejenigen, bei denen die Force-Majeure-Erklärung des Lieferanten den vertraglichen Streitgegenstand nicht abdeckt." Das ist, was eine Rechtsberaterin fragt. Es gibt keine Version dieser Frage, die die Fachexpertin produktiv in ein Copilot-Studio-Canvas, einen n8n-Workflow-Graphen oder eine Agentforce-Topic-Konfiguration übersetzen kann, ohne dabei die Arbeit einer Integrationsarchitektin zu übernehmen. Genau die Arbeit, für die sie ihre IT-Abteilung angestellt hat. 

Der Visual Workflow Builder zwingt die Fachexpertin, das Vokabular der Architektur zu erlernen, um ihre Intent auszudrücken. Diese Übersetzungsarbeit ist der Punkt, an dem 60 Prozent der Projekte zum „nicht-technischen Agent-Building" auf dem Weg vom PoC zur Produktion kollabieren — und sie ist der strukturelle Grund, warum die Gartner-Abbruchsquote so hoch ausfällt. 

Was die Technologie der Plattform jetzt stattdessen erlaubt 

Der tiefere Punkt — derjenige, der entscheidet, ob die nächste Generation von Enterprise-AI-Plattformen aussieht wie die aktuelle Kategorie oder wie etwas strukturell Anderes — ist: Die zugrundeliegende Technologie ist über die Abstraktion, für die Visual Workflow Builder konzipiert wurden, hinausgewachsen. 

Das Visual-Workflow-Builder-Paradigma ist eine Abstraktion aus der 2010er Ära. Sie war sinnvoll, als KI ein schmales, teures, manchmal falsches Werkzeug war, das legitimerweise nur ein Schritt in einem handgezeichneten Ablauf sein konnte. Der Ablauf war die Intelligenz. Die KI war ein Knoten. 

Diese Annahme trifft nicht mehr zu, und 2026 ist das Jahr, in dem die Forschungsliteratur zur architektonischen Alternative konvergiert ist. Recursive Language Models (RLMs) sind, in der Sprache einer führenden Forschungsgruppe auf diesem Gebiet, zum „Paradigma des Jahres 2026" geworden.6 Die Struktur: Statt potenziell große Eingabedaten direkt in das Kontextfenster des Modells zu laden — und die gut dokumentierte „Context-Rot"-Degradation in Kauf zu nehmen, die damit einhergeht — nutzt das LLM eine persistente Python-REPL-artige Umgebung, um seine Daten zu inspizieren, zu transformieren und rekursiv Sub-LLMs als latente Operationen innerhalb seiner eigenen Reasoning-Schleife aufzurufen. Belastbare unabhängige Benchmarks zeigen zweistellige prozentuale Verbesserungen gegenüber direkten LLM-Aufrufen, Context Compaction, Retrieval-Tool-Use Agents und Code-Generation Agents bei den 10-Millionen-Token-Kontextskalen, in denen die wirklich interessanten Enterprise-Workloads operieren.7 Die jüngste akademische Arbeit zu RecursiveMAS, ROMA und THREAD (NAACL 2025) hat die Architektur als einheitliche rekursive Berechnung über heterogene Agenten formalisiert — nativ Multi-Hop-Reasoning, Latent-Thought-Generierung, Cross-Agent State Transfer.8 

Die strukturelle Eigenschaft von RLMs, die für die Workflow-Builder-Frage entscheidend ist, ist geradlinig: Das LLM kann eine Multi-Hop-Intent in die Teilschritte zerlegen, die der Workflow gemacht hätte — automatisch, rekursiv, mit vollständiger Kontextdisziplin, gegroundet gegen jede Wissensbasis, die die Plattform bereitstellt. Die Fachexpertin zeichnet den Ablauf nicht. Die Plattform baut den Ablauf zusammen. 

Die komplementäre Hälfte der Architektur ist der Teil, in dem die Workflow-Builder-Anbieter richtig liegen: Manche Workflows müssen tatsächlich deterministisch, vorhersagbar, auditierbar und wiederholbar sein. Regulierte Rechnungsverarbeitung, Financial Close, Compliance-Routing, Audit-Trail-Generierung, Regulatory Filing. Für diese ist das deterministische Orchestrierungsmodell das richtige — aber zusammengesetzt aus der natürlichen Intent der Fachexpertin und der Ontologie des Kunden, nicht handgezeichnet Schritt für Schritt auf einem Canvas. Die Wahl zwischen deterministischer Orchestrierung und agentischem Thread-Reasoning ist selbst eine Routing-Entscheidung, die der Orchestrator pro Aufgabe trifft — keine Tooling-Entscheidung, die die Fachexpertin im Voraus treffen muss. 

Der dritte Pfeiler der Architektur — und der Teil, der diesen Beitrag direkt an den vorigen anschließt — ist die Ontologie. RLMs sind ohne Wissenssubstrat, gegen das sie reasonen können, nur clevere Python-Schleifen über verrauschten Daten. Die Ontologie-Schicht ist es, die eine rekursive Reasoning-Schleife zu einem domänen-gegroundeten Agenten macht, der weiß, was ein Kundenvertrag ist, was eine Force-Majeure-Klausel ist, wie die Lieferantenhierarchie innerhalb dieses spezifischen Unternehmens aussieht, welche Regeln der regulierten Workflow tatsächlich hat.9 

Zusammengenommen: deterministische Orchestrierung plus agentische Threads mit RLMs plus eine automatisch generierte Ontologie, die das Reasoning gegen die eigenen Daten des Kunden groundet. Das ist die architektonische Alternative zum Visual Workflow Builder. Und es ist die Architektur, auf der der neuland.ai HUB als Plattform aufgebaut ist; der konkrete Aufbau ist im Abschnitt zu neuland.ai weiter unten in diesem Beitrag dokumentiert. 

Wie das konkrete Beispiel aussieht 

Der Kontrast wird am Beispiel der Rechtsberaterin klarer, mit dem ich eingestiegen bin. „Finde mir alle Kundenverträge im DACH-Raum mit einer Force-Majeure-Klausel, bei denen der Lieferant in einer von der aktuellen Disruption betroffenen Region sitzt, und markiere diejenigen, bei denen die Force-Majeure-Erklärung des Lieferanten den vertraglichen Streitgegenstand nicht abdeckt." 

Die Visual-Workflow-Builder-Version dieser Anfrage verlangt von der Fachexpertin — oder realistischer, von einer Integrationsingenieurin, die für die Fachexpertin nach einem Discovery-Call übersetzt — Folgendes: einen Konnektor zum Vertrags-Repository konfigurieren, einen Suchausdruck zur Filterung nach Region schreiben, entscheiden ob Vector Search, Keyword Search oder beides, einen Konnektor zum Lieferantensystem konfigurieren, die Lieferant-zu-Region-Join-Logik schreiben, den Dokumenten-Parser für die Erkennung von Force-Majeure-Klauseln konfigurieren, die Vergleichslogik zwischen Vertragsscope und Erklärungsscope schreiben, Error Handling für unvollständige Klauseln konfigurieren, das Output-Format konfigurieren, ein Test-Harness bauen, deployen. Die Rechtsberaterin wartet vier Monate und prüft ein Ergebnis. Wenn sich die Frage ändert — auch nur geringfügig — muss der Workflow substanziell neu gebaut werden. 

Die architektonische Alternative ist: Die Fachexpertin tippt den Satz, die Plattform routet ihn an den ontologisch gegroundeten Orchestrator, der Orchestrator zerlegt ihn in die Multi-Hop-Kette, die der Workflow gemacht hätte, RLM-getriebene agentische Threads erledigen die Suche, den Cross-Source-Join und das Vergleichs-Reasoning, deterministische Orchestrierung übernimmt Audit Trail und Zitation zurück zu den Quelldokumenten, und die Antwort liegt der Fachexpertin innerhalb desselben Gesprächs vor. Die nächste Frage wird auf dieselbe Weise gestellt. Der Workflow wurde nie gebaut — weil der Workflow nicht gebaut werden musste. Das System hat den Pfad zusammengesetzt. 

Das ist der Unterschied zwischen „Sie können Agenten bauen" und „Agenten sind eine Eigenschaft der Plattform". Ersteres ist ein Sales Pitch über Tooling. Letzteres ist ein architektonisches Commitment darüber, wer welche Arbeit macht. 

Wo neuland.ai steht 

Der neuland.ai HUB ist um exakt dieses Paradigma herum gebaut. Das folgende Architektur-Diagramm zeigt das Design im Überblick. 

 Abbildung: Plattform-Architektur des neuland.ai HUB — Enterprise AI Management & Orchestration Platform. Souveränes Deployment auf STACKIT mit den Optionen On-Premises, Private Cloud oder Hybrid. 

Der Orchestrator routet jede Aufgabe zur passenden Ontologie und zum passenden SLM pro Domäne oder Anwendung — deterministisch oder agentisch. Agentic Retrieval and Reasoning umfasst agentische Threads, Deep Agents, Multi-Hop Reasoning, RLMs, KAG (Knowledge-Augmented Generation), Query Planning und Semantic Re-Ranking. Die Native Surfaces — Chat, Agentic Assistants, Projects, Custom Apps — sind darauf ausgelegt, Intent auszudrücken, nicht darauf, Workflows zu architekturieren.10 

Darunter liegt eine automatisch generierte Ontologie-Schicht, die sowohl die Business-Logik auf Unternehmensebene als auch das Grounding pro Konnektor abdeckt; Governance und Compliance werden einheitlich über deterministische und agentische Ausführung angewendet; Observability und Logging spannen sich über die gesamte Surface; Petabyte-scale Ingestion Pipelines bilden das Fundament. Souveränes Deployment auf STACKIT, mit On-Premises-, Private-Cloud- und Hybrid-Optionen. Modellschicht agnostisch — Frontier proprietary, wo der Workload es erlaubt; selbst-gehostete SLMs für souveräne Workloads, feingetunt pro Domäne. 

Der Teil, den ich gegenüber der Leserschaft dieser Serie klar benennen möchte und den ich in den vorigen zehn Beiträgen im Interesse, nicht überzuversprechen, zurückhaltend gehalten habe, ist: Das Forschungs-Team hinter diesen Capabilities liefert. Das MVP der Recursive-Language-Model-Thread-Architektur, der Deep Agents, des Multi-Hop-Reasoning-Fabrics, der Agentic-Retrieval-Primitives — das sind keine Architektur-Folien. Das ist funktionierende Software, aktuell in rigoroser interner Testphase in unserer Forschungsumgebung, und schrittweise integriert in den HUB nach einem gestaffelten Release-Plan. Die Forschungsarbeit ist konsequent auf das ausgerichtet, was die akademische Literatur inzwischen als State of the Art beschreibt — RLMs, rekursive Multi-Agent-Systeme, Multi-Hop-Reasoning-Fabrics, Deep-Agent-Architekturen — und wird in eine Form gebracht, die dem Production-Deployment innerhalb regulierter DACH-Unternehmen standhält. Das Produktmanagement hat den finalen Call darüber, was aus der Forschungsumgebung in den HUB übergeht und unsere Kunden erreicht — gemessen am selben Operating Standard, an dem die gesamte Plattform gemessen wird: rigorose Evaluation gegen reale Kundenworkloads, vollständige DSGVO-Konformität, souveräne Deployment-Topologie, Audit-Trail-Disziplin und saubere Integration mit allem, was der HUB bereits leistet. 

Wir treiben das aus beiden Richtungen gleichzeitig voran. Die Forschungsseite bringt neue Capability in das MVP und stress-testet sie. Die Produktseite integriert, was die Tests übersteht, in den HUB, in der Release-Kadenz, die die Kundenengagements erfordern. Es ist keine glamouröse Arbeit, und die wichtigsten Teile davon — rigorose Evaluation, Kalibrierung gegen reale Kundenworkloads, Integrationsdisziplin — sind genau die Arbeit, die keine Schlagzeilen erzeugt, aber darüber entscheidet, ob eine Enterprise-AI-Plattform der Beschaffungs- und Betriebsprüfung standhält, die in den kommenden zwölf Monaten europäischen Enterprise-Einkaufs auf sie zukommt. 

Meine persönliche Einschätzung 

Der Visual Workflow Builder wird ein realer Teil des Enterprise-Stacks bleiben, und die großen Anbieter, die um ihn herum gebaut haben, werden weiterhin genuin nützliche Werkzeuge für die Workloads liefern, für die diese Werkzeuge tatsächlich geeignet sind. Nichts davon ist eine Prognose, dass Copilot Studio, Agentforce oder n8n verschwinden. Sie werden nicht verschwinden. Sie werden weiterhin die richtige Antwort für Workflows sein, die tatsächlich davon profitieren, von jemandem handgezeichnet zu werden, der sie handzeichnen kann. 

Was der Markt meines Erachtens noch nicht vollständig internalisiert hat, ist: Der Visual Workflow Builder ist zugleich eine strukturelle Obergrenze dafür, wer Enterprise AI tatsächlich nutzen kann. Das Drag-and-Drop-Interface wird als Demokratisierung des AI-Agent-Buildings verkauft. In der Praxis ist es eine zugänglichere Version der Rolle des Integrations-Entwicklers — und diese Rolle, so gut auch immer betoolt, ist nicht dieselbe Rolle wie die der Fachexpertin, die das Business-Problem besitzt. An dem Tag, an dem europäische Unternehmen begreifen, dass die architektonische Alternative darin besteht, dass die Plattform die Assembly aus der natürlichen Intent übernimmt, ändert sich die gesamte Frage, wer Enterprise AI nutzen kann. Sie ändert sich schneller als die Budget-Zyklen und schneller, als die großen Anbieter, die die vergangenen 18 Monate ihr Marketing rund um das Visual-Builder-Paradigma aufgebaut haben, sich umpositionieren können. 

Das Argument, das ich in dieser Serie seit dem ersten Beitrag im Februar mache, lautet: Der Wert im Enterprise AI liegt in der Schicht oberhalb des Modells. Das ist dasselbe Argument, noch einmal angewendet auf die Frage, wie die Schicht oberhalb des Modells genutzt wird. Der Visual Workflow Builder ist eine Antwort. Wir arbeiten — offen und nach einem bewussten Plan — an einer anderen. Und die Architektur liegt jetzt vor, sichtbar in diesem Beitrag, für jeden, der vergleichen möchte. 

Eine kurze Anmerkung zur regulatorischen Kulisse, da sie sich weiterhin entwickelt. Die Einigung zum EU Digital Omnibus vom 7. Mai 2026 hat die High-Risk-Verpflichtungen aus Annex III vom 2. August 2026 auf den 2. Dezember 2027 verschoben, und Annex I auf den 2. August 2028.11 GPAI-Enforcement-Befugnisse unter Chapter V bleiben auf dem ursprünglichen Datum, dem 2. August 2026. Die strategische Implikation ist unverändert gegenüber den vorigen Beiträgen dieser Serie: Die Architektur-Entscheidungen im Q3 2026 sind diejenigen, die entscheiden, ob Ihr AI-Stack die Beschaffungszyklen 2027 intakt übersteht. 

Man baut keine Workflows. Man formuliert Ergebnisse. Das ist die Architektur, auf die wir hinarbeiten, und das ist die Arbeit, die vor uns liegt. 

Anmerkungen und Quellen 

[1] Serien-Beiträge unter neuland.ai/insights. Vorige Beiträge behandeln: Control Panels und Execution Surfaces; Model Drift, Multi-LLM-Strategie und Observability; Modell-Topologie und Hyperscaler-Unabhängigkeit; Compliance als Systemeigenschaft; Agent Security und die Lethal Trifecta; MCP-Protokoll-Governance; die Fast-Follower-Workhorse-These; die neuen Enterprise-Daten-Silos durch SAP-/Microsoft-/ServiceNow-/Salesforce-AI-Gateways; Flexibilität als Architektur nach dem Fable-5-Rückruf, der Microsoft Build 2026 und dem europäischen Workhorse-Ökosystem; sowie die Ontologie-Konsolidierung nach SAP-/Microsoft-/Google-/Palantir-Announcements. 

[2] n8n-Produktpositionierung, sinngemäß wiedergegeben aus öffentlichen Materialien und unabhängig zusammengefasst in der No-Code-Plattform-Analyseliteratur: „AI as one step inside a predefined automation. The workflow defines the logic. AI is powerful, but it operates inside a predefined automation rather than acting as the decision-making layer." Siehe unabhängige Übersichten und Vergleichsanalysen der Low-Code-Agent-Builder-Kategorie, Januar 2026. 

[3] Die Vier-Primitive-Struktur der Low-Code-Agent-Builder — Trigger, Instruktionen (System Prompt), Tools, Deployment — ist das gemeinsame Interface über alle führenden Anbieter der Kategorie hinweg. Die Formulierung „Instruktionen als am wenigsten investierte Komponente" ist in der Praktikerliteratur breit belegt; siehe z. B. AIUnpacker, „Build Agentic AI Systems Without Coding in 2026", Januar 2026. 

[4] Nexus, „Top 10 Low-Code AI Agent Builders for Enterprise (2026)", Februar 2026. Der 40/60-Production-Deployment-Gap ist in mehreren unabhängigen Enterprise-Low-Code-Analysen quer durch Q1 und Q2 2026 wiederholt beschrieben. 

[5] Gartner AI Agent Projections, 2026: 60 Prozent der 2026 gestarteten Enterprise-AI-Projekte werden aufgrund nicht-AI-ready Daten aufgegeben. Bis 2028 wird agentische KI in rund vier von fünf Unternehmen global über Low-Code-Plattformen implementiert — mit erheblichen Unterschieden im Produktionspfad je nach Plattform. 

[6] Recursive Language Models (RLMs): siehe Prime Intellect, „Recursive Language Models: the paradigm of 2026", 2026, mit einer Beschreibung des RLM-Scaffolding-Musters, bei dem ein LLM ein persistentes Python-REPL nutzt, um Eingabedaten zu inspizieren, Kontext zu transformieren und Sub-LLMs rekursiv als latente Operationen innerhalb seiner eigenen Reasoning-Schleife aufzurufen. Das allgemeine Phänomen des „Context Rot" bei langen Eingaben ist dokumentiert in Hong, Troynikov und Huber, „Context rot: how context degradation affects LLM performance", Chroma Technical Report, Juli 2025. 

[7] Empirische Performance: RLMs gebenchmarkt gegen direkte LLM-Aufrufe, Context Compaction, Retrieval-Tool-Use Agents und Code-Generation Agents über Deep Research, Information Aggregation, Code-Repository-Understanding und synthetisches Pairwise Reasoning hinweg. Frontier-Closed-Modell (GPT-5) und Frontier-Open-Modell (Qwen3-Coder-480B) zeigen beide, dass RLM-Scaffolding Alternativen um zweistellige Prozentpunkte übertrifft — bei 10-Millionen-Token-Kontextgrößen mit substanziell weniger Degradation bei langen Kontexten. Siehe „Recursive Language Models", publizierte Evaluationen durch 2026. 

[8] RecursiveMAS (arXiv 2604.25917, April 2026); ROMA: Recursive Open Meta-Agent Framework (arXiv 2602.01848, 2026); THREAD: Thinking deeper with recursive spawning (Schroeder et al., NAACL 2025, ACL Anthology, doi 10.18653/v1/2025.naacl-long.427). Die konvergente Richtung dieser Literatur ist die Formalisierung rekursiver Multi-Agent-Systeme als einheitliche latent-space Berechnung über heterogene Agenten, mit Cross-Agent State Transfer und nativem Multi-Hop-Reasoning. 

[9] Für das zugrundeliegende Ontologie-Argument und seine Verbindung zur rekursiven Reasoning-Schleife siehe den vorigen Beitrag dieser Serie zum Ontologie-Rennen nach den Announcements von SAP Sapphire / Microsoft Build / Google Cloud Next / Palantir Foundry. 

[10] neuland.ai HUB Plattform-Architektur, wie im Diagramm oben dargestellt. Kernelemente: Orchestrator-Routing pro Ontologie und SLM pro Domäne / Anwendung (deterministisch oder agentisch); Agentic Retrieval and Reasoning (Agentic RAG, Recursive Language Models, Agentic Threads, Deep Agents, Multi-Hop Reasoning, KAG, Query Planning, Semantic Re-Ranking); Ontologie-Schicht (Company Ontology und Connector Ontologies, automatisch generiert, kontinuierlich aktualisiert, materialisiert als Knowledge Graph, Skills, Rules, Vector Index); Governance und Compliance (Roles and Rights, Guardrails, Audit Trail, EU AI Act / DORA / BaFin / DSGVO / BRAO, Explainability über AtMan und Aleph Alpha); Observability und Logging über sämtliche Konnektoren und agentische Prozesse; Petabyte-scale Ingestion Pipelines auf Kubernetes-GPU-Clustern; souveränes Deployment auf STACKIT mit On-Premises, Private Cloud und Hybrid-Optionen; modell-agnostisch (Frontier proprietary via Cloud API, wo der Workload es erlaubt; selbst-gehostete SLMs — Qwen, gpt-oss, DeepSeek, Mistral, Llama, Cohere, Pharia-1 mit AtMan von Aleph Alpha — für souveräne Workloads). Die neuland.ai AG übernimmt die inhaltliche und ergebnisbezogene Verantwortung für die saubere Umsetzung in allen Kundenengagements. 

[11] Politische Einigung zwischen Rat der EU und Europäischem Parlament zum Digital Omnibus on AI, 7. Mai 2026. Annex-III-High-Risk-Verpflichtungen verschoben vom 2. August 2026 auf den 2. Dezember 2027 (16 Monate Verschiebung); Annex-I-Verpflichtungen verschoben auf den 2. August 2028 (12 Monate Verschiebung); Artikel 50(2) Watermarking verschoben auf den 2. Dezember 2026. GPAI-Enforcement-Befugnisse unter Chapter V bleiben auf dem ursprünglichen Datum 2. August 2026.