​ To learn more, see the sources I considered: [[1] GHL + Make + Retell](https://community.retellai.com/t/ghl-make-retell/806) ​

### Answer Bonjour ! Pouvez-vous préciser votre question d'architecture ? Je n'ai pas encore de détails sur le problème spécifique que vous souhaitez confirmer. Ceci dit, si votre question concerne l'intégration de Retell avec d'autres outils (comme GHL, Make, ou des webhooks) , voici un point d'architecture important déjà documenté : lorsqu'un appel Retell est déclenché avant que les données nécessaires (comme des disponibilités de calendrier) ne soient injectées dans le contexte de l'appel, le modèle peut "halluciner" des informations au lieu de lire les données réelles [(1) ]() . La règle clé est que le système qui récupère les données doit être celui qui démarre l'appel Retell, avec les variables injectées directement dans la requête de création d'appel . Dites-moi quelle est votre question précise et je pourrai vérifier avec les sources disponibles.

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Les sources confirment partiellement cette architecture, mais avec des nuances importantes. Ce qui est bien documenté : un numéro de téléphone peut être configuré avec un webhook d'appel entrant (

inbound_webhook_url

) , qui permet à Retell d'interroger votre serveur à chaque appel entrant pour ce numéro spécifique [(1) ]() . Dans la réponse de ce webhook, vous pouvez fournir des

dynamic_variables

propres à ce tenant/client, et même surcharger la configuration de l'agent (

agent_override

) pour cet appel précis, incluant le prompt (

begin_message

) , la voix, la base de connaissance, etc. [(2) ]() L'exemple de réponse webhook documenté montre exactement ce mécanisme :

json
{
 "call_inbound": {
 "override_agent_id": "agent_12345",
 "override_agent_version": 1,
 "agent_override": {
 "agent": {
 "voice_id": "11labs-Adrian",
 "voice_temperature": 0.6,
 "interruption_sensitivity": 0.8,
 "max_call_duration_ms": 1800000
 },
 "retell_llm": {
 "model": "gpt-4o-mini",
 "model_temperature": 0.2,
 "knowledge_base_ids": ["kb_abc123"],
 "start_speaker": "agent",
 "begin_message": "Hi {{customer_name}}, thanks for calling."
 }
 },
 "dynamic_variables": {
 "customer_name": "John Doe"
 },
 "metadata": {
 "random_id": "12345"
 }
 }
}

Ensuite, dans le prompt, vous pouvez injecter les variables spécifiques au tenant via la syntaxe

{{variable_name}}

(par exemple

{{customer_name}}

,

{{product_name}}

) [(3) ]() . Point important à nuancer : la réponse de Claude mentionne "un agent, N numéros" comme un modèle strict, mais les sources montrent que l'`agent_override` permet même de changer le modèle LLM, la base de connaissance, la voix, etc. par appel — donc l'architecture peut aller au-delà d'un simple "agent avec variables", jusqu'à littéralement reconfigurer l'agent utilisé pour cet appel précis via

override_agent_id

[(2) ]() [(1) ]() . Cela dit, les sources ne précisent pas explicitement de recommandation officielle du type "les pros utilisent toujours un seul agent mutualisé pour N clients" — cette conclusion n'est pas documentée telle quelle dans les sources disponibles. Un utilisateur de la communauté a aussi partagé un usage similaire : utiliser l'Inbound Call Webhook pour renvoyer des variables dynamiques (comme le numéro de l'appelant) issues d'un système externe (CRM) [(4) ]() .

​ To learn more, see the sources I considered: [[1] Update Phone Number](https://docs.retellai.com/api-references/update-phone-number) [[2] Inbound call & SMS webhook](https://docs.retellai.com/features/inbound-call-webhook) [[3] Dynamic variables: personalize Retell agent calls](https://docs.retellai.com/build/dynamic-variables) [[4] Discord message from @fyodor2572 on 2025-01-13](https://discord.com/channels/1186424376300679209/1186462578310910112/1328210142830788669) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.