להרכיב צי אמיתי: gru-ai, Orloj והחברים — Templates, Observability ו-Governance

החלטהבחירת stackשלוש הדרכים להרכיב צי — ואיזו מתאימה לך

בפרק 2 הכרת את ההבחנה ברמה התיאורטית: framework מול OS מול minimal stack. עכשיו צריך להחליט באמת, כי אתה עומד להרכיב. ההחלטה לא נקבעת לפי מה שמגניב — היא נקבעת לפי רמת הנוחות ההנדסית שלך ולפי כמה governance ה-use-case שלך באמת דורש. operator עסקי שמוכר ייעוץ לא צריך את אותה תשתית כמו מי שמריץ פעולות כסף אוטומטיות מול חשבונות לקוחות.

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

שים/י לב לעמודה האחרונה. "חינם" כאן הוא חינם ברישיון בלבד — gru-ai, Orloj ו-Hermes כולם פתוחים וללא תשלום על הקוד, אבל מתחתם רץ מודל ששולח חשבון טוקנים. צי always-on יכול להשתוות בעלותו למשכורת (חזרה ל-P&L של פרק 6). אל תבלבל "free OSS" עם "free to run".

הנה דוגמה מספרית שממחישה את הפער: נניח שהצי שלך כולל 4 סוכנים שרצים כל אחד 20 פעמים ביום, צורך בממוצע 4,000 טוקנים לריצה (input+output), על מודל שעולה ₪0.06 לאלף טוקנים. חישוב מהיר: 4 × 20 × 4,000 × 0.06/1,000 = ₪19.2 ליום, כלומר ~₪576 לחודש — בלי קריאות eval, בלי retries, בלי טריוויה אנושית. זו עלות חודשית שצריך להפחית ב-routing policy של פרק 6 (לשלוח חלק מהקריאות למודל זול יותר), ולכן ההחלטה "איזה stack" מתחילה בשאלה "כמה governance ה-use-case דורש" — לא "כמה זמן ההרכבה לוקחת".

תפקידים: 4
נוגע בכסף: כן (Finance renewal agent בלבד)
נוחות YAML: 3
החלטה: Orloj (governance production נדרש על חיובי לקוחות)

תבניתgru-aigru-ai מקרוב: צוות 11 סוכנים על Claude Code

gru-ai (הריפו andrew-yangy/gru-ai) הוא תבנית קוד-פתוח ברישיון MIT שמתארת את עצמה כ-"autonomous AI agent team for one-man companies" — צוות סוכנים אוטונומי לחברות של איש אחד. נכון לתאריך המחקר (יוני 2026) הוא ~142 כוכבים ב-GitHub, כתוב ב-TypeScript (~78%), ובפיתוח פעיל. הוא הופך את Claude Code ל"צוות" של 11 סוכנים.

הרעיון המרכזי שמתאים לקורס הזה: directive בודד זורם דרך pipeline בן 15 צעדים. אתה כותב הנחיה אחת (למשל "תוסיף dark mode"), והיא עוברת תחנות שמדמות חברה אמיתית:

שתי תכונות הופכות את gru-ai לרלוונטי במיוחד לכל מה שבנינו עד כה:

• זיכרון .context/ version-controlled. כל ה-state חי כ-Markdown + JSON רגיל בשורש הריפו, תחת git. זה בדיוק ה-pattern שאימצנו בפרק 3 לאחסון SOPs — gru-ai הוא ההמחשה החיה שלו ברמת תבנית שלמה. ה"חברה" שלך נהיית forkable ו-diff-able.
• לכידת lessons אוטומטית בשלב ship. ה-pipeline שומר "lessons learned ו-design rationale" כך ש"ההנחיה ה-10 רצה טוב יותר מהראשונה". זה היישום המעשי של ה-reflexion מפרק 4 — אבל אַל תבטח בו עיוורות: לקח שגוי שנשמר מרעיל ריצות עתידיות (חזרה לאזהרה מפרק 4).

