Skip to main content

Rédigez vos étiquettes comme des descriptions d’outils

Les étiquettes des connexions deviennent littéralement des descriptions d’outils pour le LLM : rédigez-les comme des conditions vues du point de vue de l’appelant :
  • caller confirms they are an existing customer
  • caller wants to cancel or reschedule
  • yes, path A, continue
Veillez à ce que les étiquettes d’un même niveau soient mutuellement exclusives et couvrent les cas réalistes. Si deux étiquettes se chevauchent, le routage revient à un tirage à pile ou face.

Gardez des agents petits et centrés sur une seule tâche

Un agent = une mission (qualifier, répondre aux questions de facturation, réserver). Des instructions courtes et ciblées par agent sont plus efficaces qu’un méga-agent avec un mur de texte. Les transferts ne coûtent rien : n’hésitez pas à en abuser.

Validez les données avec des nœuds de collecte, pas avec des prompts

Les e-mails et numéros de téléphone transcrits depuis la voix sont bruités. Les nœuds collect confirment et valident les informations (« C’était bien m-e-y-e-r ? ») et ne poursuivent qu’en cas de succès. Donnez toujours un nom clair à la variable (callback_phone, et non var1) : ces noms apparaissent tels quels dans les webhooks et le détail des appels.

Concevez les chemins d’échec

  • Donnez à chaque nœud collect une connexion failed qui mène quelque part de sensé (un transfert vers un humain ou un au revoir poli).
  • Définissez volontairement le fallback d’un transfert à chaud : continue pour les transferts optionnels, cold_transfer quand l’appelant doit absolument joindre quelqu’un.
  • Terminez chaque branche par un nœud end avec une formule de clôture adaptée.

Testez avec des appels web, observez les événements

Lancez des appels de test depuis le navigateur après chaque modification. Dans la vue détaillée de l’appel, le journal des événements affiche les transitions entre nœuds, les appels d’outils, les résultats de collecte et les résultats de transfert : lisez-le comme une pile d’appels lorsque le flow se comporte mal.

Utilisez des outils asynchrones au-delà de ~2 secondes

Un appel d’outil synchrone gèle la conversation. Marquez les webhooks lents en async et configurez des phrases d’attente : l’assistant reste réactif pendant que la requête s’exécute. Voir le nœud outil.

Commencez par le prompt, passez au flow quand c’est nécessaire

Prototypez d’abord le comportement avec un simple prompt système. Quand l’appel se structure en phases distinctes ou nécessite une capture de données garantie, transposez cette structure dans un flow : les nœuds d’agent dont les instructions sont vides héritent du prompt système, si bien que la migration se fait progressivement.