2 Foundation · פרק 2 מתוך 8

תנו לסוכנים תפקיד, לא הוראה: עיצוב ה-Org Chart של הצי

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

למי הפרק הזה. לבעל עסק קטן, פרילנסר או איש מוצר שכבר משתמש ב-AI לעבודה שוטפת (מיילים, סיכומים, טיוטות) ומרגיש שהוא מקליד את אותה "תן-לי-עשה" שוב ושוב. לפני שאתה צולל לפרטים: אתה לא צריך לדעת קוד כדי לעצב סוכן — רק לכתוב תיאור תפקיד ברור, כמו תיאור משרה לעובד חדש. המודל המנטלי הוא "אם הייתי שוכר עובד אחד לתפקיד הזה, מה הייתי רושם לו במייל הראשון?" — בדיוק את זה נכתוב ב-role spec, ובפרק 3 הוא יהפוך ל-SOP.

🧵 חוט הפרויקט

בפרק 1 ("אתה לא עושה הכל — אתה מפעיל צי") בחרת 4–6 פונקציות עסקיות להאצלה וסימנת מה נשאר אנושי. בפרק הזה אתה הופך את הרשימה הזו ל-org chart אמיתי: לכל פונקציה — תפקיד-סוכן עם role, goal, scope וטולים, וגם נתיב הסלמה. בפרק 3 ("SOPs לסוכנים") תיקח את ה-role spec המפורט שתכתוב כאן ותהפוך אותו ל-SOP מדויק שהסוכן יכול להריץ שוב ושוב. ה-org chart של היום הוא הקלט הישיר לכל מה שבא אחריו.

🎯 מטרות למידה

בסוף הפרק תוכל/י:

📋 דרישות קדם

📦 תוצרים (Deliverables 5–8)

  1. Org chart מלא של החברה — CEO=אתה + 4–6 תפקידי-סוכן, לכל אחד role+goal+scope+tools+escalation path (דיאגרמה + טבלה).
  2. מפרט תפקיד (role spec) כתוב לסוכן אחד לפחות — מפורט מספיק כדי להפוך ל-SOP בפרק 3.
  3. טבלת החלטת stack מנומקת — framework (CrewAI/LangGraph) / OS (Orloj/Knowlee) / minimal (API+cron+git) לפי רמת נוחות הנדסית, control, ו-lock-in.
  4. מפת escalation — לכל תפקיד: למי הוא מסלים ובאילו תנאים — חיווט הצי כמערכת אחת.

למה "הוראה" משאירה אותך צוואר בקבוק

role vs instructionbottleneckintegration-point

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

תחשוב איך אתה משתמש ב-AI היום. אתה פותח את ChatGPT או את Claude, מקליד "כתוב לי פוסט לינקדאין על X", מקבל תוצאה, מתקן, מבקש שוב. אחר כך "סכם לי את המייל הזה". אחר כך "מצא לי 5 לידים בתחום Y". כל בקשה היא הוראה נפרדת. אתה הזרוע שמחברת ביניהן. כשאתה עוצר — הכל עוצר. זה לא צוות; זה מקלדת מהירה יותר.

הבעיה היא לא שה-AI חלש. הבעיה היא מבנית: כל עוד הסוכן ממתין שתזין לו את המשימה הבאה, אתה נשארת ה-throughput של החברה. אתה יכול להכפיל את המהירות שלך, אבל לא להכפיל את עצמך. וזה בדיוק מה שמודל "צוות של איש אחד" אמור לפתור.

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

וזו המילה המדויקת: תפקיד עומד (standing role). סוכן-תפקיד הוא ישות שקיימת גם כשאתה לא מסתכל עליה. היא יודעת מה היעד שלה, מה מותר לה, ומתי לקרוא לעזרה. כשאתה חושב על העובדים הכי טובים שעבדת איתם פעם, מה הבדיל אותם? לא היית צריך להגיד להם מה לעשות בכל רגע. נתת להם תחום אחריות, והם הריצו אותו. בדיוק את זה אנחנו בונים — רק שה"עובד" הוא קובץ role-spec.md בתיקיית .context/ + לולאת LLM שמריצה אותו, לא בן אדם.

היבטסוכן-הוראה (instruction)סוכן-תפקיד (role)
מי יוזםאתה, בכל פעם מחדשהסוכן, לפי טריגר/תזמון
היקףמשימה בודדתפונקציה שלמה end-to-end
מה קורה כשאתה ישןשום דברהוא ממשיך לעבוד
הזיכרוןמתאפס בכל שיחהמצטבר (לקחים, הקשר לקוח)
צוואר הבקבוקאתהנע אל ה-eval וה-approval
מה בנית בפועלchatbotteammate

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

⚠️ טעות נפוצה: להמשיך להאכיל chat task-by-task

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

⚡ עשה עכשיו (Do Now)

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

מיני-מקרה: סטודיו עיצוב ישראלי קטן שעבר מצ'אט לצי

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

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

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

🧭 Framework: הוראה מול תפקיד — מבחן חמש שאלות

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

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

⚡ עשה עכשיו (Do Now)

בחר את הסוכן החשוב ביותר שלך. ענה על חמש שאלות המבחן עבורו — בעל פה, בלי להסתכל ב-role spec. אם ענית "לא" על אחת, הסוכן עוד לא תפקיד — הוא הוראה מתחפשת. סמן את הפער וסגור אותו עכשיו, לפני שאתה מתקדם.

אנטומיה של תפקיד-סוכן: ששת הרכיבים

anatomy of a rolegoalbackstoryscope of authority

תפקיד טוב — בין אם של בן אדם ובין אם של סוכן — נבנה מאותם רכיבים. המסגרת הזו לקוחה ישירות מהאופן שבו CrewAI (framework שנכיר בהמשך) מגדיר סוכנים: role + goal + backstory. נרחיב אותה לשישה רכיבים שמכסים גם את הצד העסקי וגם את הצד התפעולי.

רכיבהשאלה שהוא עונהדוגמה (סוכן SDR)
Role (תפקיד)מי הוא?"נציג פיתוח מכירות (SDR) שמסנן לידים נכנסים"
Goal (מטרה)מה הוא מקסם?"להעביר ליומן שלי רק לידים שתואמים ל-ICP, מנוקים ומועשרים"
Backstory / Personaאיך הוא "חושב"?"SDR ותיק, סקפטי, שמעדיף לפסול ליד מאשר לבזבז את זמן המנהל"
Scope of authorityמה מותר לו?"לקרוא ולתייג לידים; לנסח טיוטת פנייה. אסור לשלוח החוצה בלי אישור"
Tools (כלים)במה הוא נוגע?"גישת קריאה ל-CRM, כלי העשרת לידים, גישת כתיבה לתור-טיוטות בלבד"
Owned functionמה הוא מנהל end-to-end?"כל מסע הליד מהטופס ועד פגישה ביומן — או פסילה מנומקת"

נפרק כמה מהרכיבים, כי לכל אחד יש מלכודת משלו:

Goal — מטרה, לא משימה

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

