צוות שעובד לבד — חיווט הכל ל-Production, והחלטת In-Process מול Hosted

הארכיטקטורה של הצוות שעובד לבד — חיווט שבע השכבות

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

בואו נמפה את הצוות שעובד לבד כפי שהוא נראה כשהכל מחובר. המשימה שתלווה אותנו לאורך הפרק היא lead-enrichment pipeline — דוגמה אמיתית שמופיעה ב-course.research.json תחת creative_uses: ניטור כוכבי GitHub על ריפו open-source (למשל aden-hive/hive), העשרת ה-lead דרך Apollo, ניסוח טיוטת outreach מותאמת, ועצירה ל-human-approval דרך policy gate לפני שליחת מייל.

שימו לב לדבר אחד: ה-supervisor הוא harness שמעל harnesses. כל subagent הוא בעצמו לולאת agent מלאה עם ה-context, ה-tools וה-gates שלו. זה בדיוק מקור הכוח (בידוד, parallelism) וגם מקור הסכנה (כל subagent הוא session נפרד ששורף tokens — נחזור לזה ב-cost section).

למה דווקא lead-enrichment ולא משימה אחרת? כי הוא נוגע בכל נקודת כאב שהקורס פתר. הוא ארוך — מספיק turns כדי שה-context יתקרב ל-cliff (פרק 3). הוא מקבילי — שלושה תפקידים שונים שאפשר לפצל ל-subagents (פרק 6). הוא מסוכן — שולח מיילים לאנשים אמיתיים, מה שמחייב human-approval gate (פרק 4). והוא חוזר על עצמו — אותם סוגי leads, אותן שגיאות, מה שהופך אותו למקרה מבחן מושלם ל-memory ו-Dreaming (פרק 7). אם ה-harness שלך מריץ את ה-pipeline הזה נקי, הוא יריץ כמעט כל משימת אוטומציה עסקית.

חשוב להבין מה לא משתנה כשעוברים מ-demo ל-production. ב-demo כל שכבה רצה לבד ואתה צופה בה. ב-production אף אחד לא צופה — הצוות רץ בלילה, מול leads אמיתיים, מול חשבון tokens אמיתי. לכן כל החלטת חיווט נמדדת בשאלה אחת: "מה קורה כשזה נכשל ב-3 בבוקר ואני ישן?". אם התשובה היא "ה-pipeline נעצר בשקט, רושם failure, ומחכה לי" — זה production. אם התשובה היא "הוא שולח 50 מיילים שגויים" — זה demo מסוכן שמתחזה ל-production.

חמשת התפקידים של ה-subagent — לא רק "monitor, enricher, writer"

בפרק 6 דיברנו על supervisor שמפצל subagents, אבל בצוות שעובד לבד יש חמישה תפקידים ארכיטקטוניים שכל subagent יכול למלא, ולכל תפקיד יש השלכות שונות על context, budget ו-recovery:

ב-pipeline הבסיסי שלנו נשתמש ב-workers, ובסוף נראה איך להוסיף auditor לפני שליחת המייל — שימו לב איך זה מוסיף עוד רמה של בטיחות מעל ה-human-approval gate.

העיקרון המארגן: data flow, לא code flow

הטעות הקלאסית באינטגרציה היא לחשוב על "באיזה סדר לקרוא לפונקציות". זה code flow, והוא מטעה. החשיבה הנכונה היא data flow: איזה אובייקט state עובר בין השכבות, ומי בעלים שלו בכל רגע. ב-harness שלנו יש אובייקט מרכזי אחד — נקרא לו RunState — שמחזיק את ה-goal, את ה-messages, את ה-token accounting, את ה-trace_id ואת ה-reference ל-memory store. כל שכבה מקבלת אותו, נוגעת רק בחלק שלה, ומעבירה הלאה.