דוגמה מעשית ל-directive שזורם ב-pipeline: נניח שאתה מנהל סטודיו קטן לעיצוב ואתה רוצה להוסיף דף תמחור חדש לאתר. אתה כותב directive אחד: "צור/י דף תמחור עם 3 חבילות, מחירים בש"ח, וקריאת CTA לוואטסאפ." ב-pipeline של gru-ai, סוכן triage בודק אם הבקשה ברורה; אם לא — סוכני C-suite (PM, Designer, Engineer) מתווכחים איזו חבילות הגיוניות. סוכן COO מפצל למשימות: copy לחבילות, עיצוב, הטמעה. סוכן engineering בונה branch; סוכן fresh-context עובר על ה-PR בעיניים נקיות; ship+lessons קולט את ההחלטות שקיבלת ("חבילה בסיסית ₪990, מקצועית ₪2,490, ארגונית ₪4,990") ושומר אותן ל-.context/lessons/ כדי שה-directive הבא לדף "שאלות נפוצות" יידע מה הקול המותגי שלך. בלי gru-ai, היית עושה את כל זה ידנית או עם פרומפטים בודדים; איתו — יש תהליך עקבי שחוזר על עצמו ומשתפר.

roles
sops
lessons
governance.md

תבניתOrlojOrloj מקרוב: agents כ-infrastructure-as-code

אם gru-ai הוא "צוות מוכן", Orloj (הריפו OrlojHQ/orloj) הוא הקצה השני: agent infrastructure-as-code — תשתית-סוכנים-כקוד. במקום לכתוב לוגיקה, אתה מצהיר על Agents, Tools ו-Policies כ-YAML, ו-Orloj מתזמן, מריץ, מנתב ומסדיר אותם ל-production. הוא ברישיון Apache-2.0, כתוב ב-Go (~80%), ~102 כוכבים נכון ליוני 2026, ובפיתוח פעיל (pre-1.0).

הרעיון שמבדל אותו: הוא מתייחס לסוכנים כתשתית. versioned manifests, runtime bounds, credentials, observability — הכל בערימת config אחת מוצהרת. ערימה אחת מכסה agents, tools, models, memory, schedules, webhooks, approvals, policies, workers, traces, metrics ו-deployment.

ה-resources שמגיעים מובנים ב-Orloj הם בדיוק המושגים שבנינו בפרקים 4–5 — אבל כאן הם native, לא משהו שאתה מרכיב ידנית:

הנה דוגמה מצומצמת למניפסט Orloj (YAML) עבור סוכן finance-renewal אחד — זה ה-config שמחליף את ה-Skill + ה-approval gate הידני מפרק 5:

apiVersion: orloj/v1alpha1
kind: AgentPolicy
metadata:
  name: finance-renewal
spec:
  allowedModels: ["claude-haiku-4-5", "claude-sonnet-4-5"]
  blockedTools: ["send_email", "refund_customer", "delete_account"]
  tokenBudgetPerRun: 15000
  tokenBudgetPerDay: 200000
  childDepth: 0
  approvals:
    - kind: TaskApproval
      threshold: 100     # ש"ח
      approver: owner
    - kind: ToolApproval
      tool: charge_customer
      threshold: 100
      approver: owner

המניפסט הזה הופך את הכללים מפרק 5 לקוד שאכיף אותם: סוכן finance-renewal לא יכול לקרוא ל-Opus (לא ב-allowedModels), לא יכול למחוק חשבון (חסום), ולא יכול לחייב יותר מ-₪100 בלי אישור. אלה לא הנחיות למודל — זה ה-runtime שעוצר את הקריאה לפני שהיא יוצאת.