קח לדוגמה סוכן תוכן. goal כמשימה: "לכתוב 3 פוסטים בשבוע". goal כתוצאה: "להעלות לאתר 3 פוסטים שעומדים בקריטריון 'קריאה מלאה ≥30% מהקוראים שנכנסו', עם ≥80% אישור אוטומטי של ה-eval". בגרסה הראשונה הסוכן יכול להצליח "לכתוב" — אבל אם אף אחד לא קורא, העסק לא התקדם. בגרסה השנייה הסוכן חייב לשפר עד שהתוצאה באמת מתקיימת, ולכן הוא יחזור לערוך, לשנות כותרות, להציע גישה אחרת — בלי שתגיד לו.

עוד דוגמה מעולם התמיכה. goal כמשימה: "לענות לטיקטים תוך 24 שעות". goal כתוצאה: "לסגור ≥90% מהטיקטים בפעם הראשונה (one-touch resolution), עם ציון CSAT ממוצע ≥4.5/5". הראשון מודד מהירות תגובה — ומשאיר את ה-CEO צולל בטיקטים שלא נפתרו. השני מודד את מה שבאמת חשוב: האם הלקוח קיבל פתרון.

⚠️ טעות נפוצה: goal-כמשימה שמתחזה ל-goal-תוצאה

הגרסה המתחכמת של הטעות: "להעלות את שביעות הרצון של הלקוחות" — נשמע כמו תוצאה, אבל אין לה מדד אובייקטיבי. סוכן יכול "להצליח" ב-goal הזה בלי להצליח בעסק. תמיד דרוש מספר או סף: "≥80% פתרון בפעם ראשונה", "≤48 שעות זמן תגובה חציוני", "≥4.5/5 CSAT". מספר שאפשר למדוד — אחרת זו לא מטרה, זו כוונה.

Backstory / Persona — להזרים טעם בלי לפקח על כל החלטה

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

דוגמאות טובות ל-backstory שעובדות: "כותב תוכן שמתמחה ב-SEO ארוך-טווח, סקפטי לגבי טרנדים חולפים, מעדיף לפרסם פחות פוסטים באיכות גבוהה מהרבה באיכות בינונית"; "אנליסט פיננסי שמרני, תמיד מציג שלוש תרחישים (פסימי/ריאלי/אופטימי) ומסמן את ההנחות שלו"; "סוכן תמיכה שמדבר עברית בגובה העיניים, נמנע מסלנג, משתמש בשם פרטי של הלקוח". כל אחד מהם נותן לסוכן "אופי" שמתבטא באופן אוטומטי במאות החלטות קטנות שלא תרצה לקודד.

⚡ עשה עכשיו (Do Now)

לכל סוכן שאתה מתכנן, כתוב 2-3 משפטים של backstory. התחל ב"אני [X] שמאמין ב-[Y] ונמנע מ-[Z]". זה המקום שבו אתה מזריק את הטעם שלך — את הערכים שמבדילים את הסוכן שלך מסוכן גנרי. אם אתה לא יכול לנסח את זה, סימן שאתה עוד לא יודע מה אתה רוצה מהסוכן הזה.

Scope of authority — הרכיב שכולם שוכחים

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

נחזור ל-scope of authority בעומק בפרק 5 ("Owner-as-Operator"), שם נהפוך אותו לסולם autonomy עם approval gates. כרגע מספיק שתגדיר לכל סוכן: מה מותר לבד, מה דורש את החתימה שלך.

דוגמה מסכמת. ניקח סוכן תוכן לסטודיו של רוני. scope of authority מפורש עשוי להיראות כך: "רשאי לקרוא את כל הפוסטים הקודמים באתר ולשאוב מהם; רשאי לכתוב טיוטאות לתיקיית /drafts/ בלבד; רשאי להציע 3 כותרות חלופיות לכל פוסט; רשאי לפרסם רק פוסטים שעברו eval פנימי (מדד brand-voice ≥0.8). אסור בהחלט: פרסום ללא אישור, שינוי פוסטים שכבר פורסמו, מחיקת תוכן, גישה למערכות תשלום, תקשורת ישירה עם לקוחות." המשפט האחרון הוא הקריטי: אם תשכח אותו, סוכן התוכן עלול לענות ללקוח במייל "בשם הסטודיו" — וליצור מצב שאתה לא שולט בו.

⚠️ טעות נפוצה: תפקיד בלי scope ובלי escalation

להגדיר role, goal ו-tools — ולשכוח scope of authority ו-escalation path. התוצאה: הסוכן מאלתר בכיוון הלא נכון (כי אף אחד לא אמר לו "עד כאן"), ואין מי שתופס אותו כשהוא טועה. תפקיד בלי גבולות ובלי נתיב הסלמה הוא לא תפקיד — הוא סיכון.

⚡ עשה עכשיו (Do Now)

לכל סוכן שאתה מתכנן, כתוב scope of authority בשלוש שורות: (1) מה מותר בלי לשאול; (2) מה דורש אישור; (3) מה אסור בהחלט. אם הסעיף השלישי ריק, הסוכן שלך לא בטוח.

ששת התפקידים הסטנדרטיים: תבניות מוכנות להעתקה

six standing rolesrole templatesKnowlee verticals

אחרי שהבנו את ששת הרכיבים, השאלה המעשית היא: איזה סוכנים אני בכלל צריך? התשובה לא צריכה להיות מקורית. בכל חברה אמיתית יש אותן 5–6 מחלקות חוזרות; חברת "איש אחד" יכולה לאמץ את אותה חלוקה בדיוק. הנה המיפוי, עם דוגמת role spec קצרה לכל אחד, שתוכל/י להעתיק כקלט לתרגיל 2.

#תפקיד (Role)Goal (תוצאה מדידה)Scope — דוגמהמסלים אל…
1SDR / מכירות נכנסות≥80% מהלידים שמועברים ראויים לפגישה; זמן מענה ראשון ≤60 דקותלקרוא CRM, לסמן, לנסח טיוטאות; אסור לשלוחל-CEO על כל שליחה החוצה
2תוכן / שיווק≥3 פוסטים/שבוע שעומדים ב-brand-voice ≥0.8 (eval פנימי)לקרוא היסטוריית תוכן, לכתוב ל-/drafts/, להציע כותרות; אסור לפרסם בלי אישורל-CEO על כל פרסום
3תמיכהone-touch resolution ≥90%; CSAT ≥4.5/5; זמן תגובה חציוני ≤4 שעות בשעות העבודהלקרוא טיקטים, לסווג, לענות מתוך knowledge base; אסור refunds/מחיקת חשבונותל-CEO על כל החזר כספי או ביטול
4מחקר / תחרותלהפיק דוח שבועי (≤2 עמודים) שמסמן 3 תובנות + 3 הזדמנויותלקרוא אתרי תחרות, דוחות, RSS; אסור לפרסםל-CEO אם מוצא סיכון משמעותי לעסק
5כספים / חידושיםלסמן ≥95% מהחידושים בזמן (T-30 יום); לזהות לקוחות בסיכון leaving ≥7 ימים לפנילקרוא CRM, לחשב churn-risk; אסור חיוב/החזר/שינוי תמחורל-CEO לפני כל מגע כספי
6תפעול / "morning brief"להפיק digest יומי ≤5 דקות קריאה שמסכם את כל הצי (לידים, טיקטים, פוסטים, חידושים)לקרוא הכל; אסור לכתוב בשום מערכתל-CEO (אתה), כל בוקר

