בלוג ← BUILD AN AGENT

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

בן קלסקי · CTO, DIGITIZER06.08.2026

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

המפרט שנכתב לפני שורת הקוד הראשונה

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

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

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

שלוש רמות הרשאה, ולמה רוב הסוכנים עוצרים בשנייה

אני עובד עם מדרג פשוט. הוא לא תיאורטי, הוא מה שמנהל מוכן לחתום עליו:

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

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

חיבור למערכות: כאן הסוכן מפסיק להיות צעצוע

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

אפשר לחבר סוכן בכמה דרכים: ‏API ייעודי לכל מערכת, ‏SDK של הספק, או MCP. אני מעדיף את האחרון כשיש יותר משתי מערכות בתמונה, כי הוא נותן לסוכן ממשק אחיד אחד במקום ממשק נפרד לכל כלי. ‏מה שהוא לא עושה זה לבטל את החיבור למערכת עצמה: מאחורי כל שרת MCP עדיין יושבת אינטגרציה ל-API או ל-SDK של אותו CRM, מייל או מערכת חשבוניות. ‏MCP מייתר את השכבה שמול הסוכן, לא את זו שמול המערכת, ומי שמתמחר לכם לפי ההנחה השנייה מתמחר פרויקט אחר. מה שחשוב לדעת כלקוח הוא לא הפרוטוקול אלא שלושת הכללים שמסביבו: הרשאה נפרדת לכל מערכת, הפרדה מפורשת בין קריאה לכתיבה, ותיעוד של כל פעולה שהסוכן ביצע. מי שמציע לכם לחבר סוכן עם משתמש אדמין אחד כדי לחסוך זמן, חוסך את הזמן שלו ולא שלכם.

לחבר בלי לכתוב קוד: n8n כגשר בין הסוכן למערכות

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

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

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

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

הפיילוט: להריץ לצד הצוות, לא במקומו

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

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

מה עולה, ומה באמת חוזר

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

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

ארבע טעויות שאני רואה חוזרות

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

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

מתי ההזמנה הנכונה היא לא סוכן

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

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

שאלות ותשובות