הדבר החזק ביותר ב-Orloj הוא ש-ה-governance מוערכת ב-runtime, ונכשלת-סגור (fail-closed). נחזור לזה בסעיף ה-governance — אבל בקצרה: אם הסוכן מנסה לקרוא למודל שלא ברשימת ה-allowed, להשתמש בכלי חסום, או לחרוג מ-token budget, Orloj עוצר אותו, לא מתעלם. זה ההבדל בין "כתבתי בהנחיה שאסור" (המודל אולי יציית) לבין אכיפה אמיתית בתשתית.

הרכבהחיבור החלקיםלחבר את החלקים: מ-org chart ל-SOPs ל-loop חי

בחרת stack. עכשיו מחברים את כל מה שבנית בפרקים 2–6 לתוכו. זה הרגע שבו תיאוריה הופכת לצי שרץ. הסדר חשוב — חבר/י שכבה אחר שכבה, ואל תנסה/י להפעיל הכל בבת אחת:

שים/י לב מה קרה כאן: פתרת את בעיית נקודת-האינטגרציה מפרק 1. במקום כלים מפוזרים שאתה ה-glue היחיד ביניהם, יש לך שכבה אחת — ה-stack — שבה כל סוכן יודע מי בעליו, מה ה-scope שלו, ומה ה-loop שלו. הצי פועל כמערכת אחת.

עוד דוגמה לעומק: נניח שבחרת minimal stack, והתפקיד הראשון הוא "support-triage". תיקיית .context/roles/support-triage.md מכילה role+goal+scope; קובץ .context/sops/support-triage.md מכיל את ה-SOP עם RFC 2119 ("MUST לסווג לאחת מארבע קטגוריות", "SHOULD להציע מאמר מה-base אם confidence > 0.7", "MUST להעביר לאנוש אם category = billing"). סקריפט support-triage.py בתיקיית bin/ טוען את שני הקבצים, קורא ל-API, מחזיר JSON עם category+confidence+reply. cron מפעיל אותו כל 5 דקות על תור נכנס. ה-tracing עוטף את קריאת ה-API. כל אלה קבצים ב-git. כל שינוי — diff. כל רגרסיה — revert.

[09:00:01] cron tick: support-triage started
[09:00:01] loaded SOP .context/sops/support-triage.md (v1.2)
[09:00:02] loaded role .context/roles/support-triage.md
[09:00:03] found 7 tickets in queue
[09:00:04] idempotency: 2 already processed, 5 new
[09:00:08] processed 5 tickets → 4 self-served, 1 escalated to human (billing)
[09:00:08] trace: langfuse span id=abc123 tokens=2,340 cost=₪0.14
[09:00:08] done

תצפיתObservabilityObservability: מצלמת האבטחה על הצי

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

למה זה קריטי דווקא לסוכנים? כי רוב התקלות בסוכנים אינן שגיאות מודל — הן שלוש בעיות אחרות שכלי ניטור רגיל (APM — application performance monitoring, ניטור ביצועי אפליקציה) פשוט לא רואה:

מה ש-trace טוב מראה לך: node-by-node state (מצב בכל צעד), פירוק model + tool-call (לאיזה מודל פנה, איזה כלי קרא), retries (כמה פעמים ניסה), ו-loops (אם נתקע). זו ממש מצלמת אבטחה על כל החברה — אתה רואה כל סוכן בכל רגע.

דוגמה מספרית למה זה חיוני: נניח שהרצת סוכן support-triage בלילה. סוכן support נתקל בלקוח שמתלונן על "חיוב כפול", מחפש ב-DB, לא מוצא, מנסה שוב, מחפש ב-API, לא מוצא, מנסה שוב, ובמשך 47 דקות שורף 1.2M טוקנים (~$72) בלי להגיע לפתרון — ואז קורס ב-OOM. בלי trace, אתה רואה רק "ההרצה נכשלה, ₪72 נשרפו". עם trace, אתה רואה: 14 ניסיונות חיפוש חוזרים, אותו prompt, אותה תשובה "no results", לולאה ברורה. התיקון: להוסיף max-retries=3 לסוכן הזה, או להעבירו לאנוש אחרי 3 ניסיונות כושלים. בלי trace — אתה לא יודע מה ה-pattern, ולכן לא יודע איך לתקן.