שים לב לדפוס: הסוכן ה"קל" ביותר להתחלה הוא מס' 6 (morning brief). הוא רק קורא, לא כותב, ולכן גם אם הוא טועה — לא נגרם נזק. אחריו מס' 4 (מחקר — קריאה בלבד, דוח ראשון שעובד). רק אחרי שאתה בוטח בצי במצב read-only, עוברים למס' 2 (תוכן — כתיבה ל-/drafts/ עם eval gate), ולבסוף למס' 1 (SDR — אישור אנושי לפני כל שליחה). מס' 3 ו-5 הם האחרונים, כי הם נוגעים בכסף ובלקוחות קיימים — סיכון גבוה.

🧭 Framework: סדר ההאצלה לפי סיכון

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

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

⚡ עשה עכשיו (Do Now)

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

תבנית ארגונית מוכנה: הוורטיקלים של Knowlee

Knowlee verticals (reference)org template

אם אתה תקוע על "איך בכלל מחלקים את הפונקציות", יש תבנית מוכנה ומאומתת שאפשר להעתיק ממנה — בלי לקנות כלום. החברה Knowlee מפעילה פלטפורמת "AI workforce" מסחרית עם חמש ורטיקלים שרצות על אותו backbone אחד (Knowlee OS): 4Sales, 4Marketers, 4Talents, 4Operations, 4Finance. כל ורטיקל הוא בעצם "מחלקה" שלמה של סוכנים.

אנחנו לא ממליצים לקנות את Knowlee — נחזור לשאלת build-vs-buy בפרק 7. כאן Knowlee שימושית כתבנית ארגונית בלבד: היא מראה שחברה שלמה ניתנת לחלוקה לאותן 5–6 מחלקות שמיפינו למעלה, ושכל מחלקה יכולה לעמוד בפני עצמה כפונקציה. כשאתה מסתכל על העסק שלך ושואל "אילו מחלקות יש לי?", הרשימה של Knowlee היא נקודת התחלה טובה. העתק את המבנה, לא את המוצר.

💡 הערה על מקור: Knowlee היא vendor

Knowlee הוא מקור מסחרי עם מוטיב מכירה. השתמש בו כדוגמה ארכיטקטונית — "ככה אפשר לחלק חברה לסוכנים" — לא כהמלצת קנייה. לאורך הקורס נראה תמיד גם את החלופה ה-OSS/חינמית לצד כל פלטפורמה מסחרית. כך, למשל, את אותו מבנה חמש-ורטיקלי אפשר לממש לגמרי בחינם עם תבניות OSS שנכיר בפרק 7 (gru-ai ברישיון MIT, Orloj ברישיון Apache-2.0) — אותה ארכיטקטורה, אפס דמי פלטפורמה.

איך המבנה החמש-ורטיקלי נראה בעסק ישראלי טיפוסי

ניקח דוגמה מציאותית: יועץ עסקי עצמאי (אסטרטגיה שיווקית ל-SMB) שמטפל ב-12 לקוחות פעילים. כשהוא מסתכל על הוורטיקלים של Knowlee, הוא יכול למפות אותם כך:

זה ה-org chart המלא שלו: CEO=היועץ, חמישה סוכנים שכל אחד מהם בעל-בית על פונקציה אחת, ובלילה — כשהוא ישן — הם ממשיכים לעבוד. הבוקר הוא פותח morning brief של 5 דקות, מאשר 2-3 פעולות, וממשיך לפגישה הראשונה. הוא לא בילה שעה על סינון לידים, לא כתב מייל תגובה לכל ליד, ולא בדק מה המתחרים עשו. הצי עשה את זה.

⚠️ טעות נפוצה: להעתיק את הוורטיקלים של Knowlee בלי להתאים לעסק שלך

הפיתוי: להעתיק את כל חמשת הוורטיקלים כמו שהם, גם אם העסק שלך לא צריך אחד מהם (למשל, 4Finance לעסק שמבוסס כולו על מנוי חודשי פשוט). התוצאה: סוכן שרץ לשווא, עולה טוקנים, ומייצר דוחות שאף אחד לא קורא. כלל אצבע: התחל מ-3-4 תפקידים שמכסים 80% מהזמן שלך. הוסף תפקיד חמישי רק אחרי שהראשונים רצים חלק. עדיף 3 סוכנים שעובדים מ-5 שמפזרים את תשומת הלב.

שלוש דרכים לחווט את הצי: framework מול OS מול minimal

framework vs OS vs minimal stackCrewAILangGraphskip-the-framework

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

אופציה 1: Framework — CrewAI

CrewAI הוא ה-framework שהכי קל לקהל עסקי, מהסיבה הפשוטה שהוא חושב במונחי תפקידים — בדיוק כמו ה-org chart שבנינו. אתה מגדיר agents עם role + goal + backstory, ואז מקצה להם tasks. הקצאת המשימות יכולה להיות sequential (משימה אחרי משימה, בסדר קבוע) או hierarchical (סוכן "מנהל" מחלק משימות לסוכנים אחרים). אפשר להתחיל עם ~20 שורות קוד. אם המודל המנטלי שלך הוא "צוות עם תפקידים", CrewAI מתורגם אליו כמעט אחד-לאחד.

ה-20 שורות האלה הן בערך כך: אתה יוצר agent אחד עם role="SDR", goal="לסנן לידים", backstory="ותיק, סקפטי". אתה יוצר agent שני עם role="copywriter", goal="לנסח מייל פנייה ראשון", backstory="קצר, ישיר, בעברית". אתה יוצר task שמקצה את הליד ל-SDR, ו-task שלוקח את הליד שאושר ושולח אותו ל-copywriter. אתה בוחר Process.sequential או Process.hierarchical, ומריץ crew.kickoff(). זה הכל. הקוד עצמו קריא, מתועד, וקל לשנות.

אופציה 2: Framework — LangGraph

LangGraph הוא יותר כבד אבל יותר חזק. במקום "צוות", הוא חושב במונחי גרף מכוון (directed graph): צמתים (פעולות) ו-conditional edges (חיבורים מותנים — "אם התוצאה X, לך לצומת Y"). בתמורה לתלילות הלמידה, אתה מקבל audit trails (תיעוד מלא של כל צעד) ו-rollback points (יכולת לחזור אחורה). זה ה-framework לבחור בו כשאתה צריך control ו-compliance מקסימליים — למשל אם אתה בתחום מוסדר. דוגמה מייצגת: בתחילת 2026 LangGraph עקף את CrewAI במספר ה-stars ב-GitHub, על רקע אימוץ enterprise/production.

ה-trade-off ברור: ב-CrewAI אתה מתאר "מי עושה מה", וזה מספיק לרוב הציודים. ב-LangGraph אתה מתאר "מה קורה אחרי מה" — שזה חזק כשיש לך flows עם הסתעפויות מורכבות (למשל: "אם ה-eval עבר, פרסם; אם לא, החזר לכותב; אם נכשל 3 פעמים, הסלם"). עבור SMB רגיל, זה לרוב overkill. עבור חברה שמוכרת לתעשיית הפיננסים/בריאות — זה כנראה הכרחי.

אופציה 3: "Skip the framework" — API + scheduler + git

