Scalabilité
La plateforme est conçue pour que chaque déploiement soit plus rapide que le précédent. Les workflows, les composants et les agents sont des éléments modulaires que n'importe quelle équipe ou région peut réutiliser : la couverture se cumule et contribue à atteindre plus vite la superintelligence.
Réserver une démoComposants de workflow réutilisables
Une logique partagée peut être packagée dans un composant réutilisable, puis importée dans plusieurs workflows : le déploiement suivant démarre ainsi à partir d'éléments déjà utilisés par les précédents. Les mises à jour d'un composant se répercutent instantanément sur tous les agents, ce qui permet de faire évoluer considérablement les déploiements à travers les régions et les fonctions.
- Vérification d'identitéUtilisé dans 14 workflowsPrompt
- Garde-fousUtilisé dans 22 workflowsPrompt
- Recherche TMSUtilisé dans 9 workflowsNœud
- Envoyer un SMSUtilisé dans 17 workflowsNœud
- Planifier une visite techniqueUtilisé dans 6 workflowsWorkflow
- Recherche d'adresseUtilisé dans 12 workflowsNœud
Appel de suivi transporteur
- Garde-fousVersion 6
- Vérification d'identitéVersion 8
- Recherche TMSVersion 3
Workflows imbriqués
Un workflow en appelle un autre et exploite sa réponse : un processus de cent étapes s'exécute donc sous la forme de quelques workflows enfants plutôt que d'un bloc monolithique. Chaque workflow enfant est détenu, testé et versionné par l'équipe la plus proche, ce qui permet aux processus de grande ampleur de continuer à évoluer sans retest complet à chaque fois.
Environnements de développement
Le développement, l'environnement de tests et la production disposent chacun de leur propre version active, de leurs identifiants et de leurs points de terminaison. Plusieurs équipes peuvent construire et valider en même temps sans attendre une fenêtre de livraison ni toucher au processus que vos clients utilisent en ce moment même : le nombre de personnes pouvant livrer simultanément n'est donc pas limité par le risque pour le trafic en production.
Version 14
Brouillon
Version 13
En test
Version 12
En direct
- Identifiants
- Clé TMS de production
- Endpoint
- /checks
- Déployé
- 26 sept., 11:02
- Exécutions aujourd'hui
- 2 140
Contrôle d'accès basé sur les rôles
Les rôles Owner, Editor et Viewer déterminent qui peut modifier un workflow, publier en production ou consulter les données sous-jacentes. Une nouvelle équipe peut commencer à construire sans faire transiter chaque modification par un propriétaire central unique, et sans pouvoir toucher aux éléments dont elle n'est pas responsable : ajouter des créateurs ne revient donc pas à ajouter du risque.
- Modifier le workflow
- Publier en production
- Lire les données d'exécution
- Gérer les membres
- Renouveler les identifiants
Orchestration des agents
Les workflows peuvent être construits avec un agent orchestrateur capable de trier et d'aiguiller vers des sous-agents, chacun avec son propre prompt, ses outils et ses connaissances, en reprenant la main pour re-trier à tout moment, ce qui permet à l'opération de couvrir plus de terrain sans qu'aucun agent ne devienne plus difficile à tester.
- 01Routé vers l'agent PlanificationVisite reportée à jeudi 08:00
- 02Contrôle rendu à l'orchestrateurDeuxième demande détectée
- 03Routé vers l'agent Facturation via MCPQuestion de facture transférée
Questions fréquentes
Un agent doté de nombreux outils fonctionne jusqu'à ce que les instructions propres à différentes situations entrent en concurrence. Le découpage en agents spécialisés, chacun avec son propre prompt, ses outils et ses connaissances, les garde tous ciblés et testables, avec un orchestrateur qui effectue le tri entre eux. Les transferts peuvent aussi traverser les canaux : un agent vocal peut passer une conversation à un agent textuel, et des agents externes peuvent être connectés via MCP.
Un composant de workflow est importé : la séquence fait partie intégrante du workflow qui l'utilise. Un workflow appelé est invoqué : il s'exécute comme une exécution enfant distincte, renvoie une réponse, et le parent poursuit. Importez lorsque vous voulez une logique intégrée et partagée ; appelez lorsque vous voulez que l'enfant s'exécute, soit supervisé et versionné indépendamment.
C'est le comportement par défaut : mettez à jour un prompt, un nœud ou un composant de workflow partagé à un seul endroit et chaque agent qui l'utilise reflète le changement, sans avoir à traquer les instances une à une. Lorsqu'un workflow ne doit pas évoluer avant que vous ne soyez prêt, un workflow appelé peut être épinglé à une version et à un environnement précis, afin que le parent reste sur la version avec laquelle il a été testé.
Oui. Chaque workflow enfant dispose de ses propres délais d'expiration et de sa propre gestion des erreurs : une défaillance est donc contenue plutôt que propagée en cascade. Chaque exécution enfant est observable séparément et peut être annulée en toute sécurité, ce qui signifie que vous pouvez identifier précisément l'exécution imbriquée en échec et la restaurer sans dérouler le processus parent qui l'entoure.
La couche partagée se situe au niveau de l'espace de travail : même bibliothèque de composants, mêmes indicateurs phares, afin que chaque région parte d'un standard unique. Chaque région conserve ensuite ses propres versions de workflow, ses environnements et ses identifiants, pour que les règles et intégrations locales puissent différer sans que les déploiements divergent les uns des autres.
