איך לבנות צוות סוכני AI שעובד כמו מערכת אחת

מצ’אט עם AI למערכת שמנהלת עבודה

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

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

בפגישת עבודה עם איתמר מלול בנינו ארכיטקטורה כזאת סביב עסק אמיתי: חמישה סוכנים עצמאיים, חדר בקרה משותף, מאגר ידע ארגוני, חיבור לכלי העבודה ובקרת איכות באמצעות Claude Code ו־Codex.

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

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

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

מפת הדרך: מה בונים ובאיזה סדר

הסדר חשוב. אם מחברים כלים לפני שמגדירים תפקידים, מקבלים סוכנים עם יותר מדי הרשאות ופחות מדי אחריות. אם מתזמנים לפני שבודקים ידנית, הופכים טעויות חד־פעמיות לטעויות אוטומטיות.

1. בוחרים תהליך עסקי אחד עם ערך ברור.
2. מפרקים אותו לתפקידים ולמסירות ביניים.
3. יוצרים חוזה עבודה לכל סוכן.
4. מחברים ידע וכלים בהרשאה מינימלית.
5. בונים ערוצים וחוקי העברת עבודה.
6. מוסיפים ביקורת ואישור אנושי.
7. מריצים ידנית, מודדים ורק אז מתזמנים.

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

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

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

1. מודל — מנוע החשיבה, למשל Claude, Codex או מודל שפה אחר.
2. מעטפת (Harness) — ההוראות, קובצי הזיכרון, הסקילים, ההרשאות ולולאות העבודה שעוטפים את המודל. ההגדרה השימושית של איתמר הייתה: כל מה שקובע איך המודל עובד. מודל חלש יותר בתוך מעטפת טובה יכול לעקוף מודל חזק יותר בתוך מערכת מבולגנת.
3. סוכן — מודל בתוך מעטפת, עם תפקיד, סביבת עבודה, כלים, זיכרון וגבולות.
4. אורקסטרטור — שכבת הבקרה שמנתבת משימות, שומרת הקשר משותף, מנהלת תורים וכשלים ומתאמת בין הסוכנים.

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

הארכיטקטורה שבנינו

יצרנו חמישה מומחים עצמאיים, כל אחד בסביבת עבודה משלו:

• סטודיו התוכן — לומד את סגנונות הכתיבה והסקילים שלי ומכין טיוטות מותאמות לכל פלטפורמה.
• סוכן החשבוניות — מאתר חשבוניות במייל, מחלץ נתונים, בונה טבלה מסודרת ומעביר אותה אליי לאישור לפני שמשהו נשלח לרואה החשבון.
• בונה סוכני WhatsApp — מומחה Green API שיודע לבנות סוכני שירות, מכירה, גבייה והתראות. הוא אינו נציג השירות עצמו; תפקידו לבנות ולתחזק סוכנים כאלה.
• מפעיל הפגישות — קורא תמלולים מ־Spinach, מכין סיכומים ומשימות ומנסח טיוטות המשך.
• מפעיל הלידים — מזהה לידים פוטנציאליים בערוצים שאושרו ומכין עדכונים ל־CRM.

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

לאחר מכן פתחנו ערוץ עבודה משותף, בדומה לחדר קטן ב־Slack. בערוץ התוכן, למשל, סטודיו התוכן יוצר טיוטה ו־Claude Code ו־Codex בודקים אותה באופן עצמאי.

אתם
  ↓
המנהל המרכזי
  ├── סטודיו התוכן ──→ ביקורת Claude Code ──┐
  │                         ביקורת Codex ────┤→ אישור אנושי
  ├── סוכן החשבוניות                         │
  ├── בונה סוכני WhatsApp                    │
  ├── מפעיל הפגישות                          │
  └── מפעיל הלידים                           │
            ↑                                │
       כלים ומאגר ידע משותף ─────────────────┘

שלב 1: ממפים אחריות לפני שיוצרים סוכנים

אל תתחילו משמות או מאווטארים. התחילו מהעבודה עצמה.

בחרו תהליך שעומד בארבעה תנאים:

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

צרו קובץ בשם agent-map.md ותנו לסוכן הפיתוח את הפרומפט הבא:

אני רוצה לתכנן צוות קטן של סוכני AI לעסק שלי.

לפני שאתה מציע מבנה, ראיין אותי על:
1. התוצאות החוזרות שאני צריך בכל שבוע
2. המקום שבו נמצא מידע המקור
3. אילו פעולות הן לקריאה בלבד ואילו משנות משהו בעולם
4. אילו משימות דורשות מומחיות, הקשר או גבול הרשאות נפרד
5. אילו החלטות חייבות להישאר בידי אדם

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