זו האופציה שרוב המדריכים שוכחים להזכיר, ולרוב היא הנכונה ל-operator עסקי: לוותר על framework לגמרי. קריאות API ישירות למודל (Claude/GPT) + scheduler פשוט (cron) + git לאחסון ה-context. בלי תלות framework, בלי שכבת הפשטה שצריך ללמוד ולתחזק. לסוכן שמריץ SOP ברור, שולח טיוטה לאישור ושומר לקח — לרוב לא צריק יותר מזה. פחות קוד = פחות מה שיכול להישבר, ופחות מה שיכול להתיישן.

כשה-stack הזה עובד: סוכן ה-SDR שלך הוא בעצם 30 שורות Python שעושות (1) קריאה ל-Inbox API, (2) קריאה ל-Claude API עם prompt שמכיל את ה-role spec, (3) כתיבה ל-/drafts/ ב-CRM, (4) cron שמריץ את זה כל 15 דקות. אין framework, אין dependencies מתחלפות, אין breaking change. אם מחר Claude יוציא גרסה חדשה, אתה מחליף את שם המודל בקובץ env. אם CrewAI יחליטו לשנות API, אתה לא מושפע.

חשוב להבחין בין minimal stack לבין "no stack". גם כשאתה מוותר על framework, אתה עדיין צריך: (א) מקום לאחסן את ה-role specs וה-SOPs (תיקיית .context/ ב-git, אותה נבנה בפרק 3); (ב) scheduler (cron, GitHub Actions, או Claude Code Routines); (ג) דרך לעקוב אחרי ריצות (לוג פשוט בקובץ, או Langfuse אם אתה רוצה tracing מלא); (ד) דרך להתריע על תקלות (טלגרם בוט, אימייל, Slack). זה לא "בלי תשתית" — זה תשתית מינימלית שאתה בונה בעצמך.

קריטריוןCrewAI (framework)LangGraph (framework)API+cron+git (minimal)
עקומת למידהנמוכהגבוההנמוכה–בינונית
מודל מנטליצוות / תפקידיםגרף / זרימהסקריפטים + תזמון
control & auditבינונימקסימליאתה בונה ידנית
תלות frameworkגבוההגבוההאפסית
הכי מתאים ל…קהל עסקי שחושב בתפקידיםcompliance / production מורכבoperator שרוצה מינימום plumbing

🧭 Framework: framework, OS, או minimal?

בחר את ה-stack לפי רמת הנוחות ההנדסית שלך, לא לפי מה ש"מגניב":

כלל אצבע: התחל מ-minimal. עבור ל-framework רק כשהכאב מצדיק את התלות.

⚠️ טעות נפוצה: לבנות net-new על AutoGen, או לבחור stack כבד מדי

שתי מלכודות תאומות. הראשונה: AutoGen — framework פופולרי לשיחות רב-סוכניות (GroupChat) — עבר ב-2026 ל-maintenance mode; הפיתוח הפעיל עבר ל-Microsoft Agent Framework. לבנות מערכת חדשה על בסיס קפוא = לאמץ תשתית שלא תתפתח. השנייה: לבחור framework כבד (LangGraph) כשהעסק שלך היה צריך minimal stack — נשארת עם plumbing מורכב לתחזק במקום עם org מעוצב היטב. תמיד אמת את סטטוס ה-framework לפני שאתה מתחייב.

⚡ עשה עכשיו (Do Now)

לפני שאתה כותב את stack-decision.md (תרגיל 3), פתח את הדף של ה-framework שאתה שוקל. חפש את הקטע "Maintenance / Status" או "Roadmap" ב-README. אם אתה רואה "maintenance mode", "looking for maintainers", או "no longer actively developed" — סימן שה-API יכול להישבר בלי התראה. רשום את תאריך הבדיקה ב-stack-decision, וקבע תזכורת חוזרת כל 3 חודשים.

Scope של סמכות ונתיב הסלמה: לחווט את הצי כמערכת אחת

scope of authorityescalation pathintegration-point problem

org chart שבו כל קופסה עומדת לבד הוא לא org chart — הוא רשימה. מה שהופך רשימת סוכנים לצי זה שני דברים: גבולות ברורים (scope), ונתיבי תקשורת (escalation). בלעדיהם אתה נופל בדיוק לבעיה שכל הקורס בא לפתור.

הבעיה מוגדרת היטב על ידי Nestr, וחוזרת בכל מקור שמדבר על "one-person AI company": "כשאין מבנה ארגוני לצי של סוכני-AI… כל סוכן הוא כלי מנותק, אף אחד לא יודע מה השני עושה, והמייסד הוא נקודת-האינטגרציה היחידה." יש לך chat פה, custom GPT שם, flow ב-no-code במקום שלישי — ואתה הדבק היחיד שמחבר ביניהם. כשאתה לא שם, אין צי; יש כאוס.

הפתרון הוא shared context layer — שכבת הקשר משותפת שכל הסוכנים קוראים וכותבים אליה. בפועל זה לרוב פשוט: תיקיית .context/ ב-git repo עם קבצי Markdown ו-JSON — ה-org chart, ה-role specs, ה-SOPs, והלקחים. כל סוכן יודע מי הוא, מי הבעלים שלו, ומה השאר עושים, כי הכל כתוב במקום אחד מנוהל-גרסאות. את התבנית הזו (ה-.context/ pattern, מתוך הפרויקט gru-ai) נבנה בפועל בפרק 3. כרגע מספיק שתבין: המבנה הוא הפתרון לפיזור.

נתיב הסלמה (escalation path)

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

זה ה-preview ל-calibrated autonomy של פרק 5, אבל גם בלי המנגנון המלא — עצם זה שכתבת "מי מסלים למי ומתי" הופך את הסוכנים המנותקים לארגון. הערה: בפרק 7 נראה שפלטפורמות כמו Orloj מממשות את זה native (ToolApproval / TaskApproval); כרגע אתה רק מתעד את הנתיב.

🧭 Framework: מתי סוכן מסלים?

נסח לכל סוכן כלל הסלמה לפי הסכמה:

כתוב את הכלל הזה בתוך ה-role spec, לא בראש שלך. סוכן לא יכול להסלים לפי כלל שלא נכתב.

⚡ עשה עכשיו (Do Now)

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

ההקשר הישראלי: org chart לעסק שירותים מקומי

local marketSMB ישראליproductized role

נעשה את זה קונקרטי עם דוגמה ישראלית טיפוסית: סוכנות תוכן/דיגיטל קטנה, operator אחד. איך נראה ה-org chart? הפונקציה הראשונה שכמעט תמיד כדאי להאציל ב-SMB מקומי היא תוכן (הרבה execution חוזר) ומכירות נכנסות (סינון לידים מבזבז זמן). תמיכה ומחקר באים אחר כך.

נקודה ישראלית חשובה: סוכנים שעובדים בעברית הם בידול אמיתי בשוק ה-SMB המקומי. סוכן תמיכה או מכירות שמדבר עברית טבעית, מבין את הטון המקומי ופונה נכון ללקוח ישראלי — זה משהו שפלטפורמות גלובליות לא תמיד נותנות. כשאתה מעצב את ה-backstory וה-SOP (בפרק 3), שווה לכלול במפורש את העברית ואת הטון המקומי.