שלושת הכלים המאומתים — ומתי כל אחד

נכון ל-2026, אלה שלושת השחקנים. כולם תומכים ב-tracing של סוכנים; ההבדל הוא ברישוי, ב-eval, ובאקוסיסטם:

ל-operator עסקי ישראלי שמתחיל, Langfuse OSS הוא לרוב הבחירה הנכונה: $0 infra, אתה מחזיק את הנתונים בעצמך (חשוב ל-portability — נגיע לזה), ואין lock-in. אם ה-eval gate הוא מרכז הכובד שלך — Braintrust. אם בנית על LangGraph — LangSmith.

ממשלGovernanceGovernance שנאכפת ב-runtime: שוטר התנועה של הצי

observability מראה לך מה קרה. governance קובעת מה מותר לקרות — ואוכפת את זה. ההבדל הקריטי: governance אמיתית נאכפת ב-runtime, לא בהנחיה. אם כתבת בהנחיה "אסור לך להוציא יותר מ-₪100", המודל אולי יציית — ואולי יחליט שזה case מיוחד. governance ב-runtime עוצרת אותו פיזית.

המודל שמובנה ב-Orloj הוא הדוגמה הנקייה ל-fail-closed: ברירת המחדל היא "אסור", והפעולה מתבצעת רק אם היא עברה את הבדיקה. אם הבדיקה נכשלת או לא ברורה — הפעולה נחסמת, לא עוברת. ארבעת הסוגים שכדאי לאכוף:

ויש בונוס קריטי: audit trail כברירת מחדל. כשה-governance רצה ב-runtime, כל פעולה — מה הסוכן ניסה, מה אושר, מה נחסם — נרשמת אוטומטית. זה compliance מובנה. ל-operator ישראלי שמטפל ברשומות לקוח או בחיובים, audit trail אינו מותרות — הוא מה שמאפשר לך לענות על "מי אישר את זה ומתי" בלי לשחזר מהזיכרון.

הנה תרחיש מעשי: סוכן finance-renewal מזהה לקוח שחיוב החידוש שלו עומד על ₪180, אבל הוא "זוכר" (מ-context) שבעבר ניתנה לו הנחה של 30% בגלל תקלה. הסוכן מציע לחייב רק ₪126. ה-token budget שלו: 15,000 לריצה. ה-allowed models שלו: רק haiku (מה-routing policy). ה-blocked tools שלו: refund_customer, delete_account, send_email. ה-approval gate שלו: כל חיוב מעל ₪100 דורש אישור בעלים. ברגע שהסוכן מנסה לבצע את החיוב — ה-runtime חוסם אותו (מעל הסף), רושם audit: charge 126 blocked, requires approval, ושולח הודעה לבעלים. אחרי אישור (או דחייה) — החיוב מתבצע או מתבטל, וה-audit נשמר. בלי governance — הסוכן היה חיוב באופן עצמאי, וההנחה הייתה רק "מה שהוא זוכר" (כלומר מה שהמודל המציא).

## SDR (lead-screener)
- allowed_models: claude-haiku-4-5
- blocked_tools: send_email_paid, charge_customer
- token_budget_per_day: 80,000
- approval: outbound to VIP tag → owner review

## Support Triage
- allowed_models: claude-haiku-4-5, claude-sonnet-4-5
- blocked_tools: refund_customer, delete_account
- token_budget_per_day: 150,000
- approval: category=billing → human queue

## Finance Renewal
- allowed_models: claude-haiku-4-5
- blocked_tools: refund_customer, delete_account, change_permissions
- token_budget_per_run: 15,000
- token_budget_per_day: 200,000
- approval: any charge >₪100 → owner (named: yair@studio.co.il)