שמור את התוצאה ב-agent-map.md. אל תיצור עדיין סוכנים.

עברו על המפה. אחדו תפקידים שמשתמשים באותו הקשר ובאותן הרשאות. פצלו תפקיד כאשר סוכן יחיד יקבל יותר מדי כלים או מטרות סותרות.

איך נראית הגדרה טובה: לכל סוכן יש תוצאה שאפשר לבדוק. “סוכן שיווק” הוא תפקיד עמום. “להפוך תובנה אחת מפגישה מאושרת לשלוש טיוטות מותאמות לפלטפורמה ולשמור אותן ב־Google Docs” הוא תפקיד מדיד.

Checkpoint: אל תמשיכו עד שלכל תפקיד יש פלט מוחשי, מקור מידע, לקוח פנימי ונקודת סיום.

שלב 2: יוצרים סביבת עבודה וחוזה תפקיד לכל סוכן

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

צור את הסוכנים העצמאיים שמתוארים ב-agent-map.md.

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

חוזה תפקיד קצר יכול להיראות כך:

# מפעיל הפגישות

## משימה
להפוך תמלולי פגישות מאושרים לסיכום מדויק, משימות וטיוטת המשך.

## מקורות
- תמלולי Spinach
- נתוני המשתתפים מהיומן
- הקשר על הלקוח מה-CRM

## פלטים
- סיכום עם קישור למקור
- משימות עם בעלים ותאריך יעד
- טיוטת מייל המשך

## גבולות
- לעולם לא לשלוח מייל ללא אישור
- לא להמציא התחייבות שלא נאמרה
- לסמן בבירור ייחוס דובר שאינו ודאי

## בדיקת הצלחה
לכל משימה יש קישור לפגישה ובעלים, או שהיא מסומנת כלא משויכת.

חוזה טוב מונע שלוש בעיות: כפילות בין סוכנים, אלתור מחוץ לתחום והעברת פלט שאף אחד לא יודע מה לעשות איתו. הוסיפו לכל חוזה גם פורמט פלט קבוע. לדוגמה, מפעיל הפגישות תמיד מחזיר summary, רשימת decisions, רשימת action_items ושדה open_questions.

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

שלב 3: מחברים יכולות, לא מפזרים מפתחות

הערך בקובץ החיבורים שלנו לא היה מפתחות הסוד, אלא מפת הניתוב: איזה שירות מטפל באיזו משימה ואיך ניגשים אליו. צרו קובץ בטוח בשם tool-registry.md:

| יכולת | ספק | דרך גישה | סוכנים | מצב | אישור |
|---|---|---|---|---|---|
| ידע מ-GitHub | Composio | חשבון מחובר | תוכן, מנהל | קריאה | לא |
| יומן | Composio | חשבון מחובר | פגישות, מנהל | קריאה | לא |
| דוא"ל | Composio | חשבון מחובר | חשבוניות, פגישות | טיוטה | שליחה באישור |
| WhatsApp | Green API | API ישיר | WhatsApp, לידים | קריאה/טיוטה | שליחה באישור |
| רשתות חברתיות | ספק מאושר | API ישיר | תוכן | טיוטה | פרסום באישור |
| תמלולי פגישות | Spinach | חיבור/API | פגישות | קריאה | לא |

לאחר מכן הנחו את המנהל:

קרא את tool-registry.md והקצה יכולות לפי עקרון ההרשאה המינימלית.
תן לכל סוכן רק את הכלים שנדרשים בחוזה התפקיד שלו.
כל כלי שמסוגל לכתוב יתחיל במצב טיוטה או dry-run.
לפני קריאת API ישירה, הבא את התיעוד הרשמי העדכני לפי הצורך.
לעולם אל תציג, תעתיק או תשמור ערכי סוד בלוגים או בזיכרון.
החזר מטריצת הרשאות והריץ בדיקות קריאה בלבד.

MCP או API ישיר?

בשיחה איתמר העדיף לעיתים API ישיר בגלל איכות הקריאה והשליטה, לא משום שכל חיבור MCP אינו בטוח. הכלל המעשי מדויק יותר:

• השתמשו במחבר בשל כאשר הוא מספק אימות אמין, סכמות ברורות ואת הפעולה הנדרשת.
• עברו ל־API ישיר כשנדרש endpoint שאינו חשוף במחבר, שליטה מדויקת ב־payload, טיפול צפוי בשגיאות או תכונה חדשה של הספק.
• בשני המקרים בודקים scopes, קוראים תיעוד עדכני, שומרים לוג ללא סודות ודורשים אישור לפעולה בלתי הפיכה.

