פרק 5 מתוך 8 Skill-Building Owner-as-Operator

Owner-as-Operator: אוטונומיה, אישורים, ואיפה אתה נשאר ב-Loop

בפרק הקודם בנית מנוע — סוכן שרץ ב-cron, מנקד את עצמו ב-eval gate, וכותב לקח ב-reflexion בזמן שאתה ישן. עכשיו השאלה הקשה: מה מותר לו לעשות בלי לשאול אותך? זו לא שאלה טכנית. זו שאלת הניהול המכרעת שמגדירה אם תוכל באמת לנהל עסק שלם לבד — או שתשכב ער ב-2 בלילה ותתפלל שהסוכן לא שלח הצעת מחיר שגויה ללקוח הגדול ביותר שלך. בפרק הזה נעבור מתפיסה של "מערכת אוטומטית" לתפיסה של "ארגון מנוהל", שבו אתה המנכ"ל שקובע את גבולות הסמכות באופן אכיף ומדיד. שלושה מושגי יסוד יחזרו בכל סעיף: אוטונומיה (מה הסוכן רשאי לעשות בלי לשאול אותך), אישור (פעולה שהסוכן עוצר ומחכה לחתימה הדיגיטלית שלך), SOP (נוהל כתוב ב-Markdown שמגדיר לסוכן בדיוק מה מותר ומה אסור).

חוט הפרויקט

פרק 4 — "ה-Loop שעובד בזמן שאתה ישן": בנית סוכן שרץ בתזמון, מנקד את עצמו מול golden dataset, ומשתפר ב-reflexion. יצרת מנוע שעובד.

הפרק הזה — Owner-as-Operator: אתה מחליט מה ה-loop הזה מורשה לעשות לבד ומה דורש את החתימה שלך. אתה בונה מטריצת calibrated autonomy, approval gate חי על פעולת כסף, סולם autonomy פר-תפקיד שמתקדם לפי נתונים, ו-tripwires שמתריעים אליך רק כשחשוב.

פרק 6 הבא — "ה-P&L של הסוכנים": אחרי שהחלטת מה רץ לבד, נתמחר כמה זה עולה — ונראה שדווקא הסוכנים האוטונומיים הם אלה ששורפים הכי הרבה טוקנים ב-loop. האישורים שתבנה כאן הם גם בלם בטיחות וגם בלם עלות אדיר.

מה תדע לעשות בסוף הפרק

לסווג כל פעולת-סוכן בצי שלך לפי שלושה צירים קריטיים: reversibility (האם הפיכה), stakes (כמה עולה טעות) ו-confidence (כמה הסוכן בטוח בעצמו), ולנתב אותה ל-full autonomy או ל-human approval queue — זהו מודל ה-calibrated autonomy.
להגדיר approval gate מחמיר לכל פעולה שנוגעת בכסף / הרשאות / רשומות / state — עם סף ב-₪ ו-named approver מפורש, המבוסס על חוקי RFC 2119.
לבנות סולם autonomy פר-תפקיד שמתחיל ב-human-in-the-loop ומטפס ל-human-on-the-loop רק אחרי ש-eval pass-rate חוצה סף מספרי שאתה קובע מראש.
להגדיר tripwires אגרסיביות — retries רבים, מקורות סותרים, diff גדול — שמתריעים אליך באופן סלקטיבי במקום לחייב אותך לצפות בכל פעולה ופעולה.

מה צריך לפני הפרק הזה

פרק 1 — המודל של owner-as-operator / vibe CEO וה-"2am escalation": ה-operator עדיין עובד, וה-loop האוטומטי לא מבטל אותך אלא משנה את תפקידך.
פרק 2 — scope of authority ו-escalation path פר-תפקיד ב-org chart. כאן נהפוך אותם לכללים אכיפים ברמת המערכת.
פרק 3 — ה-SOPs האגנטיים (AOPs) שלך עם RFC 2119 (MUST / SHOULD / MAY). את ה-approval gates נשתול בתוך ה-SOPs כצעדי MUST.
פרק 4 — ה-eval gate וה-golden dataset. ה-pass-rate שלהם הוא הדלק האובייקטיבי שמאפשר לטפס בסולם ה-autonomy בבטחה.

מה תפיק בפרק הזה (3 תוצרים)

מטריצת calibrated autonomy לצי: טבלה מקיפה שבה לכל סוג פעולה → reversibility / stakes / confidence → ההחלטה: autonomous או approval. מסמך החלטה אחד שממפה את כל הצי.
approval gate חי ופעיל על פעולת כסף אחת (למשל הצעת renewal ללקוח קיים) — עם סף ב-₪, named approver, ו-one-click approve / reject בתוך ערוץ תקשורת ייעודי.
מפת סולם autonomy פר-תפקיד: מסמך המפרט היכן כל תפקיד יושב היום, מהו סף ה-eval pass-rate לטיפוס לשלב הבא, ורשימת ה-tripwires שמתריעות אליך.

למה זו בכלל העבודה שלך עכשיו

מסגור owner-as-operator המשמעת הניהולית

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

זכור את הגבול הכן מפרק 1, מתוך ה-research של הקורס: "מישהו עדיין צריך לנהל את הסוכנים; זה אתה, ב-2 בלילה, כשלקוח מסלים תקלה שהבוט פספס." הצי לא מבטל את ה-operator — הוא משנה את תפקידו מהיסוד. במקום לבצע משימות (לכתוב, למחוק, לשלוח), אתה מתכנן איפה אתה נשאר ב-loop ואיפה אתה יוצא ממנו. זו לא משימה צדדית של אינטגרציה. זו כל המשמעת הניהולית של ה-vibe CEO. אתה עובר מלהיות מתכנת ללהיות מחוקק ושופט בעסק שלך.

תחשוב על זה כמו על מנכ"ל אמיתי בחברה אמיתית. מנכ"ל לא חותם על כל הזמנת קפה למשרד ולא מאשר כל מייל שיווקי — אבל הוא כן חותם על חוזה רב-שנתי של חצי מיליון שקל. ההבדל בין השניים הוא בדיוק מה שאנחנו לומדים לקודֵד כאן: איזה פעולות זולות והפיכות מספיק כדי לתת להן לרוץ, ואיזה יקרות ובלתי-הפיכות מספיק כדי לדרוש את העין שלך ואת החתימה הדיגיטלית שלך. בעולם של סוכנים, ההחלטה הזו לא נשארת בראש או במסמך אקסל – היא נכתבת ככלל ברזל, נשתלת ב-SOP, ונאכפת ב-runtime שאינו מתפשר.

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

עשה עכשיו (5 דקות)

פתח את ה-org chart מפרק 2. עבור על 4-6 התפקידים שלך וכתוב ליד כל אחד שתי פעולות קונקרטיות לחלוטין שהוא מבצע (למשל: "סוכן מכירות → שולח הודעת follow-up לליד חדש", "סוכן כספים → מייל אישור חידוש מנוי"). זה ה-raw material שנסווג בהמשך הפרק. אל תסווג שום דבר עדיין — רק רשום את הפעולות בצורה ברורה.

Calibrated Autonomy: שלושת הצירים שמחליטים הכל

מושג ליבה calibrated-autonomy routing

Calibrated autonomy (אוטונומיה מכוילת) הוא העיקרון המרכזי של הפרק ושל העסק כולו. במקום השאלה הבינארית והילדותית "האם לתת לסוכן אוטונומיה?", הוא שואל שאלה מכוילת ובוגרת: אוטונומיה לְאיזו פעולה בדיוק? לפי ה-research של הקורס, הכלל התעשייתי ל-2026 הוא ברור: "full autonomy ל-high-confidence + reversible + low-stakes; uncertain / irreversible / high-risk → approval queue."

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

הציר	השאלה שאתה שואל	אוטונומי כש...	דורש אישור כש...
Reversibility (הפיכוּת)	אם הפעולה הזו יוצאת שגויה — אפשר לבטל אותה בקלות ובלי נזק משמעותי?	הפיך לחלוטין — טיוטת מסמך, תיוג פנימי, סיכום פגישה, שאילתת קריאה ממסד נתונים.	בלתי-הפיך או קשה להפיכה — שליחת אימייל חיצוני ללקוח, חיוב כרטיס אשראי, מחיקת רשומת לקוח מה-CRM.
Stakes (מה על הכף)	כמה תעלה טעות אחת — בכסף, באמון הלקוח, במוניטין העסקי?	נמוך — תיוג פנימי, עדכון סטטוס טכני, יצירת רשימת רעיונות.	גבוה — הצעת מחיר, ביטול מנוי של לקוח, מענה לקודם ללקוח כועס, הוצאת חשבונית כפולה.
Confidence (ביטחון מדווח)	כמה הסוכן עצמו בטוח בפלט שהוא מפיק?	גבוה — תשובה אחת ברורה, נשען על מקור יחיד עקבי, מצב שגרתי.	נמוך — התשובות סותרות, נדרשו מספר ניסיונות חוזרים, חוסר התאמה פנימית ל-SOP.