החלטה עסקיתbuild-vs-buybuild-vs-buy ו-portability plan: לא להיתקע עם ספק

הגענו להחלטה העסקית הסופית של הפרק. build-vs-buy: לבנות (template OSS שאתה הבעלים שלו, משלם רק טוקנים) או לקנות (commercial OS כמו Knowlee — מהיר יותר, אבל lock-in). אין תשובה אחת נכונה — יש תשובה נכונה לך, ויש דרך לקבל אותה במספרים ולא בתחושה.

הנה המספר שמכריע: קח/י את ה-agent payroll dashboard מפרק 6. אם עלות הטוקנים החודשית של הצי + הערך של הזמן שלך להרכבה נמוכים ממנוי ה-OS המסחרי — build. אם ה-OS חוסך לך כל-כך הרבה זמן שהוא משתלם למרות ה-lock-in, ויש לו נתיב export — buy יכול להיות נכון. זו החלטת P&L, לא החלטת "מה מגניב".

חישוב מעשי לדוגמה: נניח שהצי שלך עולה ₪2,400/חודש בטוקנים (מתוך ה-payroll dashboard). אתה מעריך שהרכבה על gru-ai/Orloj תיקח לך 30 שעות עבודה. שווי השעה שלך כ-operator: ₪300. עלות ההרכבה: 30 × 300 = ₪9,000 (חד-פעמי). מנוי commercial OS דומה: ₪1,500/חודש. הנקודה שבה build משתלם: 9,000 / 1,500 = 6 חודשים. אם אתה מתכנן להפעיל את הצי לפחות חצי שנה — build משתלם. אם זה ניסוי לחודש-חודשיים — עדיף לשלם על commercial ולא להשקיע. אבל אל תשכח את ה-lock-in: גם אם ה-OS זול יותר, אם אין לו נתיב export — אתה קונה את עצמך לכלא.

ה-portability plan: הביטוח נגד lock-in

לא משנה מה תבחר/י, כתוב/כתבי portability plan לפני שאתה תלוי. הסכנה: ה-"Brain" / knowledge-graph וה-audit trail של פלטפורמת "AI workforce" (Knowlee-class) חיים ב-OS שלהם. ביום שתרצה לעבור — או שהמחיר יקפוץ, או שהספק ייסגר — הנתונים נעולים. portability plan הוא ארבעה סעיפים:

• config ב-git: כל ה-org chart, ה-SOPs וה-policies כ-Markdown/YAML version-controlled (ה-.context/ pattern). זה לבדו עושה את החברה forkable ו-recoverable.
• memory ב-git: ה-lessons וה-state — לא נעולים ב-DB של ספק, אלא כקבצים שאתה מחזיק.
• נתיב export: לפני שאתה מאמץ כלי מסחרי, ודא/י איך מוציאים ממנו את הנתונים (API export? CSV? בכלל?). אם אין נתיב — זו דגל אדום.
• snapshot/restore: כל config + memory ב-version control, כך ש"עריכת SOP גרועה במרחק git revert אחד". snapshot לפני כל שינוי מסוכן.

# Build vs Buy — Fleet Decision
**תאריך:** 2026-06-05
**תוקף עד:** 2026-09-05 (לבדיקה מחדש אחרי רבעון)

## מספרים
- (1) עלות טוקנים חודשית: ₪2,400
- (2) עלות הרכבה: 30 שעות × ₪300 = ₪9,000 (חד-פעמי)
- (3) מנוי commercial OS (Knowlee-class): ₪1,500/חודש

## נקודת איזון
- payback period: 9,000 / 1,500 = 6 חודשים
- תוכנית הפעלה: 12+ חודשים → build משתלם

## החלטה
**BUILD** (gru-ai + Langfuse + minimal stack לתפקידי תפעול).
נימוק: payback תוך 6 חודשים, אין lock-in, הקוד שלנו.

