> ## 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.

# Philosophie de conception

> Décisions architecturales prises lors de la conception de l'exécution du DAG — ce que nous avons choisi de NE PAS construire, et pourquoi.

Le moteur d'exécution DAG de FIM One a été conçu avec une retenue délibérée. Plusieurs modèles courants dans les frameworks multi-agents ont été évalués et intentionnellement exclus. Cette page documente ces décisions et le raisonnement qui les sous-tend.

## Remise — Non nécessaire

**Motif** : Remise explicite de tâche entre agents, où un agent termine son travail et cède le contrôle au suivant.

**Raison de l'exclusion** : Les chaînes linéaires DAG couvrent déjà naturellement la remise de tâche séquentielle. Quand l'étape B dépend de l'étape A, l'exécuteur attend que A se termine, puis transmet le résultat d'A dans le contexte de B via le mécanisme de dépendance. C'est structurellement équivalent à une remise — mais sans nécessiter une couche d'abstraction séparée.

Ajouter un protocole de remise explicite dupliquerait ce que les dépendances d'étapes fournissent déjà, sans expressivité supplémentaire.

## Rétroaction — Non nécessaire

**Motif** : Les étapes en aval renvoyant les résultats aux étapes en amont pour une réévaluation (également appelée rétropropagation des résultats).

**Raison de l'exclusion** : La boucle de re-planification du PlanAnalyzer couvre déjà ce cas d'usage. Une fois que toutes les étapes sont terminées, l'analyseur évalue si l'objectif initial a été atteint. Si ce n'est pas le cas (et que la confiance est inférieure au seuil d'arrêt), il déclenche une re-planification complète avec le contexte des résultats de la ronde précédente — y compris ce qui s'est mal passé et ce qui a été appris.

Il s'agit d'une approche plus grossière mais plus robuste que la rétroaction par étape. La rétroaction par étape crée des boucles de rétroaction complexes qui sont difficiles à déboguer et peuvent entraîner des cycles infinis. La boucle de re-planification réalise le même effet correctif avec un modèle d'exécution plus propre : planifier, exécuter, évaluer, re-planifier si nécessaire.

## Équipes (Communication inter-agents) — Non nécessaire

**Modèle** : Plusieurs agents spécialisés communiquant entre eux pendant l'exécution, négociant la propriété des sous-tâches ou collaborant sur un état partagé.

**Pourquoi exclu** : Les chaînes de dépendances DAG sont suffisantes pour les tâches avec dépendances de données. Quand l'étape C a besoin des résultats à la fois de l'étape A et de l'étape B, les arêtes de dépendance expriment cela directement. L'étape C reçoit les sorties de A et B dans son contexte — aucun protocole de messagerie inter-agents requis.

Le modèle DAG est plus simple et plus prévisible que la communication agent-à-agent. Les agents n'ont pas besoin de négocier ; le planificateur détermine la structure d'exécution à l'avance, et l'exécuteur applique le flux de données par la résolution des dépendances. Cela évite la surcharge de coordination et la non-déterminisme que la messagerie multi-agents introduit.

## agent\_hint / role\_hint — Non nécessaire

**Modèle** : Un indice explicite indiquant à l'exécuteur quel type d'agent ou de persona devrait gérer chaque étape (par exemple, « utiliser l'agent chercheur » ou « utiliser l'agent codeur »).

**Pourquoi exclu** : La combinaison de trois champs existants fournit déjà des conseils suffisants :

* **`task`** — La description en langage naturel de ce que l'étape doit accomplir. Une tâche bien rédigée signale implicitement l'expertise requise.
* **`tool_hint`** — Suggère quels outils l'étape doit utiliser (par exemple, `web_search`, `python_exec`). Cela contraint l'approche d'exécution de manière plus précise qu'une étiquette de rôle vague.
* **`model_hint`** — Contrôle si l'étape utilise le modèle rapide ou le niveau de raisonnement, ce qui est la décision d'exécution la plus impactante.

L'ajout de `agent_hint` ou `role_hint` serait redondant avec ces trois champs et introduirait un autre axe de configuration que le LLM planificateur doit maîtriser. Maintenir la surface des indices réduite diminue les erreurs de planification.

## Orchestration Multi-Agent Profonde — Stratégiquement Différée

L'exclusion « Teams » ci-dessus est un argument d'ingénierie : les arêtes du DAG expriment déjà les dépendances de données. Cette section ajoute un argument **stratégique** : la tendance de l'industrie selon laquelle les capacités du modèle absorbent la complexité d'orchestration.

### Pourquoi les modèles absorbent la couche d'orchestration

Les hiérarchies multi-agents ont émergé comme une solution de contournement aux limitations des modèles — si un modèle ne pouvait pas gérer une tâche complexe, vous la décomposiez entre des agents spécialisés. Chaque génération de modèles de pointe érode cette justification :

| Capacité du modèle                                        | Ce qu'il remplace                                             |
| --------------------------------------------------------- | ------------------------------------------------------------- |
| Fenêtres de contexte en expansion (200K → 1M tokens)      | Division du contexte entre agents pour tenir dans les limites |
| Réflexion étendue / chaîne de pensée                      | Pipelines explicites d'agents Planificateur → Exécuteur       |
| Boucles natives d'agents (Claude Code, Codex)             | Exécution multi-étapes orchestrée par le framework            |
| Protocoles multi-agents natifs (Google A2A, OpenAI Swarm) | Coordination d'agents au niveau du framework                  |

### Le coût de la profondeur

Même lorsque les modèles manquent de capacités, les hiérarchies profondes d'agents entraînent des coûts composés :

* **Multiplication des tokens** — chaque niveau d'imbrication réinjecte les invites système et le contexte. À trois niveaux de profondeur, la dépense totale en tokens peut être 5 à 10 fois celle d'une approche à agent unique.
* **Accumulation de latence** — chaque niveau est un aller-retour LLM complet. Les utilisateurs attendent la chaîne la plus lente.
* **Compression lossy de l'information** — les agents délégués retournent des résumés, pas des données brutes. Chaque niveau perd en fidélité.
* **Opacité du débogage** — « quel niveau a mal compris la tâche ? » est presque impossible à diagnostiquer à une profondeur > 2.

### Position de FIM One

La délégation à un niveau via `CallAgentTool` est le juste équilibre : « Je suis un généraliste, mais cette sous-tâche nécessite l'expert SQL. » Cela couvre la grande majorité des besoins réels de délégation sans les coûts croissants des hiérarchies plus profondes.

L'orchestration multi-agent profonde est reportée indéfiniment — non pas parce qu'elle est difficile à construire, mais parce que la trajectoire des modèles de pointe suggère qu'elle deviendra inutile. La valeur de FIM One réside dans la **couche d'approvisionnement en outils** (Connecteurs, MCP, Gouvernance), et non dans la profondeur d'orchestration que les modèles internalisent rapidement.