למה זה כל כך משנה? כי בלי RunState מרכזי, כל שכבה מתחילה לשמור עותק משלה של מה שהיא צריכה — וזה הרגע שבו ה-context מתנפח והאינטגרציה מתפרקת. שכבת ה-recovery (פרק 5) צריכה לדעת כמה turns כבר היו; שכבת ה-context (פרק 3) צריכה לדעת כמה tokens נצרכו; שכבת ה-cost צריכה את שניהם. אם כל אחת מודדת בנפרד, יש לך שלוש מדידות שלא מסכימות זו עם זו, ובאג שאי אפשר לדבג. עם RunState אחד, יש מקור אמת יחיד, וכל שכבה קוראת ממנו וכותבת אליו את החלק שלה בלבד.

# RunState — האובייקט שעובר בין כל השכבות (דוגמה מייצגת)
from dataclasses import dataclass, field

@dataclass
class RunState:
    goal: str
    messages: list = field(default_factory=list)   # פרק 2: message state
    tokens_used: int = 0                            # פרק 3: token accounting
    context_pct: float = 0.0                        # פרק 3: 83.5% threshold
    trace_id: str = ""                              # פרק 5: Langfuse span
    tool_call_log: list = field(default_factory=list)  # פרק 5: loop detection
    memory_ref: object = None                       # פרק 7: memory store
    budget_tokens: int = 200_000                    # פרק 6: subagent cap

ברגע שיש לך RunState אחד שעובר בכל מקום, האינטגרציה הופכת ממנגנון מבלבל למשהו שאפשר לקרוא: כל שכבה היא פונקציה layer(state) -> state. זה גם מה שיהפוך את ההחלטה in-process מול hosted לפשוטה בהמשך — כי ה-state הזה הוא בדיוק מה ש-Anthropic מנהלת בשבילך ב-hosted.

Anti-Patterns — ארבע דרכים נפוצות להרוס צוות שעובד לבד

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

חיווט הקוד — מ-supervisor ועד memory, מקצה לקצה

עכשיו נחווט בפועל. אני אראה את ה-supervisor loop — הלב של הצוות — כשהוא מפעיל את כל השכבות. שימו לב איך כל קריאה מצביעה חזרה לפרק שבנה אותה; זה לא קוד חדש, זו תזמורת של מה שכבר יש לך.

# supervisor.py — הצוות שעובד לבד, מחווט. (דוגמה מייצגת)
from claude_agent_sdk import query           # פרק 2: ה-SDK
from harness.context import backup_if_near_threshold  # פרק 3
from harness.gates import policy_gate         # פרק 4
from harness.trace import span                # פרק 5
from harness.recovery import circuit_breaker  # פרק 5
from harness.memory import recall, remember   # פרק 7

SUBAGENTS = ["monitor", "enricher", "writer"]

async def run_team(goal: str, state: RunState):
    with span("supervisor", state.trace_id):
        # פרק 7: קוראים patterns רלוונטיים מהזיכרון — לא את כל ה-store!
        learned = recall(state.memory_ref, task=goal, top_k=3)
        plan = await plan_subtasks(goal, learned, state)

        results = []
        for name in SUBAGENTS:
            subtask = plan[name]
            # פרק 6: כל subagent עם budget cap משלו
            sub_state = handoff(state, focus=subtask, budget=60_000)
            try:
                out = await run_subagent(name, sub_state)   # session נפרד
            except CircuitBreakerTripped as e:              # פרק 5
                remember(state.memory_ref, failure=e.record)  # פרק 7
                out = await fallback(name, sub_state)
            results.append(out)

        return await synthesize(results, state)

ועכשיו ה-subagent עצמו — לולאת agent מלאה מהפרקים 2–5, מקופלת לפונקציה אחת:

async def run_subagent(name: str, state: RunState):
    breaker = circuit_breaker(max_repeats=3)   # פרק 5
    for turn in range(20):                      # פרק 2: max-turns
        backup_if_near_threshold(state, at=0.75)  # פרק 3: לפני 83.5%
        resp = await call_model(state)
        for call in resp.tool_calls:
            breaker.check(call)                 # פרק 5: loop detection
            decision = policy_gate(call)        # פרק 4: gate דטרמיניסטי
            if decision == "require_human":
                await pause_for_approval(call)  # human-in-the-loop
            elif decision == "deny":
                continue
            result = await run_tool(call)       # פרק 4: structured output
            state.messages.append(tool_result(call, result))
        if resp.is_final:
            return resp.output
    raise MaxTurnsReached(name)