ולמה זה בכלל משתלם? דוגמה מייצגת מהשוק הישראלי (Times of Israel): סוכנות בת 5 אנשים צריכה לתמחר משהו כמו בוט WhatsApp ב~₪45,000 כדי לכסות משכורות, משרד, ניהול פרויקט ומרווח. operator סולו עם צי סוכנים, ללא overhead כזה, יכול לספק עבודה דומה בחלק קטן מהמחיר. זה היתרון המבני של מודל "צוות של איש אחד" — וזה בדיוק מה שמאפשר אחר כך לארוז תפקיד בודד (למשל "סוכן SDR כשירות") כהצעה productized ל-SMB ישראלי. נחזור לזה ב-P&L של פרק 6 ובהצעה המסחרית של פרק 8.

דוגמה מורחבת: סוכנות שיווק ישראלית בת 3 עובדים

ניקח תרחיש אמיתי: "שירן", איש שיווק עצמאי, רץ 3 קמפיינים בחודש עבור לקוחות שונים (אחד בתחום המזון, אחד ב-B2B SaaS, אחד בציוד רפואי). לפני שהוא בנה צי, הוא היה מבלה בערך 60% מהזמן בלהיות "איש התפעול": לענות ללידים נכנסים, להכין דוחות שבועיים, לסכם פגישות, לעקוב אחרי חידושי חוזים, לחפש רעיונות לתוכן. על הקמפיינים עצמם (העבודה האסטרטגית, היצירתית) הוא הצליח להקדיש רק 40%.

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

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

דוגמה מס' 2: חנות אונליין ישראלית (e-commerce) בת 2 עובדים

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

שים לב להבדל המבני משירן: אין כאן סוכן SDR (אין לידים נכנסים — רק רכישות אורגניות), ויש סוכן תמיכה שמופעל ב-WhatsApp ולא במייל, עם SLA של "מענה תוך 30 דקות בשעות 9–22". ה-org chart לא קובע "מה צריך"; הוא קובע "מה העסק שלך צריך". בעל חנות e-commerce לא יבנה סוכן מכירות נכנסות; יועץ B2B שמוכר שעות ייעוץ ב-₪1,800 לפגישה — דווקא כן.

⚠️ טעות נפוצה: לבנות סוכן "לכל דבר שאני עושה"

הפיתוי בגרסה הישראלית שלו: לנסות לאצל כל פעולה, כי "אם כבר יש צי, למה לא לנצל אותו". התוצאה: סוכן שמטפל בדברים שלא משתלם לאצל, overhead של תחזוקה, ובלבול. כלל אצבע ישראלי: האצל רק פעולות שעולות יותר מהעלות של הסוכן. אם סוכן עולה לך $200/חודש בטוקנים, הוא צריך לחסוך לך לפחות $400/חודש (יחס 2:1) — אחרת הוא רק מוסיף רעש.

💡 תזכורת תחום: משפט/מס שייכים למקום אחר

org chart של סוכנים הוא עיצוב תפעולי. הצד המשפטי/מיסויי — עוסק פטור/מורשה, חשבונית, התנהלות מול רשויות — נשאר בדיוק כמו לכל עצמאי, ומטופל בקורסי ה-freelancer/creator-economy. כאן אנחנו לא מלמדים את זה מחדש; רק מזכירים שזה לא נעלם כי הוספת AI. אל תיפול למלכודת ש"סולו + AI" מוחק את הצד המשפטי — הוא שם בדיוק כמו קודם.

⚡ עשה עכשיו (Do Now)

חשב על העסק שלך ב-שקלים, לא בדולרים. לכל פונקציה שאתה שוקל להאציל, הערך: (1) כמה שעות בחודש אתה מבלה על זה היום; (2) מה השווי של שעה שלך (₪); (3) מה תעלה הסוכן בטוקנים + תחזוקה (₪/חודש). רק אם (1)×(2) > (3)×1.5, ההאצלה משתלמת. זה ה-P&L הראשון שלך בעברית, והוא יחזור בפרק 6.

לכתוב role spec מלא: מ-org chart לקלט של פרק 3

role specowned functionSOP-ready

ה-org chart נותן מבט-על. אבל כדי שהסוכן יוכל לעבוד, צריך לרדת לרזולוציה של role spec — מסמך תפקיד אחד, מפורט, לסוכן אחד. זה התוצר שיהפוך ל-SOP בפרק 3, אז שווה לעשות אותו טוב. הנה תבנית מלאה, עם דוגמה מיושמת לסוכן SDR.

📄 תבנית role spec (דוגמה מייצגת — סוכן SDR)

שים לב כמה ה-role spec הזה כבר כמעט-SOP. הוא אומר מי הסוכן, מה הוא מקסם, מה מותר לו, במה הוא נוגע, ומתי הוא מסלים. מה שחסר — הצעדים המדויקים ("קודם תייג, אחר כך העשר, אחר כך נסח") עם ניסוח RFC 2119 (MUST/SHOULD/MAY) — זה בדיוק מה שנוסיף בפרק 3. ה-role spec הוא השלד; ה-SOP הוא השריר.

דוגמה מס' 2: role spec לסוכן תוכן (כדי שתראה שהתבנית גנרית)

כדי להראות שהתבנית לא ספציפית ל-SDR, הנה role spec לסוכן תוכן לאותו סטודיו של רוני. שים לב כמה המבנה זהה, רק התוכן משתנה:

רואה? אותם 7 שדות, אותו מבנה, תוכן אחר. זה היופי של תבנית: אתה יכול להעתיק אותה לכל סוכן חדש, למלא את השדות, ולקבל role spec מוכן ל-SOP.

⚡ עשה עכשיו (Do Now)

בחר את הסוכן הכי חשוב שלך (זה שיחסוך לך הכי הרבה זמן). מלא עבורו את כל שבעת השדות בתבנית למעלה. אל תסתפק ב"בערך" — ככל שה-role spec מדויק יותר, ה-SOP בפרק 3 יהיה קל יותר לכתוב. זה ה-deliverable המרכזי שלך מהפרק.

🔁 שגרת עבודה: סבב עיצוב org-chart (פעם בחודש)

ה-org chart אינו מסמך חד-פעמי. שמור אותו ב-git ועבור עליו פעם בחודש:

  1. סקירה: פתח את ה-org chart. לכל סוכן שאל — האם הוא עדיין מנהל פונקציה שלמה, או שחזרתי להאכיל אותו משימות?
  2. תפקיד חדש? אילו 1–2 פונקציות חדשות הבשילו להאצלה החודש? הוסף קופסה, כתוב role spec.
  3. scope drift: האם איזשהו סוכן עושה דברים שלא הגדרת לו? עדכן את ה-scope of authority במפורש.
  4. escalation: האם נתיבי ההסלמה עדיין נכונים? האם משהו שהסלים אליך כל הזמן כדאי שיעבור לאוטונומיה (פרק 5)?
  5. commit: שמור את השינויים ב-git. ה-diff הוא ההיסטוריה הארגונית של החברה שלך.

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

תרגילים

exercisesdeliverables

ארבעת התרגילים הבאים מצטברים לתוצרי הפרק. כל אחד מייצר פלט גלוי שתשמור ב-git — ושישמש קלט ישיר לפרק 3. התרגיל החמישי (אופציונלי) הוא "stretch" — עושים אותו רק אם הראשונים הושלמו.

תרגיל 1 — בניית ה-Org Chart המלא (תוצר נראה: דיאגרמה + טבלה)