אמצעי התקשורת עם הכלי אינו מודל האבטחה. ההרשאות ונקודות האישור הן מודל האבטחה.

שלוש רמות פעולה שכדאי להגדיר

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

התחילו תמיד בקריאה. עברו לטיוטה לאחר כמה הרצות מוצלחות. ביצוע אוטונומי מגיע אחרון ורק בפעולות צרות, הפיכות וצפויות.

שלב 4: בונים חדר בקרה

רוצים לבנות את חדר הבקרה והסוכנים תוך כדי קריאת המדריך? פתחו חשבון ב־ClawBud עם הקישור של יובל והתחילו מהערוץ הכללי.

צרו ערוץ כללי עם המנהל וכל המומחים, ולצדו ערוצים ממוקדים לתהליכים שדורשים הקשר משלהם:

• #general-operations — המנהל וכל המומחים
• #content-studio — המנהל, סטודיו התוכן ושני מבקרים
• #meeting-follow-up — המנהל, מפעיל הפגישות ומפעיל הלידים
• #finance-review — המנהל וסוכן החשבוניות, עם אישור אנושי חובה

שלחו לערוץ הכללי הודעת אתחול:

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

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

חוזה המסירה בין סוכנים

הגדירו גם איך סוכן מוסר עבודה לסוכן הבא. כל מסירה צריכה לכלול:

1. מה הייתה המשימה המקורית.
2. אילו מקורות נבדקו.
3. מה הופק ומה עדיין חסר.
4. רמת הביטחון והנחות שנעשו.
5. מה בדיוק נדרש מהסוכן הבא.

כך המנהל המרכזי לא צריך לנחש מה קרה, וסוכן שמקבל משימה אינו מתחיל מאפס.

שלב 5: מחברים את המוח הארגוני

כללי הכתיבה שלי כבר היו ב־Obsidian Wiki שמסתנכרן ל־GitHub. במקום להסביר מחדש את הקול שלי בכל פרומפט, ביקשנו מהמנהל למצוא את הריפו הנכון, לחלץ את כללי הכתיבה והסקילים הרלוונטיים וללמד את סטודיו התוכן.

באמצעות חיבור GitHub המאושר, אתר את מאגר הידע העסקי שלי.
אל תנחש לפי שם הריפו בלבד; בדוק את ה-README ואת האינדקס.

מצא רק את החומרים הדרושים לסטודיו התוכן:
- כללי קול וסגנון
- תבניות נפרדות לכל פלטפורמה
- דוגמאות מוצלחות
- סקילים ליצירת תוכן ולייצוא ל-Google Docs
- טענות ועובדות שדורשות אימות

צור רשימת מקורות עם נתיבי הקבצים ו-SHA של ה-commit.
למד את סטודיו התוכן בלי להעתיק מידע פרטי שאינו קשור למשימה.
הרץ בדיקת שליפה: בקש ממנו להסביר שלושה הבדלים בין סגנון הכתיבה שלי
בלינקדאין, בפייסבוק ובוואטסאפ, עם הפניה לנתיבי המקור.

רשימת המקורות מונעת מהמשפט “למדתי את הסגנון שלך” להפוך להצהרה שאי אפשר לבדוק. היא גם מאפשרת לרענן את הידע כאשר הריפו משתנה.

אל תכניסו את כל החברה לפרומפט אחד

ידע ארגוני טוב בנוי בשכבות:

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

הפרדה כזאת משפרת דיוק, מפחיתה עלות ומקטינה את הסיכוי שמידע לא רלוונטי יזלוג לפלט.

שלב 6: מוסיפים מבקרים עצמאיים

בערוץ התוכן שלנו סטודיו התוכן היה היוצר, ו־Claude Code ו־Codex היו המבקרים. זה מועיל רק כאשר למבקרים יש מחוון מפורש. “תן ציון” מייצר הצגה; צ’קליסט מייצר ראיות.

צרו content-review-rubric.md:

תן לכל סעיף ציון 0-5 וציין את המשפט המדויק שבדקת:
1. הפתיח מושך תשומת לב בלי לייצר מתח מזויף
2. הטענה נתמכת במקור או מוצגת בבירור כדעה
3. הקול מתאים לפלטפורמה
4. דוגמה קונקרטית מחליפה עצה כללית
5. המבנה קל לסריקה
6. הקריאה לפעולה מתאימה לכוונת הקורא
7. אין מידע פרטי או טענה לא מבוססת

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

כעת הגדירו את הלולאה:

סטודיו התוכן יוצר טיוטה ראשונה ממקורות מאושרים.
Claude Code בודק ביסוס עובדתי ומבנה לפי המחוון.
Codex בודק בהירות, התאמה לקול ומקרי כשל לפי אותו מחוון.
סטודיו התוכן מבצע סבב תיקון אחד על בסיס שני הדוחות.
אם אחד המבקרים מצא כשל חוסם, עצור והעבר אליי.
אחרת הצג טיוטה סופית ואת שני דוחות הציונים לאישור.
לעולם אל תפרסם אוטומטית.

הסכמה בין שני מודלים אינה הוכחה. מה שהופך את הביקורת לשימושית הוא ראיות עצמאיות ומחוון עם תנאי פסילה.

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

שלב 7: מריצים תהליך אמיתי אחד

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

אל תתזמנו אותו מיד. הריצו אותו ידנית תחילה:

הרץ תצוגה מקדימה ידנית של תהליך התוכן היומי עבור אתמול.

1. מפעיל הפגישות מציג את הפגישות שיש לי הרשאה לקרוא.
2. הוא מחלץ תובנות אפשריות עם קישור למקור וחותמת זמן.
3. המנהל מבקש ממני לבחור תובנה אחת.
4. סטודיו התוכן יוצר טיוטה אחת ל-X לפי מקורות הסגנון המאושרים.
5. Claude Code ו-Codex בודקים אותה לפי המחוון.
6. סטודיו התוכן מבצע תיקון אחד.
7. החזר את הטיוטה ואת דוחות הבדיקה. אל תפרסם.

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

רק לאחר שלוש הרצות ידניות נקיות כדאי לתזמן. התחילו במצב טיוטה בלבד. אוטומציה היא השלב האחרון, לא הראשון.

שלב 8: מודדים אם האורקסטרציה באמת משתלמת

מערכת מרובת סוכנים נראית מרשימה גם כשהיא אינה יעילה. לכן משווים אותה לגרסת בסיס של אדם או סוכן יחיד.

מדדו לפחות חמישה דברים:

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

דוגמה ליעד טוב לגרסה ראשונה:

תוך 30 יום המערכת תפיק 20 טיוטות תוכן מבוססות-מקור.
לפחות 80% מהן יעברו את המחוון ללא כשל חוסם.
זמן העריכה האנושי הממוצע יהיה מתחת ל-10 דקות לטיוטה.
שום תוכן לא יתפרסם ללא אישור.

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

תכנית יישום ל־90 דקות

אם אתם רוצים להתחיל היום, אל תנסו לבנות את כל חמשת הסוכנים בבת אחת:

0–20 דקות: מגדירים תוצאה

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

20–45 דקות: יוצרים מנהל ומומחה אחד

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

45–70 דקות: מריצים תרחיש אמיתי

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

70–90 דקות: מוסיפים ביקורת

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

פתחו ClawBud עם קוד ההפניה של יובל, התחילו ממנהל ומומחה אחד, והרחיבו את הצוות רק אחרי שהתהליך הראשון עובד מקצה לקצה.

צ’קליסט לפני Production

לפני שנותנים לצוות סוכנים לגעת בלקוחות או בכסף, ודאו:

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

המערכת שהתקבלה

בסיום אין לנו רק קבוצת צ’אט מלאה בבוטים. יש לנו:

• מומחים עם אחריות תחומה
• סביבות עבודה נפרדות וחוזי תפקיד קבועים
• מנהל שמנתב עבודה במקום להשתלט עליה
• מפת כלים המבוססת על הרשאה מינימלית
• ערוצים משותפים לשיתוף פעולה
• לולאות ביקורת עצמאיות עם תנאי פסילה
• אישור אנושי לפני פעולות חיצוניות
• מעבר מסודר מהרצה ידנית לתזמון
• מדדים שמוכיחים שהמערכת מוסיפה ערך

זוהי אורקסטרציה: לא “סוכנים שמדברים עם סוכנים”, אלא מערכת שבה האחריות, ההקשר, הכלים, המצב, הראיות וההתנהגות במקרה של כשל תוכננו בכוונה.

ממשיכים לבנות יחד

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

אני משתף בקהילת Future Proof Agents מדריכים, דוגמאות ותהליכים שעובדים בעבודה אמיתית. הצטרפו לקבוצת הוואטסאפ ובואו עם התהליך הראשון שאתם רוצים להפוך למערכת סוכנים.

מקור מקרה הבוחן: פגישת העבודה של יובל קשטכר ואיתמר מלול, 11 באוגוסט 2026. ממשקים ומגבלות מוצר משתנים; לפני יישום יש לבדוק את התיעוד העדכני.