הכלל הפרקטי הוא מחמיר: פעולה צריכה לקבל "ירוק" בכל שלושת הצירים (AND לוגי) כדי לרוץ אוטונומית ללא התערבות. מספיק שציר אחד יהיה אדום — בין אם היא בלתי-הפיכה, או יקרה מדי, או שהסוכן לא בטוח בעצמו — והפעולה מנותבת אוטומטית ל-approval queue. זה לעולם לא ממוצע. כי הנזק הכספי והמוניטינרי מ-stake גבוה אחד מוחק בשנייה את כל החיסכון בזמן מאלף פעולות אוטונומיות מוצלחות שעשית באותו יום. אין כאן שיקול דעת הסתברותי של "בוא נסתכן", יש כאן שמירת חיים עסקית.

Framework #1 — מסנן ה-AUTONOMY: "אם X אז Y"

החל את המסנן הבא על כל פעולה ב-org chart שרשמת ב-do-now הראשון. אין יוצא מן הכלל:

אם הפעולה הפיכה לחלוטין וגם היא low-stakes וגם ה-confidence של הסוכן גבוה → אז full autonomy. תן לה לרוץ בלי לשאול אותך דבר.
אם הפעולה בלתי-הפיכה או נוגעת ישירות בכסף / הרשאות / רשומות / state → אז approval gate הוא חובה, גם אם ה-confidence מהשמיים וגם אם הסוכן צדק 10,000 פעם בעבר.
אם ה-confidence של הסוכן נמוך או שנדלקה tripwire נסתרת (נראה מיד) → אז route ל-review, גם אם הפעולה לכאורה טכנית והפיכה לחלוטין.
אם אתה לא בטוח בעצמך לאיזו קטגוריה הפעולה שייכת → אז ברירת המחדל היא תמיד approval. אתה תוריד את הגדר בעתיד לפי נתונים ומדדים, לא להפך.

למה ברירת המחדל לפעולה לא ברורה היא approval ולא autonomy: בגלל אי-סימטריה קיצונית בעלויות. טעות של אוטונומיה מוגזמת עולה לך בנזק יקר לפני שגילית אותה (או בכלל לא גילית אותה). לעומת זאת, אישור מיותר עולה לך רק 30 שניות מזמנך. אי-הסימטריה הזו מכתיבה את כיוון הזהירות תמיד.

טעות נפוצה: לתת אוטונומיה מלאה על פעולות בלתי-הפיכות בלי approval gate בכדי "לחסוך זמן"

זו טעות מספר 1 של operators מתלהבים בתחילת דרכם. נתת לסוכן הכספים אוטונומיה מלאה לשלוח הצעות renewal "כי הוא כל כך חכם ותמיד צודק" — עד הפעם שבה הוא שלח ללקוח הגדול ביותר הצעה עם מחיר ישן שנמוך ב-30% מהמחירון המעודכן, והלקוח, בצדק חוקי מוחלט, תפס אותך במילה ובמחיר. תקלה אחת על פעולה בלתי-הפיכה עולה יותר מכל החיסכון של חודשים של אוטומציה. הכלל: כל פעולה שמשנה כסף / הרשאות / רשומות / state מקבלת gate — ללא יוצא מן הכלל.

Human-IN-the-Loop מול Human-ON-the-Loop

מושג ליבה in-vs-on שתי תנוחות פיקוח

ברגע שהחלטת שפעולה מסוימת לא רצה באוטונומיה מלאה, יש לך שתי תנוחות פיקוח עיקריות — וההבדל ביניהן הוא ההבדל בין operator שמרוויח זמן ומטפח סקייל, לבין operator שנשאר צוואר בקבוק של העסק שלו עצמו. ה-research של הקורס מנסח אותן במדויק: "in = אישור לפני פעולה; on = ניטור והתערבות רק בעת הצורך."

מאפיין	Human-IN-the-loop (אישור מוקדם)	Human-ON-the-loop (ניטור ובקרה)
מתי אתה מעורב	לפני כל פעולה — הסוכן עוצר מיידית, מקפיא את הרצת המשימה וממתין לחתימה הדיגיטלית שלך.	אחרי הפעולה — הסוכן כבר פעל בעולם האמיתי, אתה רואה את התוצאה בדאשבורד ויכול להתערב/לתקן בדיעבד.
מה בפועל אתה עושה	בודק, מאשר / דוחה / עורך ידנית כל מקרה ומקרה נכנס.	מנטר זרם של יומנים (logs), מתערב רק כשנורה אדומה (tripwire) נדלקת במערכת ההתראות.
עלות תשומת הלב שלך	גבוהה מאוד — אתה תקוע בלולאה כל הזמן ונעצר מעבודת האסטרטגיה שלך.	נמוכה מאוד — אתה מחוץ ללולאת הביצוע רוב הזמן, ומופיע רק לכיבוי שריפות.
מתאים ל...	תפקיד חדש לחלוטין, פעולה יקרה במיוחד, או כשעדיין אין לך אמון ב-SOP (או בסוכן).	תפקיד מנוסה וותיק, שעבר היסטוריה ארוכה של פעולות נכונות ויש לו eval pass-rate גבוה ויציב.
הסיכון הטמון	הופך אותך לצוואר הבקבוק האנושי שניסית לברוח ממנו כשפתחת את העסק.	פעולה רעה ובלתי-הפיכה כבר קרתה בעולם האמיתי לפני שהספקת לראות אותה (לכן משתמשים בזה רק לפעולות הפיכות!).

שים לב לטרייד-אוף המובנה: human-in בטוח הרבה יותר, אבל מחזיר אותך לתפקיד הביצועי השחור של פקיד אישורים. human-on משחרר אותך סופית לעשייה אסטרטגית, אבל מקבל פעולות רק אחרי שהן כבר קרו במציאות. אף אחד מהם לא נכון "תמיד" ובאופן גורף — התנוחה הנכונה לכל תפקיד נקבעת אך ורק לפי כמה הוא הוכיח שאפשר לסמוך עליו לאורך זמן ומול נתונים קשיחים. וזה בדיוק מה שסולם ה-autonomy (בהמשך הפרק) הופך לתהליך מסודר, מדעי ומבוסס-נתונים במקום החלטה תחושתית של "נדמה לי שהוא מוכן".

אנלוגיה ניהולית לחיים: human-in-the-loop זה כמו לחתום באופן אישי על כל המחאה שהעוזר הזוטר שלך כותב, כשאתה בודק את החשבונית מול כל קבלה. human-on-the-loop זה לתת לאותו עוזר פנקס המחאות עם תקרת סכום מאושרת מראש, ולעבור על דפי הבנק בסוף השבוע רק כדי לוודא שלא יצא דבר חריג. אתה לעולם לא מתחיל את העבודה עם העוזר במתן פנקס פתוח — אתה מרוויח את זה במו ידיך לאורך זמן, ובעולם ה-AI קוראים לזה "לעלות בסולם".

עשה עכשיו (3 דקות)

קח את רשימת הפעולות שיצרת ב-do-now הראשון. ליד כל פעולה כתוב אות אחת בלבד: A (autonomous — רצה לבד לגמרי), I (human-in — דורש את אישורך המוקדם לפני ביצוע), או O (human-on — הסוכן מבצע ואתה רק עובר על זרם הנתונים אחר כך). אל תתלבט יותר מ-10 שניות על כל פעולה — האינסטינקט הראשוני שלך לרוב צודק, ואנחנו נחדד ונכייל את זה בהמשך הפרק. ספור בסוף: כמה A קיבלת? כמה I, וכמה O? אם סימנת הכל כ-A — אתה אופטימי מדי וקרוב לאסון. אם הכל I — אתה עדיין תקוע בעבודה סיזיפית וצוואר בקבוק של עצמך.

Confidence != Correctness: ה-Blind Spot של ניתוב לפי ביטחון

מלכודת confidence-routing tripwires

הדרך הנפוצה והקלה ביותר לנתב פעולות באופן אוטומטי בצי של סוכנים היא confidence-based routing: הסוכן נדרש לדווח בעצמו על ציון ביטחון (confidence score) לפעולה שלו, ומעל סף מסוים שנקבע מראש — הוא פועל לבד; מתחת לסף — הוא הולך ל-review. זה נשמע הגיוני ונקי — ובדיוק בגלל זה הוא מסוכן. דוגמה מספרית אחת: סוכן המכירות שלך מסמן להצעת renewal ב-₪4,200 עם ביטחון 0.96. ה-gate הישן רואה 0.96 ומאשר אוטומטית. בפועל הצעה זו הציגה תאריך חידוש שגוי ב-3 חודשים ומחיר שמבוסס על מחירון ישן שירד מהמלאי ב-2024. הציון 0.96 לא אמר שום דבר על הנכונות — והלקוח הגדול שלך קיבל הצעה שגויה.