מטרה: להפוך את רשימת הפונקציות מפרק 1 ל-org chart שלם ומחווט.

  1. צייר דיאגרמה: קופסה עליונה "אתה — CEO", ומתחתיה 4–6 קופסאות-סוכן (השתמש בששת התפקידים הסטנדרטיים כתבנית).
  2. בנה טבלה עם עמודה לכל אחד מ-5 השדות: תפקיד | goal (תוצאה מדידה) | scope of authority | tools | escalation path.
  3. מלא שורה לכל סוכן. ב-escalation, ציין במפורש למי הוא מסלים ובאיזה טריגר.
  4. שמור כקובץ org-chart.md בתיקייה ייעודית (זה הזרע ל-.context/ של פרק 3).

פלט נראה: קובץ org-chart.md עם דיאגרמה (אפילו ASCII) + טבלה מלאה. מבחן הצלחה: כל סוכן יודע מי בעליו, מה מותר לו, ולמי הוא מסלים.

דוגמה לפלט צפוי (חלק מהטבלה, עבור סוכן SDR):

| תפקיד | Goal (תוצאה מדידה) | Scope of Authority | Tools | Escalation Path |
|---|---|---|---|---|
| SDR | ≥80% מהלידים שמועברים ראויים לפגישה; זמן מענה ראשון ≤60 דקות | קריאה+תיוג+טיוטאות; אסור שליחה החוצה | CRM (קריאה), enrichment (קריאה), תור-טיוטות (כתיבה) | ל-CEO על כל שליחה החוצה; על סתירה בנתונים |
| תוכן | 1 פוסט/שבוע, brand-voice ≥0.8, מאושר ב-≤3 איטרציות | כתיבה ל-/drafts/; אסור פרסום | תיקיות תוכן, eval scorer | ל-CEO על כל פרסום |
| ... | ... | ... | ... | ... |

תרגיל 2 — כתיבת role spec מלא לסוכן אחד (תוצר נראה: מסמך תפקיד)

מטרה: לרדת מרזולוציית org chart לרזולוציית מסמך תפקיד מפורט — הקלט הישיר ל-SOP של פרק 3.

  1. בחר את הסוכן החשוב ביותר שלך (זה שחוסך הכי הרבה זמן).
  2. מלא את כל שבעת השדות מתבנית ה-role spec: role, goal (מדיד!), backstory, scope of authority, tools, owned function, escalation path.
  3. בדוק את ה-goal: אם אתה לא יכול להגיד "הצליח/נכשל" בסוף החודש — חדד אותו עד שתוכל.
  4. שמור כקובץ role-[שם-הסוכן].md לצד ה-org chart.

פלט נראה: קובץ role spec מלא בן 7 שדות. מבחן הצלחה: אדם אחר (או סוכן) יכול לקרוא את המסמך ולהבין בדיוק מה התפקיד עושה ומה אסור לו — בלי לשאול אותך.

דוגמה ל-goal שעובר את המבחן: "להעביר ליומן 8-12 לידים מתאימים בחודש (≥80% מהם יובילו לפגישה שנסגרת לשלב הבא)". goal כזה ניתן למדוד — בסוף החודש אתה יכול להגיד "8/10 הובילו לפגישה = 80%, עבר" או "5/10 = 50%, נכשל, צריך לחדד את ה-ICP".

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

תרגיל 3 — טבלת החלטת stack (תוצר נראה: מסמך החלטה מנומק)

מטרה: לבחור באיזה stack תממש את הצי, מנומק לפי רמת הנוחות שלך — לא לפי trend.

  1. בנה טבלה עם 3 שורות (CrewAI / LangGraph / minimal API+cron+git) ועמודות: עקומת למידה, control נדרש, תלות framework, התאמה לעסק שלך.
  2. דרג כל אופציה 1–5 לכל קריטריון, מנקודת המבט של העסק שלך (לא באופן כללי).
  3. כתוב פסקת החלטה: באיזה stack בחרת ולמה. אם בחרת minimal — מצוין, זו לרוב הבחירה הנכונה להתחלה.
  4. הוסף שורת freshness: תאריך הבדיקה + תזכורת לאמת סטטוס frameworks (AutoGen/LangGraph/CrewAI) לפני שתתחייב לקוד.

פלט נראה: קובץ stack-decision.md עם טבלה מדורגת + פסקת החלטה מנומקת. מבחן הצלחה: אתה יכול להסביר לחבר ב-30 שניות למה בחרת את ה-stack הזה ולא אחר.

דוגמה לפלט (עבור operator ישראלי ללא רקע הנדסי):

| קריטריון (משקל) | CrewAI | LangGraph | minimal |
|---|---|---|---|
| עקומת למידה (פי 3) | 5 | 1 | 4 |
| control/audit (פי 2) | 3 | 5 | 3 |
| תלות (פי 2) | 2 | 2 | 5 |
| התאמה לעסק שלי (פי 3) | 4 | 2 | 5 |
| **ניקוד משוקלל** | **42** | **26** | **49** |

**החלטה: minimal (API+cron+git).** העסק שלי (סוכנות שיווק קטנה, 3 לקוחות) לא דורש audit trails enterprise-level, ואני לא רוצה להשקיע שבועות בללמוד LangGraph. minimal מספיק: cron + Claude API + git. אם אגדל ל-15+ לקוחות או אכנס לתחום מוסדר, אעבור ל-CrewAI או LangGraph.

**תאריך בדיקת frameworks: 2026-06-20. תזכורת לבדיקה חוזרת: 2026-09-20. סטטוס נוכחי: AutoGen → maintenance mode, LangGraph → active + enterprise adoption growing, CrewAI → active + role-based ecosystem strong.**

תרגיל 4 — מפת ההסלמה והאוטונומיה של הצי (תוצר נראה: טבלת escalation)

מטרה: לחווט את כל הסוכנים זה לזה ואליך — להפוך רשימת קופסאות לארגון אחד, ולהכין את הקרקע ל-calibrated autonomy של פרק 5.

  1. בנה טבלה עם שורה לכל סוכן ועמודות: סוכן | פעולות שמותר לבד | פעולות שדורשות אישור | טריגרי הסלמה | למי מסלים.
  2. לכל פעולה שאתה רושם, סווג אותה בראש לפי שני צירים: האם היא הפיכה או בלתי-הפיכה, ומה ה-stakes (נמוך/בינוני/גבוה). פעולה בלתי-הפיכה או high-stakes → לעמודת "דורש אישור".
  3. סמן את כל הפעולות שנוגעות בכסף/הרשאות/רשומות — אלה תמיד בעמודת האישור, ללא קשר לביטחון הסוכן.
  4. הוסף עמודת "autonomy ladder": היכן כל סוכן יושב היום (human-in-the-loop = אישור לכל פעולה) ומה הסף שיאפשר לו לטפס (נחבר אותו ל-eval pass-rate בפרק 5).
  5. שמור כקובץ escalation-map.md לצד שאר התוצרים.

פלט נראה: קובץ escalation-map.md שמראה לכל סוכן מה מותר לו, מתי הוא מסלים ולמי. מבחן הצלחה: אין אף סוכן שיכול לבצע פעולה בלתי-הפיכה או שנוגעת בכסף בלי שהטבלה אומרת במפורש "דורש אישור".

דוגמה לפלט (חלק מהטבלה):

