Workflows
Un workflow est une carte visuelle de ce que votre agent doit faire étape par étape — qui parle en premier, quoi demander, quand se ramifier, quand transférer l'appel et quand confier l'appel à un autre agent. Vous le construisez sur un canevas en déposant des nœuds et en les reliant.
Utilisez un workflow lorsqu'un seul prompt ne suffit pas — lorsque l'appel a des étapes claires (« d'abord qualifier, puis collecter les détails, puis soit réserver soit transférer »), lorsque vous avez besoin d'un routage déterministe basé sur les réponses de l'appelant (et non « l'IA fait généralement la bonne chose »), ou lorsqu'un agent doit confier une partie du travail à un spécialiste.
Un prompt est une longue instruction unique. L'agent le lit une fois et l'utilise pour tout l'appel. Un workflow est composé de nombreuses petites instructions, une par nœud, avec des transitions explicites entre elles. Le graphe pilote l'appel — l'agent sur chaque nœud ne gère que sa portion.
Si votre agent fonctionne déjà bien avec un prompt unique, vous n'avez pas besoin de workflow. Recourez aux workflows lorsque vous ne cessez d'ajouter des règles « si X alors Y » au prompt et qu'elles cessent de fonctionner de manière fiable.
L'éditeur
L'éditeur de workflow se trouve dans son propre onglet sur la page de l'agent. Vous voyez un canevas avec un nœud Start et un nœud End par défaut. Vous ajoutez des nœuds depuis la barre d'outils, les faites glisser sur le canevas et les câblez avec des arêtes.
Le panneau de droite change selon ce que vous sélectionnez :
- Cliquez sur un nœud — son panneau de paramètres s'ouvre (prompt, champs, variables de récupération, etc.).
- Cliquez sur une arête — ses paramètres de déclenchement s'ouvrent (L'IA décide / Condition / Toujours).
- Le panneau Variables (bouton de la barre d'outils) liste chaque variable que le workflow déclare ou utilise, avec un saut en un clic vers le nœud qui définit ou lit chacune d'elles.
Lancez un appel de test in-browser directement depuis l'éditeur — une luciole rayonnante suit la position en direct pour que vous puissiez voir exactement quel nœud est actif à chaque instant.
Annuler / Rétablir (v2.8) — l'éditeur conserve un historique de jusqu'à 20 étapes, ce qui vous permet de revenir sur un faux mouvement (ou de le rétablir) sans tout reconstruire. La suppression d'un nœud demande d'abord une confirmation (v2.8), pour que vous ne perdiez pas une étape sur un clic malencontreux.
Vous n'êtes pas obligé de partir d'un canevas vierge. Le point d'entrée « construire en tant que workflow » provisionne un workflow pour l'agent et vous dépose directement dans le constructeur — une seule action crée le workflow et ouvre l'éditeur, prêt à recevoir des nœuds.
Les workflows ont trois statuts :
- Brouillon — modifiable, pas encore en ligne. Utilisez l'appel de test pour l'essayer.
- Actif — en ligne pour les vrais appels. L'agent utilise ce workflow à partir de l'appel suivant.
- Modèle — un plan réutilisable, jamais directement lié à un agent. Vous pouvez l'instancier sur plusieurs agents.
Nœuds
Chaque nœud est une étape de la conversation. Différents types de nœuds font différentes choses — certains parlent, certains écoutent, certains routent, certains exécutent des outils.
Agent
Le nœud agent est le cœur d'une étape de workflow. Lorsque le graphe atteint un nœud agent, cet agent prend la parole et pilote la conversation jusqu'à ce que quelque chose déclenche une transition.
Vous configurez la persona et la tâche du nœud agent directement sur le canevas (l'onglet Prompt s'ouvre lorsque vous cliquez sur le nœud) — c'est le prompt pour cette portion de la conversation, pas pour tout l'appel. Vous pouvez également attacher des bases de connaissances et des outils par nœud.
Accueil — la phrase d'ouverture. Si c'est le nœud d'entrée (le premier arrêt après Start), c'est ce que l'appelant entend en premier.
Lorsqu'un graphe gouverne un appel, le prompt du nœud actif est superposé au prompt de base de l'agent (celui de l'onglet Model). Le graphe possède la personnalité et la tâche de chaque étape, tandis que les instructions de base de l'agent restent en place comme fondation.
Sous-agent
Un sous-agent est un assistant qui s'exécute en ligne — il prend le relais de la conversation pour une tâche ciblée, puis renvoie le résultat à celui qui l'a invoqué.
Les sous-agents sont parfaits lorsqu'une partie du travail est réutilisable ou semble distincte : « vérifier l'identité de l'appelant », « collecter une adresse de livraison », « qualifier un lead avec la méthode SPIN ». L'agent parent appelle le sous-agent, le sous-agent fait son travail et rapporte un résultat, le parent reprend là où il s'était arrêté.
Les nœuds sous-agent ont les mêmes onglets qu'un nœud agent (Prompt, Knowledge, Tools, Actions) — l'éditeur crée automatiquement pour vous un agent de support caché. Vous ne voyez pas cet agent caché dans votre liste d'agents principale, et il ne compte pas dans le plafond d'agents de votre plan.
Variable de retour — l'emplacement où stocker le résultat du sous-agent (par ex. identity_verified, lead_score).
Qui parle en premier
Par défaut, un sous-agent ouvre son tour en parlant — il salue ou pose sa première question dès qu'il prend le relais. Deux bascules changent cela :
- Attendre l'appelant (ne pas parler en premier) — le sous-agent reste silencieux à l'entrée et ne répond qu'une fois que l'appelant a dit quelque chose. Activez ceci lorsque le sous-agent est le premier arrêt de l'appel et que vous voulez que l'appelant commence (un vrai « Allô ? ») au lieu que l'agent ouvre — ou en cours d'appel, lorsque l'étape précédente a déjà tout dit et que le sous-agent doit simplement écouter la réponse.
- Étape silencieuse (ne pas parler) — le sous-agent ne parle jamais du tout. Il lit la conversation jusqu'ici, décide d'un résultat et rend directement le contrôle. Utilisez-le comme un routeur invisible : « lire ce que l'appelant a demandé et décider de quel service il s'agit » — aucun mot prononcé, juste une décision sur laquelle le graphe se ramifie.
Valeurs de résultat autorisées
Un sous-agent termine normalement avec la valeur qu'il a jugée appropriée. Si vous allez vous ramifier sur ce résultat avec des arêtes Condition, épinglez-le plutôt à une liste fermée de valeurs autorisées :
- Listez chaque valeur autorisée sous Valeurs de résultat autorisées (par ex.
sales,support,billing). - Le sous-agent doit terminer avec exactement une d'entre elles — il ne peut pas en inventer une nouvelle.
- Associez chaque valeur à une arête Condition (
le résultat est "sales"→ …) pour un routage propre et prévisible.
C'est la manière fiable de faire décider et router un sous-agent : le résultat est garanti de correspondre à l'une de vos branches.
Un sous-agent rend un résultat unique lorsqu'il a terminé. Câblez ce qui se passe ensuite avec des arêtes Condition ou Toujours sur ce résultat — la sortie d'un sous-agent n'utilise pas d'arêtes « L'IA décide ». C'est pourquoi Valeurs de résultat autorisées + arêtes Condition est le modèle recommandé pour un sous-agent de routage.
Message
Le nœud Message prononce une phrase fixe, sans tour d'IA, sans improvisation. Utilisez-le pour les transitions (« Un instant, je vous transfère… »), les avis de non-responsabilité légalement requis ou les confirmations préparées où la formulation importe.
Texte — ce qu'il faut prononcer. Prend en charge les tokens {{variable}} pour injecter des valeurs collectées, par ex. "Merci {{first_name}}, je vous ai réservé pour {{appointment_time}}."
Un nœud Message consomme le tour — l'agent n'ajoutera rien d'autre par-dessus.
Recueillir une saisie
Un nœud Recueillir une saisie pose une question et capture la réponse de l'appelant dans une variable.
Prompt — la question à poser. Prend en charge les {{tokens}}.
Variable — le nom de l'emplacement où stocker la réponse.
Silence maximal (v2.8) — un plafond par question sur la durée d'attente de la réponse de l'appelant avant de passer à la suite. Réglez-le par nœud Recueillir une saisie, pour qu'une question oui/non rapide puisse expirer plus tôt qu'une question demandant à l'appelant de lire un long numéro de compte.
Utilisez-le chaque fois que vous avez besoin d'une valeur spécifique avant de continuer — email, numéro de compte, taille du groupe, catégorie de problème. Le tour suivant de l'appelant devient la valeur ; vous pouvez vous ramifier dessus avec une arête Condition juste après.
Mettre à jour l'état
Un nœud Mettre à jour l'état écrit une ou plusieurs valeurs dans les variables du workflow sans parler ni demander. Utilisez-le pour préconfigurer des valeurs par défaut, marquer des indicateurs de progression ou préparer des valeurs calculées à partir d'étapes antérieures.
Variable / Valeur — une paire clé-valeur. Plus de variables (optionnel) — paires clé-valeur supplémentaires.
Les clés et les valeurs prennent en charge les {{tokens}}, ce qui vous permet de composer de nouvelles valeurs à partir de valeurs existantes.
Condition
Le nœud Condition est un nœud uniquement dédié au routage — il ne parle pas, ne demande rien, il envoie simplement l'appel vers la branche sortante qui correspond.
La condition elle-même vit sur chaque arête sortante, pas sur le nœud — voir Arêtes Condition ci-dessous.
Utilisez un nœud Condition lorsque vous voulez un point de « répartition » clair dans votre graphe : de nombreuses branches qui dépendent de la valeur d'une variable. Comparé au fait de placer des conditions sur les arêtes d'un nœud agent, un nœud Condition dédié rend la logique de routage visuellement évidente.
Outil
Le nœud Outil exécute l'un des outils connectés de l'agent en tant qu'étape du graphe — sans laisser à l'IA le moindre mot à dire sur l'opportunité de l'appeler. Utilisez-le lorsque vous voulez un fait, pas une conversation : « rechercher ce client », « vérifier le stock », « GET la météo actuelle ».
Vous pouvez soit :
- Choisir l'un des outils existants de l'agent (recherche de calendrier, recherche dans la base de connaissances, une action spécifique d'une intégration), soit
- Configurer un appel HTTP en ligne directement sur le nœud (URL, méthode, headers, paramètres, corps).
La réponse de l'outil devient disponible pour tous les nœuds en aval. Si la réponse est un objet JSON, chaque champ de premier niveau devient sa propre variable — ainsi une réponse comme {"is_known": true, "tier": "gold"} écrit à la fois is_known et tier pour que vous puissiez vous y ramifier.
Chaque champ texte du nœud Outil — URL, valeurs des headers, corps — prend en charge les {{tokens}}. Insérez une variable dans un chemin d'URL, un header ou un corps de requête sans écrire de code.
Si un appel d'outil échoue (erreur HTTP, timeout, réseau), le nœud journalise l'échec et le graphe continue — sans les données. Prévoyez vos conditions en aval pour gérer le cas « aucune valeur ».
Knowledge (RAG)
Le nœud Knowledge (RAG) est une variante d'Outil centrée sur la récupération dans une base de connaissances. Choisissez l'une des bases de connaissances de l'agent, écrivez une requête de recherche (avec des {{tokens}} si vous le souhaitez), et le nœud exécute la recherche en tant qu'étape du graphe.
Utilisez-le lorsque vous voulez que le workflow recherche quelque chose avant qu'un nœud Agent parle — par ex. récupérer la dernière commande du client pour que le nœud Agent suivant puisse la mentionner sans avoir à demander. Le contenu récupéré atterrit dans une variable que vous pouvez insérer dans les prompts et les messages.
Intégration
Le nœud Intégration est une variante ciblée d'Outil, pour les services externes connectés — Google Calendar, Outlook, HubSpot. Vous choisissez le fournisseur et l'action spécifique (par ex. check_availability, create_event), définissez les paramètres, et le nœud appelle l'intégration de manière déterministe.
Si l'intégration n'est pas connectée sur cet agent, le nœud passe sans rien faire — votre graphe continue. Vérifiez les conditions en aval pour le cas « non exécuté ».
Transfert téléphonique
Le nœud Transfert téléphonique transfère l'appel en mode chaud vers un numéro de téléphone externe. Après un transfert réussi, l'appel a quitté votre workflow — votre agent n'est plus en ligne.
Numéro — destination au format international avec un + en tête (par ex. +15551234567). Prend en charge les {{tokens}} pour que la destination puisse provenir d'une étape antérieure (par ex. la réponse à « à quel bureau devons-nous vous connecter ? »).
Si le transfert n'aboutit pas (numéro invalide, pas de réponse, connexion téléphonique non configurée), le graphe revient en arrière et l'agent actuel reste en ligne. La conversation continue normalement — l'agent peut s'excuser et essayer un autre chemin.
Terminer l'appel
Le nœud Terminer l'appel conclut — l'agent prononce le message d'adieu configuré, puis raccroche. Utilisez-le comme un point de terminaison propre pour les branches « tout est fait » ou pour la branche « désolé, nous ne pouvons pas vous aider » d'une Condition difficile à gérer.
Aucune configuration nécessaire au-delà du câblage d'une arête vers lui.
Réutiliser un workflow (Sous-workflow)
Un nœud Sous-workflow est réservé à l'intégration d'un autre workflow en tant que sous-graphe. Ce nœud est présent dans l'éditeur mais n'est pas encore entièrement câblé — le graphe le traverse sans rien faire. Ne comptez pas dessus pour des appels en production. Nous l'activerons une fois que nous aurons livré les sous-graphes réutilisables.
Arêtes (Connexions)
Vous câblez un nœud au suivant avec une arête. Le déclencheur de l'arête décide quand la transition se produit.
Il existe trois déclencheurs :
| Déclencheur | Qui décide | Quand il se produit |
|---|---|---|
| L'IA décide | L'IA | Lorsque la conversation en fait l'étape suivante naturelle. L'IA reçoit un « outil de transition » qu'elle peut appeler. |
| Condition | Le runtime | Lorsqu'une variable correspond à une règle que vous écrivez. Évaluée avant que l'IA réponde. |
| Toujours | Le runtime | Sans condition — dès que le nœud source a terminé. Aucune saisie de l'appelant, aucune IA impliquée. |
L'IA décide (piloté par l'intention)
Utilisez L'IA décide lorsque seule l'IA peut savoir quand basculer — « si l'appelant pose une question sur les tarifs, transférer à l'agent commercial », « si cela ressemble à une réclamation, exécuter le sous-agent d'excuses ».
Vous écrivez une courte description d'intention sur l'arête (par ex. « L'appelant pose une question sur les tarifs ou veut passer à une offre supérieure »). L'IA la voit comme un outil étiqueté avec cette intention et décide de l'appeler ou non en fonction de la conversation. Si plusieurs arêtes « L'IA décide » existent, l'IA en choisit au plus une par tour.
Condition (branchement déterministe)
Utilisez Condition lorsque vous voulez que le graphe — et non l'IA — décide en fonction d'un fait connu : « si lead_score is more than 7, envoyer au closer ; sinon, terminer l'appel poliment ».
Les conditions s'évaluent avant que l'IA réponde, elles l'emportent donc toujours sur l'IA à ce tour. L'IA ne peut pas outrepasser une condition qui correspond.
Vous pouvez construire une condition à partir de ces opérateurs :
| Opérateur | Signification | Exemple |
|---|---|---|
| is | correspondance exacte (insensible à la casse pour le texte) | intent is "billing" |
| is not | ne correspond pas | status is not "active" |
| contains | correspondance de sous-chaîne (insensible à la casse) | feedback contains "broken" |
| is more than | > numérique | lead_score is more than 7 |
| is less than | < numérique | wait_minutes is less than 5 |
Vous pouvez aussi combiner des clauses avec Toutes (chaque clause doit correspondre — ET) ou N'importe laquelle (au moins une doit correspondre — OU), et les imbriquer. Ainsi une règle comme « l'appelant est connu et son niveau est gold ou premium » devient :
All:
- is_known is true
- Any:
- tier is gold
- tier is premium
Si vous référencez une variable qui n'a pas encore été définie (par ex. l'IA ne l'a jamais collectée), les conditions sur celle-ci échouent toujours — elles ne génèrent pas d'erreur, elles ne correspondent simplement pas. Ainsi loyalty_tier is "gold" renvoie faux si loyalty_tier n'a jamais été défini. Concevez vos branches pour gérer cela — généralement avec une branche else (voir ci-dessous).
Branche else — quand aucune condition ne correspond
Si vous avez plusieurs arêtes Condition quittant un nœud et qu'aucune ne correspond, l'appel bascule vers l'arête non-Condition de plus basse priorité (Toujours, ou une arête « L'IA décide »). S'il n'y a aucun repli, l'IA reprend le contrôle et peut continuer librement.
Un modèle courant : plusieurs Conditions pour les chemins bien connus, plus une arête Toujours vers un fourre-tout (Message de quelque chose, puis Terminer l'appel, ou transfert).
Toujours (avancement automatique)
Utilisez Toujours lorsque l'étape suivante est inconditionnelle — aucune décision, aucune saisie de l'appelant. Deux usages naturels :
- Enchaîner des étapes : Message → Mettre à jour l'état → Message → Outil → Condition. Chaque étape se termine et l'arête Toujours passe immédiatement à la suivante.
- Avancer automatiquement après que l'agent a fini de parler : un nœud agent avec une arête sortante Toujours signifie « dès que l'IA arrête de parler, passer à la suite » — sans que l'appelant ait besoin de répondre. Utile pour les flux de type monologue, comme un agent présentateur qui délivre son propos puis passe à la section suivante.
Condition et Toujours (les déterministes) l'emportent toujours sur L'IA décide. Si une Condition correspond, les outils de transition de l'IA sont ignorés pour ce tour. C'est ce qui vous permet d'écrire des règles que l'IA ne peut pas contourner.
Ordre des branches
Lorsque plusieurs arêtes quittent le même nœud, l'éditeur vous permet de définir une priorité en faisant glisser les lignes vers le haut ou le bas. Les branches de plus basse priorité sont vérifiées en premier. Cela n'a d'importance que lorsque deux branches pourraient toutes deux se déclencher au même tour — généralement deux arêtes Condition avec des règles qui se chevauchent. La première branche correspondante l'emporte.
Transporter le contexte — combien le prochain agent se souvient
Chaque arête possède un paramètre Transporter le contexte qui contrôle la part de la transcription de la conversation que le nœud suivant voit :
- Transcription complète (par défaut) — le prochain agent voit tout ce qui a été dit jusqu'ici.
- Résumé uniquement — la plateforme résume la conversation précédente et remet un court résumé au prochain agent.
- Rien — le prochain agent démarre à zéro, sans transcription antérieure.
Utilisez Résumé uniquement lors du passage à un agent spécialiste qui n'a pas besoin de chaque mot — cela économise des tokens et garde le nouvel agent concentré. Utilisez Rien pour les branches où la persona du nouvel agent est censée être distincte (par ex. une enquête de satisfaction à la fin de l'appel).
Variables
Les variables sont la mémoire du workflow. La plupart des choses dans un workflow consistent soit à définir une variable, soit à en lire une.
Déclarer des variables
Le panneau Variables (bouton de la barre d'outils) affiche chaque variable du workflow avec les étapes qui la définissent ou la lisent. Cliquez sur une variable pour sauter vers un endroit qui la définit ; c'est le moyen le plus rapide de trouver où quelque chose se passe mal.
Vous pouvez déclarer une variable avec une valeur par défaut dans le panneau — utile pour les indicateurs comme escalated=false qui doivent exister dès le départ afin que vos conditions n'échouent jamais silencieusement sur « manquant ».
Variables d'appel intégrées
Quelques variables sont remplies pour vous tout au début de chaque appel — vous ne les déclarez ni ne les définissez, elles sont simplement là à lire :
| Variable | Ce qu'elle contient |
|---|---|
{{call_from}} | Le numéro de téléphone de l'appelant |
{{call_to}} | Le numéro qui a été composé (votre numéro) |
{{call_direction}} | inbound ou outbound |
Parce qu'elles existent dès le premier instant, vous pouvez vous y ramifier sur le tout premier nœud — par exemple, une Condition sur call_from pour accueillir un VIP connu par son nom, router par indicatif pays, ou envoyer les numéros inconnus vers un chemin de vérification avant que quoi que ce soit d'autre ne se produise.
Comment les variables sont définies
| Source | Exemple |
|---|---|
| Valeurs par défaut (déclarées dans le panneau Variables) | escalated = false défini avant le début de l'appel |
| Recueillir une saisie | La réponse orale de l'appelant est capturée dans la variable du nœud |
| Mettre à jour l'état | Vous écrivez une valeur (littérale ou composée à partir de {{tokens}}) directement |
| Résultat d'Outil / Intégration | La réponse entière est stockée sous le nom du nœud ; si la réponse est un objet JSON, chaque champ de premier niveau devient aussi sa propre variable |
| Retour de sous-agent | Ce avec quoi le sous-agent termine est stocké dans la variable de retour du nœud sous-agent |
Lire les variables — {{tokens}}
Partout où vous pouvez taper du texte sur un nœud — prompt d'agent, texte de Message, prompt de Recueillir, URL / corps / headers d'Outil, numéro de Transfert téléphonique, valeur de Mettre à jour l'état, valeurs de condition — vous pouvez insérer {{variable}} et elle sera substituée au runtime.
Les chemins pointés fonctionnent aussi pour les données imbriquées — par ex. si une réponse d'Outil était {"customer": {"name": "Anna", "tier": "gold"}}, vous pouvez lire {{customer.name}} ou {{customer.tier}}.
Si un token référence une variable qui n'existe pas, le texte littéral {{name}} est laissé en place (il n'est pas effacé). C'est intentionnel — cela rend les templates cassés faciles à repérer dans un appel de test, au lieu de les avaler silencieusement.
Modèles courants
Qualifier → Ramifier → Router
Start
└─ Agent (greeting + qualify)
└─ Gather input (intent)
└─ Condition: intent == "sales" → Agent (sales)
└─ Condition: intent == "support" → Subagent (triage)
└─ Always (catch-all) → Message "Let me connect you" → Phone transfer
Rechercher → Personnaliser
Start
└─ Tool (CRM lookup, writes is_known, name, tier)
└─ Condition: is_known == true → Agent (warm greeting with {{name}})
└─ Always (else) → Agent (cold greeting)
Assistant réutilisable (détour par sous-agent)
Agent (main conversation)
└─ AI decides: "Caller mentions an address" → Subagent (address collector)
└─ on finish: result = full_address
└─ Agent continues with {{full_address}}
Ce qui est verrouillé pendant un appel de workflow
Quelques valeurs par défaut changent lorsqu'un graphe gouverne l'appel :
- La langue est verrouillée sur celle qu'utilise le premier agent du workflow. L'IA ne peut pas changer de langue en cours d'appel. Cela empêche le modèle de dériver vers la mauvaise langue lors d'un tour bruité.
- Le prompt principal de l'agent est remplacé par le prompt du nœud actif. C'est la règle « le graphe possède la persona » — voir l'avertissement sous Agent.
- Le premier message provient de l'accueil du nœud d'entrée, et non du champ « Begin Message » principal de l'agent.
Sécurité anti-boucle — budget d'étapes
Chaque workflow a un nombre maximum de transitions par appel (par défaut 25). Chaque fois que le graphe passe à un nouveau nœud, le compteur diminue de un. Lorsqu'il atteint zéro, le workflow cesse de sauter entre les nœuds pour éviter les boucles incontrôlées.
Vous pouvez choisir un nœud de repli pour ce cas (généralement un Transfert téléphonique ou Terminer l'appel) — l'appel y est dérouté une fois le budget épuisé. Sinon, l'IA reprend le contrôle et le graphe se fige effectivement pour le reste de l'appel.
Vous n'avez que très rarement besoin d'y penser — c'est un filet de sécurité pour les graphes qui bouclent accidentellement. Si vous l'atteignez en usage normal, vous avez probablement un cycle quelque part.
Tests
Le bouton Appel de test dans l'éditeur ouvre un appel in-browser avec le brouillon de workflow actuel. Pendant l'appel, une luciole rayonnante se déplace entre les nœuds sur le canevas pour que vous puissiez voir exactement où en est l'appel. L'éditeur est verrouillé pendant un appel de test pour éviter que les modifications ne se désynchronisent avec l'état en direct.
Utilisez l'appel de test pour vérifier :
- Que vos conditions correspondent aux valeurs que vous attendez (regardez la luciole sauter par-dessus une branche que vous pensiez voir se déclencher).
- Que vos tokens se substituent correctement (écoutez un
{{name}}égaré si une valeur n'a pas encore été définie). - Que les échecs d'outils se dégradent gracieusement (votre chemin de repli se déclenche réellement).
Modes de défaillance à connaître
| Situation | Ce qui se passe |
|---|---|
| Échec d'un appel d'Outil / Intégration | Le graphe continue sans les données. Vos conditions en aval devraient gérer la variable manquante. |
| Échec d'un Transfert téléphonique (numéro invalide, pas de réponse, connexion téléphonique manquante) | Le graphe revient en arrière, l'agent actuel reste en ligne, et la conversation continue normalement. |
| Un sous-agent ne parvient pas à démarrer | Le détour est annulé, l'agent parent reste en ligne, et une courte phrase d'échec est prononcée. |
{{missing_variable}} dans le texte | Laissé littéral dans la sortie — facile à repérer lors des appels de test. |
| Nœud Sous-workflow | Passe actuellement sans rien faire. Ne comptez pas encore dessus. |
| Budget d'étapes épuisé | Déroute vers le nœud de repli s'il en existe un, sinon l'IA reprend le contrôle. |
Quand NE PAS utiliser de workflow
Les workflows sont puissants mais ils ne sont pas la bonne réponse pour chaque agent. Restez avec un prompt unique lorsque :
- La conversation est ouverte (« répondre aux questions de l'appelant sur nos produits »).
- Vous n'avez pas de logique de branchement bien nette — la plupart des décisions relèvent du jugement que l'IA gère bien.
- Vous écririez un nœud agent et un nœud Terminer l'appel — ce n'est qu'un prompt avec des étapes en plus.
Recourez à un workflow lorsque :
- Vous pouvez esquisser l'appel sous forme d'organigramme avec trois étapes distinctes ou plus.
- Vous avez besoin d'au moins une branche déterministe sur une variable (une Condition).
- Vous voulez réutiliser une portion de conversation sur plusieurs agents (un sous-agent).
- Vous entassez déjà des règles « si l'appelant dit X alors faire Y » dans un prompt et qu'elles ne sont pas fiables.