סוכן אחד, עשרים לקוחות: איך מפרידים בין לקוחות כשסוכן AI מנהל את ההפצה

סוכן אחד יכול לנהל הפצה לעשרים לקוחות, בתנאי שהגבול בין הלקוחות מוגדר במבנה ולא רק בזיכרון של השיחה. בְּשַׁגֵּר הגבול הזה הוא סביבת העבודה: כל לקוח הוא סביבת עבודה נפרדת, וכל ערוץ, פוסט וקישור שייכים לאחת בלבד. מה שנשאר לכם הוא לוודא שהסוכן תמיד יודע באיזו סביבת עבודה הוא נמצא, ושהוראות המותג של לקוח אחד לא דולפות לאחר.

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

איך שַׁגֵּר מפריד בין לקוחות?

היררכיה פשוטה: ארגון, ובתוכו סביבות עבודה. הארגון הוא הסוכנות. סביבת עבודה היא לקוח או מותג. בתוך כל סביבת עבודה יש חשבונות מחוברים, קבוצות חשבונות, פוסטים וקישורים מקוצרים. כמעט כל כלי של שַׁגֵּר מקבל workspace_id כפרמטר חובה, כך שאי אפשר ליצור פוסט "באוויר" בלי לציין לאיזה לקוח הוא שייך.

ישות	שייכת ל	כלי רלוונטי
סביבת עבודה	ארגון	list_workspaces, create_workspace
חשבון מחובר	סביבת עבודה	list_channels, create_connect_link
קבוצת חשבונות	סביבת עבודה	list_groups, create_group
מדיה ופוסטים	סביבת עבודה	upload_media_from_url, create_post
לחיצות	סביבת עבודה	get_analytics

מפתח API שייך לארגון, ולכן סוכן עם מפתח אחד רואה את כל סביבות העבודה של הסוכנות. זה מה שמאפשר לו לעבוד עם כולן, וזה גם מה שמחייב משמעת.

הקמת לקוח חדש בידי הסוכן

create_workspace {
  "name": "משרד עו\"ד לוי ושות'",
  "timezone": "Asia/Jerusalem",
  "approval_required": true
}

approval_required קובע אם פוסטים בסביבת העבודה הזו צריכים אישור לקוח לפני תזמון. לסוכנים ברירת המחדל היא false, ולכן ללקוח שרוצה לראות כל פוסט צריך להגדיר את זה במפורש. אני מגדיר true לכל לקוח חדש בחודש הראשון, גם אם הוא אומר שהוא סומך עלינו.

אחרי שסביבת העבודה קיימת, הסוכן יוצר קישור חיבור עם create_connect_link ושולח אותו ללקוח. הלקוח פותח אותו, מתחבר לפייסבוק, לאינסטגרם או ליוטיוב ובוחר את החשבונות, בלי חשבון בְּשַׁגֵּר ובלי למסור סיסמה. ההסבר המלא במאמר על קישורי חיבור ללקוח. שימו לב שקישורי חיבור ובקשות אישור לא זמינים בסנדבוקס שעוד לא נתבע, ולפי עמוד המחירים הם נכללים בחבילת Agency ומעלה.

חמישה כללים שמונעים ערבוב בין לקוחות

1. שיחה לכל לקוח. זה הכלל הכי פשוט והכי אפקטיבי. כשהשיחה מתחילה, הסוכן קורא את קובץ ההנחיות של הלקוח ועובד רק בסביבת העבודה שלו. כשעוברים ללקוח אחר, פותחים שיחה חדשה.
2. בדיקת סביבת עבודה לפני כל כתיבה. ההוראות הקבועות של הסוכן מחייבות אותו לציין את שם סביבת העבודה בכל פעולה שיוצרת משהו, ולהשוות אותו לשם הלקוח בבריף.
3. קובץ הנחיות לכל לקוח. קול המותג, מילים אסורות, מתחרים שלא מזכירים, ימים שלא מפרסמים. הקובץ יושב בתיקייה של הלקוח, לא בהוראות הכלליות.
4. אין העתקה בין לקוחות. הסוכן לא משתמש בכיתוב, בתמונה או בקישור שנוצרו ללקוח אחד בעבודה של לקוח אחר, גם אם הנושא דומה.
5. בדיקה אחרי פעולה. אחרי create_post, הסוכן מריץ get_post ומוודא שרשימת החשבונות שייכת ללקוח הנכון.

