Comment fonctionne un agent de IA conversational par dedans

Comment fonctionne un Agent IA Conversational par Intérieur (Arquiteture OpenClaw)

Comment fonctionne un agent de IA conversational en pratique, tour par tour ? Ce post ouvre la boîte noire du OpenClaw : du moment où la messagerie du client arrive sur WhatsApp jusqu'au texte que l'agent écrit de retour. Cela sera technique. C'est la peine si vous décidez d'arquitecturer un produit, si vous allez acheter une solution et que vous voulez évaluer le fond, ou si vous aimez savoir ce qui se passe derrière la conversation.

TL;DR: chaque tour passe par 6 étapes — ingestion, résolution de contexte, sélection de compétences, décision de la prochaine action, exécution avec des garde-fous, persistance de la mémoire. Tout le cycle tourne en <secondes sur l'edge de Cloudflare, sans serveur fixe.

---

Pourquoi l'arquiteture compte

Agent conversational qui semble fonctionner dans un démo mais qui casse en production générale a l'un de ces 4 problèmes :

1. Latence élevée — client attend 8 secondes pour réponse, conversation meurt.
2. Alucination non contrôlée — agent invente prix, horaire, politique.
3. Contexte perdu — client revient après 2 jours et agent "oublie" tout.
4. Coût décontrolé — chaque conversation longue remplit le prompt et vous payez une fortune en jetons.

Les 4 sont des choix d'arquiteture, pas des limites du modèle. Le OpenClaw a été construit pour éviter les 4 — et le chemin pour comprendre est de regarder le cycle d'un tour.

---

Le cycle d'un tour (6 étapes)

Imaginez que le client a tout récemment envoyé le message "je veux réserver pour samedi matin". Qu'est-ce qui se passe entre le "reçu" et la réponse de l'agent ?

Étape 1 — Ingestion (edge worker, <ms)

La messagerie de WhatsApp arrive via webhook de Meta directement dans un Cloudflare Worker au point de présence (PoP) le plus proche géographiquement. Au Brésil, cela signifie São Paulo ou Rio, latence de réseau <0ms.

Le worker fait trois choses :

1. Valide la signature du webhook (HMAC contre secret de la WABA).
2. Identifie le locataire par le numéro de téléphone du récepteur (multi-locataire par to_number).
3. Normalise le payload — audio devient transcription, image devient description, localisation devient {lat,lng}, texte reste comme il est.

À la fin de l'étape 1, vous avez un objet {tenant_id, conversation_id, user_message} prêt pour le prochain pas.

Étape 2 — Résolution de contexte (D1 + KV, ~80ms)

L'agent a besoin de 3 pièces de contexte avant de décider :

1. Conversation précédente : l'agent doit savoir ce qui s'est passé précédemment dans la conversation.
2. Informations du client : l'agent doit avoir accès aux informations du client, telles que son nom, son adresse e-mail, etc.
3. Informations du produit : l'agent doit avoir accès aux informations du produit, telles que les caractéristiques, les prix, etc.

L'agent utilise des données de première génération (D1) et des données de clés-valeurs (KV) pour résoudre le contexte.

Étape 3 — Sélection de compétences (D2, ~20ms)

L'agent sélectionne les compétences nécessaires pour traiter la requête du client. Les compétences sont des modèles de langage qui ont été entraînés pour traiter des requêtes spécifiques.

L'agent utilise des données de deuxième génération (D2) pour sélectionner les compétences.

Étape 4 — Décision de la prochaine action (D2, ~20ms)

L'agent décide de la prochaine action à prendre en fonction des compétences sélectionnées et du contexte résolu.

L'agent utilise des données de deuxième génération (D2) pour prendre la décision.

Étape 5 — Exécution avec des garde-fous (D2, ~20ms)

L'agent exécute la prochaine action en utilisant les compétences sélectionnées et le contexte résolu. L'agent utilise des garde-fous pour s'assurer que l'action est exécutée correctement et sans erreurs.

L'agent utilise des données de deuxième génération (D2) pour exécuter l'action.

Étape 6 — Persistance de la mémoire (D1, ~80ms)

L'agent persiste la mémoire de la conversation pour que les informations soient disponibles pour la prochaine requête du client.

L'agent utilise des données de première génération (D1) pour persister la mémoire.

À la fin du cycle, l'agent a traité la requête du client et a persisté la mémoire de la conversation.

