@Abidul_Haque_Shohel auf jeden Fall möglich, aber die Two-Agent-Aufteilung ist eigentlich nicht das richtige Pattern dafür — erzeugt Latenz und gibt dir zwei Fehlerpunkte statt einem. Das saubere Setup ist ein einzelner AI-Agent, der strukturiertes JSON ausgibt, und dann routest du im Workflow basierend auf dem, was das Modell sagt, das es tun will. Der Flow endet bei Messenger Webhook → AI Agent → Switch on intent → Airtable lookup → Messenger Send API.
Gib für den Agent etwas wie folgendes aus:
{
"intent": "image_request",
"product_id": "rec123abc",
"message_text": "hier ist das Foto des Black Cycle Pro, das du angefordert hast"
}
dann Switch on intent, mache ein Airtable lookup nach product_id, um die Bild-URL zu bekommen, sende an Messenger.
ein großes Gotcha — Airtable Attachment-URLs sind SIGNIERT und verfallen nach etwa 2 Stunden seit ihrer Sicherheitsänderung vor einer Weile. Wenn du die Raw Airtable-URL direkt an Messenger weiterleitest, funktioniert das bei sofortigen Sends, bricht aber zeitweilig ab, wenn Messenger das Bild lazy-loaded und die Signatur bereits ungültig ist. Die saubere Lösung ist das Uploaden auf Mesengers attachment_upload Endpoint, danach bekommst du eine permanente attachment_id zurück, dann referenzierst du diese id bei nachfolgenden Sends. Eine schnellere Alternative ist das Neuhosten auf stabilem Storage (s3, cloudflare r2, supabase storage) und das Einfügen dieser stabilen URL in Airtable statt des nativen Attachment-Felds.
der Messenger Send API Aufruf für ein Bild sieht wie folgt aus:
{
"recipient": {"id": "<user_psid>"},
"message": {
"attachment": {
"type": "image",
"payload": {
"url": "https://your-cdn/product-123.jpg",
"is_reusable": true
}
}
}
}
wenn du is_reusable auf true setzt, cached FB es server-seitig, sodass wiederholte Sends desselben Produktbildes nicht jedes Mal neu heruntergeladen werden, großer Latenzgewinn, wenn dein Katalog aufgebaut ist.