איך נראה מבנה התיקיות

בסוכנות שעובדת עם Claude Code או עם כלי דומה, מבנה כזה עובד טוב:

clients/
  levi-law/
    brief.md          # קול המותג, קהל, מה מותר ומה אסור
    workspace.txt     # שם סביבת העבודה בשגר, בדיוק כפי שהוא
    calendar.md       # ימים ושעות לפרסום, חגים, אירועים
  cafe-alma/
    brief.md
    workspace.txt
    calendar.md

וההוראה בתחילת כל שיחה:

אנחנו עובדים היום על הלקוח בתיקייה clients/levi-law.
1. קרא את brief.md, את workspace.txt ואת calendar.md.
2. הרץ list_workspaces ומצא את סביבת העבודה ששמה זהה לתוכן של workspace.txt. אם אין התאמה מדויקת, עצור ושאל.
3. מכאן והלאה השתמש רק במזהה workspace_id הזה. אם בקשה שלי נראית כאילו היא שייכת ללקוח אחר, שאל לפני שאתה מבצע.

קבוצות חשבונות בתוך לקוח

לקוח עם ארבעים סניפים לא מפרסם תמיד לכולם. קבוצות חשבונות פותרות את זה: create_group עם name וchannel_ids, ואחר כך create_post עם group_ids במקום רשימה ארוכה של ערוצים. כל ערוץ פעיל בקבוצה נכלל בפוסט.

create_group {
  "workspace_id": "ws_cafe_alma",
  "name": "סניפי צפון",
  "channel_ids": ["ch_fb_haifa", "ch_fb_karmiel", "ch_ig_haifa", "ch_fb_nahariya"]
}

הקבוצות שימושיות גם לסוכן. במקום לזכור אילו עמודים שייכים לצפון, הוא קורא לlist_groups ומקבל את המבנה כפי שהסוכנות הגדירה אותו. מבחינת עקביות המותג בין עשרות חשבונות, יש עוד על הנושא במאמר על קול מותג אחיד.

בקרה: מי עשה מה

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

כמה לקוחות סוכן אחד יכול להחזיק?

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

התמחור של שַׁגֵּר לפי מספר החשבונות המחוברים, לא לפי מספר המשתמשים או הסוכנים. גישת API וגישת MCP כלולות בכל חבילה, כך שסוכן נוסף לא עולה כסף. הוא עולה זמן בדיקה.

מאיפה מתחילים

קחו שני לקוחות, לא עשרים. הקימו לכל אחד תיקייה עם brief.md, הריצו את הסוכן שבועיים בשיחות נפרדות, ובדקו את היומן בסוף כל שבוע. שימו לב במיוחד לשתי שאלות: האם כל פעולה נעשתה בסביבת העבודה הנכונה, והאם היו בקשות שהסוכן עצר בהן ושאל. אם לא היה ערבוב, והסוכן עצר בדיוק במקומות שהגדרתם, מוסיפים לקוחות בהדרגה, שניים או שלושה בכל פעם. ההנחיות להתחברות נמצאות בעמוד הסוכנים.

שאלות נפוצות

אפשר להגביל מפתח לסביבת עבודה אחת?

מפתחות בְּשַׁגֵּר מוגדרים לפי הרשאות read, write וpublish, והם שייכים לארגון. ההפרדה בין לקוחות נשענת היום על workspace_id בכל קריאה ועל ההוראות של הסוכן. לכן כללי העבודה שלמעלה חשובים.

מה קורה אם הסוכן יוצר פוסט בסביבת העבודה הלא נכונה?

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

הלקוח יכול לראות את הפוסטים של לקוחות אחרים?

לא. לקוח שמקבל קישור אישור רואה רק את הפוסט שנשלח אליו, בלי להתחבר לְשַׁגֵּר. לקוח שמחבר חשבונות דרך קישור חיבור לא מקבל גישה לְשַׁגֵּר בכלל.