ה-research של הקורס מנסח את הבעיה ישירות ובאכזריות: "confident-but-wrong עובר gate נאיבי." מודל שפה גנרטיבי (LLM) יכול להיות בטוח לחלוטין ושגוי לחלוטין בדיוק באותו הרגע נתון. הביטחון שהוא מדווח עליו אינו מודד הסתברות אמיתית לנכונות בעולם האמיתי — הוא תוצר סטטיסטי מובהק של איך נוסחה השאלה (prompt) ומה היה ההקשר המידע שהוזן לשיחה (context). סוכן שהמציא מחיר שלא קיים לשירות שלך, יכול לדווח עליו ב-confidence של 0.95 באותה קלות וודאות רבה שבה ידווח על מחיר נכון ומעודכן לגמרי. הוא לא משקר לך, הוא פשוט ניבא טקסט בעליזות שגויה — במינוח מקצועי זה נקרא hallucination (הזיה), וזו לא תקלה שמתקנים אלא תכונה מובנית של המודל.

הפתרון לבעיה הקיומית הזו: אל תנתב על confidence לבד, אף פעם. נתב גם על סמך אותות התנהגותיים וטכניים שמסגירים בעיה בעליל, גם כשהסוכן "בטוח במאה אחוז". אלו הן ה-tripwires (חוטי מתיחה נסתרים). מתוך ה-research המרכזי של 2026:

סוג Tripwire	מה זה מסמן בפועל	למה בהכרח לנתב ל-review
Retries רבים	הסוכן ניסה לבצע את אותה המשימה שוב ושוב (לפני שליחה, חישוב, וכו') בטרם הגיע לתשובה הסופית שלו.	אם המשימה הייתה פשוטה וברורה, זה היה עובד בניסיון הראשון או השני. ריבוי ניסיונות = אי-ודאות מבנית ומשהו לא יושב בנתונים עצמם.
מקורות סותרים	ההקשר (RAG / חיפוש רשת) שהזנת לסוכן הכיל שני מקורות מידע שלא מסכימים עם עצמם (למשל: מחירון ישן מול חדש).	הסוכן נאלץ לבחור צד באופן שרירותי למדי — אולי הוא בחר בצד הלא נכון. במקרה כזה רק אדם (אתה) צריך להכריע ולבדוק לעומק.
Diff גדול	הפלט שהסוכן הפיק שונה משמעותית ובצורה קיצונית מהצפוי לפי ה-SOP, או מהתוצאה של הפעם הקודמת שביצע את אותה פעולה.	שינוי חד וגדול בתוצאה = או שמדובר בפריצת דרך מבורכת, או (ברוב המקרים) בבאג מערכתי. שתיהן תוצאות ששוות הצצה ומבט אנושי.
חריגה מ-SOP	הסוכן החליט לבצע צעד שכלל לא מופיע ב-SOP הנוקשה שלו, או עשה פעולה בסדר שגוי מזה המצופה.	אילתור והמצאה מחוץ ל-scope שנקבע. זה בדיוק מה שניסינו למנוע בכללים הקשיחים של פרק 3. אי אפשר לתת לזה אוטונומיה.

ה-tripwire היא AND מול ה-confidence, ולא OR מולו. כלומר, החוק האולטימטיבי הוא: confidence גבוה וגם שאף tripwire לא נדלקה בתהליך → אוטונומי. לעומת זאת: confidence גבוה אבל נדלקה tripwire אחת לפחות → ניתוב ל-review באופן מיידי. רק ככה אתה תופס מראש את המקרים הקלאסיים של confident-but-wrong שצצים בכל עסק, ושניתוב נאיבי וחלש מחמיץ בקלות.

טעות נפוצה: לסמוך על confidence לבד ככלי יחיד לאכיפת gate

בנית gate מרשים בקוד שאומר: "אם confidence > 0.9, הסוכן רשאי לפעול לבד לחלוטין." חודש אחרי העלייה לפרודקשן, הסוכן שולח תשובה שגויה באופן חרוץ ללקוח רגיש ב-confidence עקשני של 0.96. המודל לא שיקר לך ולא ניסה לרמות אותך — הוא פשוט היה משוכנע לחלוטין בתשובה שגויה מיסודה (hallucination). ביטחון הוא לא נכונות אובייקטיבית. אתה חייב לנתב גם על סמך אירועים התנהגותיים כמו retries / מקורות-סותרים / diff-גדול, אחרת בנית בעצם gate שעושה בדיוק את ההפך: הוא מסנן ביעילות את המקרים הקלים ומעביר בשלווה את הקשים והמסוכנים שבכולם.

תרגיל 1 — בנה את מטריצת ה-Calibrated Autonomy של הצי

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

שלבי העבודה:

פתח קובץ חדש בשם autonomy-matrix.md בתיקיית .context/ המרכזית של החברה (אותה יצרנו בפרק 3).
צור בתוכו טבלת Markdown עם 7 עמודות חובה בדיוק בסדר הזה (אל תוותר על אחת — בלי עמודה ריקה):
תפקיד | פעולה | reversible? | stakes | confidence-typical | tripwires רלוונטיות | החלטה (A / I / O).
מלא שורה מלאה ומדויקת לכל פעולה שרשמת ב-do-now הראשון. השתמש נאמנה ב-Framework #1 (מסנן ה-AUTONOMY) כדי להכריע על ההחלטה בכל שורה.
סמן בצבע עז (או בהדגשה ברורה בעמודה) כל שורה שבה ההחלטה היא I (אישור מוקדם) או O (ניטור) — אלו הן הפעולות שדורשות בניית gate או הגדרת tripwire פעילה בהמשך.
שמור את הקובץ והכנס אותו לבקרת הגרסאות: git add .context/autonomy-matrix.md && git commit -m "fleet autonomy matrix v1".

איך בדיוק ייראה הפלט (דוגמה מייצגת):

תפקיד	פעולה	reversible?	stakes	confidence-typical	tripwires רלוונטיות	החלטה
מחקר	סריקת מתחרים → דו"ח פנימי	כן	נמוך	0.93	—	A
תוכן	טיוטת פוסט (לא מתפרסם עדיין)	כן	נמוך	0.88	diff גדול	O
מכירות	שליחת follow-up לליד חם	לא	בינוני	0.91	—	I
כספים	הצעת renewal ללקוח קיים	לא	גבוה (₪)	0.96	diff / סתירה	I + gate

כלל ה-Money / Permissions / Records / State

מושג ליבה approval-gate הכלל שלא מתפשרים עליו לעולם

יש קטגוריה אחת ויחידה של פעולות בעסק שלך שלעולם לא מתפשרים עליה, וזה לא משנה כמה הסוכן המסוים מנוסה, ותיק, או חכם: פעולה שמבצעת שינוי או כתיבה לכסף, הרשאות, רשומות או state. ה-research של הקורס מנסח את הכלל הקפדני: "פעולה שמשנה כסף / הרשאות / רשומות / state מקבלת gate מחמיר יותר מ-retrieval קריאה-בלבד."

ההבחנה הבסיסית ביותר בארכיטקטורת מערכות מידע היא ההבדל הבינארי בין read (קריאה) ל-write (כתיבה). סוכן שרק קורא נתונים ומאחזר אותם — מושך דו"ח, סורק inbox, מחפש מידע ברשת — לכל היותר טועה בפרשנות הקריאה, ואתה קורא את הסיכום שלו ומתקן במחי עכבר. נזק אפסי. לעומת זאת, סוכן שכותב נתונים — שולח אימייל, מחייב כרטיס, מוחק רשומה, משנה הרשאה, מבצע deploy למערכת — משאיר חותם פיזי ומשפטי בעולם האמיתי. ה-Write הוא הפעולה שדורשת את ה-gate ללא כל פשרות, גם אם זה אומר שאתה מאבד קצת יעילות.

קטגוריית Write	דוגמאות נפוצות בעסק מבוסס סוכנים	סוג הנזק הפוטנציאלי	דרישת gate מינימלית
Money (כסף)	שליחת חשבונית באוטומציה, חיוב כרטיס אשראי של לקוח, מתן הנחה לא מאושרת, יצירת הצעת מחיר רשמית.	write בלתי-הפיך — הפסד ישיר של הכנסה או תביעה משפטית.	gate חובה מלא + סף ₪ + named approver.
Permissions (הרשאות)	הוספת משתמש חיצוני למערכת, מתן גישת אדמין לשרת, שיתוף קובץ סודי עם גורם חיצוני.	write בלתי-הפיך לחלוטין — דליפת מידע או חשבון שנפרץ.	gate חובה, אין מצב שעובדים בלי אישור מפורש.
Records (רשומות)	מחיקת לקוח רגיש מ-CRM היסטורי, עדכון חוזה קיים, שינוי סטטוס הזמנה ל-"בוטל".	write קשה-להפיכות — אובדן נתונים היסטורי קריטי או בלגן משפטי.	gate חובה בכדי למנוע השחתת מידע בטעות.
State (מצב מערכת)	deploy קוד לפרודקשן, שינוי קובץ config מרכזי, כיבוי שירות ענן חיוני, הרצת migration למסד נתונים.	write בלתי-הפיך — קריסה מיידית של פעילות העסק ודאונטיים יקר.	gate חובה עם שכבת אבטחה נוספת (למשל אימות דו-שלבי).
Retrieval (קריאה)	סריקה, חיפוש, סיכום, תיוג פנימי של נתונים קיימים.	read הפיך — אין נזק בלתי הפיך בעולם האמיתי, רק טעות בתוך מערכת סגורה.	בדרך כלל autonomous, ללא צורך ב-gate כלל.

שתי דרישות נוספות וקריטיות לכל פעולת כסף, ישירות מתוך ה-research שנבדק לעומק:

סף ₪ מפורש (Threshold): מתחת לסכום מסוים שקבעת — הסוכן יכול לפעול בעצמו (אם ורק אם שאר הצירים, כמו הפיכות, ירוקים); מעליו — אישור אנושי הוא חובה גמורה. למשל, בחוק של העסק: "מתן הנחות שיווקיות עד ₪200 יכול להתבצע אוטונומית; מעל ₪200 ועד אינסוף — מחייב את האישור המפורש שלי."
Named approver מלא (מאשר בשם): לא "מישהו מאשר את זה" אלא אתה מאשר באופן אישי, או אדם ספציפי ואחראי בשמו המלא. במודל ה-vibe CEO של חברה של איש אחד, ה-named approver הוא כמעט תמיד אתה באופן טבעי — וזה דווקא דבר טוב ומצוין: זה מכריח אותך לנסח בכתחילית מתי אתה חייב להיות בלולאת הביצוע כדי להגן על הונך והעסק שלך.

איפה הכלל הקשיח הזה חי וקיים בפועל בתוך המערכת שלך? בנקודת זמן זו, הוא חי בשלושה מקומות שונים (שכבות הגנה), שחלקם בנית כבר בפרקים הקודמים:

ב-scope of authority של התפקיד בארגון (פרק 2) — למשל, ייקבע שם: "סוכן הכספים MAY להציע הנחה עד ₪200 בלבד; MUST לקבל אישור מפורש מה-operator לכל סכום שמעל זה."
ב-Agent SOP כצעד MUST מובהק (פרק 3) — בתוך הוראות העבודה ייכתב במפורש: "לפני שליחת הצעת מחיר רשמית: MUST לעצור את הריצה, לכתוב את ההצעה לקובץ ולהמתין לאישור operator במידה והסכום > ₪200."
ב-runtime עצמו — זוהי שכבת האכיפה האולטימטיבית. בפלטפורמת orchestration שאוכפת את הכללים הללו אוטומטית ברמת השרת (כפי שנראה בהמשך עם Orloj ובפרק 7).

תרגיל 2 — בנה approval gate חי ופעיל על פעולת כסף אחת

תוצר גלוי ומוחשי: מערכת approval queue שעובדת מקצה לקצה — פעולת כספים שנעצרת על ידי הסוכן באופן אוטונומי, שולחת לך הודעה עשירה בהקשר לסלולרי/מחשב עם כל הנתונים הדרושים, וממתינה בסבלנות ללחיצת approve / reject שלך לפני שהיא יוצאת לעולם האמיתי.

הפעולה לדוגמה בתרגיל: סוכן הכספים מכין הצעת renewal (חידוש) שנתית ללקוח קיים. במקום לשלוח אותה ישירות ללקוח כפי שהיינו עושים באוטונומיה מלאה — הוא נעצר ב-gate.

שלבי העבודה (גרסה מינימלית, ללא צורך ב-framework כבד לריצה):

הוסף ל-Agent SOP של סוכן הכספים צעד MUST קשיח בתחביר מדויק: "MUST: לפני שליחת כל הצעת מחיר או חידוש לקוח, כתוב את ההצעה כקובץ JSON לנתיב .context/pending-approvals/ ועצור את כל פעולות העמקה. אל תשלח."
בנה הודעת webhook ל-operator (שילוב עם Telegram / סלאק / מייל ייעודי): שלח הודעה הכוללת את תקציר ההצעה — שם הלקוח, סכום ההצעה ב-₪, השינוי הדיפרנציאלי מהתקופה הקודמת (ה-diff הכלכלי), וסיבת ההצעה במשפט. הצמד להודעה שני כפתורי פעולה אינטראקטיביים: ✅ אשר ושלח · ❌ דחה וארכב.
הגדר את הכלל הכלכלי בשרת: סכום הצעה המעלה מחיר מעל סף ה-₪ שקבעת → תמיד gate ועצירה; מתחתיו (אם החלטת לאפשר זאת) → אוטונומי לחלוטין.
בלחיצת "אשר" על ידיך מהסלולר → הסוכן מקבל אישור, ממשיך ב-SOP ושולח בפועל את המייל ללקוח. בלחיצת "דחה" → הסוכן נכנס למצב reflexion וכותב לעצמו: "ההצעה נדחתה על ידי המנכ"ל כי..." (חיבור ישיר ל-loop שלמדנו בפרק 4).
בדיקה (Testing): צור הצעה אחת מעל הסף (תתבקש אישור) ואחת מתחתיו (תישלח אוטונומית). ודא שהראשונה נעצרה לחלוטין והשנייה עברה חופשי.

איך בדיוק תיראה הודעת ה-gate בסלולר שלך (דוגמה מייצגת):

🔔 אישור נדרש מיידי — הצעת renewal התקבלה בשרת
לקוח: סטודיו "אורבן דיזיין" · סכום חדש: ₪4,200/שנה (היה בשנה שעברה ₪3,800)
שינוי: +₪400 (העלאת מחיר שנתית מוצדקת) · ביטחון סוכן: 0.91
⚠️ Tripwire נדלקה: diff תקציב > 10% → סומן ל-review יזום
[ ✅ אשר ושלח במייל ] [ ❌ דחה והחזר לטיוטות ] [ ✏️ ערוך ידנית ]

סולם ה-Autonomy: לטפס לפי נתונים, לא לפי תחושה

Framework מרכזי autonomy-ladder eval-pass-rate

עד כאן קיבלנו החלטות נקודתיות, פעולה-פעולה, מה אוטונומי ומה דורש אישור ידני. אבל חשוב לזכור: מידת האוטונומיה של תפקיד מסוים בארגון שלך היא לא נתון קבוע משמיים — היא אמורה לעלות באופן מבוקר עם הזמן, ככל שהתפקיד מוכיח את עצמו בשטח ובנתונים קשיחים. הבעיה היא שרוב ה-operators הסולו מעלים את רמת ה-autonomy של הסוכנים לפי תחושת בטן ("הוא נראה אמין עכשיו" או "נמאס לי לאשר") ונשברים בשטח ביום בהיר אחד. הפתרון הארכיטקטוני לכך הוא סולם autonomy שמטפסים בו אך ורק לפי מספר אחד אובייקטיבי לחלוטין — ה-eval pass-rate אותו הגדרנו בפרק 4.

ה-research המוביל של התעשייה מנסח את הכלל החבוי: "כל תפקיד חדש שנולד בארגון מתחיל את דרכו ב-approve-each-action, ומטפס בהדרגה ל-monitor-only רק אחרי ש-eval pass-rate חוצה סף נתון שאתה קובע מראש." הנה הסולם המלא, מהתחתית הבטוחה לפסגה האוטונומית:

שלב 0 — Shadow (צל חסר נזק): הסוכן רץ במקביל באופן מלא אבל לא פועל בעולם האמיתי — הוא רק מציע וכותב ללוג מה הוא היה עושה, ואתה משווה את ההצעה שלו להחלטה שלך בפועל. אין אפס סיכון לעסק. מטרת השלב היא לאסוף golden cases ולבנות את מערך המדידה. תנאי מעבר הלאה: 10+ מקרים מוצלחים שעברו dry-run בהצלחה מלאה.

שלב 1 — Human-IN-the-loop (אישור כל פעולה): הסוכן יוצא לעולם האמיתי ופועל, אבל עוצר ומבקש אישור מראש לפני כל פעולה ופעולה. אתה מאשר/דוחה/עורך כל מקרה לפני שהוא יוצא. כאן רוב התפקידים בארגון מתחילים את חייהם ה"אמיתיים" והמועילים. תנאי מעבר הלאה: eval pass-rate גבוה מ-הסף המינימלי שקבעת (למשל 90%) על פני N מקרים אחרונים ורציפים.

שלב 2 — Human-ON-the-loop (ניטור ובקרה בלבד): הסוכן פועל לגמרי לבד באוטונומיה על כל פעולות ה-read/write ההפיכות / low-stakes, ואתה מנטר רק זרם של דוחות ומתערב רק כש-tripwire נדלקת. פעולות money/permissions/records/state הבלתי-הפיכות עדיין עוברות דרך gate ידני נפרד. תנאי מעבר הלאה: pass-rate גבוה ויציב לאורך זמן רב + 0 תקריות חמורות שהובילו לנזק.

שלב 3 — Full autonomy (בתחום מוגדר ומתוחם): אוטונומיה מלאה וחופשית — אבל רק על תת-קבוצה ספציפית של פעולות שהוכיחו את עצמן לחלוטין, וגם אז, עם מערכת tripwires חיות ברקע. זכור כלל ברזל: אף תפקיד לא מקבל full autonomy על הכל. ה-gate על כסף ו-state נשאר לעד, גם בשלב 3.

הנקודה הקריטית למעבר הדרגתי: מי קובע מהו הסף המספרי למעבר? אתה — אבל פעם אחת ויחידה, מראש, בכתב ובאופן קפדני. למשל: "תפקיד 'ניהול תמיכה טכנית' עולה משלב 1 לשלב 2 רק כש-eval pass-rate שלו הוא ≥ 92% על פני 20 המקרים האחרונים." מהרגע שכתבת את הכלל הזה לקובץ התצורה שלך, הטיפוס בסולם הופך להיות תהליך אוטומטי ומבוסס-נתונים לחלוטין, ולא ויכוח פנימי מתיש עם עצמך בכל יום ראשון בבוקר. זה בדיוק מה שהופך את ה-eval gate מפרק 4 ממדידה סטטיסטית יבשה לכלי ניהולי ואסטרטגי של ממש בעסק שלך.

Framework #2 — שער הטיפוס המדעתי בסולם: "אם X אז Y"

עבור כל תפקיד בעסק, פעם בשבוע (או אחרי כל N ריצות מבוקרות), בצע את הבדיקה הבאה:

אם ה-eval pass-rate ≥ סף-הטיפוס שקבעת מראש בכתב וגם 0 תקריות חמורות מאז הבדיקה האחרונה → אז העלה את התפקיד שלב אחד בסולם (promote). ברכות, ללא חגיגות.
אם ה-pass-rate ירד מתחת לסף-הטיפוס השמור או שהתרחשה תקרית חמורה אחת בלבד → אז הורד את התפקיד שלב אחד מיד (demote דרסטי). ה-autonomy במערכת אינה חד-כיוונית, ירידה חזרה לשלב נמוך יותר היא הגיונית ומצילת חיים.
אם ה-pass-rate יציב ותקוע באמצע (לא חצה סף למעלה, ולא צנח למטה) → אז השאר במקום, אל תזוז, ופשוט אסוף עוד מקרים לבדיקה. אין שום לחץ לטפס מהר ולייעל יתר על המידה.
אם מדובר בפעולת money/permissions/records/state בלתי-הפיכה → אז ה-gate נשאר על כנו ללא שום קשר לשלב בסולם שבו התפקיד נמצא. הסולם משחרר פעולות הפיכות בלבד, לעולם לא פעולות בלתי-הפיכות.

טעות נפוצה: להעלות תפקיד לאוטונומיה לפי תחושת בטן במקום לפי מדד eval pass-rate

"הסוכן הזה עובד מצוין כבר שבועיים, הוא באמת נראה חכם, בוא נשחרר אותו לגמרי." זו בדיוק הנקודה שבה תפקידים נשברים והורסים את העסק — כי "מרגיש אמין" הוא לא מדד אובייקטיבי. בלי לקשור את הטיפוס ל-pass-rate נמדד בפועל מול golden dataset, אתה מדלג על שלבים בסולם, נותן אוטונומיה לפני שהוכחה באופן סטטיסטי, ומגלה את הבעיה החמורה רק כשלקוח אמיתי וכועס נופל בה. הסולם כולו קיים בדיוק כדי שהחלטת הקידום תהיה מספר מובהק, ולא הרגשה אנושית מוטעית.

תרגיל 3 — מפה את סולם ה-Autonomy של כל הצי המלא שלך

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

שלבי העבודה:

צור מסמך חדש בשם .context/autonomy-ladder.md ובו טבלת Markdown עם העמודות: תפקיד | שלב נוכחי (0-3) | eval pass-rate נוכחי | סף מספרי לטיפוס | tripwires פעילות | פעולות תמיד-מגודרות (גם בשלב 3).
עבור כל תפקיד קיים מהפרקים הקודמים, מלא את השלב הנוכחי שבו הוא נמצא בפועל כעת. כל תפקיד חדש שאתה מוסיף למערכת מתחיל בשלב 0 או 1 בלבד — אל תתחיל אף אחד גבוה יותר מתוך אופטימיות טכנולוגית. התשלום על כך יהיה כבד מדי.
קבע סף טיפוס מספרי נוקשה לכל תפקיד (למשל 90%, או 95%, תלוי בקריטיות התפקיד). כתוב אותו במפורש בטבלה — זהו החוזה הארגוני שלך עם עצמך שאוסר על קידומים מתוך שעמום או התלהבות.
רשום בעמודה האחרונה אילו פעולות מרכזיות של אותו תפקיד נשארות מגודרות בחומת קרח תמיד, לא משנה באיזה שלב יטפס התפקיד בעתיד (כל ה-money/permissions/records/state שלו).
שמור ו-commit ל-git. עכשיו תהליך ה"קידום" של סוכן הוא פרוצדורה מתועדת, מדעית וניתנת למעקב, לא החלטה רגעית ושרירותית.

איך תיראה המפה המלאה (דוגמה מייצגת מצוינת):

תפקיד	שלב נוכחי	pass-rate	סף טיפוס הבא	תמיד מגודר (חסין שלב)
מחקר ובינה עסקית	3 (full autonomy)	97%	—	—
תוכן וניוזלטר	2 (on-the-loop)	93%	95% → 3	פרסום פומבי רשמי לרשת
תמיכה טכנית	1 (in-the-loop)	88%	90% → 2	הנפקת החזר כספי ללקוח
כספים וחשבונאות	1 (in-the-loop)	91%	— (קפוא מטעמי בטיחות)	כל פעולת כסף מעל ₪0 כלפי חוץ

Selective Attention: איך operator סולו מגדיל את עצמו בלי להישרף

מושג ליבה selective-attention tripwires כמערכת התראה חכמה

הנה הפרדוקס המרכזי והאכזרי של ה-operator הסולו ב-2026: ככל שהצי שלך גדל ומצליח, יש יותר ויותר מה לפקח עליו — אבל לך יש בדיוק אותן 24 שעות ביממה בדיוק כמו אתמול. אם הפיקוח הידני שלך יגדל ליניארית יחד עם היקף הפעולות בצי, חזרת סופית להיות צוואר הבקבוק ההוא שניסית לברוח ממנו כשהקמת את העסק. הפתרון האולטימטיבי לפרדוקס הזה הוא selective attention (תשומת-לב סלקטיבית מובנית): לא לצפות בהכל כל הזמן בלו"ז סדוק, אלא לתכנן ולבנות מערכת חכמה שמושכת את העין שלך ושולחת אותך התראה רק כשבאמת צריך להסתכל על משהו.

ה-tripwires הן בדיוק אותו מנגנון חכם של התראה. במקום המודל הישן של "אני עובר ידנית על כל הפעולות של כל הסוכנים בסוף היום" → אתה עובר למודל "אני רואה בדאשבורד רק את הפעולות שהדליקו tripwire באופן חריג". ה-research של הקורס מנסח את המודל הזה במילים: "tripwires שמפנגים אותך (חוסכות ממך עבודה) רק כשחשוב — איך operator סולו 'מגדיל את עצמו' בלי לצפות בכל פעולה ופעולה ידנית."

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

איך מערכת selective attention נראית בפועל, ברמת הארגון היומיומית של הצי שלך: דוגמה מספרית מיום שישי אחד בצי של 7 סוכנים: בוצעו 247 פעולות במשך 9 שעות (תגובות ללידים, מיילים, עדכוני CRM, חישובי מס) — 0 צפצופים, שתיקה מוחלטת. בשעה 16:42 דלקה tripwire יחידה: סוכן מכירות ניסה לשלוח הצעת renewal של ₪4,200 ללקוח קיים, אבל נדלק דגל "diff גדול מ-10% מהמחיר ההיסטורי". אישרת בנייד ב-8 שניות, וההצעה יצאה. שאר 246 הפעולות לא דרשו ממך דבר.

תקרית חריגה של money/permissions מעל סף מסוים → ping מיידי לנייד בכל שעה (זהו ה-approval gate שלנו, שעובד 24/7).
tripwire נדלקה במערכת (retries / מקורות סותרים / diff גדול מהרגיל) → מצטרפת אוטומטית ל-review queue ייעודי, שאתה עובר עליו פעם אחת ביום בלבד.
eval pass-rate של תפקיד שלם צנח מתחת לסף המותר → התראה בסיכום השבועי השקט: "תפקיד 'מכירות' ירד ל-84% הצלחה, שקול demote לשלב 1".
הכל ירוק לגמרי, שום חריגה, שום בעיה → אתה פשוט לא שומע כלום מהמערכת ולא מקבל הודעה. שתיקה אבסולוטית היא ההצלחה הגדולה ביותר של המערכת שבנית. המטרה היא לא לקבל לייקים והתראות ירוקות, אלא שקט מוחלט.

זו בדיוק אותה tripwire מתוך ניתוח היצירות המעשיות ב-research: "customer-escalation tripwire — human-on-the-loop monitor שמפנג אותך רק כשסוכן ניסה הרבה פעמים לבצע משימה, פגש מקורות מידע סותרים ב-RAG, או הפיק פעולה מסוכנת ולא שגרתית." תשומת-לב סלקטיבית ואגרסיבית במקום הצפה של צפייה ידנית בהכל.

עשה עכשיו (2 דקות, חשיבה אסטרטגית)

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

מימוש טכנולוגי: איפה ה-Approval חי ב-Runtime בפועל

כלים וטכנולוגיה Orloj preview לפרק 7

עד כאן עיצבנו וכתבנו את ה-מדיניות הניהולית במסמכים וב-SOPs. אבל חשוב לזכור כלל בסיסי בהנדסת תוכנה: מדיניות שלא נאכפת ב-runtime על ידי קוד קשיח, היא רק כוונה טובה שתישבר ברגע האמת. איפה ה-approval gates באמת חיים ונאכפים בעולם האמיתי של הרצת סוכנים?

קיימות שלוש רמות מימוש הדרגיות, מהקלה והזולה ביותר לחזקה והמקצועית ביותר:

בתוך ה-Agent SOP (פרק 3): צעד MUST כתוב בבירור בטקסט שאומר לסוכן "עצור והמתן לאישור". זוהי רמת ההגנה הזולה ביותר, והיא עובדת היטב מהיום הראשון של העסק — הסוכן מציית באופן מילולי כי כתוב לו בפרומפט. החיסרון הברור: אם הסוכן יחליט לסטות מה-SOP ו"לשכוח" את החוק (hallucination של עקיפה), אין מי שעוצר אותו ברמה הנמוכה יותר. הוא עלול לפעול בכל זאת.
קוד עוטף מכאני (Wrapper / Middleware): פונקציית מעטפת שעוטפת פיזית כל פעולת write בקוד שלך ובודקת את ה-gate לפני שמריצה את הפקודה במערכת החיצונית (למשל, אם מדובר בשליחת מייל, הפונקציה תחסום את קריאת ה-API של שליחת המייל עד לקבלת אישור). זוהי אכיפה אמיתית וקשיחה, אבל אתה צריך לכתוב אותה ולתחזק אותה בעצמך בשפת הקוד שלך.
פלטפורמת governance ייעודית (runtime fail-closed): כאן נכנסות תשתיות כמו Orloj, שמביאות את זה כשירות מובנית בלי שתצטרך לכתוב שורת קוד לאכיפה.

מתוך ה-research המעמיק של הקורס: Orloj (רישיון Apache-2.0, ספריית agent infrastructure-as-code) מספקת רכיבי מערכת מובְנים בשם ToolApproval ו-TaskApproval, וכן runtime governance שנאכפת במצב fail-closed — כלומר, כלל ברזל שבו אם המערכת לא מאשרת את הפעולה במפורש מראש ובהצלחה, הפעולה נחסמת פיזית כברירת מחדל. לא משנה מה הסוכן מנסה לעשות, השרת לא יאפשר לו. זוהי תכונה קריטית לעסק: gate שמתפקד במצב "fail-open" (כלומר, מאשר אוטומטית אם משהו משתבש בתקשורת) הוא gate שאינו gate מבחינה ביטחונית. ב-Orloj אתה מצהיר את כל ה-policies בקובץ YAML פשוט — מודלים מותרים, כלים חסומים, תקציב טוקנים, ודרישות אישור — והם נאכפים בזמן ריצה אבסולוטי על כל הצי שלך.

הערה חשובה ביותר (גישה וניטרליות מקצועית): Orloj היא ללא ספק דוגמה מצוינת וקיצונית ל-approval native בקוד פתוח, אבל היא בשלב pre-1.0 וה-APIs שלה עשויים להשתנות בלי התראה (לפי אזהרה מפורשת וברורה של המפתחים ב-repo). אם אתה בונה עליה את המערכת שלך — קפא על שמיים (pin) את הגרסה הנוכחית בקובץ ההתקנה שלך. ולפני שאתה נלחץ ומתחייב ללמוד טכנולוגיה חדשה: גרסת ה-SOP (רמה 1) הפשוטה מספיקה בהחלט לרוב ה-operators הסולו רק כדי להתחיל לעבוד ולהרוויח. את ה-runtime governance המלא, הכבד והמקצועי נרכיב ביחד בפרק 7. כאן, הנקודה היא רק להבין שה-approval gate הוא דבר אמיתי, קיים ואפשר לאוכף אותו באופן טכנולוגי מוחלט, לא רק כוונה טובה במסמך.

ה-2am Escalation, מנוהל בהצלחה

חיבור לפרק 2 escalation-path fallback אנושי חכם

נחזור לסיוט המוכר מפרק 1: השעה 2 בלילה, לקוח כועס ומתוסכל מתכתב במייל או בוואטסאפ, והבוט שלך פספס את הרגישות וגרם לנזק. בלי המערכת שבנינו כאן, זה הרגע שבו העסק נופל והלקוח עוזב. אבל עכשיו, אחרי שהטמעת את הכלים של פרק 5, יש לך יכולת לנהל את הרגע הזה בהצלחה קרה ומקצועית במקום לחשוש ממנו ולהתעורר בבהלה. ה-escalation path שהגדרת בפרק 2 (למי הסוכן מסלים את התקלה ובאילו תנאים מדויקים) פוגש כאן בשלמות את ה-tripwires האוטומטיות ומערכת האישורים.

כך נראית escalation מנוהלת, נכונה ואלגנטית בפועל בעסק שלך:

תרחיש השטח הבעייתי	מה הסוכן עושה אוטומטית (לפי ה-SOP)	מה אתה כ-operator מקבל בסלולר וכמה מהר
לקוח כועס, רושם טון אגרסיבי, הסוכן לא בטוח בתשובה לתלונה ואינו מסוגל לפתור לבד.	tripwire פנימית (confidence נמוך מאוד) נדלקת → הסוכן אינו משיב ללקוח כלל עם תשובה יבשה, הוא מסלים מיידית ופותח כרטיס.	התראת פוש חמה ובולטת עם כל ההקשר המלא של השיחה עד כה + טיוטת תשובה רכה שהסוכן הכין להמתנתך ואישורך המהיר.
לקוח דורש החזר כספי מיידי בגובה ₪500 עקב טעות חיוב של המערכת.	gate כספי חובה → הסוכן נעצר במקום, מאשר באופן מיידי את קבלת הבקשה וממתין בסבלנות לאישור הכספי שלך לביצוע.	בקשת אישור החזר כספי ברורה עם הסכום המדויק, פרטי העסקה מקורית וסיבת הלקוח במסמך אחד מסודר.
שאלה שגרתית, ברורה ותפעולית מלקוח אודות שעות פעילות העסק (נמצאת ב-SOP במלואה).	הסוכן משיב לבד לחלוטין ובמהירות (נניח שתפקיד התמיכה כבר בשלב on/full), מאחל שבוע טוב וסוגר את הפנייה בחיוך דיגיטלי.	שום דבר, כלום, חדשות מוצלחות — שתיקה מוחלטת בטלפון שלך פירושה הצלחה מלאה של המערכת ואתה יכול להמשיך לישון בשקט.

ה-fallback האנושי של העסק הוא אתה, אבל כעת מדובר ב-fallback מנוהל ומתוכנן: לא מודל מתיש של "אני בודק ידנית כל הודעה וכל מייל בעצמי", אלא "אני מקבל בכל יממה אך ורק את 3 ההסלמות האמיתיות שבאמת דורשות את המגע האנושי וההכרעה שלי, כשכל ההקשר האפשרי כבר מוכן ומוגש לי על מגש דיגיטלי, ואני מכריע באישור ב-30 שניות מה יהיה". ההבדל הקריטי בין operator שנשרף ונכנע לעומס לבין operator שמנהל אימפריה בשלווה אינו נמדד בכמות העבודה הכוללת שהם עושים — הוא נמדד אך ורק באילו רגעים ואיזה סוג של מקרים מגיעים אליך בכלל.

שגרת עבודה: הריטואל השבועי של ה-operator המקצועי (15 דקות בלבד, יום ראשון בבוקר)

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

review queue (5 דקות ראשונות): עבור בזריזות על הפעולות הבודדות שהדליקו tripwire במהלך השבוע שחלף ונכנסו לתור האישורים. אשר / דחה / ערוך כל אחת מהן בנפרד. כל דחייה או תיקון שלך → מכניס אוטומטית את הסוכן למצב reflexion עמוק (כפי שהוגדר בפרק 4).
סולם autonomy (5 דקות הבאות): פתח את המסמך autonomy-ladder.md של הצי. עבור על כל תפקיד — האם ה-pass-rate שלו חצה בהצלחה את סף הטיפוס המצופה? אם כן, קדם אותו (promote). צנח לו ה-pass-rate לתהום? הורד אותו מיד לשלב אחד לפניו (demote). זה יישום ישיר של Framework #2.
כיול tripwires עדין (3 דקות): הסתכל לאחור: האם קיבלת יותר מדי פינגים רועשים בטלפון השבוע שחלף (סימן לרעש והצפה של נתונים)? או שקיבלת מעט מדי פינגים (סימן שאתה עיוור לבעיות וטמן את הראש בחול)? כייל את הספים המספריים של ה-tripwires כך שיהיו מדויקות יותר בשבוע הבא.
החלטת gate אחת גלובלית (2 דקות אחרונות): הסתכל על המטריצה כוללת ושאל את עצמך: האם יש פעולה מרכזית שמגודרת היום בכבדות, שהנתונים מראים שאפשר לשחרר לאוטונומיה מלאה? או, להיפך, פעולה אוטונומית שהתחילה להכשיל וצריך לגדר אותה חזרה לאישור ידני? בצע עדכן את המטריצה בהתאם למסקנה.

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

ההקשר הישראלי: Approval על הצעת מחיר ב-₪

ישראל SMB הצעת מחיר

בעסק שירותים ישראלי טיפוסי — נניח שאתה מפעיל סוכן מכירות/כספים עצמאי מול לקוחות SMB בשוק המקומי — ה-approval gate הקריטי ביותר שלך, זה שחייב להיות קפדני ונוקשה יותר מכל השאר, הוא על יצירה ושליחת הצעת מחיר וחוזה רשמי בשקלים (₪). זהו הרגע הרגיש שבו ה-operator הסולו חייב להכניס את ידו למערכת, לחתום ידנית (או ללחוץ אישור), ולא משנה בכלל כמה הסוכן מנוסה, ותיק או "חכם" בעיניך.

למה דווקא כאן, במסמך הזה, נדרשת הקפדה יתרה? כי בשוק הישראלי העסקי, הצעת מחיר אינה רק עוד סכום מספרי נייטרלי שמסוגל לחשב — היא מחויבות משפטית ומסחרית כבדה מול לקוח שמכיר אותך באופן אישי (ולעיתים אף מתקשר אליך בטלפון בשעות הערב). סוכן שמתמחר שירות ב-30% פחות מהמחירון בגלל שנשאר מחיר ישן בהקשר שלו, או שמבטיח בטקסט SLA (הסכם רמת שירות) עוצר נשימה שאתה לא יכול לעמוד בו בעליל, יוצר נזק כלכלי ומשפטי שאף eval pass-rate לא יכול לתפוס או לחזות מראש. הכלל הבלתי ניתן לשינוי עבור העסק שלך פשוט ואלים: כל הצעת מחיר ו/או חוזה שיוצאת ללקוח ישראלי מקומי עוברת gate — וסף ה-₪ יהיה בדיוק ₪0. הכל מגודר עד כדי כך שאין מצב של אוטונומיה.

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

תרגיל 4 — נסח את כלל ה-Approval שלך ושתול אותו עמוק ב-Agent SOP הפעיל

תוצר גלוי ומוחשי: צעד MUST כתוב בבירור ובתוך SOP אמיתי העובד כעת + שורת עוגן מעודכנת ב-scope of authority הארגוני — הכלל שלך חי ונושם בשתי שכבות ארגוניות שונות ומגבות אחת את השנייה.

שלבי העבודה המדויקים:

בחר תפקיד אחד ספציפי בעל פעולת כסף בלתי-הפיכה (כספים / מכירות). פתח את מסמך ה-SOP המלא שלו אותו יצרת בפרק 3.
מצא את השלב הקריטי ב-SOP וכתוב צעד MUST בתחביר RFC 2119 הקפדני: "MUST: לפני שליחת הצעת מחיר סופית ללקוח במייל, עצור את כל הפעולות. כתוב את ההצעה לקובץ ייעודי בשם .context/pending-approvals/. שלח בהודעה נפרדת ל-operator: שם לקוח, סכום ₪, ושינוי diff מהתקופה הקודמת. אל תשלח עד שתקבל קוד אישור מפורש בחזרה."
עדכן את הגדרת scope of authority של אותו תפקיד (אותה הגדרת בפרק 2): "סוכן הכספים MUST NOT לשלוח הצעת מחיר ללקוח באופן עצמאי ללא אישור operator מפורש מראש. MAY להכין, לחשב ולתייג את ההצעה בלבד."
הגדר את ה-named approver במסמך בצורה מפורשת לחלוטין (לא "המנהל"): השם המלא שלך והשם בלבד.
בצע commit מיידי ל-git. כעת הכלל כפול ואכיף בשתי שכבות שונות ומנותקות ארגונית (SOP הניתן לקריאה + scope מערכתי), והוא מוכן לחיזוק בשכבה השלישית (runtime fail-closed) בפרק 7 הקרוב.

איך ייראה הצעד ב-SOP האמיתי שבקובץ (דוגמה מייצגת וברורה):

# SOP — סוכן כספים · שלב 4: שליחת הצעה ללקוח MUST: עצור מיידית לפני שליחה. כתוב את ההצעה המלאה ל-`.context/pending-approvals/`. MUST: שלח הודעה ל-operator (named approver הרשמי: נדב) — לקוח, סכום ₪, diff כלכלי מראשית השנה. MUST NOT: לשלוח כלפי לקוח חיצוני ללא קבלת קוד "אשר" מפורש בחזרה. MAY: להכין, לחשב, לתייג ולהציע טקסט — הכל מותר, אך ורק לפני ה-gate הסופי. Tripwire חובה: אם diff המחיר > 10% מהמחיר ההיסטורי → סמן את המייל במפורש ל-review יזום וקפוא.

מילון מונחים — מהדורה מורחבת ומלאה

Calibrated Autonomy (אוטונומיה מכוילת): מתן אוטונומיה מלאה לסוכן אך ורק לפעולות high-confidence + reversible + low-stakes, וניתוב פעולות uncertain / irreversible / high-risk באופן יזום ל-approval queue ידני. לא שאלה בינארית של "אוטונומיה כן/לא" אלא שאלה מכוילת של "אוטונומיה לְאיזו פעולה בדיוק ותחת אילו תנאים".
Human-IN-the-loop (אדם בתוך הלולאה): תנוחת ניהול שבה אדם (ה-operator) נדרש לאשר פעולה לפני שהסוכן מבצע אותה בפועל. בטוחה מאוד לעסק, אבל משאירה את האדם בתוך לולאת הביצוע וכך הופכת אותו לצוואר בקבוק מעכב סקייל.
Human-ON-the-loop (אדם על גבי הלולאה): תנוחת ניהול שבה אדם מנטר תוצאות ומתערב במערכת רק בעת הצורך והחירום אחרי שהסוכן כבר פעל. משחררת את האדם לחלוטין ממטלות הביצוע, אך חשופה יותר לפעולות שכבר יצאו לאוויר העולם וגרמו לנזק בלתי הפיך בטרם עוקבים אחריהן.
Approval Gate / Approval Queue: מחסום תוכנה ארגוני חסין שבו פעולת סוכן נעצרת וממתינה לאישור אנושי בשרת לפני שהיא מתבצעת במציאות. ה-queue הוא אגן ההמתנה הדיגיטלי של כלל הפעולות העצורות והממתינות להכרעת האדם.
Confidence-based routing: שיטת ניתוב אוטומטי של פעולות סוכנים לפי ציון הביטחון (confidence score) שהמודל עצמו מדווח על התשובה. שימושית ונפוצה אך לא מספיקה כשלעצמה, מכיוון ש-confidence אינו מעיד על correctness אובייקטיבי.
Confidence != Correctness: אקסיומה מרכזית בעולם ה-LLM: מודל שפה יכול להיות בטוח לחלוטין ושגוי לחלוטין באותה הנשימה. ביטחון מדווח אינו מודד הסתברות אמיתית לנכונות, אלא רק עד כמה התשובה "מרגישה" נכונה למודל מבחינה סטטיסטית.
כלל Money / Permissions / Records / State: חוק ברזל ארגוני: כל פעולת write שמשנה ומוציאה מכסף, הרשאות, רשומות לקוחות או מצב-מערכת (state) מקבלת approval gate מחמיר ויקר פי כמה מפעולת retrieval (קריאה בלבד), שלרוב יכולה לרוץ עצמאית.
$ Threshold + Named Approver: מודל האכיפה הכפול לפעולות כסף: סף סכום נוקשה (שמעליו נדרש אישור חובה) + שם מפורש של המאשר האנושי (ולא סתם "מישהו"). במודל החברה של איש אחד (vibe CEO) ה-named approver הוא כמעט תמיד אתה באופן אישי.
Autonomy Ladder (סולם האוטונומיה): מודל התפתחות ארגוני המורכב מארבעה שלבים (Shadow → in-the-loop → on-the-loop → full) שתפקיד בארגון מטפס בהם בהדרגה לפי חציית סף ה-eval pass-rate הנקבע מראש, ואינו מתקדם לפי תחושות בטן או התלהבות של המנהל.
Eval-pass-rate graduation threshold: המספר הקשיח (למשל 92%) שקבעת מראש בכתב: מעליו תפקיד עולה אוטומטית שלב בסולם; מתחתיו — הוא נשאר קפוא או אף יורד שלב אחורה.
Tripwires (איתותי אזעקה): אותות התנהגותיים מובנים במערכת (כגון retries רבים, מקורות RAG סותרים, diff תוצאה גדול, או חריגה מ-SOP מקומי) שמכריחים את המערכת לנתב פעולה ל-review ידני גם כאשר ציון ה-confidence של הסוכן גבוה מאוד מאוד.
Selective Attention (תשומת-לב סלקטיבית): תפיסת ניהול מתקדמת שמטרתה לבנות מערכת שמושכת את העין וההודעות אליך אך ורק כשקורה משהו שבאמת דורש אותך, במקום לנסות לצפות בכל העסק וכל הסוכנים ידנית — כך operator סולו מצליח לנהל צי עצום באמצעות הגדלה עצמית (Scaling) ללא התפוצצות.
Fail-closed (מצב סגור כברירת מחדל): אסטרטגיית governance ארכיטקטונית קפדנית (המיושמת למשל בפלטפורמת Orloj) שבה המערכת חוסמת ביצוע פעולה באופן פיזי כברירת מחדל, אם הכלל המותאם אינו מאשר אותה במפורש. זאת בניגוד גמור ל-fail-open שמאשר אוטומטית פעולות בעת תקלה בתקשורת, ומהווה סכנה ביטחונית חמורה לעסק.

בדוק את עצמך לעומק (5 שאלות חותכות)

פעולת read פנימית הפיכה לחלוטין, low-stakes מאוד, אבל הסוכן ניסה לבצע אותה 5 פעמים שונות בטרם הצליח לסכם אותה בהצלחה. לפי חוקי ה-calibrated autonomy — היא רצה אוטונומית או שמועברת ל-review? (רמז: חשוב על מערכת ה-tripwires).
מדוע ברירת המחדל המומלצת לפעולה שאתה לא בטוח כיצד לסווג אותה היא תמיד approval ולעולם לא autonomy? נסח במילותיך את אי-הסימטריה הקיצונית בעלויות בין שתי האפשרויות הללו.
סוכן מכירות שלך מדווח בשיא הביטחון על confidence של 0.97% לגבי הצעת מחיר מנצחת ללקוח. האם המספר הזה מהווה עילה מספקת כדי לשלוח אותה אוטומטית ללקוח ללא אישור? מדוע זה רעיון נוראי, ואיזה קריטריונים נוספים עליך לבדוק לפני שליחה?
תפקיד ניהול התמיכה הטכנית נמצא כעת בשלב 1 (human-in) עם pass-rate שבועי של 88%. סף הטיפוס שקבעת מראש בשבילו הוא מעל 90%. מה אתה עושה בריטואל השבועי של יום ראשון — מקדם (promote), מוריד (demote), או משאיר במקום (freeze)? ולמה בדיוק?
הסבר בחומר הקורס: מהו ההבדל הארכיטקטוני המהותי בין runtime שפועל במצב fail-closed לבין runtime שפועל במצב fail-open בעת ניהול approval gate, ומדוע gate ארגוני ש"מאשר אוטומטית כשמשהו משתבש בשרת" נחשב בעצם לאיום שאינו gate כלל?

Just One Thing (הלקח המרכזי אם שכחת הכל)

אם תיקח איתך רק דבר אחד מהפרק הארוך הזה: טעות של אוטונומיה מוגזמת עולה לך הון ולקוחות עוד לפני שגילית אותה במערכת; אישור ידני מיותר עולה לך רק 30 שניות מהיום שלך. אי-הסימטריה ההרסנית הזו היא כל המשמעת של ה-vibe CEO — היא מכתיבה שברירת המחדל הארגונית היא תמיד approval, שכל פעולת כסף בעסק מגודרת עד כדי עצירה, ושאתה מטפס בסולם האוטונומיה אך ורק לפי נתוני מעבדה קשיחים (eval pass-rate) ולא לפי תחושות בטן. תבנה את הגדר רחבה ונוקשת מדי בהתחלה — ותוריד אותה בזהירות רבה לפי נתונים, ולעולם, אף פעם לא להפך.

סיכום הפרק המלא

Owner-as-operator זו עבודת ניהול אמיתית: הצי הדיגיטלי לא מבטל אותך כעובד — הוא משנה את תפקידך מ"מבצע ידני שוטף" ל"מחוקק ושופט שמחליט איזה פעולות רצות לבד ומה דורש את החתימה הדיגיטלית היומית שלו".
Calibrated autonomy מתבססת על שלושה צירים: פעולה במערכת צריכה לקבל תאורה ירוקה ב-reversibility וגם ב-stakes וגם ב-confidence (ממש כמו AND לוגי שאינו מתפשר) כדי לרוץ אוטומטית. ציר אחד אדום בלבד → הפעולה מנותבת ל-approval באופן מיידי.
הבדל בין Human-in ל-Human-on: in = אישור ידני וחוסם לפני הביצוע (מאוד בטוח, אבל הופך אותך לצוואר בקבוק עסקי); on = ניטור שקט אחרי הביצוע (משחרר אותך לחלוטין, אבל פעולה שגויה כבר יצאה לאוויר העולם). מתחילים תמיד ב-in, ומרוויחים בעבודה קשה את on.
Confidence אינו Correctness: אל תנתב פעולות על ביטחון הסוכן לבדו. מערכת הפעלה של סוכנים חייבת להוסיף tripwires נסתרות — retries / מקורות סותרים / diff גדול / חריגה מ-SOP — שתופסות בדיוק את המקרים הקלאסיים של confident-but-wrong, שאחרת היו חומקים.
כלל money/permissions/records/state: כל פעולת write שנוגעת בהן מגודרת בחומת קרח — תמיד, וללא יוצא מן הכלל, עם סף ₪ ברור ו-named approver בשרת. ה-gate הכלכלי נשאר לעד, לא משנה באיזה שלב גבוה בסולם התפקיד נמצא.
סולם ה-autonomy הארגוני: Shadow ראשוני → in-the-loop איטי → on-the-loop משוחרר → full autonomy. מטפסים בו בקפידה לפי חציית סף eval pass-rate שקבעת במדעיות מראש, ויורדים מיד חזרה למטה אחרי תקרית חמורה אחת. המדד הוא נתונים מוחלטים, לא תחושות אנושיות מוטעות.
Selective attention ככלי סקייל: tripwires חכמות שמפנגות את הסלולר שלך ומזעזעות אותך רק כשחשוב — כך operator סולו בודד מצליח לנהל אימפריה שלמה בלי לצפות בכל פעולה ופעולה. שתיקה מוחלטת מצד המערכת = הצלחה מלאה.

הגשר הישיר לפרק 6 — "ה-P&L הפיננסי של הסוכנים שלך": עכשיו, אחרי שהכרעת והחלטת מה רץ לבד ומה דורש אישור ומשאבי אנוש מצידך, נשאלת השאלה הבלתי נמנעת הבאה: כמה בעצם עולה לנו כל העסק הזה להרצה חודשית? בפרק הבא נתמחר את הצי שלך כ-cost center עסקי עם שורת רווח והפסד מוגדרת — ונגלה הפתעה צורבת: דווקא הסוכנים האוטונומיים שמריצים loops ארוכים בלי השגחה הם אלה ששורפים לנו הכי הרבה טוקנים יקרים (נניח, session בן 10 turns ארוכים שווה עלות של פי 50x מקריאה בודדת יעילה). ה-approval gates הנוקשים שבנית כאן אינם רק בלם בטיחות חיוני שמציל לקוחות — הם גם בלם עלות כלכלי שמציל את הרווחיות של העסק. בפרק הבא נבנה ביחד agent payroll dashboard ראשון מסוגו בש"ח, נגדיר model-routing policy שחותך עלויות עד ~80%, ונלמד להכריע לכל תפקיד: האם לפטר אותו לאלתר, לקדם אותו למשימות קשות יותר, או פשוט לכוונן את פרמטרי העבודה שלו — והכל, כמובן, לפי מספרים קשיחים.

צ'קליסט מסכם הפרק (12 פריטי שליטה ובקרה)

☐ רשמתי פעולה קונקרטית אחת לפחות לכל אחד מ-4-6 התפקידים המרכזיים ב-org chart הארגוני שלי.
☐ סיווגתי כל פעולה לפי שלושת הצירים במדויק — reversibility (הפיכות), stakes (סיכון), confidence (ביטחון מדווח).
☐ בניתי ושמרתי ב-git את המסמך autonomy-matrix.md עם החלטת A / I / O סופית לכל פעולה.
☐ זיהיתי ורשמתי במפורש את כל פעולות ה-money / permissions / records / state הקיימות בצי הארגוני שלי.
☐ הגדרתי סף ₪ מספרי + named approver אישי לכל פעולת כסף יוצאת.
☐ בניתי approval gate חי ופעיל על פעולת כסף אחת קריטית — הפעולה נעצרת לחלוטין, מודיעה לי לסלולר, וממתינה בסבלנות ללחיצת approve/reject מצידי.
☐ הוספתי מערכת tripwires אוטומטיות (retries / מקורות סותרים / diff גדול / חריגת SOP) שפועלות במקביל ומעל ל-confidence המדווח.
☐ מיפיתי כל תפקיד קיים לשלב הנכון בסולם ה-autonomy (Shadow / in / on / full).
☐ קבעתי וכתבתי במסמך סף eval pass-rate מספרי ואובייקטיבי לטיפוס עתידי לכל תפקיד בצי.
☐ וידאתי שכל פעולת money/permissions/records/state נשארת מגודרת בקפידה בכל שלב אפשרי בסולם (אפילו בשלב 3 המתקדם).
☐ הגדרתי את שלושת התנאים היחידים שבהם אני מוכן לקבל הודעת פוש מיידית לסלולר (selective attention מלאה).
☐ שתלתי את כלל ה-approval לא רק בראש, אלא כצעד MUST קשיח ב-Agent SOP אמיתי + שורת עוגן ב-scope of authority, וביצעתי commit מלא ל-git.