לפי פרסום של צוות Agentforce מבית Salesforce, תזמור מרובה-סוכנים (Multi-agent orchestration) זמין כעת באופן כללי (Generally Available), על רקע מגבלות ביצועים שמתגלות כאשר סוכן יחיד מנסה לנהל מגוון רחב מדי של יכולות. בפרסום מוסבר כי רוב פריסות ה-Agentforce מתחילות באופן דומה: סוכן יחיד מקבל על עצמו משימה אחת, כמו בדיקת הזמנות ומענה לשאלות סטטוס. כאשר הוא מבצע את העבודה היטב, מתווספות אליו יכולות נוספות לאורך זמן, כגון החזרות, המלצות על מוצרים וניהול מועדוני לקוחות. עם זאת, כאשר יכולות הסוכן גדלות מעבר לסף מסוים, תהליך החשיבה וההסקה (Reasoning) שלו מתחיל להישבר והתוצאות מידרדרות.
לפי המאמר, תזמור מרובה-סוכנים מוגדר כשיתוף פעולה מתואם בין שני סוכני בינה מלאכותית ייעודיים או יותר, במטרה להשלים משימות שאף סוכן יחיד לא יכול היה להתמודד איתן היטב בעצמו. אף שלא כל פריסה זקוקה למספר סוכנים, זהו הדפוס שצוותים רבים פונים אליו כאשר הסוכן הראשון שלהם מתחיל להיתקל בקשיים. הצוות פירט שלושה סימנים המעידים על כך שסוכן יחיד כבר אינו מספיק, לצד ארבעה נתיבי ארכיטקטורה מתוך מדריך הארכיטקטים החדש של החברה (Architect's Guide to Agentforce Interoperability).
סימן ראשון: הסוכן מנסה לבצע יותר מדי משימות במקביל
לפי הפרסום, כאשר מוסיפים תת-סוכנים ופעולות כדי לטפל בתרחישי שימוש נוספים, שני תהליכים מתחילים להתרחש:
ראשית, חלון ההקשר (Context window) של הסוכן מתמלא בהנחיות, בפלטים ובהיסטוריית השיחה. כתוצאה מכך, מנוע ההסקה מתחיל להתעלם מכללי ליבה, לערבב בין נושאים שונים או להחיל לוגיקה שגויה על הבקשה הלא נכונה. תופעה זו מוגדרת כהתנגשות כוונות (Intent collision), והיא מורגשת כנסיגה ביצועית (Regression): התנהגות שהייתה אמינה בחודש הקודם הופכת לבלתי עקבית בחודש הנוכחי, ללא שינוי בודד שמסביר זאת. המאמר משווה זאת לפתיחת 30 לשוניות או יותר בדפדפן, שבה מציאת הלשונית הנחוצה אורכת זמן רב יותר ונפתחות לשוניות שגויות בדרך.
שנית, בלוק התיאור שבו משתמש מנוע ההסקה לצורך ניתוב בקשות הולך ומתרחב. ככל שהוא גדל, כך הנתב מהסס יותר או מנתב באופן שגוי — למשל שאלת חיוב המגיעה למחלקת החזרות, או בקשה טכנית שנוחתת במכירות. במצב זה התיאור מבצע עבודה שצריכה להתבצע ברמת התכנון הארכיטקטוני, וכיול התיאור אינו פותר את הבעיה מהשורש. הפתרון המוצע הוא פיצול סוכן עמוס למספר סוכנים ייעודיים: סוכן-על (Superagent) המנתב לסוכני משנה מקושרים (Connected Subagents) בעלי היקף מוגדר, מה שמספק לכל סוכן סט הנחיות קטן יותר, הקשר נקי יותר ואות ניתוב ברור יותר.
סימן שני: המידע נמצא במקומות שהסוכן אינו יכול לגשת אליהם
לפי המאמר, סוכן Agentforce יחיד פועל בתוך ארגון Salesforce ספציפי. אם תהליך העבודה תלוי בנתונים, בהרשאות או במערכות שנמצאים במקום אחר, סוכן יחיד מגיע לגבול שאינו יכול לעקוף באמצעות עיצוב הפרומפט. הטיפול בבעיה זו דורש שינוי ארכיטקטוני שמותאם לכיוון תנועת העבודה:
- גישה לכלים חיצוניים: כאשר Agentforce צריך לגשת למערכת או לכלי חיצוני כמו Jira, Box או מסד נתונים, רכיב MCP Client מאפשר לו להשתמש ביכולת זו ככלי עבודה תוך שמירה על מעמדו כמתזמר המרכזי.
- העברת משימות לסוכן חיצוני: כאשר Agentforce נדרש להעביר משימה לסוכן חיצוני, דוגמת סוכן של Google או של AWS המחזיק בחלק מתהליך ההסקה, מנגנון Outbound A2A מאפשר להאציל סמכויות לסוכן צד שלישי.
- הפעלה ממערכת חיצונית: כאשר מערכת חיצונית כמו פורטל מותאם אישית או Microsoft Copilot צריכה להפעיל ביצוע בתוך Salesforce, מנגנוני Inbound A2A או הפעלת Agentforce בתור MCP Server מאפשרים לפלטפורמות חיצוניות לנצל את יכולות Agentforce ללא צורך בבנייתן מחדש.
סימן שלישי: צוותים שונים נדרשים לנהל חלקים שונים של הסוכן
במקרים שבהם סוכן יחיד נמסר לשימוש כלל החברה, מחלקות שונות דורשות שינויים עצמאיים: המחלקה המשפטית מבקשת לעדכן את לוגיקת המדיניות, מחלקת הכספים נדרשת לשנות את כללי האישור, ומחלקת השיווק מעוניינת לכייל את זרימת ההמלצות. במצב כזה, כל עדכון הופך למשא ומתן על בלוק הנחיות משותף, צוותים אינם יכולים לפעול באופן עצמאי, והחדשנות נבלמת אצל הגורם שמחזיק בהגדרות הסוכן הבודד. תזמור מרובה-סוכנים מאפשר לכל מחלקה לבנות ולבדוק סוכן משלה באופן עצמאי וללא הפרעה לחוויית הלקוח הקיימת, ולאחר מכן לחבר אותו לסוכן-העל בהתאם ללוח הזמנים של אותה מחלקה.
ארבעה נתיבי ארכיטקטורה ושאלות מוכנות
המדריך של החברה מפרט שבעה תרחישי תפעול הדדי, ומתוכם ארבעה נתיבים נפוצים למעבר מסוכן יחיד:
- הישארות עם סוכן יחיד: ארכיטקטורה תקפה וככל הנראה היעילה ביותר כאשר תהליך העבודה מתקיים כולו בתוך ארגון Salesforce, עושה שימוש במודל נתונים יחיד, שומר על מספר מוגבל של תת-סוכנים ומספק תוצאות איכותיות.
- תזמור מרובה-סוכנים פנימי: מתאים כאשר הבעיה משתרעת על פני מספר קווי פעילות עסקיים (כגון חיוב, תמיכה והחזרים) אך הנתונים, ההרשאות והמשתמשים כולם נמצאים בתוך מופע Salesforce, או כאשר סוכן יחיד צומח מעבר לשבעה תת-סוכנים ותוצאותיו מתחילות להידרדר.
- תזמור מרובה-סוכנים מול צד שלישי (A2A): מתאים כאשר Agentforce נדרש לשתף פעולה עם סוכן חיצוני שמנהל חלק מתהליך ההסקה או זרימת העבודה.
- חיבור MCP לכלים חיצוניים: מתאים כאשר Agentforce נשאר הגורם המנהל, אך נדרש לגשת לכלי חיצוני, ל-API או לזרימת עבודה חיצונית.
לפני המעבר לארכיטקטורה חדשה, הפרסום ממליץ לבחון מספר שאלות:
- מספר תת-סוכנים מחוברים: בבדיקות פנימיות של החברה נמצא כי התנגשות כוונות והידרדרות תוצאות מתרחשות לרוב כאשר ישנם יותר משבעה תת-סוכנים מחוברים לסוכן יחיד.
- שימוש במודלים ובהגדרות שונות: בארכיטקטורה מרובת-סוכנים ניתן להגדיר לכל סוכן הגדרות ניתוב ורמת יצירתיות (באמצעות טמפרטורה) משלו, ולהשתמש במודלים מורכבים למשימות בעלות ערך גבוה או במודלים זולים ומהירים למשימות בעדיפות נמוכה.
- שליטה לפי קווי פעילות עסקיים (Business units).
- עקביות מודל הנתונים: כאשר מזהי לקוחות, מק"טים של מוצרים או רשומות מקרים אינם תואמים במדויק בין מערכות שונות, הפלט של סוכן אחד הופך לניחוש עבור הסוכן האחר.