שימו לב לשלושה דברים שהפכו את זה ל-production ולא ל-demo:

1. כל subagent מגודר פעמיים: max-turns מבחוץ (פרק 2) ו-budget cap מבפנים (פרק 6). אם monitor בורח, הוא לא לוקח את כל ה-budget של הצוות.
2. כשל לא מפיל את הצוות: circuit_breaker תופס לולאה, רושם failure ל-memory, ועובר ל-fallback — ה-pipeline ממשיך.
3. ה-gate הוא דטרמיניסטי: send_email תמיד עוצר באדם, גם אם המודל "החליט" שהוא בטוח. ה-prompt לא יכול לעקוף את זה.

שימו לב גם למה ש-לא נמצא בקוד: אין try/except אחד ענק שעוטף את כל הריצה ו"מקווה לטוב". כל כשל נתפס במקום הספציפי שלו, עם השכבה שאחראית עליו. circuit-breaker תופס לולאות; policy gate תופס פעולות מסוכנות; max-turns תופס ריצות שלא נגמרות. זה ההבדל בין harness ש"יודע למה הוא נכשל" לבין סקריפט ש"קרס ולא יודע למה". כל בלם הוא ספציפי, וכל בלם מצביע על שכבה.

ה-handoff — הנקודה שהכי קל לפשל בה

הפונקציה handoff(state, focus=subtask, budget=60_000) נראית תמימה, אבל היא הנקודה הכי רגישה בכל החיווט. מה היא עושה? היא מעבירה ל-subagent רק את ה-context הממוקד למשימה שלו — לא את כל ההיסטוריה של ה-supervisor. הטעות הנפוצה (ונחזור אליה ב-warning) היא להעביר לכל subagent "ליתר ביטחון" את כל ההיסטוריה. התוצאה: כל subagent מתחיל עם context מנופח, מאיץ compaction (פרק 3), ושורף tokens מיותרים — והכל מוכפל ב-3 subagents. handoff נכון הוא distillation: מהי המשימה, מה ה-leads הרלוונטיים, ומה ה-constraints — ותו לא.

יש שלושה דפוסי handoff שכדאי להכיר:

מחזור החיים של ריצה (Run Lifecycle) — חמש הפאזות

כל ריצה של צוות שעובד לבד עוברת חמש פאזות, ולכל פאזה יש מאפיינים שמשפיעים על החיווט. הבנה של הפאזות עוזרת לדבג בעיות ("האם זה ב-pre-flight או ב-descent?") ולהחליט איפה לשים observability נוסף.

source .venv/bin/activate
export ANTHROPIC_API_KEY=sk-ant-...
export LANGFUSE_PUBLIC_KEY=pk-lf-...
export LANGFUSE_SECRET_KEY=sk-lf-...
make harness-up   # או: python -m harness.cli up

// fixtures/stargazers.json — קלט דטרמיניסטי ל-monitor
{
  "repo": "aden-hive/hive",
  "since": "2026-06-19T00:00:00Z",
  "stargazers": [
    {"login": "jane-doe",     "starred_at": "2026-06-20T14:02:11Z"},
    {"login": "acme-eng",     "starred_at": "2026-06-20T15:31:48Z"},
    {"login": "noa-lev",      "starred_at": "2026-06-20T18:09:05Z"}
  ]
}

// fixtures/apollo_mock.json — קלט דטרמיניסטי ל-enricher
{
  "jane-doe": {"name":"Jane Doe","company":"Acme","title":"Staff Eng"},
  "acme-eng": {"name":"Acme Eng","company":"Acme","title":"DevRel"},
  "noa-lev":  {"name":"Noa Lev", "company":"LevLabs","title":"Founder"}
}

ההחלטה הגדולה: In-Process מול Hosted

