Skip to main content

​
Graph Engineering (2026) und FIM One

Diskussionen in der Industrie beschreiben oft einen Shift von Loop Engineering (ein einzelner Agent denkt und handelt wiederholt) zu Graph Engineering (Multi-Node-Topologien als explizites Engineering-Objekt). Das Label ist neu; die Praxis nicht. LangGraph-ähnliche Systeme und Multi-Agent-Organisationen nutzen seit Jahren Graphen. Für FIM One ist entscheidend, welche Art von Graph gemeint ist und wie diese auf unsere drei Execution Layers abgebildet wird.

​
Was Graphengineering normalerweise bedeutet

Konsens über diese Darstellung: Graph ersetzt Loop nicht. Graph-Designs Beziehungen zwischen Prozessen; jeder agentic Node kann immer noch einen vollständigen Loop ausführen. “Graph” ist in der Praxis überladen. Drei Verwendungen vermischen sich: Diese Seite behandelt die ersten beiden (Orchestrierung).

​
Nicht „Dify Workflow mit neuem Namen”

Dify-ähnliche visuelle Workflows und Graph Engineering teilen eine gemeinsame Herkunft (explizite Topologie), sind aber nicht dasselbe Produkt. Kurzform: Klassischer Workflow ist eine deterministische (oder semi-deterministische) Leitung mit gelegentlichen LLM-Schritten. Graph Engineering ist Multi-Knoten-Systemtopologie, wo kritische Positionen immer noch autonome Agenten sein können.

​
Wie die Industriekarte auf FIM One sitzt

FIM One umfasst bereits das gesamte Kontrollspektrum; Chat-„Planner-Modus” ist nur ein Ausschnitt.

​
Graph Engineering vs. FIM One DAG (Chat Planner)

Gleiche Familie (explizite Multi-Step-Topologie). Unterschiedliche Arten. Implikation: Industrielle Aufmerksamkeit für Graph Engineering validiert die Beibehaltung einer Graph-/Scheduling-Engine. Sie erfordert nicht einen Chat-Standard, der Benutzer zwingt, für jeden Durchgang „Planner” zu wählen. Die meisten Aufgaben wünschen sich eine starke Schleife; Graphen rechtfertigen ihren Einsatz bei parallelen Branches, festen Compliance-Pfaden und Multi-Rollen-Orchestrierung.

​
Was FIM One lernen kann (ReAct, DAG, Workflow empowern)

Konkrete Erkenntnisse, keine Slogans. Geordnet nach Hebelwirkung. Anti-Muster, die beim „Graph machen” zu vermeiden sind:
  • Verwendung eines Abhängigkeitsgraphen zur Simulation einer menschlichen Zustandsmaschine (mehrstufiges „auf Antworten warten” ohne Wait-Primitiv).
  • Gleichsetzung von ReAct update_plan (Checklisten-Speicher) mit Graph-Engineering (Topologie-Planung).
  • Versand von Graph-Wärme als zweite Chat-Persönlichkeit statt als Engine-Komposition (Loop außen, Schedule innen bei Bedarf).
  • Beschreibung von FIM One DAG-Schritten als „flache LLM-Aufrufe”: das unterschätzt die Engine und führt zu fehlgeleiteten Produktentscheidungen.

​
Fünf Arten von „Planning” in der KI-Tooling-Landschaft

Das Wort „Planning” ist überbelastet. Es gibt heute mindestens fünf unterschiedliche Ansätze, die verschiedene Probleme lösen: Die ersten beiden sind Design-Zeit-Planning — sie erzeugen einen Plan, bevor die Arbeit beginnt, und ein Mensch (oder das Modell selbst) folgt ihm Schritt für Schritt. Die letzten drei führen Runtime-Planning ein — Ausführungsgraphen werden programmgesteuert generiert und geplant, wobei unabhängige Branches parallel laufen. Der Unterschied liegt darin, wer ausführt: Claude Code Teams startet autonome Agenten; FIM One DAG verteilt Schritte innerhalb eines einzelnen Orchestrators. Diese Ansätze sind keine Konkurrenten; sie sind komplementäre Schichten. Eine Kiro-ähnliche Spezifikation kann definieren, was gebaut werden soll, während ein FIM One DAG wie die Unteraufgaben parallel ausgeführt werden, planen kann. Claude Code’s Plan Mode stellt sicher, dass ein Mensch dem Ansatz zustimmt; FIM One’s PlanAnalyzer überprüft das Ergebnis automatisch.

​
Three-Layer Nesting: The Full-Power Architecture

Sowohl Claude Code Teams als auch FIM One DAG zeigen in ihrer vollen Kapazität eine dreischichtige verschachtelte Architektur:
  • Layer 1 — Human gate: Der Benutzer überprüft den Plan und genehmigt ihn vor Beginn der Ausführung.
  • Layer 2 — DAG orchestration: Der genehmigte Plan wird in Aufgaben mit Abhängigkeitskanten zerlegt. Unabhängige Aufgaben laufen parallel; nachgelagerte Aufgaben warten darauf, dass ihre Blocker aufgelöst werden.
  • Layer 3 — ReAct inner loop: Jede Aufgabe wird von einem Agenten ausgeführt, der einen vollständigen ReAct-Zyklus durchläuft (Perceive → Reason → Act → Observe), mit Fähigkeit zu mehrstufigem Reasoning, Tool-Nutzung und autonomem Retry.
Der Schlüsselgedanke: Claude Code Teams und FIM One DAG implementieren die gleichen drei Schichten, nur mit unterschiedlichen Layer-2-Mechaniken — Message-Passing vs. Dependency-Edge-Auflösung.

​
Full-Power Runtime: FIM One vs Claude Code Teams

