Pourquoi déterministe
Scrydon exécute les workflows comme un DAG fixe avec des agents appelés en tant que blocs typés — pas comme une boucle orchestrée par un LLM. La comparaison, le raisonnement et les implications pour les appels d'outils.
Scrydon se positionne comme une plateforme Données & IA pour l'entreprise, et non comme un framework à boucle agentique. L'exécution des workflows est un DAG déterministe ; les agents sont des blocs typés invoqués à l'intérieur de ce graphe ; les appels d'outils sont des API typées, pas un protocole de découverte MCP. Cette page explique le contraste et le raisonnement.
Deux formes d'« agentique »
Les plateformes d'agents modernes s'organisent autour de deux architectures :
- Boucle agentique (Crewai, Langgraph, runtimes pilotés par MCP) — le LLM est l'orchestrateur. À chaque étape, le modèle inspecte l'état, choisit le prochain outil, sélectionne les arguments, observe le résultat et décide à nouveau. Le runtime est une boucle
while (not done) { reason; act; }. Puissant pour l'exploration ; non déterministe par construction. - DAG déterministe avec agents à l'intérieur (Scrydon, et conceptuellement N8N / Node-Red / UiPath enrichis de LLM) — le graphe d'exécution est fixé à la conception. Le LLM est invoqué à l'intérieur d'un bloc Agent quand un travail de langage est nécessaire, mais il ne décide pas quel bloc s'exécute ensuite. Les blocs
ConditionetRouterélagent les branches en fonction d'entrées typées.
Des agents là où le langage est le goulot d'étranglement ; tout le reste reste déterministe.
Pourquoi le déterminisme d'abord pour l'entreprise
Les contraintes de l'entreprise — auditabilité, reproductibilité, gestion des changements, RBAC, preuves de conformité — tirent fortement vers le côté DAG :
- Reproductibilité. Le même payload de déclenchement sur la même version de workflow exécute les mêmes blocs dans le même ordre. Les exécutions s'expliquent par la seule trace ; les réviseurs n'ont pas à comprendre pourquoi le LLM a choisi un chemin différent le mardi.
- L'autorisation est une propriété du graphe, pas une négociation tour par tour. Les permissions de chaque bloc sont déclarées. Le point de décision de politique les évalue au démarrage du workflow et émet un droit d'exécution éphémère — le runtime ne fait jamais confiance aux décisions d'identité prises par le modèle en cours d'exécution.
- Les modes de défaillance sont locaux. Un bloc défaillant arrête un sous-graphe connu. Il n'existe pas de mode de défaillance « l'agent a dévié et appelé 14 outils » à trier.
- Le coût est prévisible. Les blocs déclarent leur usage LLM ; vous estimez le coût d'un workflow avant de l'exécuter. Les agents pilotés par boucle font dépendre le coût de la profondeur de raisonnement du modèle, qui évolue de semaine en semaine.
- La preuve de conformité, c'est la trace. Les contrôles ISO 42001 / EU AI Act / SOC 2 se mappent sur « ce qui a été exécuté, qui l'a déclenché, quelles données il a touchées ». Une exécution de DAG produit cette preuve par construction.
Le compromis : moins d'exploration ouverte. Scrydon n'est pas le bon outil pour « donnez un objectif à l'agent et regardez ce qui se passe ». C'est le bon outil pour « intégrer l'IA dans un processus que mon auditeur valide ».
Pour un point de vue externe sur les difficultés des boucles d'agents de style MCP dans les systèmes d'entreprise de niveau production, consultez l'article de Perplexity Why Perplexity is stepping back from the Model Context Protocol internally.
Les outils sont des API typées, pas des serveurs MCP
Conséquence de la posture déterministe : quand un bloc Agent doit effectuer un appel externe, il appelle un outil typé déclaré par une intégration vendor installée. Il n'y a pas de serveur MCP au milieu, pas de découverte d'outils à l'exécution, pas de réécriture de schéma pilotée par le modèle. Les entrées et sorties d'outils sont des schémas Zod figés à la construction ; la plateforme valide les deux extrémités.
Ce que cela vous apporte :
- Analyse statique. L'ensemble des outils qu'un workflow peut appeler est énumérable depuis sa définition. Les outils de révision peuvent le lister ; la politique peut le contraindre.
- Pas de dérive de schéma d'outil. Le catalogue d'outils que le modèle voit à l'inférence est le même que celui contre lequel la plateforme valide. Vous ne pouvez pas obtenir de désaccord à l'exécution entre ce que le LLM attendait et ce que l'intégration accepte.
- Autorisation par outil. Les listes d'autorisation, les portées de capacité et l'enrobage DLP s'attachent à l'outil typé, pas à une négociation de protocole au niveau du transport.
Si vous souhaitez un agent d'exploration ouverte pour une sous-tâche spécifique, construisez-le comme une Automation (Automations) — un agent unique avec une liste d'outils contrainte et un contrat entrée/sortie clair. Le DAG extérieur reste déterministe ; la boucle agentique est une feuille, pas la racine.
Voir aussi
- Architecture → Agentic — le moteur de workflow et le modèle de runtime.
- Intégrations → Capacités — comment la surface de capacités typées est déclarée.
- Sécurité → Autorisation — droits d'exécution et point de décision de politique.
- Automations — tâches mono-agent, le bon endroit pour un comportement en boucle.