קלוד ב-Asana: מי מאמן את הסוכן, ומי רק עובד איתו

מי זו Asana ולמה דווקא הסיפור הזה

Asana היא פלטפורמת ניהול עבודה מסן פרנסיסקו, שנוסדה ב-2009. הפרסום עליה מ-29 בספטמבר 2026 הוא השלישי בסדרה של אנתרופיק על צוותים משולבים של אנשים וסוכנים, אחרי פוסט הפתיחה והפרק על Slack. הדברים מובאים מפי ה-CPO של החברה, Arnab Bose.

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

איך סוכן הופך לחבר צוות?

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

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

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

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

החלוקה שכדאי להעתיק: לעבוד עם סוכן זה לא לאמן אותו

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

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

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

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

למה העבודה של הסוכן צריכה להיות גלויה?

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

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

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

שלוש משימות שהסוכנים קיבלו

שאלות מוצר מערוץ Slack

כש-Asana משיקה פיצ’רים, אנשי המכירות והצלחת הלקוח שואלים שאלות בערוץ משותף. קודם אותן שאלות חזרו שוב ושוב, והמומחים תויגו בכל פעם מחדש. מאגר ידע לא פתר את זה, כי התשובות עדינות ומשתנות עם המוצר.

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

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

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

תקציר בוקר על חוזים בסיכון

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

	קודם	היום
תדירות	סיכום שבועי	תקציר כל בוקר
מי מרכז	אדם	סוכן בשם At-Risk Renewal
היקף	מה שהספיקו לסכם	כל משימת חידוש בסיכון, כולל עדכונים, הערות ותגובות
מבנה	לא מתואר בפרסום	מומנטום חיובי, מומנטום שלילי והמלצות להמשך; קודם תמונה גלובלית, אחר כך לפי אזור

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

תכנון מחזורי פיתוח עם Command

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

את הלולאה הזאת החברה מנהלת היום ב-Command, מוצר של Asana לצוותי הנדסה גדולים:

• צוות של 10 עד 12 מהנדסים עובד במרחב אחד על מוצר אחד
• סוכנים ממלאים לוח של עבודה לא מתוכננת: כרטיסים ממשוב לקוחות ומתגובות בערוץ המשוב של הצוות ב-Slack
• אנשים מחליטים מה עובר מהלוח למחזור, ו-Command חוזה מתי המחזור יסתיים, בשלוש הערכות: אופטימית, מאוזנת ושמרנית
• כרטיס מוקצה לאדם או לסוכן קוד, ומנהל יכול לשאול בצ’אט למה שחרור מאחר ואילו פשרות יחזירו אותו למסלול

והכול חשוף דרך שרת ה-MCP של Asana, כך שהמנהלים יכולים לשאול את קלוד מה עומד בלוח הזמנים בלי לפתוח את Command בכלל. פרט אחד שכדאי לדעת: לפי דף המוצר של Command, הוא משמש שכבת תזמור גם ל-Cursor וגם ל-GitHub Copilot. סוכן הקוד שמקבל כרטיס הוא לא בהכרח קלוד.

איך מחברים את Asana לקלוד קוד?

שרת ה-MCP הרשמי של Asana עובד בתעבורת HTTP עם אימות OAuth. לפי התיעוד של Asana, קודם יוצרים אפליקציית MCP בחשבון המפתחים שלהם ומקבלים מזהה לקוח וסוד. אחר כך:

claude mcp add --transport http \
  --client-id YOUR_CLIENT_ID \
  --client-secret \
  --callback-port 8080 \
  asana https://mcp.asana.com/v2/mcp

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

ממה כדאי להיזהר כשקוראים את הסיפור

• אין אף מספר: לא זמן שנחסך, לא עלות, לא שיעור שגיאות. זה ראיון עם מנהל המוצר הראשי של Asana, על המוצר של Asana, בבלוג של אנתרופיק. הוא שווה קריאה בגלל המבנה שהוא מתאר, לא בגלל תוצאות
• שאלת המודל: הפרסום מדבר על העבודה הסוכנית בתוך Asana. לגבי המוצר, ה-CTO של Asana אמר בהשקת Claude Managed Agents באפריל 2026 שהכלי האיץ את הפיתוח של AI Teammates. אבל דף המוצר עצמו מדבר על “שותפי ה-AI שלנו” בלי לנקוב בשם, ו-Command מתזמר גם כלים של חברות אחרות. מי שבוחנים את המוצר צריכים לשאול את Asana איזה מודל ירוץ אצלם
• תחימת ההרשאות היא הצהרה: הכלל שלפיו סוכן מוגבל להרשאות של מי שהפעיל אותו מתואר כ”Asana says” גם בפרסום עצמו. לא ראינו בדיקה חיצונית שלו

מה לוקח מכאן צוות ישראלי

אין צורך ב-Asana כדי ליישם את שלושת העקרונות האלה. הם עוברים כמו שהם לצוות שעובד עם קלוד קוד:

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

שורה תחתונה

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

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