Both are genuine Agents — the core loop is identical: Perceive → Reason → Act → Feedback. The difference lies in how they orchestrate parallel work at full capacity.

​
Real-World Benchmark: v0.5 RAG System

Claude Code Teams built FIM One’s entire v0.5 RAG subsystem in a single session:
  • 8 phases: Embedding → Reranker → Loaders → Chunking → VectorStore → Retrieval → KB Backend → Frontend + Docs
  • 46 tests passing, frontend build clean
  • Wall time: ~5 minutes
  • Token cost: ~100k tokens per agent task × 8+ tasks ≈ 800k+ total tokens
  • Dependency edges: Phase 5 depends on Phase 4 + 1b; Phase 6 depends on Phase 5 + 2 + 3 — a genuine DAG
This demonstrates the core trade-off: time parallelism at the cost of token multiplication. Claude Code Teams trades compute dollars for developer hours.

​
Konvergenz, nicht Konkurrenz

Die Grenze zwischen „Team-Zusammenarbeit” und „Pipeline-Planung” verschwimmt:
  • Claude Code Teams’ blockedBy/blocks IST ein DAG — Tasks haben explizite Abhängigkeitskanten, und der Leader verteilt neu freigegebene Tasks, wenn Vorgänger abgeschlossen sind. Dies ist topologische Planung mit zusätzlichen Schritten (Nachrichten).
  • FIM One DAG-Schritte sind bereits vollständige ReAct-Agenten — Layer 3 ist nicht aspirativ. Jeder Schritt führt agent.run() mit Tools und Multi-Iterations-Schleifen aus; Unterschiede zu einem ReAct-Chat-Turn auf oberster Ebene sind absichtlich (kein Plan-Board pro Schritt, kein Chat-Level ask_user_question-Wait, Modell gewählt durch model_hint / allgemeinen Standard).
Fazit: Gleiche Agent-Essenz, konvergierende parallele Philosophien. Claude Code folgt einem Team-Zusammenarbeits-Modell — ein Leader delegiert an Worker, die sich über Nachrichten verständigen. FIM One folgt einem Pipeline-Planungs-Modell — ein DAG Executor verteilt ReAct-Schritte basierend auf Abhängigkeitsauflösung. In der Praxis implementieren beide abhängigkeitsgesteuerte parallele Ausführung; der Unterschied liegt im Koordinations-Overhead (Nachrichten vs Kanten), Isolation (Peer-Agenten vs Task + Abhängigkeitsergebnisse) und Token-Ökonomie. Die Produktlücke ist weniger „mache Knoten zu Agenten” und mehr wann man einen Graph plant vs in einer Chat-Schleife bleibt, plus Human-Wait-Kanten, wo der Graph nicht pausieren kann.

​
Structured Output Degradation

All structured LLM call sites in the DAG pipeline (Planner, Analyzer, Tool Selection) use a unified structured_llm_call() utility that implements a 3-level degradation chain: Each text-based level retries once with a reformat prompt before falling to the next. The result is a StructuredCallResult containing the parsed value, which extraction level succeeded, and accumulated token usage. This design means the same prompt works reliably across GPT-4 (native FC), Claude (JSON mode), and local models (plain text), with consistent error handling and retry logic in one place instead of scattered across four call sites.

​
Three Execution Layers: Control Spectrum

Die fünf Planungsansätze oben beschreiben die Landschaft. Innerhalb von FIM One selbst bieten drei Ausführungsebenen ein Kontrollspektrum von vollständiger menschlicher Kontrolle bis zur vollständigen KI-Autonomie. Im Verhältnis zur Graph-Engineering: Workflow ist das Design-Zeit-Graph-Produkt; DAGPlanner ist ein Laufzeit-Task-Graph; ReAct ist Loop-Engineering (mit optionalem Plan-Board-Speicher, kein Schedule-Graph). Das Designprinzip: Geben Sie Benutzern genau so viel Kontrolle, wie sie möchten.
  • Müssen Sie nachweisen, dass jede Kreditgenehmigung fünf spezifische Schritte durchläuft? → Workflow.
  • Müssen Sie drei Themen parallel recherchieren und dann synthetisieren? → DAG.
  • Müssen Sie während der Ausführung entwerfen, verfeinern oder strukturierte Fragen stellen? → ReAct.
  • Unsicher? → execution_mode: "auto" klassifiziert die Abfrage und leitet zur Laufzeit zu DAG oder ReAct weiter (bevorzugt ReAct, wenn das Ziel hauptsächlich Klärung oder kurze Exploration ist).
Diese Schichtung ist das, was FIM One von Single-Paradigma-Tools unterscheidet:
  • Dify betont die Workflow-Ebene (statische oder semi-statische visuelle Graphen).
  • LangGraph betont eine Code-Level-Kontrollfluss-Graph-DSL (benutzer-definierte Topologie, dynamisches Routing, Checkpointing). Strukturell verwandt mit visuellen Workflows, ausgedrückt als Software.
  • Manus-Klasse-Agenten betonen die Agent/Loop-Ebene (autonome Ausführung, wenig benutzerdefinierte Struktur).
FIM One deckt alle drei Ebenen ab, plus automatisches Routing zwischen Chat-Engines. Die Progression benutzerdefinierter Graph → LLM-generierter Task-Graph → kein Schedule-Graph entspricht einer breiteren Brancheneinsicht: Mit verbesserten Modellen wird explizite Topologie für die meisten Durchläufe optional, nicht obligatorisch. Graph-Engineering-Hitze ist ein Grund, in Engines und Komposition zu investieren, nicht um jeden Chat durch einen Planner zu zwingen.

​
Verwandte Dokumentation