זה הפרק שבו כל מה שבנית — org chart, SOPs, loop, autonomy, P&L, template — מתחבר למערכת אחת חיה שרצה כעסק. לא עוד תרגיל בודד; הפעם אתה מרכיב חברה.
פרק 7 (קודם): הרכבת צי חי מתבנית OSS מאומתת (gru-ai / Orloj / Hermes) או stack מינימלי, חיברת עליו observability והגדרת governance ב-runtime — הבסיס הטכני.
פרק 8 (כאן, אחרון): מחברים את ארבעת התפקידים למערכת עסקית אחת חיה — loop + autonomy + observability + payroll — ומקבלים את ההחלטות העסקיות הסופיות: build-vs-buy, הצעת תפקיד-כשירות לשוק הישראלי, ו-portability plan. זה ה-capstone שסוגר את הקורס.
אחרי הפרק: אין פרק נוסף — יש לך 'חברה של אחד' רצה ב-git, וצ'קליסט production שמכין אותה לעולם האמיתי. אתה מסיים את הקורס כ-operator, לא כפרילנסר.
זה פרק אינטגרציה — הוא נשען על כל שבעת הפרקים הקודמים. אם דילגת על אחד מהם, ה-capstone לא יחבר את החלקים שאין לך:
עד עכשיו בנית שבעה חלקים נפרדים, פרק אחרי פרק. כל אחד מהם עמד בפני עצמו: org chart בפרק 2, SOP בפרק 3, loop בפרק 4. אבל חלקים נפרדים הם בדיוק מה שהקורס הזה בא לרפא — בעיית נקודת-האינטגרציה שראינו בפרק 1: כלים מנותקים שאף אחד מהם לא יודע מה השני עושה, ואתה ה-glue היחיד ביניהם. כפי שניסחה זאת Nestr, "לרוב המייסדים הסולו שבונים עם סוכני-AI אין מבנה... המייסד הוא נקודת-האינטגרציה היחידה". ה-capstone הזה הוא הרגע שבו אתה מפסיק להיות ה-glue.
המעבר מ"שבעה חלקים" ל"חברה אחת" הוא מעבר בחיווט (wiring), לא בכמות. אתה לא בונה שום דבר חדש — אתה מחבר את מה שכבר קיים כך שכל חלק מזין את השני. ה-wiring עצמו הוא ה-competitive moat שלך: כל אחד יכול לפתוח Notion ולשים שם GPT. אבל operator שמחזיק org chart ב-git, SOPs שסוכנים טוענים, loop שמשפר בלילה, ו-P&L חודשי — זה מה שמפריד בין "שימוש ב-AI" לבין "הפעלת חברה":
| השכבה | מאיזה פרק | מה היא תורמת לצי החי |
|---|---|---|
| Org chart (4 תפקידים) | פרק 2 | מי הסוכנים, מה ה-scope של כל אחד, ולמי הוא מסלים |
| SOPs כ-Skills | פרק 3 | איך כל תפקיד מבצע את העבודה שלו בעקביות (RFC 2119) |
| Loop: cron+eval+reflexion | פרק 4 | המנוע שמריץ בתזמון, מנקד מול golden set, ומשפר בלילה |
| Autonomy + approval gates | פרק 5 | מה רץ לבד מול מה דורש חתימה שלך — המשמעת |
| Agent payroll + routing | פרק 6 | כמה כל תפקיד עולה בש"ח, ואיזה מודל מריץ אותו |
| Template + observability | פרק 7 | הבסיס הטכני וה'מצלמת אבטחה' על כל הצי |
הצי החי הוא ארבעה תפקידים — בדיוק אלה שה-capstone של הקורס (מה-syllabus) דורש: מכירות, תוכן, תמיכה, כספים. למה דווקא ארבעה ולא שישה? כי ה-capstone מודד אם אתה יודע לחבר מערכת, לא אם אתה יודע למלא org chart. ארבעה תפקידים מכסים את כל ארבעת דפוסי החיווט שצריך לשלוט בהם: eval-gate (תוכן), reflexion (תמיכה), approval-gate על כסף (כספים), ו-human-in-the-loop על outreach (מכירות). מי שמרכיב את הארבעה האלה נכון — מרכיב גם שישה. וכפי שמציין Nestr בניסוח חד: "סוכן עם תפקיד מחזיק פונקציה מקצה לקצה; סוכן עם הוראה מחכה להוראה הבאה". ארבעת התפקידים שלמטה הם ארבעה "בעלי-תפקיד", לא ארבעה מבצעי-הוראות.
מקרה ממחיש: דניאל, מנהל שיווק עצמאי בתל אביב, ניסה לנהל שלושה כלים נפרדים — Notion לניהול לידים, Make להפצת תוכן, ו-ChatGPT לפניות תמיכה. הוא עצמו היה הגשר: כל שישי בבוקר הוא העביר נתונים ידנית בין הכלים. ב-capstone הוא עצר את זה. כתב org chart, חיבר SOP, והפעיל loop. כעת כל הנתונים זורמים אוטומטית בין ארבעת התפקידים, ויום שישי שלו פנוי לאסטרטגיה. זה בדיוק מה שה-capstone הזה מלמד — לא לבנות כלי חדש, אלא לחבר את מה שיש.
פתח את ה-repo של החברה (תיקיית .context/ מפרק 3). ודא שיש בה את שלושת אלה: org-chart.md, תיקיית sops/ עם לפחות SOP אחד, ותיקיית lessons/ ריקה או מאוכלסת. אם חסר אחד מהם — חזור לפרק הרלוונטי לפני שתמשיך. אי-אפשר לחבר חלק שלא קיים.
כל אחד מארבעת התפקידים מדגים דפוס חיווט אחר. זה לא מקרי — אם תשלוט בארבעת הדפוסים האלה, תוכל לחבר כל תפקיד עתידי. נעבור אחד-אחד, ונקשור כל תפקיד לפרק שבו בנית את החלק שלו.
סוכן ה-SDR (Sales Development Representative — נציג פיתוח מכירות, התפקיד שמסנן ומכשיר לידים לפני שמגיעים אליך) צופה ב-form/inbox, מכשיר כל ליד מול ICP SOP (Ideal Customer Profile — פרופיל הלקוח האידיאלי), מעשיר אותו, ומנסח outreach. החיווט הקריטי: approval gate אנושי לפני כל הודעה יוצאת. מקור המחקר (Knowlee 4Sales) מתאר את התפקיד הזה כ"autonomous prospecting + multi-channel outreach + meeting booking" — אבל הכלל מפרק 5 חד: כל פעולה שיוצאת ללקוח חיצוני מתחילה ב-human-in-the-loop.
בפועל זה נראה כך: ליד נכנס ל-Google Form בשעה 02:14. הסוכן מתעורר (event-driven), בודק מול ה-ICP SOP — גודל חברה, ענף, תפקיד פונה — ומחשב ציון כשירות. אם הציון עובר 70%, הסוכן מעשיר מ-LinkedIn ומנסח הודעת outreach. ב-07:00 אתה מקבל Telegram עם שלושה לידים ממתינים: "✓ אשר שליחה / ✗ דחה / ✏ ערוך". ליד שלא מקבל אישור עד 09:00 נכנס לתור "cold" אוטומטית. שום הודעה לא יצאה בלי עיניים שלך.
זה לא סוכן אחד אלא שניים בשרשרת: Writer מנסח טיוטה, Editor מנקד אותה מול golden set של brand-voice (קול-המותג). רק טיוטות שעוברות את ה-rubric (מחוון הניקוד) מגיעות לתור הסקירה שלך. זה ה-eval-gate מפרק 4 בפעולה: scorer אוטומטי שחוסם פלט שלא עומד בסטנדרט לפני שאתה מבזבזת עליו תשומת-לב. ה-golden set כאן נבנה מתוצרי ה-dry-run של פרק 3.
הדיוק שמשנה: ה-golden set חייב להכיל דוגמאות של כשל, לא רק הצלחה. Editor שמאומן רק על פוסטים טובים לא יידע לחסום פוסט שטחי שנשמע טוב — הוא רואה את הסגנון אבל לא את העומק. הכנס למינימום 3 דוגמאות "נדחה + הסבר למה" לכל קריטריון ב-rubric. זה מה שמבדיל eval שעובד מ-eval שמאשר הכל.
סוכן התמיכה מסווג פנייה (classify), מנפק first response מ-SOP, ומסלים פניות קשות/מסוכנות אליך. החיווט הייחודי: אחרי כל פנייה הוא מריץ צעד reflexion — כותב "מה הייתי צריך לעשות אחרת" ל-.context/lessons/. זה ה-loop מפרק 4 ברמת התפקיד: לפי המאמר המכונן (Shinn et al., arXiv 2303.11366), שלושת המודולים Actor→Evaluator→Self-Reflection מאפשרים שיפור בלי אימון מחדש, כך ש"הפנייה ה-10 מטופלת טוב יותר מהראשונה" (gru-ai מכנה זאת "lessons learned").
דוגמה קונקרטית מה-paper: במבחן HotPotQA (שאלות מורכבות עם מרובה-מקורות), מודל GPT-4 עם Reflexion השיג +20% על ביצוע בלי reflexion — בלי אף עדכון משקל. על פי gru-ai, "ה-directive ה-10 רץ טוב יותר מהראשון" בגלל שהלקחים שנצברים ב-.context/lessons/ הופכים לחלק מה-context של כל ריצה עתידית. בסוכן תמיכה זה אומר: פנייה שגרמה לסלמה בשבוע שעבר → lesson נכתב → השבוע אותו סוג פנייה טופלה מיד בלי סלמה.
סוכן הכספים מנקד חוזים/מנויים לסיכון חידוש (renewal/churn-risk), ומנסח את פניית החידוש. החיווט הקריטי, מפרק 5: כל פעולה שנוגעת בכסף מגודרת ב-approval gate עם סף ₪ + named approver. הסוכן מנסח, אבל אף שקל לא זז בלי one-click approval שלך. זה היישום הישיר של כלל money/permissions/records/state — הפעולה הכי בלתי-הפיכה בצי מקבלת את הגדר הכי מחמירה.
למה דווקא finance נשאר הכי נמוך בסולם ה-autonomy? כי טעות בתוכן אפשר לתקן — מחיקת פוסט, שליחת פוסט מתקן. טעות ב-outreach אפשר לתקן — התנצלות, הסבר. אבל פנייה שגויה לחידוש לקוח (מחיר שגוי, תנאים שגויים, לחצן "שלח חשבונית" שנלחץ לא נכון) — זה נזק שיכול לעלות ביחסי לקוח, במשפטי, ובפנים. reversibility הוא מה שמכתיב את רמת ה-gate, לא רמת ה-eval.
כשתרצה להוסיף תפקיד חמישי או שישי, אל תמציא חיווט — מַפֵּה אותו לאחד מארבעת הדפוסים:
רוב התפקידים הם שילוב של שניים מהדפוסים. סוכן מכירות, למשל, הוא human-in-the-loop וגם reflexion.
המפתה ביותר הוא לתת לכל ארבעת הסוכנים אותה רמת autonomy ("כולם human-in-the-loop, ליתר ביטחון" או — גרוע יותר — "כולם אוטונומיים, כי בניתי eval"). זו טעות. תפקיד הכספים חייב approval-gate על כסף גם אחרי שה-eval pass-rate שלו מצוין; תפקיד התוכן לא צריך approval-gate אנושי על כל טיוטה — ה-eval-gate מספיק. דפוס שגוי = או צוואר בקבוק (אתה מאשר הכל) או סיכון (כסף זז לבד).
.context/ לפני תרגיל 1תרגיל 1 (וגם 2) תלויים בקבצים שיוצרים בפרקים 2+3. אם הם לא קיימים ב-.context/ שלך — צור אותם עכשיו, אחרת fleet-wiring.md יצביע על קבצים חסרים ותרגילים 1+2 ייתקעו:
mkdir -p .context/{org,sops,lessons,decisions,schedules} — צור את 5 תתי-התיקיות..context/org/chart.md (4 התפקידים + owned function לכל אחד)..context/sops/sdr-qualify.md, .context/sops/writer-edit.md, .context/sops/support-triage.md, .context/sops/finance-renewal.md — 4 קבצי ה-SOP שעליהם fleet-wiring.md יצביע.בלי 5 הקבצים האלה, "מלא שורה לכל תפקיד" הופך ל-תרגיל תיאורטי. השלם את 3 הצעדים לפני שאתה פותח את fleet-wiring.md.
מטרה: תוצר נראה לעין — טבלה אחת שמחווטת את כל ארבעת התפקידים שלך, מוכנה להפוך לקוד.
שלבים:
fleet-wiring.md ב-.context/.תוצר נראה: טבלת חיווט בת 4 שורות ו-6 עמודות שאפשר להראות למישהו והוא יבין מיד איך החברה שלך עובדת. זה ה-blueprint שתחבר לפיו בתרגילים הבאים. פלט צפוי — דוגמה מלאה ל-4 שורות: שורת SDR תראה: "SDR | סינון לידים + הכנה לפגישה | sops/sdr-qualify.md | human-in-the-loop על outreach | in-the-loop | כל outreach ממתין לאישור | L (הודעה שנשלחה לא חוזרת)".
| תפקיד | owned function | SOP file | דפוס חיווט | autonomy | reversibility |
|---|---|---|---|---|---|
| SDR | סינון לידים + הכנה לפגישה | sops/sdr-qualify.md | human-in-the-loop על outreach | in-the-loop (כל outreach ממתין לאישור) | L (הודעה יצאה — לא חוזרת) |
| Writer+Editor | טיוטה + ניקוד מול brand-voice rubric | sops/writer-edit.md | eval-gate על golden set | on-the-loop (אחרי 90% pass-rate) | H (מחיקה/תיקון תמיד אפשרי) |
| Support | triage + first-response + reflexion | sops/support-triage.md | reflexion שכותב לקח | on-the-loop (טיפוס מהיר) | H (תגובה ניתנת לתיקון מיידי) |
| Finance | renewal/churn-risk + ניסוח פנייה | sops/finance-renewal.md | approval-gate עם סף ₪ + approver | in-the-loop (תמיד) | L (פעולת כסף — לא הפיכה) |
עכשיו לוקחים את ארבעת התפקידים המחווטים ומחברים אותם ל-loop אחד שרץ בתזמון. בפרק 4 בנית את ה-loop לתפקיד בודד (ה-morning brief); כאן אתה מרכיב את אותו דפוס על ארבעה תפקידים שרצים זה לצד זה. שלושת מרכיבי ה-loop — cron, eval, reflexion — חוזרים, אבל עכשיו ברמת הצי:
| מרכיב | ברמת הצי | מימוש (self-host / managed) |
|---|---|---|
| Cron | כל תפקיד רץ בתזמון משלו (SDR כל שעה, Finance פעם ביום, Support על trigger) | Hermes Agent (daemon, $0 infra) או Claude Code Routines (תשתית Anthropic, בלי תהליך לוקלי) |
| Eval | ה-golden set של כל תפקיד מנקד את הפלט שלו לפני שהוא יוצא | Braintrust (free tier: 1M spans/חודש, 10K eval runs) או Langfuse (OSS, חינמי ל-self-host) |
| Reflexion | כל תפקיד כותב לקח ל-.context/lessons/ אחרי ריצה | קבצי Markdown ב-git — ה-.context/ pattern של gru-ai |
הקריטי כאן: חמשת דפוסי התזמון מפרק 4 לא חלים על כל התפקידים באותה צורה. תזמן כל תפקיד לפי הטבע שלו —
שמור על ה-loop-debt ב-0: בכל פעם שמשהו מצטבר ב-queue בלי שהסוכן מטפל בו, קרא לזה "loop-debt". Loop-debt גדל בשקט — ואתה לא מבחין בו עד שלקוח מתלונן על תגובה שלא הגיעה, על תוכן שלא פורסם, או על חידוש שנשכח. ה-heartbeat (בדיקה שהסוכן בחיים וה-queue מתרוקן) הוא מה שמונע צבירת debt בלתי-נראה. כלל פשוט: כל תפקיד שרץ event-driven צריך heartbeat כל 4 שעות שבודק שה-queue לא עלה מעל 10 פריטים.
פתח קובץ .context/schedules/fleet-cron.md וכתוב ארבע שורות — תזמון לכל תפקיד: "SDR: every 1h + event | Writer: queue-drain | Support: event + heartbeat/4h | Finance: daily 08:00". זה לא הקוד — זה ה-blueprint שממנו תכתוב את הקוד. תרגיל 2 יישאר תקוע בלי זה.
זו המלכודת מפרק 4, אבל היא מתחדדת פי-ארבעה בצי חי. אם ל-SDR אין already-done marker (סימון 'כבר טופל'), הוא יעבד שוב את אותם לידים בכל ריצה — ובצי שרץ כל שעה, זה אומר 24 הודעות outreach כפולות ביום לאותו ליד. כל אחד מארבעת התפקידים חייב סימון idempotency לפני שהוא עולה ל-cron. בדוק את זה לפני ההפעלה, לא אחרי שלקוח מתלונן.
מטרה: תוצר נראה — שני תפקידים שרצים אוטומטית בתזמון, עם eval ו-reflexion מחוברים.
שלבים:
lessons/ שלו (ל-reflexion).תוצר נראה: שני traces ב-Langfuse/Braintrust שמראים את ה-loop המלא רץ end-to-end על שני תפקידים — צילום מסך של ה-trace הוא ההוכחה. פלט צפוי לTrace של Support: span עם שם "support-triage", תת-spans "classify → sop-lookup → draft-response → eval-score:0.87 → reflection-written", וזמן ריצה כולל תחת 45 שניות.
ארבעה תפקידים שרצים בלילה יוצרים בעיה חדשה: איך אתה רואה את התמונה הכוללת בלי לצפות בכל ריצה? התשובה היא דפוס מתוך מחקר הקורס — ה-weekly agent all-hands: cron job שמרכז את הפלטים, הכשלים והלקחים של כל סוכן ל-report אחד שאתה סוקר ביום ראשון בבוקר. כפי שמנסח זאת המחקר: "הישיבה הקבועה שלך עם צוות שלא קיים".
ה-all-hands הוא מה שהופך אותך מ"מי שמגיב לתקלות" ל"operator שמנהל מגמות". הוא צריך לכלול, לכל תפקיד:
החיבור ל-tripwires מפרק 5 קריטי כאן. ה-all-hands הוא הסקירה היזומה השבועית; ה-tripwires הם ההתראות הסלקטיביות בזמן אמת. שניהם יחד הם איך operator סולו "מגדיל את עצמו": ה-tripwire מפנג אותך רק כשסוכן ניסה שוב ושוב, נתקל במקורות סותרים, או הפיק diff/פעולה מסוכנת — אחרת אתה לא מתערב עד יום ראשון. זו selective attention בפעולה.
שאלת ה-operator הנכונה ל-all-hands: לא "מה הסוכן עשה?" אלא "האם הוא עשה זאת בצורה שמשרתת את העסק?". ל-SDR עם 40 לידים שהוכשרו אבל רק פגישה אחת שהפכה ללקוח — ייתכן שה-ICP SOP שלו צר מדי, או שה-outreach טמפלייט גרוע. ה-output count הוא מה שה-all-hands מדווח; הפרשנות היא מה שה-operator עושה ביום ראשון בבוקר.
הבחנה חשובה: all-hands ≠ observability dashboard. ה-observability (פרק 7) מראה לך כל span, כל tool-call, כל retry — ברמת המיקרו. ה-all-hands מדווח ברמת המאקרו: מגמות שבועיות, eval pass-rate, לקחים. אם תנסה לנהל את הצי מ-observability בלבד, תאבד את עצמך בפרטים. אם תנהל רק מ-all-hands, תחמיץ תקלות חדות. שניהם יחד — מיקרו ומאקרו — זה הזוג שמאפשר לך לראות ולהגיב. Langfuse או Braintrust לפרטי הריצות; ה-all-hands לקצב הניהול השבועי.
כתוב טיוטה של תבנית ה-all-hands report שלך כקובץ .context/reports/all-hands-template.md. ארבעה בלוקים, לכל אחד ארבע שורות (output / failures / lessons-to-review / eval-pass-rate). אל תמלא נתונים עדיין — רק את השלד. הוסף שורת כותרת עם: "שבוע: ___ | עלות כוללת: ₪___ | החלטה דחופה: ___". ה-cron ימלא אותו אוטומטית בהמשך.
מטרה: תוצר נראה — report שבועי שנוצר אוטומטית + tripwire אחד חי שמפנג אותך.
שלבים:
תוצר נראה: קובץ all-hands report מלא בנתונים אמיתיים + צילום מסך של התראת ה-tripwire שהגיעה אליך (Telegram/email). פלט צפוי ל-report: "SDR: 18 לידים שוכשרו | 2 כשלים (tool-call timeout) | 1 lesson חדש: 'לא לפנות לחברות מתחת ל-10 עובדים' | pass-rate: 83%".
בפרק 6 בנית את ה-agent payroll dashboard כתבנית. כאן אתה מפעיל אותו על הצי החי — עם נתוני עלות אמיתיים מה-observability. ההבדל קריטי: בפרק 6 חישבת אומדנים; כאן אתה קורא את החשבון האמיתי. ה-payroll הוא מה שהופך את "אני מפעיל סוכנים" ל"אני מנהל עסק עם מרווח".
מספרי-העוגן מהמחקר (להציג כ-ranges עם הנחות, לא כהבטחות — זה COST-CLAIM RISK מפורש בקורס):
ה-payroll dashboard לצי החי, בש"ח (כולל FX מ-USD — ספקי ה-LLM מחייבים בדולרים, וזה חייב להיכנס ל-P&L שלך). הטבלה למטה היא דוגמה מייצגת — המספרים הם המחשה, לא נתוני אמת; אתה ממלא את שלך מה-observability:
| תפקיד | מודל ראשי | עלות/חודש (₪)* | ROI (הכנסה/חיסכון שמייצר) | החלטה |
|---|---|---|---|---|
| SDR (מכירות) | frontier ל-qualify, זול ל-enrich | ~₪650 | מכשיר 40 לידים/חודש → 3 פגישות | Promote (העלה ב-autonomy) |
| Writer+Editor (תוכן) | זול ל-draft, frontier ל-edit | ~₪420 | 12 פוסטים/חודש שעוברים eval | Right-size (הורד את ה-Editor למודל זול יותר) |
| Support (תמיכה) | זול ל-triage, frontier ל-10% הקשים | ~₪300 | חוסך ~15 שעות/חודש שלך | Keep |
| Finance (כספים) | frontier (סיכון גבוה, נפח נמוך) | ~₪180 | תופס 2 חידושים בסיכון/חודש | Keep |
* דוגמה מייצגת. הנחות: שער USD→ILS ו-נפחים הם להמחשה בלבד; מלא את שלך מנתוני ה-observability האמיתיים.
ההחלטה לכל תפקיד היא תמיד אחת משלוש — fire / promote / right-size — ותמיד לפי מספרים, לא vibes. שים לב למלכודת ה-loop הריבועי שחוזרת כאן מפרק 6: session בן 10 turns עולה ~50x קריאה בודדת, לא 10x, כי כל turn שולח שוב את כל ההיסטוריה. תפקיד שנראה זול פר-קריאה יכול להיות יקר מאוד פר-session. תקצב loops, לא קריאות.
כיצד "right-size" נראה בפועל: תפקיד ה-Writer+Editor בדוגמה למעלה עולה ₪420/חודש. ה-tiered routing שלמדת בפרק 6 אומר: שלח את 90% ה-drafts הפשוטים למודל זול (עלות: ~$0.001/draft), ואת ה-10% שה-Editor דחה לבדיקה מחודשת על מודל frontier. בהנחת 12 פוסטים/חודש, מעבר למודל זול ל-draft חוסך ~₪280/חודש — כמעט 67%. הכלל מהמחקר: tiered routing יכול לחתוך עלות פר-conversation עד ~80%.
הסוכן הכי "מרשים" שלך הוא לא בהכרח הכי רווחי. תפקיד שמפיק תוכן יפה אבל רץ על מודל frontier יקר על כל טיוטה יכול לשרוף יותר ממה שהוא מייצר. בלי ה-payroll dashboard לא תראה את זה — תראה רק פלט יפה. ה-ROI פר-תפקיד הוא מה שמבחין בין "סוכן מרשים" ל"סוכן רווחי". 'free OSS' לא פותר את זה: gru-ai/Orloj/Hermes חינמיים ברישיון בלבד — צי always-on עדיין צובר חשבון טוקנים שיכול להשתוות למשכורת.
מטרה: תוצר נראה — dashboard payroll בש"ח עם נתוני עלות אמיתיים מה-observability + החלטה לכל תפקיד.
שלבים:
תוצר נראה: טבלת payroll מלאה בש"ח + שורת החלטה לכל תפקיד + חישוב חיסכון אחד מ-routing + אחוז עלות מול הכנסה. פלט צפוי — 4 שורות בטבלת payroll (מתואם לדוגמה למעלה; המספרים הם אותם ערכי-דוגמה שתרגיל 5 ייקח מהם): "SDR: ₪650/חודש | מכשיר 40 לידים → 3 פגישות → ~₪24,000 ARR | ROI: ~37x | Promote · Writer+Editor: ₪420/חודש | 12 פוסטים/חודש שעוברים eval | Right-size (להוריד editor למודל זול) · Support: ₪300/חודש | חוסך 14 שעות × ₪150/שעה = ₪2,100 | ROI: ~7x | Keep · Finance: ₪180/חודש | תופס 2 חידושים בסיכון/חודש | Keep · סך עלות צי: ₪1,550/חודש (~4% מהכנסה ₪40,000/חודש — מתחת לסף ה-20% המסומן)".
עכשיו שיש לך צי חי עם payroll, אתה יכול לקבל את ההחלטה העסקית הסופית לכל תפקיד: לבנות על OSS (אתה הבעלים, אתה משלם טוקנים) או לקנות commercial OS (מהיר יותר, אבל lock-in). זו לא החלטה אחת לכל הצי — היא יכולה להיות שונה פר-תפקיד.
| אופציה | דוגמאות מאומתות | מתי לבחור | הסיכון |
|---|---|---|---|
| Build (OSS) | gru-ai (MIT), Orloj (Apache-2.0), Hermes | אתה רוצה בעלות מלאה, control, ו-portability; נוח לך עם git ו-YAML | חשבון טוקנים שלך; Orloj pre-1.0 — APIs עשויים להשתנות, חובה ל-pin גרסה |
| Buy (commercial OS) | Knowlee OS (5 verticals על backbone אחד) | אתה רוצה מהירות time-to-value ולא אכפת לך לשלם על פלטפורמה | vendor lock-in: ה-'Brain'/knowledge-graph וה-audit trail חיים ב-OS שלהם |
| Minimal | plain API + cron + git | צי קטן, אתה רוצה אפס תלות framework | אתה בונה יותר בעצמך; פחות observability/governance מובנים |
בלי קשר לבחירה, ה-portability plan הוא חובה — זה ה-VENDOR-LOCK RISK המפורש בקורס. הכלל הפשוט: כל config + memory של הצי חי ב-git כ-Markdown+JSON (ה-.context/ pattern). זה אומר שני דברים: (1) ה'חברה' שלך forkable, diff-able ו-recoverable — עריכת SOP גרועה היא git revert אחד; (2) אם תלך לפלטפורמה מסחרית, ודא שיש לה נתיב export לפני שאתה תלוי ב-'Brain' שלה. תכנן את היציאה לפני הכניסה.
דוגמה מוחשית לחשיבות ה-portability: Langfuse, אחד מכלי ה-observability המובילים בקורס, נרכש על ידי ClickHouse בינואר 2026. הוא נשאר OSS ועצמאי — אבל אם לא היה נשאר, ואת כל ה-traces שלך היו נעולים ב-cloud שלו? מי שהריץ self-hosted היה עצמאי לחלוטין. הכלי הנכון הוא הכלי שאפשר לעזוב.
פלטפורמות 'AI workforce' (Knowlee-class) מאחסנות את הידע המצטבר של הצי שלך ב-OS שלהן. זה נוח עד הרגע שבו תרצה לעבור — ואז תגלה שכל הזיכרון המוסדי שלך נעול. בנה את מוח-החברה ב-git מהיום הראשון, גם אם אתה משתמש בכלי מסחרי מעליו. ה-git repo הוא מקור-האמת; הפלטפורמה היא רק runtime שאפשר להחליף.
פתח את .context/decisions/build-vs-buy.md וכתוב שורה אחת לכל תפקיד: build / buy / minimal + סיבה אחת. אם בחרת buy לאיזשהו תפקיד — הוסף שורה שנייה: "נתיב export: ___". אם אין לך תשובה לנתיב ה-export, זה דגל אדום. הוסף בתחתית שורה אחת נוספת: "snapshot date: ___ | בפרויקט הבא אאמת: ___" — כי ה-freshness של ה-tech stack זז מהר, וההחלטה הזו צריכה re-check כל רבעון.
זה החלק שהופך את הקורס מ"איך לנהל את הצי שלך" ל"איך להרוויח מהצי שלך בשוק הישראלי". ישראל היא קרקע פורייה למודל הזה: ~550,000 עצמאים (~12% מכוח העבודה, נתוני למ"ס 2024) ותרבות פרילנס/indie עמוקה. אבל היתרון המבני האמיתי הוא תמחור.
הנקודה החדה (מקור: Times of Israel): סוכנות של 5 אנשים חייבת לתמחר משהו כמו בוט-WhatsApp בסביבות ~₪45,000 — לא כי העבודה שווה כך, אלא כדי לכסות משכורות, משרד, project manager ומרווח. operator סולו עם צי סוכנים, באפס תקורה, יכול לספק את אותה עבודה בחלק קטן מהמחיר — וזה לא דמפינג, זה יתרון מבני. אין לך 5 משכורות לכסות; יש לך חשבון טוקנים בש"ח (שבנית בדיוק עכשיו ב-payroll).
איך פועלים על זה? productize-a-role — אורזים תפקיד מואצל אחד כשירות:
מקרה מספרי מוחשי: נניח שתפקיד ה-SDR עולה לך ₪650/חודש (מה-payroll, תרגיל 4). ×4 מרווח = ₪2,600/חודש ללקוח. ₪2,600 × 12 = ₪31,200/שנה — 69% מהצעת ה-₪45,000 של הסוכנות, אבל הלקוח מקבל שירות 24/7 בלי שאלות על "מי הPM", בלי ישיבות, ובלי חשבונית על שינוי. ואתה מריץ 5 לקוחות כאלה במקביל — עם אותו צי. זו אסימטריה שסוכנות של 5 אנשים לא יכולה לשחק.
אל תתמחר לפי מחיר הסוכנות — תמחר לפי עלות + מרווח, ואז וודא שאתה עדיין מתחת לסוכנות:
מפתה לחשוב "הסוכנות לוקחת ₪45,000, אקח ₪8,000 וארוויח מלא". אבל אם לא בדקת את עלות הטוקנים האמיתית של התפקיד (כולל ה-loop הריבועי!), אתה עלול למכור בהפסד בלי לדעת — במיוחד אם הלקוח שולח נפח גדול. תמיד תמחר מ-עלות כלפי מעלה, לא מ-מחיר-הסוכנות כלפי מטה. ה-payroll dashboard הוא מה שמונע את זה. ואל תשכח: לקוח שמשתמש ב-SDR שלך ב-3× הנפח הצפוי = 3× העלות שלך, אבל אותו מחיר חוזי.
מטרה: תוצר נראה — מסמך הצעה בן עמוד אחד ל-SMB ישראלי, עם מרווח מוכח.
שלבים:
תוצר נראה: מסמך הצעה בן עמוד אחד עם טבלת השוואה לסוכנות + שורת מרווח מוכחת + גבולות שירות. זה מסמך שאפשר לשלוח ללקוח אמיתי מחר. פלט צפוי לשורת מרווח: "₪2,600 (מחיר) − ₪650 (עלות טוקנים) = ₪1,950 רווח/חודש | מרווח: 75%".
הצי החי מעלה שאלה: מה קורה כשאתה צריך יותר קיבולת? בעסק רגיל, אתה מגייס אדם. כאן, אתה כותב SOP. זה ההבדל המבני שמאפשר ל"חברה של אחד" לגדול בלי להפוך לחברה של חמישה. כדי "לגייס" פונקציה חדשה (נניח, סוכן מחקר-מתחרים):
זה "hire by SOP" — אונבורדינג של סוכן כמו עובד חדש, אבל בלי משכורת, בלי גיוס, ובלי תקרה של 24 שעות ביממה. ההבדל מגיוס אנושי: עובד חדש לוקח 90 יום להיות productive. סוכן חדש לוקח 90 דקות — כולל כתיבת ה-SOP, ה-dry-run, והחיבור ל-loop. ה-bottleneck היחידה הוא כמה מהר אתה יכול לכתוב SOP טוב, לא כמה מהר אתה יכול לגייס ולאנבורד.
וזה גם מחזיר אותנו לדבר שלא משתנה גם ב-scale: ה-execution-vs-judgment split מפרק 1. ככל שתוסיף תפקידים, מה שנשאר אנושי תמיד זהה — אסטרטגיה, טעם, יחסי לקוח, והחלטות בלתי-הפיכות. הצי גדל; אתה נשאר ה-operator.
על מה שומרים כשהצי גדל: הנחת היסוד שמאפשרת scale היא שהצי לא מחליף אותך — הוא מגדיל אותך. Pieter Levels, שמריץ ~$3M ARR ללא עובדים (נכון ל-2026), לא "ישב על הגדה" — הוא עבד אינטנסיבית על בחירת פרויקטים, תמחור, ואיכות מוצר. מה שה-AI עשה הוא להסיר ממנו 80% מה-execution הרוטיני. Medvi, שדיווחה על $401M מכירות בשנה ראשונה עם מייסד בודד + AI tools, ניהלה ממשקי רגולציה, ספקים, ויחסי לקוח ישירות. ה-scale של "חברה של אחד" בנוי על כך שהסוכנים לוקחים את ה-execution הרוטיני — ואתה ממקד את הזמן האנושי שנחסך על ההחלטות שרק אדם יכול לקבל.
תאר בשתי שורות: מה יהיה התפקיד החמישי שתוסיף לצי שלך — ולאיזה מארבעת דפוסי החיווט הוא ישתייך? (Research? Competitor-watch? Renewal-finance שני? אפשרות חמישית שלא ב-syllabus — מה שמתאים לעסק שלך.) כתוב את זה ב-.context/decisions/next-hire.md. זה לא משימה — זה תרגיל בחשיבה כ-operator: אתה לא מחכה לתקלה שתגרום לגיוס, אתה מתכנן scale מראש.
זו שגרת העבודה הסופית של הקורס. היא מצטברת: כל מה שבנית לאורך 8 הפרקים מתכנס לקצב הפעלה אחד. זו לא רשימת מטלות — זו הדרך שבה אתה מנהל חברה של אחד כ-operator, לא כמכבה-אש.
יומי (10–15 דק' בבוקר):
שבועי (45–60 דק', יום ראשון):
חודשי (60–90 דק'):
לפי הצורך: "גַיֵּס" תפקיד חדש דרך hire-by-SOP. snapshot ל-git לפני כל שינוי מסוכן. pin גרסת OSS לפני שה-upstream משנה API.
אם תיקח דבר אחד מכל הקורס, קח את זה: אתה לא צוואר הבקבוק — אתה ה-operator. ברגע שהפסקת להאכיל סוכנים משימה-אחר-משימה והתחלת לתת להם תפקידים, SOPs, ו-loop שמשתפר בלילה — חדלת להיות פרילנסר שעושה הכל מהר יותר, והפכת למישהו שמפעיל חברה שלמה. הצי מבצע; אתה שומר על האסטרטגיה, הטעם, ויחסי הלקוח. זה כל ההבדל.
לפני שאתה מסתמך על הצי בעסק אמיתי — עם לקוחות אמיתיים וכסף אמיתי — עליך לעבור audit סיכונים סופי. זה לא פסימיות; זו האחריות של operator. שלושה סוגי סיכון, ישירות ממחקר הקורס:
| סוג סיכון | מה לבדוק | הפעולה |
|---|---|---|
| HYPE | האם אתה בונה ציפיות על "one-person unicorn"? | הפרד proof-points מאומתים (Pieter Levels ~$3M ARR/0 עובדים; Medvi $401M שנה ראשונה) מ-forecast (תחזית Amodei ל-$1B היא ~70–80% confidence — לא עובדה) |
| FRESHNESS | star counts של OSS, סטטוס frameworks, מגבלות free-tier, מחירי טוקנים | אמת מחדש: gru-ai (~142 stars, MIT), Orloj (~102 stars, Apache-2.0, pre-1.0); AutoGen ב-maintenance (פיתוח → Microsoft Agent Framework); Langfuse נרכש ע"י ClickHouse ינואר 2026 אך נשאר חינמי ל-self-host |
| LOCK-IN | האם config/memory נעולים ב-vendor? | ודא portability plan: הכל ב-git, נתיב export קיים, מודלים GA בלבד (לא preview) |
כיצד ה-audit מתנהל בפועל: שב 30 דקות, פתח דפדפן, ועבור על הרשימה הזו שורה-שורה. לכל שורה — אמת את הנתון ממקור ראשוני (GitHub repo, אתר מוצר, Carta). אם הנתון השתנה — עדכן את ה-.context/ שלך. אם שינוי מתקרב (API breaking change, framework שעובר למצב maintenance) — הוסף לכל-טבלת-ה-all-hands כ-"freshness flag" שתסקור בחודש הבא.
מחזור ה-audit: עשה audit מלא לפני כל הפעלה ראשונית, ו-audit מקוצר (15 דקות, FRESHNESS בלבד) כל חודש. השאלה המרכזית בכל audit: "האם משהו השתנה שמסוכן ל-runtime שלי?" — לא "האם הכל בסדר?" (כי לרוב הכל בסדר). מה שחיפוש ב-GitHub issues של Orloj, CHANGELOG של framework שאתה תלוי בו, ובדיקת מחירי API אחת לחודש קונה לך הוא שקט נפשי: אתה יודע שהקרקע שתחתיך יציבה — ואם היא זזה, תדע את זה לפני שהלקוח שלך יגלה.
לבנות עסק אמיתי על מוצר pre-1.0 (Orloj מצהיר במפורש שה-APIs עשויים להשתנות) בלי ל-pin גרסה, או על framework קפוא (AutoGen ב-maintenance), או על 'Brain' של vendor בלי נתיב יציאה — זה לבקש שהצי שלך יישבר ברגע שמשהו זז מתחתיו. ה-audit הזה הוא 30 דקות שחוסכות שבוע של תקלות. עשה אותו לפני ההפעלה, וחזור עליו חודשית.
Cross-links סופיים — מה לא לשכפל (וזה מכוון, כדי שהקורס יישאר על שכבת ה-business/org-design):
זו רשימת ה-go/no-go הסופית. אל תפעיל את הצי על לקוחות אמיתיים לפני שכל סעיף מסומן. כל סעיף נשען על פרק שלם — אם משהו לא מסומן, חזור לשם. הרשימה הזו היא לא תיבת סימונים — היא חוזה שאתה כותב לעצמך: מתחת לרמה זו לא תלך לייצור.
שים לב שהרשימה מכוונת לא רק ל-"האם כל הכלים מחוברים?" אלא ל-"האם המערכת בטוחה לפעול ב-production?" — הבדל מהותי. כלים יכולים להיות מחוברים ועדיין לא בטוחים אם חסרים approval gates על כסף, חסרה idempotency, או שה-observability עיוור לרוב הכשלים. production readiness הוא מעגל safety, לא מעגל completeness.
.context/ (פרק 3).הגעת לסוף. לא רק לסוף הפרק — לסוף המסע מ"פרילנסר שעושה הכל" ל"operator שמפעיל חברה". בוא נסגור את שני המעגלים.
מה הפרק הזה עשה:
מה הקורס כולו נתן לך: התחלת (פרק 1) כמי שמשתמש ב-AI לפי הוראה, chat task-by-task, ונשאר צוואר הבקבוק היחיד. אתה מסיים עם 'חברה של אחד' רצה ב-git: org chart כתוב, SOPs מדויקים, loop שמשתפר בלילה, סולם autonomy עם approval gates, observability שרואה הכל, ו-P&L חודשי שמתמחר כל סוכן כמו משכורת. הפכת מ-glue יחיד ל-operator של מערכת.
וזכור את הגבול הכן מפרק 1, שלא השתנה: המודל לא מבטל אותך. מישהו עדיין מנהל את הסוכנים — זה אתה, ב-2 בלילה, כשלקוח מסלים תקלה. אבל עכשיו יש לך מערכת שתופסת את רוב התקלות לפני שהן מגיעות לשם, ו-tripwire שמפנג אותך רק כשבאמת צריך. זו לא הכנסה פסיבית — זו חברה שאתה מנהל כ-operator. וזה, בדיוק, היה כל העניין.
צוות של איש אחד — סיימת. עכשיו לך תפעיל אותו.