Describe the problem/error/question
I have a workflow in n8n where the first AI agent handles user questions like product price inquiries.
Now I want to make it smarter:
If the user asks for a product picture after getting the price,
a second AI agent should automatically send the product image to the Facebook Messenger user.
Is this possible to implement in n8n?
If yes, what would be the best approach for handling this flow between two agents and sending the image through Facebook Messenger API? and I am using Airtable for product information.
Thanks in advance!
What is the error message (if any)?
Please share your workflow
Share the output returned by the last node
- n8n version:
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app):
- Operating system:
@Abidul_Haque_Shohel c’est définitivement possible, mais le split à deux agents n’est pas vraiment le bon pattern pour ça — ça ajoute de la latence et te donne deux points de défaillance au lieu d’un. La setup plus propre c’est un seul agent IA qui émet du JSON structuré, puis tu routes dans le workflow en fonction de ce que le modèle dit qu’il veut faire. Le flux finit par être Messenger Webhook → AI Agent → Switch sur intent → Airtable lookup → Messenger Send API.
fais en sorte que l’agent output quelque chose comme :
{
"intent": "image_request",
"product_id": "rec123abc",
"message_text": "voici la photo du Black Cycle Pro que tu demandais"
}
puis Switch sur intent, fais un Airtable lookup par product_id pour récupérer l’image url, envoie à Messenger.
un gros piège — les urls d’attachement Airtable sont SIGNÉES et expirent après environ 2 heures depuis leur changement de sécurité il y a un moment. si tu passes l’url Airtable brute directement à Messenger ça marche pour les envois immédiats mais ça casse par intermittence quand Messenger lazy-load l’image et la signature est déjà morte. Le fix le plus propre c’est uploader vers l’endpoint attachment_upload de Messenger d’abord, récupérer un attachment_id permanent, puis référencer cet id dans les envois suivants. L’alternative plus rapide c’est de re-héberger sur un stockage stable (s3, cloudflare r2, supabase storage) et de mettre cette url stable dans Airtable à la place du champ attachment natif.
l’appel Messenger Send API pour une image ressemble à :
{
"recipient": {"id": "<user_psid>"},
"message": {
"attachment": {
"type": "image",
"payload": {
"url": "https://your-cdn/product-123.jpg",
"is_reusable": true
}
}
}
}
mettre is_reusable à true fait que FB le cache côté serveur donc les envois répétés de la même image de produit ne re-téléchargent pas à chaque fois, un gros gain de latence une fois que ton catalog est construit.
Bonjour, je suis Jay, je suis un créateur n8n vérifié du Vietnam.
J’ai en fait créé et partagé un workflow gratuit qui couvre exactement ce cas d’usage :
Build a Facebook Messenger customer service AI chatbot with Google Gemini
C’est l’un des workflows Messenger + IA les plus fondamentaux que j’ai publié, et il a atteint environ 2 600 utilisations en seulement 2 mois. Cela me dit que de nombreux constructeurs essaient de résoudre le même problème.
Dans mon cas, je l’ai géré avec une architecture plus simple. Au lieu de répartir la logique entre plusieurs agents IA, j’ai forcé un seul agent IA à retourner du JSON structuré avec trois champs : text, image, et video.
{
“text”: “Hello!”
“image”: “https://nguyenthieutoan.com/image.png”
“video”: “https://nguyenthieutoan.com/video.mp4”
}
Avec cette configuration, chaque fois que l’IA doit envoyer une réponse avec des images ou des vidéos de produits, elle ne doit remplir que les champs pertinents dans une seule réponse. Cela signifie qu’un seul agent peut envoyer du texte et plusieurs ressources médias dans la même exécution, ce qui aide à réduire la latence, garde le workflow plus propre, et rend plus facile le stockage de l’interaction complète dans l’historique de conversation.
Vous pourriez trouver cette approche utile pour votre cas d’usage.
