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. ![Agent Initialization settings](/docs/agent-config-dark.gif) 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}}`. ChampQuand il est joué `silence_message`Prononcé quand l'appelant est silencieux plus longtemps que `take_turn_after_silence` secondes. Valeur par défaut dans l'interface : *"Allo ??"*. Laissez vide pour désactiver entièrement la détection du silence. `transfer_message`Message par défaut prononcé par un nœud Transfer avant le déclenchement du transfert. Peut être personnalisé nœud par nœud. `goodbye_message`Message par défaut prononcé par un nœud Hangup avant la déconnexion. Peut être personnalisé nœud par nœud. Le message d'accueil est configuré sur le **nœud Welcome** dans l'éditeur de flux (champ : `message`), et non comme paramètre global de l'agent. Cela permet d'avoir des messages d'accueil distincts pour les flux entrants et sortants sur le même agent. 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. ParamètreDéfautDescription `stt_provider`Premier fournisseur actifLe service STT. Prérempli à la création avec le premier fournisseur STT actif de votre organisation. Les fournisseurs disponibles sont configurés par les administrateurs de la plateforme ; les utilisateurs clients choisissent depuis la liste déroulante configurée pour leur organisation. Les différents fournisseurs supportent des langues et des formats audio différents. `stt_language``fr`Code de langue BCP-47 (ex : `fr`, `en`, `en-US`, `es`). Sélectionne le modèle acoustique et le vocabulaire. `stt_model`-Variante de modèle spécifique au fournisseur. Laissez vide pour utiliser le modèle par défaut du fournisseur pour la langue choisie. `stt_keywords``[]`Termes spécifiques au domaine pour améliorer la précision de reconnaissance, ajoutés un par un comme étiquettes dans le champ de mots-clés de l'éditeur (tapez un terme, appuyez sur Entrée). Utile pour les noms de produits, codes ou jargon technique, ex : `SIMLOCK`, `IMEI`, `4G+`, `fibre`. Un nœud Agent peut ajouter ses propres mots-clés au niveau du nœud, qui fusionnent avec cette liste par défaut via le mode **Ajouter aux mots-clés du workflow** (un sélecteur permet de passer à **Remplacer les mots-clés du workflow**), voir [Types de nœuds → Agent](https://www.manivox.ai/docs/agents/nodes#subagent). Le réglage de la fin d'énoncé se fait au **niveau du fournisseur** (par les administrateurs), pas sur l'agent. Le contrôle principal est le **seuil EOU** (`eou_ms`), le nombre de millisecondes de silence que le moteur STT attend avant de déclarer que l'appelant a fini de parler. Selon le fournisseur, les administrateurs peuvent disposer de réglages d'endpointing supplémentaires à ajuster, permettant d'arbitrer entre réactivité et risque de couper l'appelant en milieu de phrase. 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. ParamètreDéfautDescription `llm_provider`-Le backend LLM. Choisissez dans la liste de modèles validés par la plateforme (compatibilité testée, tool calls inclus), ou branchez votre propre endpoint compatible OpenAI avec votre propre clé API. `llm_model`-Identifiant de modèle transmis au fournisseur (ex : `gpt-4o`), sélectionné dans la liste de modèles validés ou parmi ceux proposés par votre propre endpoint. `temperature``0.7`Température d'échantillonnage (0–2). Plus basse = plus déterministe, plus haute = plus créative. Pour les agents support, 0.3–0.5 réduit les hallucinations. Pour la vente, 0.7–0.9 sonne plus naturel. `max_tokens``500`Tokens maximum par réponse. Gardez entre 150–300 pour la voix, les appelants ne peuvent pas interrompre une réponse de 500 tokens. `disable_thinking``false`Pour les modèles qui supportent la chaîne de pensée / tokens de réflexion : définissez `true` pour ignorer l'étape de raisonnement et réduire la latence de 100–300 ms. Recommandé pour les flux transactionnels simples. `reasoning_effort`AutomatiqueModifie l'effort de raisonnement envoyé à votre modèle : `none`, `minimal`, `low`, `medium`, `high`, ou `xhigh`. Laissez sur *Automatique* sauf si vous connaissez précisément votre endpoint, une valeur non supportée peut provoquer une erreur ou désactiver silencieusement les appels d'outils. `disable_thinking` et `reasoning_effort` n'apparaissent dans l'éditeur que pour les **fournisseurs LLM personnalisés (configurés par le client)**. Les fournisseurs de la liste de modèles validés par la plateforme sont déjà réglés par Manivox, ces contrôles restent donc masqués pour eux. Pour la **liste des modèles validés** (Google, OpenAI, Groq) et comment brancher votre propre fournisseur avec votre clé API, voir [Modèles compatibles & clé personnelle (BYOK)](https://www.manivox.ai/docs/integrations/llm-models). ### 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](https://www.manivox.ai/docs/agents/nodes#rule-based-exits). ParamètreDescription `clf_llm_provider`Fournisseur pour les tâches de classification. Par défaut le fournisseur LLM principal si non défini. `clf_llm_model`Un modèle plus léger/rapide pour la classification que le LLM principal. Synthèse vocale (TTS) --------------------- Le moteur TTS convertit les réponses textuelles du LLM en audio diffusé en temps réel vers l'appelant. ParamètreDéfautDescription `tts_provider`-Le service TTS. Les fournisseurs disponibles dépendent de la configuration de l'administrateur. `tts_model`-Variante de modèle proposée par le fournisseur. Les différents modèles offrent un compromis qualité / latence (ex : `sonic-2` pour Cartesia). `tts_voice`-Identifiant de voix depuis la bibliothèque du fournisseur. Parcourez et préécoutez les voix via le sélecteur de voix dans **Initialisation → Synthèse vocale → Voix**, ou choisissez une voix propre à un nœud dans son onglet **TTS** (nœuds Welcome/Agent). `tts_speed``1.0`Multiplicateur de vitesse de restitution (0.6–1.5, la plage supportée par Cartesia). Réduisez à 0.85 pour la clarté avec les appelants âgés ; augmentez à 1.15 pour les scripts sortants denses. **Si une voix précédemment sélectionnée disparaît de la bibliothèque**, l'éditeur conserve la voix assignée (`tts_voice`) sélectionnée et affiche un avertissement ambre *« retirée — à réassigner »* au lieu d'un sélecteur vide trompeur, afin que vous puissiez choisir un remplacement sans perdre la trace de ce qui était configuré. Pour Cartesia, la bibliothèque de voix cloud fait foi pour les noms de voix : les déploiements on-prem reflètent les noms du cloud, et les voix retirées sont supprimées en douceur (soft-delete) plutôt qu'effacées. ### 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](https://www.manivox.ai/docs/agents/prompt-guidelines) 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. ParamètreDéfautDescription `take_turn_after_silence``7 s`Secondes de silence continu (après la fin de la parole de l'agent) avant que l'agent prononce le `silence_message`. Le minuteur de silence ne démarre qu'après la fin de lecture du dernier audio de l'agent. Réduisez (2–3 s) pour les flux sortants automatisés, augmentez (8–10 s) pour les appelants humains qui réfléchissent. `max_silence_repetitions``3`Nombre de fois que le `silence_message` est prononcé avant de terminer l'appel. Après la dernière répétition, l'appel raccroche avec la raison `silence_timeout`. `spelling_patience``false`Lorsque `true`, le seuil EOU est augmenté pour permettre des pauses plus longues entre les caractères épelés. Activez pour les flux où les appelants épellent des adresses e-mail ou des codes de référence lettre par lettre. `recording_enabled``true`Enregistre l'audio de l'appel. Les enregistrements sont stockés côté serveur en fichiers WAV et accessibles via `GET /api/calls/{id}/recording`. 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** : SourceLibellé dans l'éditeurDescription `http`HTTP RequestRécupérée depuis un endpoint HTTP externe au démarrage de l'appel, avant l'exécution du nœud de départ. Supporte `{{variable}}` dans l'URL et les en-têtes. Si la requête échoue avec `stopOnError: true`, l'appel se termine avec un message d'erreur configuré avant le démarrage du flux. `connector`Connector ActionExécute une action de connecteur (Composio) au démarrage de l'appel et mappe les champs de son résultat sur vos variables. Voir [Connecteurs](https://www.manivox.ai/docs/integrations/composio) pour configurer l'intégration. `sip_header`SIP Header*Bientôt disponible.* Extraira une variable depuis un en-tête SIP de l'appel entrant (métadonnées injectées par l'opérateur). `csv_input`CSV InputPeuplée depuis les données CSV par contact quand l'appel est passé par une campagne sortante. Les campagnes sortantes arrivent prochainement ; une fois disponible, le mapping de colonnes de la campagne déterminera les colonnes disponibles. Voir [Campagnes](https://www.manivox.ai/docs/calls/campaigns). `demo_prospect` *(intégrée)*Demo prospectVisible uniquement par les super-administrateurs (et en mode usurpation d'une organisation). Injecte des données de prospect de démonstration fournies par la plateforme et les mappe sur vos variables. Données de prospect injectées par la plateforme ; aucune URL ni aucun identifiant requis. Les actions de démarrage s'exécutent avant le démarrage du flux. Les actions HTTP et connecteur s'exécutent séquentiellement ; si l'une échoue avec `stopOnError: true`, l'appel se termine immédiatement, utile pour se prémunir contre des données client obligatoires manquantes. **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](https://www.manivox.ai/docs/knowledge-bases/rag-configuration) 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](https://www.manivox.ai/docs/agents/nodes#outbound-config) 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. Le mode brouillon n'est pas nécessaire car la facturation est par canal : les appels de test dans le navigateur sont toujours économiques (pas de téléphonie), et un agent sans version live ne peut tout simplement pas être appelé. Voir [Versions](https://www.manivox.ai/docs/agents/versions) pour le modèle complet.