Warum dynamische Planung der schwierige Mittelweg ist
Die Landschaft der KI-Agenten spaltete sich in zwei Lager auf, und beide wählten den einfachen Weg. Traditionelle Workflow-Engines — Dify, n8n, Coze — entschieden sich für statische Orchestrierung: visuelle Drag-and-Drop-Flussdiagramme mit festen Ausführungspfaden. Dies war keine Unwissenheit; Unternehmenskunden fordern Determinismus (gleiche Eingabe, stabile Ausgabe), und statische Graphen liefern das. Am anderen Extrem versprachen vollständig autonome Agenten (AutoGPT und seine Nachfolger) End-to-End-Autonomie, erwiesen sich aber als unpraktisch: unzuverlässige Aufgabenzerlegung, unkontrollierte Token-Kosten und Verhalten, das niemand vorhersagen oder debuggen konnte. Der Sweet Spot ist eng, aber real. Einfache Aufgaben benötigen keinen Planer. Aufgaben, die komplex genug sind, um Dutzende voneinander abhängiger Schritte zu erfordern, überfordern aktuelle LLMs. Aber dazwischen liegt eine reichhaltige Klasse von Problemen — Aufgaben mit klaren parallelen Teilaufgaben, die mühsam zu programmieren sind, aber für ein LLM praktikabel zu zerlegen. Dynamische DAG-Planung zielt genau auf diese Zone ab: Das Modell schlägt den Ausführungsgraphen zur Laufzeit vor, das Framework validiert die Struktur und führt sie mit maximaler Parallelität aus. Kein Drag-and-Drop, keine YOLO-Autonomie.Die Wette auf verbesserte Modelle
Alle paar Monate verschiebt sich die Grundlage — GPT-4, Function Calling, Claude 3, das MCP-Protokoll. Eine starre Abstraktion auf wechselndem Untergrund zu bauen ist riskant; LangChains Über-Abstraktion ist die Vorsichtsgeschichte, die jeder in diesem Bereich verinnerlicht hat. FIM One verfolgt den gegenteiligen Ansatz: minimale Abstraktion, maximale Erweiterbarkeit. Das Framework übernimmt Orchestrierung, Parallelität und Observability. Die Intelligenz kommt vom Modell, und das Modell wird immer besser. Heute liegt die Genauigkeit der LLM-Aufgabenzerlegung bei etwa 70-80% für nicht-triviale Ziele. Wenn das 90%+ erreicht, expandiert die „Sweet Spot” für dynamische Planung dramatisch — Probleme, die gestern zu komplex waren, werden morgen lösbar. FIM Ones DAG-Framework ist so konzipiert, dass es diesen wachsenden Wert erfasst, ohne die Infrastruktur umzuschreiben.Werden ReAct und DAG-Planung obsolet?
ReAct wird nicht verschwinden — es wird in das Modell einfließen. Betrachten Sie die Analogie: Sie schreiben TCP-Handshakes nicht von Hand, aber TCP ist nicht verschwunden; es wurde vom Betriebssystem absorbiert. Wenn Modelle stark genug sind, wird die Think-Act-Observe-Schleife zu implizitem Verhalten innerhalb des Modells, nicht zu explizitem Framework-Code. Dies geschieht bereits: Claude Code ist im Wesentlichen ein Agent, bei dem die Schleife vom Modell selbst angetrieben wird, nicht von einem externen Harness. Der bleibende Wert der DAG-Planung liegt nicht darin, “dummen Modellen bei der Aufgabenzerlegung zu helfen” — es ist gleichzeitige Planung. Selbst bei unendlich leistungsstarken Modellen erzwingt die Physik Latenz: eine serielle Kette von 10 LLM-Aufrufen dauert 10x länger als 3 parallele Wellen. DAG ist ein Engineeringproblem (wie man Dinge schnell und zuverlässig ausführt), kein Intelligenzproblem (wie man entscheidet, was ausgeführt werden soll). Wiederholungslogik, Kostenkontrolle, Timeout-Verwaltung, Observability — diese verschwinden nicht, wenn Modelle intelligenter werden. Das Endspiel: Modelle besitzen das “Was” (Planungsintelligenz wird in das Modell internalisiert), Frameworks besitzen das “Wie” (Nebenläufigkeit, Wiederholung, Überwachung, Kostenverwaltung). Der bleibende Wert eines Frameworks ist nicht Intelligenz — es ist Governance.Warum nicht Difys Workflow-Editor spiegeln
Eine natürliche Frage: Wenn DAG den flexiblen Fall abdeckt, sollten wir nicht auch einen statischen Workflow-Editor für den deterministischen Fall bauen? Nein. Die Begründung:- Die Workflows existieren bereits anderswo. Die festen Prozesse von Regierungs- und Unternehmenskunden leben in ihren OA-, ERP- und Legacy-Systemen. Sie wollen diese Flows nicht noch einmal auf einer weiteren Plattform neu aufbauen — sie wollen KI, die sich mit den Systemen verbinden kann, in denen diese Flows bereits laufen. Die Connector-Plattform (v0.6) löst dies direkt.
- Bestehende Funktionen setzen sich zu festen Pipelines zusammen. Geplante Jobs (v1.0) triggern einen DAG-Agenten mit einem festen Prompt; der DAG plant die Schritte dynamisch; Connectors (v0.6) verbinden sich mit den Zielsystemen. Die Kombination entspricht einer statischen Pipeline — ist aber flexibler, weil das LLM seinen Plan basierend auf den Daten, die es findet, anpassen kann. Keine separate Pipeline-DSL nötig.
- Investitionsmismatch. Ein produktionsreifer visueller Workflow-Editor (Canvas, Node-Typen, Variablenweitergabe, Debug/Replay) erfordert Monate dedizierter Arbeit. Das Ergebnis wäre eine minderwertige Kopie dessen, was Difys 120K-Star-Community bereits pflegt. Diese Arbeit ist besser in der Connector-Architektur investiert — einer Fähigkeit, die kein Konkurrent bietet.
Wo FIM One steht
FIM One ist kein „AGI-Task-Scheduler” und keine statische Workflow-Engine. Es nimmt die Mittellösung ein: Planungsfähigkeit mit Einschränkungen, Parallelität mit Observability.- Im Vergleich zu Dify: flexibler — DAG-Generierung zur Laufzeit statt Flowcharts zur Designzeit. Sie müssen nicht jeden Ausführungspfad im Voraus antizipieren. Konkurriert nicht bei der visuellen Workflow-Bearbeitung; konkurriert bei der Integration von Legacy-Systemen.
- Im Vergleich zu AutoGPT: kontrollierter — begrenzte Iterationen, Neuplanungslimits, mit Human-in-the-Loop auf der Roadmap. Autonomie innerhalb von Schutzvorrichtungen.
Wo FIM One sitzt: Planungs- x Ausführungsspektrum
Die KI-Ausführungslandschaft kann auf zwei Achsen abgebildet werden – wie Pläne erstellt werden (statisch vs. dynamisch) und wie sie ausgeführt werden (starr vs. adaptiv): Warum Dify/n8n statische Planung + statische Ausführung sind: Der DAG wird von einem Menschen zur Entwurfszeit auf einer visuellen Leinwand gezeichnet. Jeder Knoten führt eine feste Operation aus (ein LLM-Aufruf mit einem festen Prompt, eine HTTP-Anfrage, ein Codeblock). Es gibt keine Neuplanung zur Laufzeit – wenn ein Schritt fehlschlägt, schlägt der Workflow fehl oder folgt einem vorverkabelten Fehlerzweig. Dies ist strukturell dasselbe wie BPM, nur mit KI-Knoten im Graphen. FIM Ones Position: Dynamische Planung + Dynamische Ausführung- DAG-Topologie wird zur Laufzeit von LLM generiert (dynamische Planung) – kein Mensch entwirft den Graphen
- Jeder DAG-Knoten führt eine vollständige ReAct-Schleife aus (dynamische Ausführung) – Knoten denken nach, verwenden Tools und passen sich an
- Neuplanungsmechanismus (ausführen → analysieren → neu planen, falls nicht zufrieden)
- Aber begrenzt: max. 3 Neuplanungsrunden, Token-Budgets, Bestätigungsgates durch Menschen
Konzept-Glossar
Für Leser, die mit der in diesem Dokument verwendeten Terminologie nicht vertraut sind:| Begriff | Einzeilige Erklärung | Bezug zu FIM One |
|---|---|---|
| BPM (Business Process Management) | Prozesse vollständig zur Entwurfszeit festgelegt, starr ausgeführt. Camunda, Activiti. | FIM One ist kein BPM. Keine feste Process Engine. |
| FSM (Finite State Machine) | System befindet sich zu jedem Zeitpunkt in genau einem Zustand; Ereignisse lösen Übergänge aus. Unterstützt Schleifen (Ablehnung → Neueinreichung). | Zielsysteme (ERP, Vertragssysteme) verwenden FSM intern. FIM One benötigt keine eigene FSM — es ruft die API des Zielsystems auf. |
| ACM (Adaptive Case Management) | Skelett statisch, Verzweigungen dynamisch. Hauptfluss vordefiniert, jeder Knoten passt sich zur Laufzeit an. | FIM Ones DAG + ReAct fällt natürlich in diesen Quadranten. |
| HTN (Hierarchical Task Network) | Rekursive Aufgabenzerlegung: High-Level → Unteraufgaben → atomare Operationen. | DAG-Neuplanung deckt die meisten Szenarien ab; vollständiges HTN noch nicht erforderlich. |
| iPaaS (Integration Platform as a Service) | Cloud-Integrations-Plattform, die mehrere SaaS-/On-Prem-Systeme verbindet. MuleSoft, Zapier. | FIM Ones Hub Mode ist wie AI-natives iPaaS — natürliche Sprache treibt systemübergreifende Integration voran. |
Architektur-Grenze: FIM One repliziert keine Workflow-Logik
Komplexe Geschäftsprozesse (Genehmigungsketten, Übertragungen, Ablehnungen, Eskalationen, Mitzeichnung, Gegenzeichnung) sind die Verantwortung des Zielsystems. Diese Systeme haben Jahre damit verbracht, diese Logik zu entwickeln — ERP-, OA- und Vertragsmanagementsysteme verfügen alle über ausgefeilte State Machines. Aus der Perspektive des Konnektors:| Operation | Was der Konnektor tut |
|---|---|
| Übertragung | Eine API aufrufen, Zielperson übergeben |
| Ablehnung | Eine API aufrufen, Ablehnungsgrund übergeben |
| Eskalation | Eine API aufrufen, Eskalationspersonenliste übergeben |
| Mitzeichnung | Eine API aufrufen, Mitzeichnerliste übergeben |
- Wartungsaufwand erzeugen (zwei State Machines, die synchron gehalten werden müssen)
- Fehlermöglichkeiten hinzufügen (was wenn sie sich widersprechen?)
- Keinen zusätzlichen Wert bieten (das Zielsystem macht das bereits korrekt)