סוכני שיחה בוואטסאפ: מארכיטקטורה ל-Production

המגבלות שמעצבות את הארכיטקטורה

ה-WhatsApp Business API כופה חלון הודעה של 24 שעות, הודעות תבנית מחוץ לחלון, latencies של webhooks וקצבים מוגבלים. אלה לא הערות שוליים — הם אלה שמעצבים את ניהול המצב. הערוץ הזה הוא duplex אסימטרי: שולחים ב-REST, מקבלים ב-webhooks, ומה שמותר לשלוח תלוי בשאלה אם המשתמש פתח חלון. כל הארכיטקטורה נבנית סביב האסימטריה הזו.

אתם לא שולחים בתזמון: משתמש יכול לשלוח הודעה ולהיעלם ל-20 דקות. הסוכן חייב לשרוד את הפער הזה בלי לאבד context.

עיצוב Session — החלק שמפריד בוט צעצוע ממערכת

מיפוי קבוע per user+thread: session store (Redis לחם, Postgres לקבע) שמחזיר context, מצב משימה ו-last-seen. TTL שמגדיר מתי לסגור מחזור. ה-state machine של כל שיחה כוללת שלושה מצבים שאסור לערבב:

1. חלון פתוח — חופשי לשלוח הכל.
2. חלון סגור, יש template — רק הודעות תבנית מאושרות.
3. ממתין למשתמש — לא שולחים כלום, שומרים מצב.

עקבו אחרי idempotency — webhooks נשלחים לפעמים יותר מפעם אחת, וזה מצב תקין של הערוץ, לא באג. עיבוד כפול = השבה כפולה = משתמש מבולבל. המפתח לדה-דופליקציה הוא מזהה ההודעה, והדרישה העסקית היא לא "לא יתקבלו כפולים" אלא "כפול לא מייצר אפקט עסקי שני".

ממשק שיחה בתוך ווצאפ

הודעות קצרות, צ'אנקים של פסקאות, והעדפת lists/buttons על פני free text כשזה זמין — כל בחירה מתפריט היא קלט ולידי מראש, וכל מילה שהמשתמש מקליד היא בעיית parsing. זמן תגובה תחת 3 שניות, עם typing indicators כשיש המתנה — המשתמש תמיד צריך לדעת שהצד השני חי.

כשלים: לעולם אל תזרקו שגיאה טכנית למשתמש. תרגום שגיאה להודעה עם פעולה ברורה + fallback לאדם. "משהו נתקע, נעביר אותך לנציג" שווה יותר מכל stack trace.

אינטגרציה למערכות עסקיות

הסוכן הוא פרונט: CRM, מסד נתונים, תשלומים — כולם דרך כלים מובנים עם הרשאות צרות. תנו למודל להחליט מה לעשות, לא איך לעשות. ההפרדה הזו — "מה" למודל, "איך" לקוד — היא מה שמאפשר לסוכן להיות חכם בלי להיות מסוכן.

לוג לכל tool call: קלט, פלט, latency, עלות. בלעדיו אי אפשר לשפר כלום — לא את הפרומפט, לא את הכלים, ולא להסביר ללקוח למה הבוט קבע לו פגישה בתאריך שעבר.