| סוכן | מותר לבד | דורש אישור | טריגרי הסלמה | למי מסלים | Autonomy ladder (היום → יעד) |
|---|---|---|---|---|---|
| SDR | תיוג, טיוטאות, סינון ICP | שליחה החוצה, שינוי סטטוס ליד | retries>3, סתירה בנתונים, סכום>0 | CEO | L1 (אישור לכל פעולה) → L3 (אוטומטי לאחר eval pass-rate ≥90%) |
| תוכן | כתיבה ל-/drafts/, הצעת כותרות | פרסום, מחיקה, שינוי פוסט קיים | brand-voice <0.7, מילים אסורות במותג | CEO | L1 → L2 (פרסום אוטומטי אחרי eval ≥0.85 במשך 4 שבועות) |
| תמיכה | מענה מ-knowledge base, סיווג | refunds, ביטול חשבון, מחיקת נתונים | CSAT<3, מילים משפטיות, לקוח VIP | CEO | L1 → L2 (refunds עד ₪100 אוטומטיים, מעל זה → CEO) |

תרגיל 5 (אופציונלי / stretch) — מיפוי "אם X אז Y" לכל סוכן (תוצר נראה: decision tree קצר)

מטרה: להפוך את המבנה המנטלי "אם X אז Y" לחלק מה-role spec — כדי שבפרק 3 תוכל לכתוב SOP מדויק בלי להתלבט.

  1. לכל סוכן, כתוב 3-5 החלטות "אם X אז Y" שהוא צריך לקבל. למשל עבור SDR: "אם הליד תואם ICP ב-3+ קריטריונים מתוך 5, אז להעביר ליומן. אם רק ב-2, אז לבקש enrichment נוסף. אם ב-1 או פחות, אז לפסול עם נימוק."
  2. כתוב את ההחלטות האלה כ-tree פשוט: התחלה → תנאי → הסתעפות → תוצאה.
  3. סמן ליד כל הסתעפות: "הסוכן יכול להחליט לבד" או "דורש אישור אנושי".
  4. חבר את ה-tree ל-role spec: בסעיף "owned function", הוסף "כולל decision tree שמתועד ב-decision-tree-[agent].md".
  5. שמור את ה-trees בתיקייה. הם יהפכו לבסיס ל-SOP-ים בפרק 3.

פלט נראה: 3-5 קבצי decision tree, אחד לכל סוכן מרכזי. מבחן הצלחה: עבור כל סוכן, אתה יכול לעקוב אחרי ה-tree עם דוגמה אמיתית מהחודש שעבר ולקבל את אותה החלטה שהסוכן יקבל. זה ה-dry-run הראשון שלך (ויוצא מפרק 4).

מילון מונחים

glossaryterminology
Role (תפקיד, מול Instruction)
היקף אחריות עומד שסוכן בעל-בית עליו end-to-end (goal + backstory + authority + tools), בניגוד להוראה חד-פעמית שהסוכן ממתין לקבל. סוכן-תפקיד יוזם; סוכן-הוראה מחך.
Goal (מטרה)
התוצאה המדידה שהסוכן מקסם — לא המשימה שהוא מבצע. "להעביר לידים מתאימים" (תוצאה) ולא "לכתוב מיילים" (משימה). חייבת לכלול סף מספרי שמאפשר "הצליח/נכשל".
Backstory / Persona
תיאור ה"אופי" של הסוכן שמכוון את ברירת המחדל של שיקול הדעת שלו בקצה. הדרך להזריק את הטעם שלך לסוכן בלי לפקח על כל החלטה. ב-CrewAI מופיע כשדה נפרד.
Scope of authority (היקף סמכות)
הגדרה מפורשת של מה מותר לסוכן לעשות לבד ומה דורש אישור — read-only מול write, תקרת כסף, אילו tools, האם מותר ליצור sub-tasks. הרכיב שהכי קל לשכוח והכי יקר לוותר עליו.
Owned function (פונקציה בבעלות)
התהליך השלם שהסוכן מנהל מתחילתו ועד סופו — לא משימה בודדת אלא מסע שלם (למשל: ליד מהטופס ועד פגישה ביומן). הסוכן הוא בעל-בית על המסע הזה, לא על צעד בודד בתוכו.
Org chart of agents
התרשים הארגוני של "חברה של אחד": אתה כ-CEO למעלה, ומתחתיך תפקידי-סוכן, לכל אחד scope ונתיב הסלמה. ממיר את האינטואיציה העסקית לעיצוב סוכנים.
Standing role (תפקיד עומד)
תפקיד שקיים גם כשה-operator לא מסתכל עליו. לסוכן יש יעד ברור, הוא יודע מה מותר לו, והוא יודע מתי להסלים. זה ההפך מ"chatbot שמחכה לבקשה הבאה".
ICP (Ideal Customer Profile)
פרופיל הלקוח האידיאלי — תיאור מפורש של הלקוח שעבורו העסק שלך נועד (תעשייה, גודל, תפקיד, כאב, יכולת תשלום). סוכן SDR משתמש ב-ICP כדי לסנן לידים.
One-touch resolution (פתרון בפעם ראשונה)
מדד מפתח לסוכן תמיכה: אחוז הטיקטים שנסגרים בפעם הראשונה בלי שנדרש מעקב. גבוה = הסוכן מבין את הבעיה. נמוך = הסוכן משאיר את הלקוח בלי פתרון.
CrewAI
Framework רב-סוכני role-based: מגדירים agents עם role+goal+backstory ומקצים להם tasks ב-process מסוג sequential (סדרתי) או hierarchical (היררכי). הכי קל לקהל שחושב בתפקידים; ~20 שורות להתחיל.
LangGraph
Framework מבוסס גרף מכוון עם conditional edges, audit trails ו-rollback. control/compliance מקסימליים, עקומת למידה גבוהה. עקף את CrewAI ב-stars בתחילת 2026.
Skip the framework (minimal stack)
לוותר על framework ולעבוד עם קריאות API ישירות + scheduler (cron) + git. פחות תלות, פחות מה שנשבר — לרוב מספיק ל-operator עסקי. כולל גם תיקיית .context/ כמקום ל-role specs.
AutoGen (maintenance mode)
Framework לשיחות רב-סוכניות (GroupChat) שעבר ב-2026 ל-maintenance mode; הפיתוח הפעיל עבר ל-Microsoft Agent Framework. לא לבנות עליו net-new. תאריך אימות סטטוס: 2026-06-05 (research date); מומלץ לבדוק שוב לפני התחייבות.
Microsoft Agent Framework
היורש של AutoGen מבית Microsoft. פיתוח פעיל ב-2026. אם חייבים תשתית native של multi-agent עם תמיכה ארגונית, זו האלטרנטיבה הנתמכת כעת.
Escalation path (נתיב הסלמה)
הכלל המפורש: למי הסוכן מסלים (אליך / לסוכן אחר) ובאילו תנאים (כסף, תקוע, בלתי-הפיך). חיווט הצי כמערכת אחת.
Integration-point problem (בעיית נקודת-האינטגרציה)
כשל המייסד הסולו: כלים מנותקים שאף אחד לא יודע מה השני עושה, והמייסד הוא הדבק היחיד. הפתרון: shared context layer (תיקיית .context/ ב-git).
Shared context layer (שכבת הקשר משותפת)
תיקיית .context/ ב-git repo שמכילה את כל המסמכים שהצי צריך: org chart, role specs, SOPs, החלטות, לקחים. הסוכנים קוראים וכותבים לתיקייה הזו, ולכן כולם רואים את אותה תמונה. התבנית מופיעה ב-gru-ai.
gru-ai
פרויקט OSS ברישיון MIT, "11-agent team for one-man companies", שמשתמש ב-.context/ pattern וב-pipeline של 15 שלבים. חלופה חינמית ל-Knowlee לסוכן שבונה את הצי. נחזור אליו בפרק 7.
Orloj
פלטפורמת OSS ברישיון Apache-2.0 ל-agent infrastructure-as-code — מגדירים agents/tools/policies ב-YAML, runtime fail-closed governance, cron+eval מובנים. חלופה חינמית ל-Knowlee לסוכן שצריך production governance.
Calibrated autonomy (אוטונומיה מכוילת)
הרעיון שאוטונומיה של סוכן היא לא בינארית (on/off) אלא סולם. כל סוכן מתחיל באישור-לכל-פעולה (human-in-the-loop), ועולה בסולם רק אחרי ש-eval pass-rate שלו עובר סף שאתה קובע. נושא מרכזי בפרק 5.
Human-in-the-loop / Human-on-the-loop
human-in-the-loop = האדם מאשר כל פעולה לפני ביצוע. human-on-the-loop = האדם רק מפקח, ומתערב רק במקרה חריג. ההבדל בין "לא נותן לסוכן לפעול בלי אישור" לבין "נותן לסוכן לפעול, ורק מתריע במידת הצורך".
RFC 2119 (MUST / SHOULD / MAY)
תקן אינטרנט שמגדיר שלוש רמות של דרישה: MUST (חובה), SHOULD (מומלץ), MAY (רשות). בעולם ה-SOPs לסוכנים, זה המנגנון שמבדיל בין "חובה לעשות X" לבין "מומלץ לעשות Y" לבין "יכול לעשות Z אם רוצה". ה-SOPs של 2026 (Strands Agent SOPs) משתמשים בו.
Determin-ish-tic (דטרמיניסטי-כמעט)
תיאור של SOPs אגנטיים: מובנים מספיק כדי להיות עקביים, גמישים מספיק כדי לא לחנוק את שיקול הדעת של המודל. האיזון הקריטי בין "כל פעולה מתועדת" לבין "הסוכן לא הופך לרובוט".
Brand-voice score (ציון קול מותג)
מדד אוטומטי (0-1) שמודד עד כמה תוכן תואם לקול המותג של העסק. חלק מה-eval שסוכן תוכן חייב לעבור לפני שטיוטה מוגשת לאישור. הסף המקובל ב-2026: ≥0.8.
Knowledge cutoff (חתך ידע)
תאריך המידע האחרון שעליו אומן מודל. חשוב לבדוק כשמסתמכים על מודל למידע עובדתי (מחירים, סטטוס frameworks). לא להסתמך על מודל שחתך הידע שלו ישן יותר מתאריך המידע שאתה צריך.
Freshness-sensitive (רגיש-לרעננות)
מידע שמשתנה מהר — סטטוס frameworks, מחירי API, תקנות. במסמך זה: כל מה שמסומן "נכון ל-2026-06-05" דורש בדיקה חוזרת לפני שימוש.
Operator (בהקשר שלנו)
לא "מפעיל טכני" אלא "בעל-בית יחיד על חברה". התפקיד שלך במודל "צוות של איש אחד": לא לבצע, אלא להכווין, לאשר, ולקבל החלטות. במקורות מסוימים זה נקרא גם "vibe CEO".

