Configuration de l'agent

Les onglets Initialisation et Paramètres de l'éditeur d'agent, ainsi que les paramètres par nœud dans Workflow d'agent, exposent tous les paramètres configurables. De la sélection du fournisseur IA à la gestion du silence et du contexte, chaque champ correspond directement à une propriété stockée sur l'agent.

Prompt système

Le prompt système est le jeu d'instructions principal envoyé au LLM au début de chaque appel. Il définit la personnalité, le rôle, le périmètre et les contraintes strictes de l'agent.

Vous êtes Sophie, une chargée de support client pour TechCorp.
Votre objectif est d'aider les appelants avec leurs questions de facturation et problèmes de compte.

Règles :
- Gardez les réponses en moins de 2 phrases. C'est un appel téléphonique, pas un chat.
- Ne révélez jamais les tarifs internes ou les informations sur les concurrents.
- Si vous ne pouvez pas résoudre le problème, dites : "Je vous transfère vers un spécialiste."
- Confirmez toujours le nom de l'appelant avant d'accéder à son compte.
- Répondez dans la même langue que l'appelant.

Le prompt système au niveau de l'agent s'applique au nœud Welcome lorsqu'il est en mode conversationnel. Chaque nœud Agent dans le flux possède son propre prompt système indépendant, celui au niveau agent n'est pas automatiquement hérité par les nœuds du flux.

Injection de variables : toute variable disponible au démarrage de l'appel peut être référencée avec la syntaxe {{nom_variable}}. Les variables définies via les en-têtes SIP ou les appels API d'initialisation sont disponibles dès le premier nœud.

Vous appelez {{customer_name}} au sujet de son abonnement {{product}}.
Son identifiant de compte est {{account_id}}.

Rédiger des prompts efficaces

• Personnalité en premier, nom, rôle, entreprise, ton (amical, professionnel, concis)
• Limites explicites, quels sujets sont hors périmètre, quoi dire quand on est bloqué
• Réponses courtes, les agents vocaux ne doivent jamais produire de listes ou de puces ; précisez-le
• Comportement de repli, quoi faire quand l'appelant pose une question hors périmètre
• Langue, si l'agent doit rester dans une seule langue, dites-le explicitement
• Pas de mise en forme, le TTS lit les astérisques et symboles littéralement ; utilisez uniquement de la prose simple

Messages statiques

Ces messages sont prononcés textuellement via TTS (non générés par le LLM). Ils supportent l'interpolation {{variable}}.

Reconnaissance vocale (STT)

Le moteur STT convertit l'audio de l'appelant en texte en temps réel. Choisissez le fournisseur et le modèle qui correspondent le mieux à votre langue et à vos exigences de latence.

Grand modèle de langage (LLM)

Le LLM génère les réponses de l'agent tour par tour. Tous les fournisseurs configurés par votre administrateur apparaissent dans la liste déroulante.

Modèle d'aiguillage des sorties

Lorsque la conversation doit passer à une autre étape, un modèle distinct et plus rapide peut prendre cette décision à la place du LLM principal, c'est ce qui alimente les routes de sortie conversationnelles sur les nœuds Welcome et Agent. Il s'exécute en parallèle du LLM principal, donc utiliser ici un modèle petit et rapide économise ~250 ms par tour. Laissez-le vide pour laisser le modèle principal décider. Les routes de sortie basées sur une règle n'utilisent jamais ce modèle : elles sont vérifiées de manière déterministe par le moteur de flux, sans aucun appel LLM, voir Types de nœuds → Routes de sortie basées sur des règles.

Synthèse vocale (TTS)

Le moteur TTS convertit les réponses textuelles du LLM en audio diffusé en temps réel vers l'appelant.

Règles d'expressivité (couche vocale)

La plateforme ajoute automatiquement un bloc de règles de sortie vocale à chaque prompt de nœud Agent, vous n'avez donc pas besoin d'écrire (ni de contrer) ces règles vous-même :