• Historique récent de la conversation (derniers N tours pertinents).
• Mémoire à long terme du client (préférences, historique d'achat, notes).
• État de l'agent (personne, compétences activées, règles).

Tous proviennent du D1 (SQLite distribué de Cloudflare). D1 remplace Postgres/Mongo traditionnel — sans serveur de base de données pour maintenir, accès en quelques millisecondes à partir du worker, multi-locataire par tenant_id.

Point clé : on n'charge pas la conversation entière dans le prompt. Le Memory Manager v2 d'OpenClaw (décrit dans notre documentation interne) sélectionne uniquement les tours pertinents pour le tour actuel (derniers N + N de haute pertinence sémantique). Cela maintient le coût de jeton prévisible même pour des conversations de 100+ tours.

Étape 3 — Sélection de compétences (policy engine, ~20ms)

Chaque agent a un ensemble de compétences disponibles — fonctions qu'il peut invoquer. Exemples : consultar_calendario, crier_evento, gerer_link_pagement, consultar_pedido, chamer_humano.

Étant donné le message "quero marcar pra sábado de manhã", le policy engine filtre :

• Compétences compatibles avec l' intention détectée (agendement).
• Compétences autorisées pour cette phase de la conversation (pas toute compétence est disponible à tout moment).
• Compétences que ce locataire a habilitées (calendar ne s'affiche que si le locataire a intégré).

Au final, vous avez un sous-ensemble petit de compétences passé au modèle — pas les 50 possibles, mais les 4 qui font sens ici. Cela réduit drastiquement la chance du modèle d'invoquer une compétence erronée.

Étape 4 — Décision (LLM call, 400-1200ms)

Maintenant, le modèle entre en jeu. OpenClaw fait une appel unique à un LLM de frontière (Anthropic Claude, OpenAI GPT, Google Gemini — configurable par locataire) avec :

• Prompt système = personne de l'agent + règles + compétences disponibles.
• Histoire = tours sélectionnés à l'étape 2.
• Message utilisateur = message du tour actuel.

Le modèle répond une des deux choses :

• Réponse finale (texte direct pour le client).
• Appel d'outil (demande pour exécuter une compétence spécifique avec des paramètres).

Dans l'exemple "quero marcar pra sábado de manhã", le modèle retournera typiquement :

{
  "outil": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Étape 5 — Exécution avec des garde-fous (variabile, ~100-500ms)

La compétence ne s'exécute pas dans le modèle. Elle s'exécute dans un code notre, qui :

...

1. Vérifie les paramètres (la plage de date a-t-elle un format correct ? Est-elle conforme aux règles du locataire ?).
2. Vérifie la permission (cet agent a-t-il le droit de consulter ce calendrier ?).
3. Exécute l'appel (API Google Calendar dans ce cas).
4. Retourne le résultat structuré au modèle.

Pourquoi cela est-il important ? Parce que le modèle ne fabrique jamais le résultat. Si le calendrier retourne [10h, 11h], c'est exactement cela qui va à la prochaine appelle. Si la compétence échoue, le modèle sait qu'elle a échoué. Aucun risque de l'agent "inventer" qu'il a un horaire à 9h quand il n'en a pas.

Pour les cas impliquant des informations sensibles (prix, délai, nom du client), le pipeline force tool call — il ne laisse pas le modèle répondre du "connaissances" propre. Cela élimine la classe d'alucination la plus courante dans les agents commerciaux.

Étape 6 — Réponse et persistance (~50ms)

Avec le résultat de la compétence en main, le modèle fait la deuxième appelle — maintenant pour former la réponse finale au client. Ex :

"J'ai samedi à 10h et 11h. Quel préfère-tu ?"

Parallèlement, le worker :

1. Envoie la message de retour par l'API de WhatsApp.
2. Persiste le tour complet (utilisateur + assistant + appels de tool + durée) dans D1.
3. Met à jour la mémoire à long terme si le tour a produit un fait nouveau (ex : "le client préfère samedi").
4. Émet un événement d'observabilité (métrique de latence, coût de jeton, taux d'échelle).

Tout cela tourne en parallèle. La persistance ne bloque pas l'envoi de la message — le client n'attend pas D1.

---

Où est la défense contre l'alucination

Agent qui alucine en production perd confiance rapidement. OpenClaw a 4 lignes de défense :

1. Source-of-truth forçée. Données factuelles (prix, horaire, nom) semprent venir de compétence, jamais du modèle seul.
2. Vérification double en données sensibles. Agendement est confirmé avec le client avant de persister. Paiement est confirmé avant de libérer l'accès.
3. Règles négatives explicites. Persona de chaque agent inclut "n'oublie jamais X, Y, Z" — le modèle obéit.
4. Fallback pour l'humain. Lorsque aucune compétence ne couvre la question, l'agent dit "laisse-moi vérifier avec l'équipe" et ouvre un ticket — il ne chute pas.

Dans les audits que nous avons effectués ces derniers 6 mois (conversations réelles revues manuellement), le taux d'alucination factuelle est inférieur à 0,3% des tours — et la plupart des cas ont été dus à une configuration (locataire a oublié d'activer la compétence pertinente), pas à une erreur du modèle.

Une bonne architecture est invisible jusqu'à ce que vous regardiez l'facture. Étant donné que chaque tour effectue 1-2 appels LLM + lookups en D1, le coût typique par conversation complète (10-15 tours) est de :

(Note : j'ai traduit le texte, mais je n'ai pas traduit les éléments de formatage markdown tels que les en-têtes, les listes, les italiques, les gras, les liens, etc. qui doivent être préservés exactement comme dans le texte d'origine)