זו ההחלטה שחזרה לאורך כל הקורס, ועכשיו, כשיש לך harness שלם, אפשר סוף-סוף להכריע בה במספרים. השאלה: האם להריץ את הצוות in-process — אתה מחזיק את הלולאה, ה-sandbox וה-scaling (Claude Agent SDK) — או hosted, כש-Anthropic מנהלת את כל זה (Claude Managed Agents)?

הסיבה שדחינו את ההחלטה הזו עד הפרק האחרון היא לא במקרה. אי אפשר להחליט נכון לפני שבנית את ה-harness, כי לפני שבנית אתה לא יודע כמה שליטה אתה באמת צריך. מי שמתחיל פרויקט בשאלה "in-process או hosted?" מחליט בעיוורון. מי ששואל אותה אחרי שבנה loop מותאם, context strategy, policy gates ו-observability — יודע בדיוק מה הוא ישים על הכף. זו הסיבה שזו השאלה האחרונה בקורס, לא הראשונה.

מה זה Claude Managed Agents (CMA)

לפי course.research.json: CMA הוא REST API serverless מנוהל לחלוטין, שבו Anthropic מנהלת את agent loop, את ה-execution harness, את ה-sandboxing המאובטח ואת ה-session persistence. הוא יצא ל-public beta ב-8 באפריל 2026 ודורש header managed-agents-2026-04-01. המחיר הוא API-only, ופרטי ה-pricing וה-sandboxing עשויים להשתנות (זה beta — נחזור לזה ב-risk audit).

יש כאן ניואנס שחובה לא לפספס: ההחלטה אינה בינארית ולא נצחית. אפשר להתחיל in-process כדי לפתח ולדבג עם שליטה מלאה (ה-tracing המותאם שלך עוזר דווקא בשלב הזה), ואז — כשהמשימה התייצבה וה-governance שלה פשוט — לשקול מעבר ל-CMA כדי להוריד עומס תחזוקת sandbox ו-scaling. גם ההפך לגיטימי: להתחיל ב-CMA כדי לעלות לאוויר מהר, ואם מגלים שצריך governance מותאם שה-beta לא חושף — להחזיר את הלולאה הביתה. המטריצה היא כלי שמריצים מחדש בכל נקודת החלטה, לא חותמת שמטביעים פעם אחת.

להעביר harness ל-CMA — מה מרוויחים, מה מאבדים

נניח שמילאת את המטריצה והיא הצביעה על hosted (תרחיש לגיטימי: צוות קטן, scaling יקר לתחזק, governance פשוט). בוא נראה איך זה נראה בפועל. ההעברה ל-CMA היא לא rewrite — היא שינוי של מי מחזיק את הלולאה.

# הרצה via CMA — Anthropic מחזיקה את הלולאה. (דוגמה מייצגת)
import anthropic
client = anthropic.Anthropic()

run = client.beta.managed_agents.create(
    extra_headers={"anthropic-beta": "managed-agents-2026-04-01"},  # נדרש
    agent={
        "system": SUPERVISOR_PROMPT,      # ה-harness config שלך (פרק 2)
        "tools": TOOLS_SCHEMA,            # ה-schemas מפרק 4 — נשמרים!
        "max_turns": 20,                  # פרק 2 — נשמר
    },
    input={"goal": "enrich new stargazers of aden-hive/hive"},
)
# Anthropic מנהלת: loop, sandbox, session persistence, scaling

הקוד נראה קצר וזה לא במקרה — זה כל הרעיון של hosted. במקום לכתוב את ה-supervisor loop, את ה-subagent loop, את ה-context management ואת ה-recovery, אתה מתאר את הסוכן (system, tools, max-turns) ו-Anthropic מריצה את הכל. כל מה שהשקעת בו 200 שורות ב-in-process מצטמק לאובייקט config. זה היתרון — וזו בדיוק הסכנה: הצמצום הזה מסתיר את כל ההחלטות שקיבלת, ואתה כבר לא שולט בהן.

שימו לב מה עבר בקלות ומה נשאר מאחור:

שכבת ה-Abstraction — איך לעטוף features ב-preview

ההמלצה החוזרת בקורס היא "לעטוף כל feature ב-preview ב-abstraction דקה". הנה דוגמה מעשית למה זה אומר — עבור ה-V2 Session API שהוא unstable_v2_*:

