סוכן AI עסקי אינו מודל שפה עם פרומפט ארוך. הוא לולאה סגורה: המודל מקבל מטרה, בוחר פעולה, מפעיל כלי חיצוני, קורא את התוצאה ומחליט מה הצעד הבא — עד שהמטרה הושגה, עד שהוא נתקע, או עד שנגמר תקציב הצעדים. מתחת למכסה המנוע יש ארבעה רכיבים בלבד: מודל, כלים, זיכרון ובקרה. בסקר McKinsey מנובמבר 2025 (1,993 משיבים בכ-105 מדינות) כ-62% מהארגונים מתנסים בסוכנים אך רק כ-23% הרחיבו אותם לקנה מידה, ו-Gartner צופה שיותר מ-40% מפרויקטי הסוכנים יבוטלו עד סוף 2027. הפער הזה כמעט אף פעם לא נמצא במודל.
מה מפריד סוכן מצ׳אטבוט ומאוטומציה
ההבדל אינו באיכות התשובה אלא בשאלה מי קובע את סדר הפעולות. בצ׳אטבוט האדם קובע: הוא שואל, מקבל טקסט, ומחליט בעצמו מה לעשות איתו. באוטומציה קלאסית המפתח קובע מראש: התהליך כתוב כתרשים זרימה, וכל ענף בו הוגדר בזמן פיתוח. בסוכן ההחלטה עוברת לזמן ריצה — המודל בוחר בעצמו איזה כלי להפעיל, באיזה סדר, ומתי לעצור.
זה ההבדל היחיד שבאמת משנה, והוא גם המקור לכל הסיכון. ברגע שסדר הפעולות אינו קבוע מראש, אי אפשר לבדוק את המערכת בשיטה שבה בודקים תוכנה רגילה, ואי אפשר להסתמך על כך שמה שעבד אתמול ירוץ היום באותו מסלול בדיוק.
| מאפיין | צ׳אטבוט | אוטומציה קלאסית | סוכן |
|---|---|---|---|
| מי קובע את סדר הפעולות | המשתמש | המפתח, בזמן פיתוח | המודל, בזמן ריצה |
| גישה למערכות | בדרך כלל אין | קבועה ומוגדרת מראש | דינמית, דרך שכבת כלים |
| התנהגות בכשל | מחזיר תשובה שגויה | נעצר ומדווח שגיאה | ממשיך לפעול ומחמיר את השגיאה |
| מה בודקים לפני עלייה לאוויר | איכות ניסוח | נתיבים ידועים | התפלגות תוצאות על פני הרצות |
שורת המפתח: אוטומציה שנשברת נעצרת. סוכן שנשבר ממשיך לעבוד. זו הסיבה שבקרה היא רכיב במערכת ולא תוספת שמוסיפים בסוף.
לולאת ההפעלה: תכנון, פעולה, תצפית
בלי קשר לספק, לשפה או למסגרת הפיתוח, כל סוכן מריץ את אותה לולאה. המודל מקבל את המטרה ואת מצב העולם הנוכחי, מייצר החלטה על הצעד הבא, מבצע קריאה לכלי חיצוני, מקבל בחזרה תוצאה — ואז מריץ את עצמו שוב עם התוצאה הזו כחלק מההקשר. הלולאה נעצרת כשהמודל מכריז שסיים, כשכלי מחזיר שגיאה חוסמת, או כשמנגנון חיצוני קוטע אותה.
המילה החשובה כאן היא תצפית. הסוכן אינו יודע דבר על העולם מלבד מה שהכלים מחזירים לו כטקסט. אם ה-CRM מחזיר שדה ריק, מבחינת הסוכן הלקוח באמת חסר טלפון. איכות התצפיות היא לכן משתנה הנדסי מדרגה ראשונה, לא פרט טכני.
| שלב בלולאה | מה קורה בפועל | מצב הכשל האופייני |
|---|---|---|
| קליטת מטרה | המטרה מתורגמת להקשר ראשוני יחד עם הוראות המערכת | מטרה עמומה שמייצרת מסלולים שונים בכל הרצה |
| תכנון הצעד | המודל בוחר כלי וארגומנטים | בחירת כלי נכון עם ארגומנט שגוי — הכשל הנפוץ ביותר |
| ביצוע | שכבת הכלים מריצה את הקריאה מול המערכת | הרשאה רחבה מדי שמאפשרת פעולה הרסנית |
| תצפית | התוצאה חוזרת אל ההקשר | פלט ארוך שדוחק מההקשר מידע קריטי קודם |
| הכרעה | המשך או עצירה | לולאה אינסופית שצורכת תקציב עד לתקרה |
ארבעת הרכיבים שכל סוכן בנוי מהם
כשמפרקים סוכן לחלקים מקבלים ארבעה רכיבים. שלושה מהם אינם המודל, ושם נמצא רוב העבודה ההנדסית וכמעט כל הכשלים.
| רכיב | תפקידו | מה נשבר כשהוא חלש |
|---|---|---|
| מודל | מייצר את ההחלטה על הצעד הבא | ניסוח יפה עם היגיון שגוי; שיפור המודל לא פותר בעיות בשאר הרכיבים |
| כלים | הממשק היחיד של הסוכן אל המציאות | תיאור כלי לא מדויק מוביל לשימוש שגוי גם במודל מצוין |
| זיכרון והקשר | מה הסוכן יודע ברגע ההחלטה | מידע חשוב שנדחק החוצה, או הקשר מזוהם שגורר את הסוכן למסלול שגוי |
| בקרה | מגבלות, הרשאות, תקציב צעדים ונקודות אישור | אין דרך לעצור טעות לפני שהיא נוגעת בלקוח או במערכת |
בפרויקטים שאנחנו רואים, כשמשהו לא עובד התגובה הראשונה היא כמעט תמיד להחליף מודל. ברוב המקרים זו לא הבעיה. תיאור כלי מדויק, פלט מובנה במקום טקסט חופשי, והגדרה ברורה של תנאי עצירה — משפרים את שיעור ההצלחה יותר מכל שדרוג מודל.
שכבת הכלים: מה באמת השתנה עם MCP
עד לא מזמן כל חיבור בין מודל למערכת ארגונית נכתב מחדש: אינטגרציה ייעודית לכל צירוף של מודל ומערכת. Model Context Protocol החליף את זה בשכבה אחידה — שרת שמצהיר על כלים, ולקוח שמפעיל אותם.
הגרסה היציבה של המפרט, מ-28 ביולי 2026, היא הרוויזיה הגדולה ביותר בפרוטוקול מאז שהושק. הוסרו ה-sessions ברמת הפרוטוקול וכותרת Mcp-Session-Id מתעבורת Streamable HTTP; בוטלה לחיצת היד של initialize; רשימות הכלים, המשאבים והפרומפטים הפכו זהות בין חיבורים ולכן ניתנות לקאשינג. במקביל נוספו בקשות מרובות סבבים, ניתוב מבוסס כותרות, מסגרת הרחבות פורמלית והקשחה של שכבת ההרשאות. שרת שצריך מצב בין קריאות מקבל אותו כעת דרך מזהה מפורש שהשרת מנפיק ומועבר כארגומנט רגיל.
למה זה מעניין גם מי שאינו כותב קוד: פרוטוקול חסר מצב אפשר לפרוס מאחורי איזון עומסים סטנדרטי, לשכפל אופקית ולנטר בכלים רגילים. במילים אחרות, שכבת הכלים הפסיקה להיות פרויקט מחקר והפכה לרכיב תשתית שאפשר לתקצב, לתפעל ולבקר. מי שמריץ את השכבה הזו על תשתית משלו ימצא את מודל העלות המלא במדריך להרצת סוכנים על חומרה שלכם.
הקשר הוא תקציב, לא מאגר
הטעות הרווחת ביותר בעיצוב סוכנים היא להתייחס לחלון ההקשר כאל מקום אחסון. הוא לא. הוא תקציב שנצרך בכל צעד, ומשלמים עליו בכל קריאה מחדש. סוכן שרץ עשרים צעדים משלם על ההיסטוריה שלו עשרים פעם.
מכאן נגזרות שלוש החלטות תכנון: להחזיר מהכלים פלט מובנה ומצומצם ולא מסמכים שלמים; לדחוס את ההיסטוריה לסיכום מצב אחרי מספר צעדים קבוע; ולשלוף ידע ארגוני בזמן אמת במקום להטעין אותו מראש. מי שרוצה את הצד הכספי של ההחלטות האלה ימצא אותו במדריך להורדת עלות ה-inference.
איפה זה נשבר בפועל
שלוש סיבות מסבירות את רוב הכשלים שאנחנו פוגשים.
שגיאות מצטברות. בלולאה, טעות בצעד שלישי אינה נשארת בצעד השלישי. היא נכנסת להקשר, ומשם מזינה את כל ההחלטות שאחריה. התוצאה היא שהכשל הנראה לעין מופיע רחוק מאוד מהמקום שבו הוא נוצר, ולכן דיבוג של סוכן דורש מעקב אחרי מסלול מלא ולא אחרי תשובה בודדת.
מדידה אופטימית. מדד ההצלחה הנפוץ בודק אם הסוכן הצליח פעם אחת בתנאים נוחים. בייצור מה שקובע הוא היציבות: אותה משימה, מאה הרצות, כמה מהן הסתיימו נכון. הפער בין שני המספרים האלה הוא הפער בין הדגמה מרשימה לבין מערכת שאפשר לסמוך עליה. הדרך לסגור אותו מפורטת במדריך ה-evals לסוכנים.
סוכנים מדומים. Gartner מעריכה שמתוך אלפי ספקים שמשווקים סוכנות, רק כ-130 מציעים יכולת אמיתית; השאר עוסקים במה שהיא מכנה agent washing — מיתוג מחדש של עוזרים, RPA וצ׳אטבוטים קיימים. השאלה שמסננת הכי מהר בשיחת מכירה: אילו כלים הסוכן יכול להפעיל, ומי מחליט מתי הוא מפעיל אותם.
אותה הערכה של Gartner מכילה גם את הצד השני: עד 2028 כ-15% מהחלטות העבודה היומיומיות יתקבלו אוטונומית, ו-33% מיישומי התוכנה הארגוניים יכללו יכולת סוכנית — לעומת פחות מ-1% ב-2024. הכיוון ברור; מה שנשבר הוא הקצב והציפיות.
רשימת בדיקה לפני הסוכן הראשון
- הגדירו משימה אחת שנגמרת. משימה עם תנאי סיום חד-משמעי, לא תחום אחריות פתוח.
- ספרו את הכלים. אם יש יותר מעשרה כלים בסוכן ראשון, כנראה מיפיתם תפקיד ולא משימה.
- כתבו את תיאורי הכלים כמו חוזה. מה נכנס, מה יוצא, מה קורה בכשל, ומתי אסור להפעיל אותו.
- קבעו תקציב צעדים ותקציב טוקנים. תקרה קשיחה שעוצרת את הלולאה גם כשהמודל משוכנע שהוא בדרך הנכונה.
- סמנו את הפעולות הבלתי הפיכות. שליחת מייל, חיוב, מחיקה, עדכון סטטוס מול לקוח — כל אלה דורשים נקודת אישור אנושית.
- הגדירו הרשאות לפני שכותבים פרומפט. מודל ההרשאות הוא מה שמגביל נזק, לא ניסוח ההוראות. הפירוט המלא נמצא במדריך גבולות הגזרה.
- הקליטו כל מסלול. בלי לוג מלא של קריאות ותוצאות אין דיבוג ואין שיפור.
מי שמעדיף להתחיל מבדיקת מוכנות מסודרת של הארגון יכול להתחיל מאבחון האסטרטגיה הדיגיטלית, ומי שכבר יודע מה הוא רוצה להריץ ימצא את שלב היישום בעמוד הפריסה.
שאלות נפוצות
מה ההבדל בין סוכן AI לבין אוטומציה רגילה?
באוטומציה סדר הפעולות נקבע מראש על ידי מפתח. בסוכן המודל בוחר את הפעולות בזמן ריצה לפי המטרה ולפי מה שהוא רואה. לכן אוטומציה נבדקת לפי נתיבים ידועים, וסוכן נבדק לפי התפלגות תוצאות על פני הרצות חוזרות.
האם צריך מודל חזק במיוחד כדי לבנות סוכן?
ברוב המקרים לא. שיעור ההצלחה נקבע יותר על ידי איכות תיאורי הכלים, ניהול ההקשר ותנאי העצירה מאשר על ידי בחירת המודל. מודל חזק יותר מסתיר בעיות תכנון לזמן מה, אך גם מייקר כל צעד בלולאה.
מה זה MCP ולמה כולם מדברים עליו?
Model Context Protocol הוא פרוטוקול אחיד לחיבור מודלים לכלים ולמקורות מידע. הגרסה היציבה מ-28 ביולי 2026 הפכה אותו לחסר מצב: אין יותר sessions ברמת הפרוטוקול, רשימות הכלים ניתנות לקאשינג, ושכבת ההרשאות הוקשחה. בפועל זה מאפשר לפרוס שכבת כלים כתשתית רגילה במקום כפרויקט חד-פעמי.
כמה זמן לוקח להעלות סוכן ראשון לייצור?
משימה יחידה עם שלושה עד חמישה כלים ונקודת אישור אנושית מגיעה בדרך כלל לייצור בתוך ארבעה עד שמונה שבועות. רוב הזמן אינו הולך לבניית הלולאה אלא לחיבור מסודר למערכות, להגדרת ההרשאות ולבניית מערך הבדיקות.
מה הסימן שסוכן אינו מתאים למשימה?
אם אפשר לכתוב את התהליך כתרשים זרימה מלא בלי החלטות עמומות, לא צריך סוכן — אוטומציה תהיה זולה יותר, מהירה יותר וניתנת לבדיקה. סוכן משתלם כשמרחב האפשרויות רחב מדי מכדי לכתוב אותו מראש.
