במאמר שפורסם בסיילספורס (Salesforce), נטען כי ארגונים רבים שבונים באמצעות בינה מלאכותית משלבים סוכן בשלב בודד של תהליך העבודה, בעוד השלבים שלפניו ולאחריו ממשיכים להתנהל בקצב הארגוני האנושי הרגיל. המאמר משווה מצב זה למכונית מרוץ בעלת מנוע מרשים שנתקעת מאחורי טרקטור בכביש כפרי, ומסביר כי הסוכן מסיים את פעולתו בשניות, אך העבודה ממתינה לבדיקה, להעברה או לבקשת שינוי. לפי המאמר, זו הסיבה לכך ש-95% מהחברות אינן מפיקות ערך מבינה מלאכותית, שכן הערך נלכד בכל שלב בקנה מידה אנושי שהסוכן נאלץ להמתין לו.
צווארי הבקבוק בתהליכי עבודה וקצב אנושי
במאמר מוסבר כי ניתן לחשוב על הסקת מסקנות לאורך כל שיחה על מצב לקוח שהתקיימה אי פעם, תוך חיפוש ב-27 שנות נתונים של Salesforce וקבלת תשובה – משימה שאף אדם אינו מסוגל לבצע. עם זאת, אם הופכים שלב אחד לסוכנותי (agentic), השלב שאחריו חייב להיות סוכנותי גם כן; אם הוא אינו כזה, התהליך נותר תקוע בקנה מידה אנושי, מאחורי הטרקטור, ושם התשואה על ההשקעה נעצרת.
לפי המאמר, הדרך המהירה ביותר להפוך לארגון סוכנותי היא יצירת סביבה פתוחה, מאובטחת ומנוהלת, שבה לכל עובד יש הזדמנות לבנות. בסיילספורס, 74% מהעובדים השתמשו או קיימו אינטראקציה עם כלי קידוד סוכנותי, כדוגמת Claude Code או Codex, לפחות פעם אחת. השימוש בקרב עובדים שאינם טכניים מגיע לעד 66%, נתון המהווה יותר מפי שלושה לעומת היקף השימוש ברבעון הראשון. רובם אינם יודעים לכתוב קוד, אך הם מוכנים להתנסות בהסבר למכונה לגבי מה שהם צריכים.
הסיכונים ותפקיד מחלקת ה-IT
לצד זאת, מודגש במאמר כי ללא המתודולוגיה והתשתית הנכונות, מצב שבו כולם בונים הכל בכל מקום עלול להפוך לסיוט מבחינת אבטחה. סוכן ללא מעקות בטיחות (guardrails) מתאימים עלול לטעות, לעשות זאת בביטחון מלא, ולפעול על פי אותה שגיאה במהירות מכונה.
כמו כן, מחלקת ה-IT עדיין נדרשת להחזיק באחריות על אמון, תאימות ויושרה. ה-IT נדרש להמשיך להחזיק במערכות הרשומה (systems of record) ובסמנטיקה של הנתונים, כגון ההגדרה של מיהו לקוח או מה המשמעות של הכנסה. במאמר מצוין כי ניתן לחשוף את כל אלה דרך ממשקי API ו-MCP, משום שהבנייה הנוכחית אינה מיועדת רק לבני אדם, אלא בעיקר עבור סוכנים שאנשים ישתמשו בהם מחוץ לשליטה, לבנייה או לבעלות של ה-IT.
מתודולוגיית צוותי החדשנות המהירה (RIS)
כדי לתת מענה לאתגרים אלה, פותח בסיילספורס מודל המכונה צוותי חדשנות מהירה (Rapid Innovation Squads, או RIS בקיצור). בראשית שנת 2026 הבינו הכותב וצוותו כי טרנספורמציה סוכנותית חורגת מעבר לכלים בלבד, והעלו שאלות לגבי האפשרות שאנשי מוצר, אנשי עסקים ומהנדסים יפעלו יחד כצוות קטן אחד שבונה פתרון במשותף, ללא תוכנית עבודה כבדה וללא מסמך דרישות מוצר אפוי מראש. המטרה הייתה לבחון כמה מהר יותר יכולים בני אדם וסוכנים להתקדם יחד, עם המבנה, מעקות הבטיחות והכלים הנכונים, תוך שמירה על אבטחה, וכיצד נראה תכנון מחדש של צוותים, תהליכים ומערכות עבור קנה מידה סוכנותי.
לפי המאמר, המבנה של RIS מורכב ממחזיק עניין עסקי בעל דעה מוגדרת וסמכות, אשר מחזיק בבעלות על הבעיה ויש לו עמדות ברורות לגבי פתרונה. לצדו מצטרפים בוני פתרונות סוכנותיים – בין אדם אחד, שניים או חמישה אנשים – כאשר הצוות נשמר קטן ככל האפשר, והבעיה מצומצמת לצורתה השימושית הקטנה ביותר.
השגרה היומית של צוותי RIS
המאמר מפרט את השגרה היומית של צוות RIS:
- הצטרפות לפגישת בוקר (stand-up): הצוות מקיים פגישת עמידה יומית אשר מוקלטת ומתומללת.
- שקיפות כברירת מחדל: התמליל מועבר לערוץ Slack ציבורי, כדי ששאר הארגון וכלל הסוכנים יוכלו ללמוד מפעולת הצוות. תהליך האיטרציה מתרחש שם גם כן: עובדים מגיבים, מציעים שינויים ובונים על גבי העבודה של עמיתיהם בתוך השרשור (בפרויקטים רגישים באמת, הערוץ יכול להיות פרטי).
- העברה לסוכנים: התמליל מוזן לכלי קידוד סוכנותי. הצוות מתפנה מעיסוקו, והסוכנים מתחילים לעבוד על מה שנדון בפגישה.
- חזרה על התהליך לאחר ארוחת הצהריים: כל אחד מחברי הצוות מתפקד כבונה, וכולם מגיעים עם רעיונות ואבות-טיפוס.
- חזרה על התהליך בסוף היום: הסוכנים ממשיכים לבנות, לבדוק ולבצע איטרציות לאורך הלילה, כך שהצוות פותח כל בוקר עם התקדמות עובדת לבדיקה, במקום רשימת משימות שממתינה לטיפול (backlog).
לפי המאמר, התוצאה היא מהירות: שותפות עם מחזיק עניין בעל דעה מובילה לקבלת החלטות מהירה פי 10 לערך, ושילוב זה עם כלי קידוד סוכנותיים מניב תוצאות מהירות פי 30 לערך. המאמר מציע לחשוב על מהירות כמדד מקורב למסירת ערך, כאשר הדבר נעשה נכון.
פרויקטים ודוגמאות יישום בסיילספורס
במאמר מוצגות מספר דוגמאות ליישום המודל בתוך סיילספורס:
- אפליקציית Sales Signals ב-Slack: אנשי מכירות לעסקים קטנים ובינוניים (SMB) התמודדו עם מעבר בין כלים מרובים ואובדן זמן בשל החלפת הקשר (context switching). אותות רכישה – כגון ביקורים באתר, עליות חדות בשימוש וחלונות חידוש חוזים – היו מפוזרים בין מערכות, והצוות ביקש מרחב עבודה קבוע בתוך Slack שירכז את כל האותות לרשימת עבודה יומית ברורה. במקום להעביר תוכנית פרויקט של 12 חודשים להנדסה, הבעיה הועברה לצוות RIS של שלושה אנשים שעבד במעגל של 24 שעות של תכנון, בנייה, עבודה משותפת (swarm), בדיקה ושילוח. הצוות סיפק את אפליקציית Sales Signals בתוך ימים, בעוד תוכנית פרויקט מסורתית הייתה נמשכת חודשים. האפליקציה כבר הניבה 28,000 הזדמנויות עסקיות.
- מיומנות Slack למהנדסי פתרונות: מהנדסי פתרונות בסיילספורס נהגו להקדיש בין 2 ל-3 שעות בשבוע לתיעוד פעילותם, בתהליך שהיה מועד לשגיאות. בתוך פחות מארבעה שבועות, צוות של שלושה אנשים (מנהל עסקי ושני בונים סוכנותיים) סיפק מיומנות Slack חדשה (Slack Skill) הסורקת את היומן של המהנדס, נתוני Slack ומערכות Salesforce כדי למלא מראש גיליון שעות לאישור המהנדס. הספרינט הביא לבניית הכלי במהירות גבוהה ב-70% עד 80% לעומת תהליך אג'ייל מסורתי, שיעור האימוץ עומד על 80%, וכעת 23,000 פעילויות שבועיות מתועדות באופן אוטומטי.
- ניתוב פניות במחלקה המשפטית: המחלקה המשפטית ניתבה וטיפלה בכ-39,000 פניות בשנה, כאשר ניתוב כל פניה לעורך הדין המתאים ארך כ-20 דקות, ולעתים נרשמו ניתובים כפולים שגרמו לעורכי דין לבזבז זמן על פנייה שמישהו אחר כבר מטפל בה. צוות קטן שילב חוקים דטרמיניסטיים עם Agentforce כדי לנתב מקרים כמעט מיידית, ובכך חסך 350,000 דולר בשנה – החזר השקעה של פי 70 שכיסה את עלותו בתוך חודש. בנוסף, הסוכנים מונעים כפילויות בפניות פעילות וזוכרים את היסטוריית הטיפול המלאה כדי לדייק את הניתוב, מה שהביא לניתוב שטוב כמעט פי שלושה בבחירת עורך הדין הנכון כבר בניסיון הראשון.
התרחבות כלל-ארגונית והמלצות לתהליכי עבודה
במאמר נמסר כי בחודש דצמבר המודל מתרחב לכלל החברה תחת אירוע המכונה RISFest – קריאה פתוחה לכל מחלקה בסיילספורס להגיש בעיה עסקית ממשית כדי שצוות RIS יבנה את הפתרון בימים ולא ברבעונים. המהלך מוגדר כ"אנטי-האקתון", שמטרתו לשלוח פתרונות באופן ישיר.
המאמר מציג המלצות מעשיות למנהלים ולארגונים:
- אין להסתפק באוטומציה של משימה בודדת; יש לעצב מחדש את תהליך העבודה כולו כך שכל שלב יפעל בקנה מידה סוכנותי.
- יש להתחיל מבעיה וממחזיק עניין בעל דעה המחזיק בבעלות עליה.
- יש לשמור על צוות קטן ועל בעיה מצומצמת עוד יותר.
- יש לספק ליוצרים, בין אם הם טכניים ובין אם לא, אבני בניין בטוחות, ולהשאיר את מחלקת ה-IT אחראית על אמון, תאימות ותשתית הנתונים.
- יש לעבוד בצורה גלויה בפומבי כדי שכל צוות ילמד מזה שקדם לו.