• L'emphase sur un seul mot avec des *astérisques* est autorisée et encouragée, ex : « La table est *disponible* demain ! ». Le mot entre astérisques doit faire partie de la phrase prononcée.
• [laughter] est la seule balise non verbale supportée. Les autres balises entre crochets ([smile], [sigh]…) sont lues à voix haute, ne les utilisez donc pas.
• Les étiquettes d'émotion isolées et les didascalies (ex : (joyeusement), [excité]) sont interdites, car le TTS les prononcerait littéralement.

Rédigez vos prompts en prose simple et laissez cette couche gérer la diction. Voir Rédaction des prompts pour des conseils de rédaction approfondis.

Comportement & timing

Ces paramètres contrôlent quand l'agent parle après un silence et comment l'appel se termine quand l'appelant arrête de répondre.

Variables d'initialisation

Les variables d'initialisation (input_variables) définissent quelles variables sont peuplées avant l'exécution de tout nœud. Elles sont déclarées dans l'onglet Initialisation de l'agent, où chaque variable choisit une source d'action de démarrage :

Ce n'est pas une source de démarrage : les variables collectées. Une variable dont la source est llm_collect n'est pas peuplée au démarrage de l'appel. C'est un concept distinct, une variable que vous déclarez pour que le LLM la recueille pendant l'appel : l'extracteur de variables parallèle, qui s'exécute aux côtés des tours des nœuds Agent, la renseigne au fur et à mesure que la conversation fait apparaître la valeur. Jusque-là, elle contient une valeur typée vide. Utilisez les sources d'initialisation ci-dessus pour les données que vous possédez avant la connexion de l'appel, et llm_collect pour les données que l'appelant fournit en parlant.

Bases de connaissances globales

Le champ global_knowledge_bases configure quelles bases de connaissances sont recherchées pour le contexte RAG sur tous les nœuds Agent qui n'ont pas leur propre configuration KB. La configuration KB au niveau du nœud a la priorité sur le paramètre au niveau de l'agent.

Configurez les bases de connaissances globales dans l'onglet Paramètres, section Base de connaissances. Voir Configuration RAG pour les détails sur les paramètres de récupération.

Paramètres sortants

Les paramètres sortants contrôlent le comportement de l'agent au début d'un appel sortant, la fenêtre entre le décrochage du destinataire et le premier énoncé de l'agent. Ils sont configurés sur le nœud Welcome dans l'éditeur de flux sous Paramètres sortants. Voir Types de nœuds → Welcome → Paramètres sortants pour la référence complète.

Actions de fin d'appel

Le champ end_flow_actions configure les appels webhook déclenchés après la fin de chaque appel (quelle qu'en soit la raison). Chaque action spécifie une URL, une méthode et un payload. Tous les placeholders {{variable}} sont résolus en utilisant l'état final des variables de l'appel avant l'envoi du webhook.

Cas d'usage courants : mises à jour CRM post-appel, journalisation de qualification de leads, archivage de transcription vers un système externe.

Save vs Make live

L'éditeur sépare l'enregistrement de la mise en live, afin que vous puissiez affiner un agent, même un agent live, sans perturber les appelants. Deux actions dans l'en-tête :

• Save, écrit l'état de l'éditeur comme nouvelle version nommée. Ne change jamais ce qu'entendent les appelants. Actif lorsqu'il y a des modifications non enregistrées.
• Make live, promeut la version enregistrée affichée dans l'éditeur vers la version live qu'entendent les appelants. Actif uniquement lorsque l'éditeur est propre et que la version affichée n'est pas déjà live.

Le flux sûr sur un agent en production : éditer → Save (l'ancienne version reste live, les appelants ne sont pas affectés) → tester la nouvelle version dans le simulateur navigateur → Make live quand vous êtes confiant. Il n'y a pas de bascule « mode brouillon » ; ce modèle à deux verbes l'a remplacée.