L'architecture d'ActionFlows
Un ActionFlow est un graphe orienté. Il est validé avant son exécution, exécuté sous forme de tâche et ouvert depuis l'application, l'API ou le SDK.

Graphiques, validation et exécutions
ActionFlows est avant tout un système de flux de travail. L'interface utilisateur est un canevas. Derrière celui-ci se trouvent un graphe orienté, un processus de validation, un moteur d'exécution qui exécute les opérations sous forme de tâches, ainsi que plusieurs interfaces produit qui partagent ce noyau.
Voici un aperçu de la manière dont ces éléments s'articulent entre eux. Il ne s'agit pas d'une simple liste de noms de classes internes.
Le graphique est la source de vérité
Un ActionFlow est un graphe orienté composé de nœuds et d'arêtes. Les nœuds contiennent les paramètres de configuration des modèles, des outils ou des commandes. Les arêtes définissent le flux de données. L'éditeur, le validateur et l'environnement d'exécution perçoivent tous la même structure ; par conséquent, ce qui s'affiche sur le canevas correspond exactement à ce qui sera exécuté.
Validation avant exécution
Avant le lancement d'une exécution, le graphe est validé. Les entrées manquantes, les arêtes rompues et les formes incompatibles entraînent un échec précoce. Cette approche est moins coûteuse qu'un échec silencieux survenu à mi-parcours d'une tâche, et elle permet de comprendre les causes des échecs.
Fonctionne comme une tâche de première classe
Une exécution correspond à une application du graphe. Elle enregistre la progression et les résultats, ce qui vous permet de comparer les tentatives et de corriger un nœud spécifique. Sans exécutions, le canevas n'est qu'un schéma. Avec les exécutions, il devient un système opérationnel.
Registre des prestataires
L'accès aux modèles et aux intégrations s'effectue via un registre partagé plutôt que par le biais de chemins d'accès aux fournisseurs codés en dur. L'interface interroge le registre pour connaître les éléments disponibles, puis achemine les tâches. De nouveaux modèles et outils peuvent ainsi apparaître sans modifier le modèle de graphe lui-même.
Un noyau, plusieurs portes
L'environnement de test, les modèles, l'API REST, le SDK et les contrôles d'organisation reposent tous sur le même noyau de workflow. Un collaborateur peut déclencher un flux conçu visuellement par quelqu'un d'autre. Le modèle mental reste le même : composer un chemin, l'exécuter, inspecter le résultat.
Organisations et crédits
Le travail s'inscrit au sein des organisations afin que les équipes puissent distinguer les projets et gérer les droits d'accès. Les crédits permettent de visualiser l'utilisation d'une exécution à l'autre. L'architecture désigne ici à la fois le graphe et les limites définissant qui est autorisé à l'exécuter.
Ce sur quoi nous nous concentrons
- Un graphique que vous pouvez montrer du doigt.
- Validation avant le début de la tâche.
- Des sessions que vous pourrez ouvrir plus tard.
- Les prestataires que vous pouvez changer.
- Le même noyau à la base de l'éditeur, de l'API et du SDK.
Newsletter
Recevoir les mises à jour produit
Nouveaux nœuds, agents et notes produit. Nous n'envoyons un e-mail que lorsqu'il vaut la peine de l'ouvrir.