# session_wrapper.py — abstraction מעל V2 Session API
# הקוד שלך משתמש רק ב-SessionManager, לא ב-unstable_v2 ישירות.
from claude_agent_sdk import unstable_v2  # import שעלול להשתנות

class SessionManager:
    """abstraction יציב. הקוד שלך לא מכיר את unstable_v2_*."""

    def __init__(self):
        self.client = unstable_v2.Client()

    def create(self, goal: str) -> str:
        # חתימה נוכחית; אם ה-API ישתנה — משנים רק פה
        return self.client.createSession(goal=goal).id

    def resume(self, session_id: str) -> Session:
        return self.client.resumeSession(id=session_id)

    def fork(self, session_id: str) -> Session:
        return self.client.forkSession(id=session_id)

    def list_active(self) -> list[Session]:
        return self.client.listSessions()

למה זה קריטי? כי כש-Anthropic תשנה את ה-API (והיא תשנה — זה unstable), אתה משנה רק את SessionManager. שאר הקוד ב-harness שלך ממשיך לעבוד. בלי ה-wrapper, היית צריך לעבור 30 קבצים ולתקן כל קריאה.

Playbook להעברה — חמשת הצעדים

הנה רצף מומלץ להעברה בפועל, בלי קפיצות:

מעבר ה-Billing של 15 ביוני 2026 — והעלות האמיתית

זה החלק הכי time-sensitive בכל הקורס, והוא רלוונטי בדיוק עכשיו. לפי course.research.json, ב-15 ביוני 2026 תוכניות ה-subscription של Claude עברו ל-Agent SDK credit חודשי ייעודי שמפריד בין שימוש אינטראקטיבי לאוטומטי. המשמעות הקריטית לצוות שעובד לבד: ריצות אוטומטיות על subscription auth יחטפו rate limits פתאומיים — אלא אם תעבור ל-API key auth.

למה ההפרדה הזו קיימת בכלל? כי עד עכשיו אדם יחיד שמשתמש ב-Claude אינטראקטיבית, וצוות סוכנים שרץ אוטומטית 24/7, נמשכו מאותו דלי. סוכן אוטומטי יכול לשרוף בלילה אחד את מה שאדם שורף בחודש — וזה עיוות שה-billing החדש מתקן בכך שהוא נותן לאוטומציה דלי נפרד (Agent SDK credit) או דורש ממנה auth נפרד (API key). מבחינתך, מהנדס ה-harness, המסקנה פשוטה וחד-משמעית: אם הצוות רץ בלי שאתה יושב מולו, הוא חייב auth שמיועד לאוטומציה.

Cost Cascade — מודל זרימת ה-tokens בצוות

הצוות שעובד לבד שורף tokens ביותר מקומות ממה שנראה. הנה המודל המלא של Cost Cascade — איך tokens זורמים דרך הצוות, ואיפה כדאי לחתוך:

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

שלוש תובנות שחייבים להפנים:

1. ה-subagents הם 75% מהעלות. כל subagent הוא session שלם נפרד (פרק 6) — זה ה-"Parallel Subagent Cost Explosion" מ-course.research.json. בלי budget caps, המספר הזה מתפוצץ אקספוננציאלית.
2. Dreaming הוא לא חלק מ-cost-per-run — והוא מסוכן יותר. curation על עד 100 transcripts שורף מיליוני tokens (פרק 7). אם תתזמן אותו אחרי כל ריצה, החשבון יתפוצץ בשקט ברקע. תזמן אותו בתדירות מרוסנת.
3. Tool results זולגים בחזרה ל-context. כל קריאת tool שמחזירה 10K tokens של JSON — התוצר נכנס להיסטוריה של ה-subagent, ומשם ל-supervisor, ומשם לסינתזה. reference handoff (דפוס 2 למעלה) חותך את זה בחדות.

