Design-Philosophie

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

FIM Ones DAG-Ausführungsmodul wurde mit bewusster Zurückhaltung entworfen. Mehrere Muster, die in Multi-Agent-Frameworks häufig vorkommen, wurden evaluiert und absichtlich ausgeschlossen. Diese Seite dokumentiert diese Entscheidungen und die Begründung dahinter.

​

Handoff — Nicht erforderlich

Muster: Explizite Aufgabenübergabe zwischen Agenten, bei der ein Agent seine Arbeit abschließt und die Kontrolle an den nächsten Agent übergibt. Grund für Ausschluss: DAG-lineare Ketten decken sequenzielle Aufgabenübergaben bereits auf natürliche Weise ab. Wenn Schritt B von Schritt A abhängt, wartet der Executor auf den Abschluss von A und übergibt dann das Ergebnis von A über den Abhängigkeitsmechanismus in den Kontext von B. Dies ist strukturell gleichwertig mit einer Übergabe – erfordert aber keine separate Abstraktionsebene. Das Hinzufügen eines expliziten Handoff-Protokolls würde duplizieren, was Schrittabhängigkeiten bereits bieten, ohne zusätzliche Ausdruckskraft zu bringen.

​

Rückfluss — Nicht erforderlich

Muster: Nachgelagerte Schritte geben Ergebnisse an vorgelagerte Schritte zurück zur Neubewertung (auch Backpropagation von Ergebnissen genannt). Warum ausgeschlossen: Die PlanAnalyzer-Neuplanungsschleife deckt diesen Anwendungsfall bereits ab. Nach Abschluss aller Schritte bewertet der Analyzer, ob das ursprüngliche Ziel erreicht wurde. Falls nicht (und das Vertrauen unter dem Stoppwert liegt), wird eine vollständige Neuplanung mit Kontext aus den Ergebnissen der vorherigen Runde ausgelöst – einschließlich dessen, was schief gelaufen ist und was gelernt wurde. Dies ist ein grobkörnigerer, aber robusterer Ansatz als Rückfluss pro Schritt. Rückfluss pro Schritt erzeugt komplexe Rückkopplungsschleifen, die schwer zu debuggen sind und zu Endlosschleifen führen können. Die Neuplanungsschleife erreicht denselben Korrektureffekt mit einem saubereren Ausführungsmodell: Planen, Ausführen, Bewerten, bei Bedarf neu planen.

​

Teams (Agent-Kommunikation) — Nicht erforderlich

Muster: Mehrere spezialisierte Agenten kommunizieren während der Ausführung miteinander, verhandeln über die Übernahme von Teilaufgaben oder arbeiten an gemeinsamen Zuständen zusammen. Warum ausgeschlossen: DAG-Abhängigketten sind für Aufgaben mit Datenabhängigkeiten ausreichend. Wenn Schritt C Ergebnisse sowohl von Schritt A als auch von Schritt B benötigt, drücken die Abhängigkanten dies direkt aus. Schritt C erhält die Ausgaben von A und B in seinem Kontext — kein Agent-zu-Agent-Messaging-Protokoll erforderlich. Das DAG-Modell ist einfacher und vorhersehbarer als die Agent-zu-Agent-Kommunikation. Agenten müssen nicht verhandeln; der Planer bestimmt die Ausführungsstruktur im Voraus, und der Executor erzwingt den Datenfluss durch Abhängigkeitsauflösung. Dies vermeidet den Koordinationsaufwand und die Nicht-Determinismus, die Multi-Agent-Messaging mit sich bringt.

​

agent_hint / role_hint — Nicht erforderlich

Muster: Ein expliziter Hinweis, der dem Executor mitteilt, welcher Typ von Agent oder Persona jeden Schritt handhaben sollte (z. B. „verwenden Sie den Recherche-Agent” oder „verwenden Sie den Coding-Agent”). Warum ausgeschlossen: Die Kombination von drei bereits vorhandenen Feldern bietet bereits ausreichende Orientierung:

• task — Die natürlichsprachliche Beschreibung dessen, was der Schritt erreichen soll. Eine gut geschriebene Aufgabe signalisiert implizit die erforderliche Expertise.
• tool_hint — Schlägt vor, welche Werkzeuge der Schritt verwenden sollte (z. B. web_search, python_exec). Dies beschränkt den Ausführungsansatz präziser als ein vages Rollen-Label.
• model_hint — Steuert, ob der Schritt das schnelle oder das Reasoning-Modell-Tier verwendet, was die wirkungsvollste Ausführungsentscheidung ist.

Das Hinzufügen von agent_hint oder role_hint würde redundant mit diesen drei Feldern sein und würde eine weitere Konfigurationsachse einführen, die der Planer-LLM richtig verstehen muss. Eine kleine Hinweis-Oberfläche reduziert Planungsfehler.

​

Deep Multi-Agent Orchestration — Strategically Deferred

The “Teams” exclusion above is an engineering argument: DAG edges already express data dependencies. This section adds a strategic argument: the industry trend of model capability absorbing orchestration complexity.

​

Warum Modelle die Orchestrierungsschicht aufzehren

Multi-Agent-Hierarchien entstanden als Workaround für Modellbeschränkungen — wenn ein Modell eine komplexe Aufgabe nicht bewältigen konnte, wurde sie auf spezialisierte Agenten verteilt. Jede Generation von Frontier-Modellen untergräbt diese Begründung:

​

Die Kosten der Tiefe

Auch wenn Modelle über begrenzte Fähigkeiten verfügen, tragen tiefe Agent-Hierarchien kumulative Kosten mit sich:

• Token-Vervielfachung — jede Verschachtelungsebene injiziert Systemprompts und Kontext erneut. Drei Ebenen tief kann der Gesamttoken-Verbrauch 5-10x höher sein als bei einem Single-Agent-Ansatz.
• Latenz-Stapelung — jede Ebene ist ein vollständiger LLM-Roundtrip. Benutzer warten auf die langsamste Kette.
• Informationsverlust durch Kompression — delegierte Agenten geben Zusammenfassungen zurück, keine Rohdaten. Jede Ebene verliert an Genauigkeit.
• Debug-Undurchsichtigkeit — “welche Ebene hat die Aufgabe missverstanden?” ist bei einer Tiefe > 2 fast unmöglich zu diagnostizieren.

​

FIM One’s Position

One-level delegation via CallAgentTool is the sweet spot: “I’m a generalist, but this sub-task needs the SQL expert.” This covers the vast majority of real-world delegation needs without the compounding costs of deeper hierarchies. Deep multi-agent orchestration is deferred indefinitely — not because it’s hard to build, but because frontier model trajectory suggests it will become unnecessary. FIM One’s value lies in the tool supply layer (Connectoren, MCP, Governance), not in orchestration depth that models are rapidly internalizing.