Étapes de workflow d’agent IA pour les formulaires WordPress

L’étape de workflow ai.agent est l’action IA côté backend utilisée dans les workflows Flow.

Elle n’envoie pas directement l’e-mail final ni la requête webhook. Elle publie plutôt un événement ai.agent.requested dans le système de workflow backend. Le backend IA traite cette demande, puis émet :

• ai.agent.completed
• ai.agent.failed

Les workflows en aval peuvent réagir à ces événements de résultat, et les branches de déclenchement d’étape du process map peuvent limiter ces workflows en aval à l’étape IA exacte qui les a émis.

Prérequis de déploiement​

Pour que cette étape fonctionne en production, le backend Flow seul ne suffit pas.

Vous avez besoin de :

• un backend Flow déployé et synchronisant/exécutant les workflows
• un backend AI Kit déployé, car sa fonction interne AiAgentDispatcherFunction consomme ai.agent.requested et émet ai.agent.completed ou ai.agent.failed

Si le répartiteur du backend AI Kit est absent ou mal configuré, le workflow peut publier l’événement de requête IA, mais rien ne le transformera en résultat IA de suivi.

Si vous attendez des réponses ou classifications fondées sur la base de connaissances, le backend AI Kit doit aussi disposer d’une configuration de modèle fonctionnelle et d’une base de connaissances configurée avec du contenu ingéré.

À quoi sert cet écran​

L’écran de configuration de l’étape d’agent IA combine quatre aspects :

1. l’intention de la tâche via Mode
2. un routage facultatif détenu par la plateforme via Internal routing
3. la rédaction via Prompt Text et Additional System Guidance
4. la validation de sortie via Response Constraint

Si vous les gardez séparés, la configuration est beaucoup plus simple à raisonner.

Mode​

Mode est l’intention de haut niveau transmise au backend IA.

Valeurs actuelles :

• Answer
• Summarize
• Classify
• Extract structured data

Utilisation recommandée :

• choisissez Answer pour une génération générale ou la rédaction de réponses
• choisissez Summarize pour des résumés concis
• choisissez Classify pour les décisions de routage et de branchement
• choisissez Extract structured data lorsque vous avez besoin d’une sortie structurée prévisible

Mode influence les valeurs par défaut, mais le comportement réel dépend toujours de votre invite et de votre schéma.

Routage interne​

Internal routing contrôle si Flow injecte un contrat de routage détenu par la plateforme.

Préréglages actuels :

• No internal routing
• Route by category
• Route by outcomes
• Draft reply only

Utilisation recommandée :

• No internal routing : à utiliser lorsque vous ne voulez pas l’enveloppe de routage de Flow. Cela supprime le bloc de routage de la plateforme, mais tout schéma de réponse personnalisé déjà présent peut rester jusqu’à ce que vous le supprimiez ou le remplaciez.
• Route by category : à utiliser lorsque l’IA doit choisir une catégorie stable comme support, sales ou billing.
• Route by outcomes : à utiliser lorsque l’IA doit renvoyer des issues actionnables explicites comme invoke_webhook, invoke_workflow ou send_email.
• Draft reply only : à utiliser lorsque l’étape doit produire un brouillon de réponse structuré et que vous n’avez pas besoin de métadonnées de routage.

Clés de routage, types de résultats et clés de signal​

Lorsque le routage est activé, ces champs déterminent ce que l’IA est autorisée à émettre.

Clés de routage​

Utilisez des valeurs de catégorie stables telles que :

• support
• sales
• billing
• crm_lead

Elles alimentent des suggestions de branches du process map comme route:support.

Types de résultats​

Utilisez des familles d’actions réutilisables telles que :

• invoke_webhook
• invoke_workflow
• send_email
• set_status

Elles prennent en charge des clés de branche comme outcome:invoke_webhook:create_ticket.

Clés de signal​

Utilisez des métadonnées structurées facultatives telles que :

• priority
• language
• urgency

Elles prennent en charge des clés de branche comme signal:priority:high.

Bonne pratique :

• utilisez route pour la branche métier principale
• utilisez outcomes pour les prochaines étapes actionnables
• utilisez signals uniquement pour les métadonnées auxiliaires

Champs d’invite​

Texte de l’invite​

Prompt Text est l’instruction principale de la tâche et le champ le plus important saisi par l’utilisateur.

Les bonnes invites sont concrètes, opérationnelles et explicites quant à la décision ou à l’artefact souhaité.

Bloc système de la plateforme​

Platform System Block est injecté automatiquement par Flow lorsque le préréglage de routage choisi le requiert.

Vous ne le modifiez pas directement. Son rôle est d’appliquer le contrat de routage sélectionné.

Instructions système supplémentaires​

Additional System Guidance est votre propre instruction de niveau système ajoutée après le bloc de la plateforme.

Utilisez-la pour des contraintes de ton, de politique ou de comportement telles que :

• être concis
• privilégier les preuves de la base de connaissances
• éviter les affirmations spéculatives

Conservez la tâche principale dans Prompt Text.

Schéma de réponse​

Préréglages de schéma de réponse​

Cette action génère un schéma de départ pour le mode actuel ou le préréglage de routage.

Utilisez Apply routing preset lorsque vous voulez reconstruire le schéma du contrat de routage à partir de la configuration de routage courante.

Contrainte de réponse (schéma JSON)​

Il s’agit du contrat de schéma JSON à l’exécution pour la sortie IA.

Lorsque le routage est activé, il doit correspondre à l’enveloppe de routage attendue par Flow. En pratique, cela signifie généralement un objet racine contenant routing.route, routing.confidence, routing.reason et routing.outcomes, avec éventuellement routing.signals.

Lorsque Draft reply only est activé, le schéma doit plutôt correspondre au contrat de brouillon de réponse.

Comportement important :

• le JSON invalide reste dans l’éditeur jusqu’à correction
• le workflow conserve le texte du brouillon au lieu de le rejeter silencieusement

Mise à jour de l’état lors de l’envoi​

Update Status on Dispatch change immédiatement le statut de soumission après la publication de ai.agent.requested.

Il n’attend pas le résultat final de l’IA.

Utilisez-le pour des transitions de visibilité comme new -> in-progress, et non comme substitut du résultat métier final.

Configuration initiale recommandée​

Pour un premier workflow avec branchement en aval, une configuration sûre est :

• Mode: Classify
• Internal routing: Route by category
• un petit ensemble de Route Keys
• des Signal Keys facultatives comme priority
• un schéma de routage généré par préréglage
• une invite concise orientée tâche

Cela vous donne un branchement de process map prévisible sans imposer dès le départ un grand modèle de sortie personnalisé.

Erreurs courantes​

• choisir No internal routing puis s’attendre à ce que le branchement de process map par route fonctionne
• conserver un ancien schéma personnalisé tout en supposant que No internal routing rend la sortie totalement libre
• utiliser des booléens spécifiques au tenant au lieu de clés de route ou de résultat stables
• traiter Update Status on Dispatch comme la décision finale de l’IA plutôt que comme une transition d’état de traitement