למה האומדן הזה כל כך קל לפספס? כי האינטואיציה אומרת "ריצה אחת = פנייה אחת למודל". אבל ב-multi-agent זה לא נכון: ריצה אחת היא ארבע sessions לפחות (supervisor + 3 subagents), כל אחת עם ה-history המצטבר שלה. וה-history מצטבר בכל turn — אז subagent שעושה 15 turns שולח את כל ה-context שלו 15 פעמים, לא פעם אחת. זו הסיבה שהמספר נראה קטן בראש ("רק 3 subagents") אבל גדול בחשבון. הכלל: אל תאמוד tokens בראש. מדוד אותם ב-Langfuse (פרק 5), כי ה-token attribution לכל span הוא בדיוק מה שהופך את האומדן מניחוש למספר.

ויש כאן גם זווית מעשית של ROI: ה-budget caps וה-circuit-breakers שבנית לא רק מגינים מ-cost explosion — הם חוסכים כסף שנמדד. circuit-breaker שעוצר לולאה אחרי 3 קריאות חוזרות, במקום לתת לה לרוץ עד max-turns של 20, חוסך 17 קריאות מיותרות בכל פעם. כפול מספר הריצות בחודש, זה הופך מ"feature נחמד" ל"שורה בתקציב".

Agent SDK Credit מול API Key Auth — ההחלטה הבאה

אחרי 15.6.2026 יש שתי אפשרויות לאוטומציה:

ההחלטה: עבור צוות שעובד לבד עם עומס יציב, Agent SDK credit יכול להיות זול יותר. עבור עומסים משתנים או spikes, API key auth גמיש יותר. הרבה משתמשים מתחילים ב-API key auth כדי לאמוד עלויות אמיתיות, ואז עוברים ל-credit כשה-baseline יציב.

Production Readiness — Checklist ו-Freshness/Beta Risk Audit

לפני שמשחררים צוות שעובד לבד, צריך לעבור שני שערים: production readiness checklist (האם כל הבלמים מחוברים?) ו-freshness/beta risk audit (מה מבוסס על preview/beta שעלול להישבר?). זה החלק שמבדיל בין "עובד אצלי" לבין "מוכן ל-production".

מה GA מול מה Preview/Beta — מפת הסיכונים

לפי course.research.json ו-course.syllabus.json, חלק מהרכיבים שבנינו עליהם בקורס יציבים, וחלק עדיין מתפתחים. אסור לבנות production קשיח על מה שלא GA:

# Production Audit — <team-name>
תאריך: ____   חתימה: ____

## A. Production Readiness (18 בדיקות, ✅/❌ + הערה)
- [ ] API key auth (לא subscription)
- [ ] max-turns לכל subagent
- [ ] budget cap לכל subagent
- [ ] circuit_breaker (סף 3+)
- [ ] structured JSON לכל tool
- [ ] retry דטרמיניסטי על schema violation
- [ ] policy gates דטרמיניסטיים
- [ ] human-approval לפני פעולה בלתי-הפיכה
- [ ] threshold-backup ב-75%
- [ ] tool results גדולים = reference, לא context
- [ ] Langfuse tracing פעיל
- [ ] failure capture → memory
- [ ] Dreaming מרוסן (תדירות + scope)
- [ ] parallel calls + caching
- [ ] abstraction + fallback ל-preview/beta
- [ ] distilled handoff
- [ ] RunState יחיד
- [ ] cost-per-run ידוע

## B. Freshness / Beta Risk
| Feature | סטטוס | Abstraction | Fallback |
|---|---|---|---|
| V2 Session API | preview | SessionManager | single-query |
| Dreaming | research preview | DreamingClient | סיכום failures ל-prompt |
| CMA | public beta | HostedRunner | SDK מקומי |

## C. החלטה: GO / NO-GO
נימוק: ____
חוסם (אם NO-GO): ____

Work Routine — שגרת העבודה המצטברת של הקורס כולו

זו שגרת העבודה המצטברת — היא מסכמת את ההרגלים מכל הקורס לכדי routine אחד שמלווה כל harness שתבנה מעכשיו. אל תתייחס אליה כ"רשימה לסיום הקורס"; זו הדיסציפלינה שמבדילה בין vibe coder שמריץ demos לבין מהנדס harness שמשחרר production.