הגדירו לסוכן מטרה תחומה, מקורות מידע מאושרים, בדיקת תוצאה ונקודות עצירה לאישור. בדוח מבוסס נתונים הפרידו בין חישוב שאפשר לבדוק לבין הפרשנות של המודל. התחילו מתהליך אחד שבו אתם מכירים את התשובה, ותעדו גם את המקרים שבהם הסוכן צריך לעצור ולבקש עזרה.
בפוסט שלי על סדנת הסוכנים עם Google Israel תיארתי שבע משימות שתורגלו בשלוש שעות: מקמפיין ודשבורד ועד מחקר שוק, תדריך הנהלה וניתוח נתונים. זו התנסות מסוימת שסיפרתי עליה, לא התחייבות שכל ארגון יספיק אותו היקף.
מה שעניין אותי במיוחד היה המבנה. מחשבים פתוחים, עבודה על תוצרים, חיבור למידע ובדיקות לאורך הדרך. הפוסט נצפה ב־18.10.2026 עם הסימון "3w • Edited"; תאריך הפרסום המדויק עדיין לא אומת.
מתוך פוסט המקור: "סוכן יעיל חייב נקודת עצירה שבה בן אדם מאשר את הפעולה."
מאיפה הסוכן יודע את מה שהוא אומר?
בכל דוח הנהלה בקשו להבחין בין שלושה דברים: עובדה מהמקור, חישוב שנעשה על הנתונים ומסקנה של הסוכן. אלה שכבות שונות, ולכן גם בודקים אותן אחרת.
עובדה צריכה הפניה שאפשר לפתוח. חישוב צריך לוגיקה שאפשר לשחזר. מסקנה צריכה להסביר על אילו הנחות היא נשענת ומה עוד חסר כדי לקבל החלטה.
Google מגדירה Grounding כחיבור הפלט למידע שניתן לאמת. חיבור כזה עוזר לבסס את העבודה, אבל עדיין צריך לבדוק שהמקור מתאים לשאלה ושהמסקנה אינה מרחיקה מעבר למה שהוא אומר.
למה חשוב להפריד חישוב מפרשנות?
אם אתם מנתחים הכנסות, בקשו להגדיר קודם מה נחשב הכנסה, מה התקופה ואילו רשומות נכללות. אחרי זה בדקו את החישוב מול דוגמה מוכרת. רק אז בקשו הסבר על המגמה.
בפוסט כתבתי על שימוש בקוד לחישובים שניתן לבדוק. המטרה היא לא להפוך כל מנהל למתכנת. המטרה היא להימנע ממצב שבו מספר מופיע בפסקה ואין דרך להבין איך נוצר.
גם קוד יכול להיות שגוי. צריך לבדוק את ההגדרות, את הנתונים שנכנסו ואת התוצאה. הרצה מוצלחת אינה אישור שהלוגיקה העסקית נכונה.
איפה האדם צריך להיכנס לתהליך?
בעיניי, נקודת האישור צריכה להגיע כשהתוצר כבר ברור לבדיקה. סוכן רכש יכול לרכז חלופות והמלצה. מי שמאשר צריך לראות את הספק, ההיקף, ההנחות והפעולה שהסוכן עומד לבצע.
הגדירו מראש מי מאשר, מה הוא רואה ומה קורה בלי אישור. לפני בחירת מערכת, בדקו שהמנגנון הקיים באמת עוצר את הפעולה ומאפשר לאדם לקבל את ההחלטה. הנחיה כתובה לסוכן אינה הוכחה שקיימת עצירה טכנית.
הערת מקור לטיוטה: בתיעוד הבדיקה מ־18.10.2026 נשמר קישור לתיעוד Workflow Builder של Google. זמינות היכולת לא אומתה מחדש במסגרת עדכון זה, ולכן המאמר אינו נשען עליה כהבטחת מוצר עדכנית.
דוגמה: קובץ ההכנסות החסר
נניח שביקשנו טיוטת תדריך הנהלה לחודש מסוים מתוך שני קבצים מאושרים: הכנסות והוצאות. זו דוגמה מוצעת לבדיקה, ולא תיאור של משימה מהסדנה.
| מצב | ההתנהגות המצופה |
|---|---|
| שני הקבצים קיימים והתקופה תואמת | הסוכן מחשב לפי ההגדרות ומציג מקורות ולוגיקה לבדיקה |
| קובץ ההכנסות חסר | הסוכן עוצר לפני חישוב הרווח ומציין איזה קובץ ואיזו תקופה חסרים |
| נמצא רק קובץ הכנסות מהחודש הקודם | הסוכן אינו מחליף בו את הקובץ החסר בלי החלטה מפורשת של בעל התהליך |
| הקובץ החסר הגיע | הסוכן בודק התאמת תקופה ומבנה, מריץ מחדש את החישוב ומציג טיוטה לאישור |
בדיקת הקבלה פשוטה: מסירים במכוון את קובץ ההכנסות מעותק נתוני ההדגמה. תשובה שמציגה רווח מלא או ממציאה הכנסה נכשלת בבדיקה. תשובה שמזהה את החוסר ועוצרת במקום שהוגדר עומדת במקרה הזה; היא אינה מוכיחה לבדה שכל שאר המקרים תקינים.
צ'קליסט לתהליך הראשון
- כתבו תוצאה אחת רצויה. למשל טיוטת תדריך הנהלה עם מקורות.
- הגדירו רשימת מקורות והיקף הרשאות. מידע חסר צריך להיות מסומן כחסר.
- הביאו דוגמה שהצוות כבר בדק. היא תהיה בסיס להשוואה.
- הפרידו איסוף, חישוב וניסוח. כך אפשר להבין איפה נוצר פער.
- קבעו נקודת אישור לפני פעולה שיוצאת מהטיוטה לביצוע.
- בדקו מקרה חריג: קובץ חסר, שדות לא תואמים או מקורות שסותרים זה את זה.
- מנו אחראי שיבדוק את התוצאות והעדכונים גם אחרי ההרצה הראשונה.
אפשר להתחיל כך: "הכן טיוטת תדריך מהמקורות המצורפים בלבד. לכל נתון ציין מקור. הפרד בין עובדות למסקנות. אם חסר מידע, כתוב מה חסר. אל תשלח ואל תבצע פעולה בשם הארגון."
לשלב הבנייה הראשוני קראו את המדריך ל־Google Workspace Studio. להקשר הרחב קראו את סקירת כנס Google Cloud. המאמר הזה מתמקד בשאלת האמון והבקרה על התוצר.
שאלות נפוצות
האם קישור למקור מספיק כדי לאשר דוח?
לא. בדקו שהמקור תומך בטענה, מתייחס לתקופה הנכונה ושלא חסרים נתונים שמשנים את התמונה.
האם כל סוכן חייב לפעול לבד?
לא. טיוטה טובה לבדיקה יכולה להיות נקודת התחלה מועילה מאוד.
איך בוחרים תהליך ראשון?
בחרו תהליך עם בעל אחריות ברור, קלט זמין ותוצאה שהצוות יודע לבדוק.
האם שלוש שעות מספיקות לפריסה ארגונית?
הן תיאור הסדנה שבפוסט. פריסה ארגונית כוללת התאמות, הרשאות, בדיקות ותפעול לפי המקרה.