✨ Just One Thing

אם תיקח מהפרק הזה דבר אחד בלבד: תפסיק לתת משימות, התחל לתת תפקידים. משימה משאירה אותך צוואר הבקבוק; תפקיד — עם goal, scope ונתיב הסלמה — הופך את הסוכן לבעל-בית על פונקציה שלמה. כתוב היום role spec אחד מלא, ושמור אותו ב-git. זה ההבדל בין chatbot מהיר ל-teammate אמיתי.

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

  1. מהו ההבדל המבני בין סוכן-הוראה לסוכן-תפקיד, ולמה רק האחרון מוציא אותך מצוואר הבקבוק?
  2. מנה את ששת רכיבי מפרט התפקיד (role spec). איזה מהם הכי קל לשכוח, ולמה ויתור עליו מסוכן?
  3. מה ההבדל בין goal שמנוסח כמשימה לבין goal שמנוסח כתוצאה מדידה? תן דוגמה לכל אחד.
  4. מתי תבחר CrewAI, מתי LangGraph, ומתי "skip the framework"? מהו כלל האצבע להתחלה?
  5. מהי בעיית נקודת-האינטגרציה, ואיך shared context layer (תיקיית .context/) ונתיבי escalation פותרים אותה?

📝 סיכום הפרק

  1. הוראה כובלת, תפקיד משחרר. כל עוד אתה מאכיל את הסוכן משימה-אחר-משימה, אתה ה-throughput של החברה. תפקיד — שהסוכן בעל-בית עליו end-to-end — מעביר את צוואר הבקבוק אל ה-eval וה-approval, לא אליך.
  2. תפקיד-סוכן נבנה מ-6 רכיבים: role, goal (תוצאה מדידה!), backstory, scope of authority, tools, owned function. ה-scope וה-escalation הם הרכיבים שהכי קל לשכוח והכי יקר לוותר עליהם.
  3. ה-org chart האנושי ממופה לסוכנים כמעט אחד-לאחד. ששת התפקידים הסטנדרטיים (מכירות, תוכן, תמיכה, מחקר, כספים, תפעול) הם הקופסאות הטבעיות — אבל האצל קודם את מה שחוזר ולא דורש judgment. סדר ההאצלה עוקב אחרי רמת הסיכון (read-only → drafts → publish → כסף).
  4. שלושה stacks, לפי רמת הנדסה: CrewAI (קל, role-based) · LangGraph (control/compliance) · minimal (API+cron+git). התחל מ-minimal; עבור ל-framework רק כשהכאב מצדיק את התלות. הימנע מ-net-new על AutoGen (maintenance mode); אמת סטטוס לפני התחייבות.
  5. מבנה מנצח פיזור. בעיית נקודת-האינטגרציה נפתרת ב-shared context layer (.context/) + נתיבי escalation מפורשים. זה מה שהופך רשימת סוכנים לצי שפועל כמערכת אחת.

🌉 גשר לפרק הבא: יש לך עכשיו org chart מלא ולפחות role spec אחד מפורט — השלד של הצי. אבל role spec אומר מה הסוכן עושה, לא בדיוק איך. בפרק 3, "SOPs לסוכנים: לכתוב את ספר ההפעלה של החברה", ניקח את ה-role spec ונהפוך אותו ל-SOP אגנטי מדויק — נהלי עבודה בשפה טבעית עם RFC 2119 (MUST/SHOULD/MAY), מאוחסנים ב-.context/ ב-git, מוכנים להפוך ל-Claude Code Skill שהסוכן טוען לבד. נעבור מ"מי הסוכן" ל"בדיוק איך הוא עובד, צעד אחר צעד".

☑️ צ'ק-ליסט סיום פרק

→ פרק 1: אתה לא עושה הכל — אתה מפעיל צי פרק 3: SOPs לסוכנים ←