## Portability plan
1. **config ב-git:** `.context/` (roles, sops, lessons, governance) — כבר commit-ed.
2. **memory ב-git:** `lessons/` מתעדכן בכל ריצה; nightly snapshot.
3. **נתיב export:** N/A (אנחנו לא ב-OS מסחרי; אם נחליט לעבור — export = git clone).
4. **snapshot/restore:** `git tag fleet-v0`, `fleet-v1`, וכו'; revert במקרה של רגרסיה.

## תנאי סקירה מחדש
אם עלות הטוקנים תעבור ₪5,000/חודש — לבחון buy מחדש.

a3f9b21 (HEAD -> main) fleet v0: org chart + SOPs + loop + governance

שגרההרכבה ותחזוקהשגרת ההרכבה והתחזוקה של הצי

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

תרגולשלושה תרגיליםשלושת התרגילים — כל אחד מפיק תוצר נראה

# gru-ai (clone + env)
git clone https://github.com/andrew-yangy/gru-ai.git ~/fleet/gru-ai
cd ~/fleet/gru-ai
echo 'ANTHROPIC_API_KEY=sk-ant-...' > .env
# Orloj (binary + manifest dir)
git clone https://github.com/OrlojHQ/orloj.git ~/fleet/orloj
cd ~/fleet/orloj
git checkout v0.7.2   # pin גרסה (pre-1.0)
echo 'ORLOJ_CONFIG=~/fleet/orloj/manifests' >> ~/.bashrc

# langfuse/docker-compose.yml — מובא כמו ב-docs הרשמיים
git clone https://github.com/langfuse/langfuse.git
cd langfuse
cp .env.example .env   # ערוך NEXTAUTH_SECRET + DATABASE_URL
docker compose up -d   # UI על http://localhost:3000
# צור API key: Settings → Projects → New Key → שמור את
#   LANGFUSE_PUBLIC_KEY / LANGFUSE_SECRET_KEY ל-.env של הסוכן

☀️ בוקר טוב, 5 ביוני 2026

📊 אתמול בעסק:
• הכנסות: ₪3,420 (2 חיובי חידוש + 1 חדש)
• לידים חדשים: 8 (3 חמים, 5 קרים)
• תור תמיכה: 4 פתוחים (1 דחוף — billing)

🎯 היום:
• 3 לידים חמים למעקב אישי
• מאמר חדש לפרסום ב-09:30

📰 מתחרים:
• Studio-X השיקו חבילה חדשה ב-₪1,990
• Studio-Y פרסמו קייס סטאדי חדש

09:15:01  load_sop           0.02s    1,200 tokens    OK
09:15:02  load_role          0.01s    600 tokens      OK
09:15:03  llm_call_1         1.8s     2,400 tokens    OK
09:15:05  tool: fetch_orders  0.4s     -              ERROR (401 unauthorized)
09:15:05  llm_call_2_retry   1.5s     1,800 tokens    OK (סוכן מנסה שוב)
09:15:07  tool: fetch_orders  0.3s     -              ERROR (401)
09:15:07  llm_call_3_retry   1.6s     1,800 tokens    OK
09:15:09  tool: fetch_orders  0.3s     -              ERROR (401)
09:15:09  fallback_to_human  0.1s     200 tokens      OK
[summary] total_tokens: 8,000 | cost: ₪0.48 | status: escalated_to_human

     A                    | B (₪/חודש) | C (₪ חד-פעמי) | D (הערות)
1    עלות טוקנים צי       | 2,400       | -              | מתוך agent payroll פרק 6
2    הרכבה (שעות × שווי)  | -           | 9,000          | 30 שעות × ₪300
3    מנוי commercial OS   | 1,500       | -              | Knowlee-class (אם שקלת)
4    payback (חודשים)     | =C2/B3      | -              | נקודת איזון: 6.0