ניהול משימות לסוכני AI: לולאת התפיסה כחוזה, לא כפרומפט

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

אנחנו מפתחים את Weft. העובדות על מוצרים אחרים לקוחות מהעמודים הרשמיים שלהם, ונבדקו ב-27 באוקטובר 2026.

למה רשימת משימות שהודבקה לצ׳אט מפסיקה לעבוד?

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

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

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

איך נראית לולאת התפיסה כחוזה?

ב-Weft ללולאה יש חמישה שלבים, וכל אחד מהם הוא כלי נפרד על נקודת קצה MCP אחת, https://letsweft.com/api/mcp. השרת שומר את המצב ביניהם, כך שהלולאה שורדת את סופו של כל צ׳אט.

1. get_my_work: לשאול לפני שבוחרים. התשובה מכסה מה הלקוח הזה כבר מחזיק, מה מחכה לאדם, מה באיחור או קרוב למועד, והאם יש בכלל מקום להתחיל משהו.
2. start_task: לתפוס עם חכירה. התפיסה נמשכת 20 דקות ומעבירה את המשימה ל-Doing. התשובה מכילה runId, ‏leaseToken ו-renewEverySeconds: 300. לקוח שני שמנסה לקחת את אותה משימה מקבל already_claimed ורמז לא לשכפל את העבודה.
3. report_progress: הדופק. כל קריאה עם מזהה הריצה ואסימון החכירה מחדשת את החכירה. אם הסוכן מת, הדופק נעצר, ואחרי 20 דקות הריצה מסומנת כמיושנת והמשימה חוזרת להיות לא משויכת, כך שכל אחד יכול לקחת אותה. חכירה שאבדה עונה lease_lost, כך שהסוכן יודע שהעבודה כבר לא שלו.
4. request_input: רק להחלטות שהן של האדם. שאלה של עד 500 תווים, עם עד 10 אפשרויות. התפיסה נשמרת בזמן שהסוכן מחכה.
5. complete_task: לסיים עם קבלה. outcome, ‏artifacts (ראיות כמו URL, ‏commit או hash של קובץ), ‏notDone, ‏unknowns ו-nextStep.

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

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

מתי הסוכן צריך לקרוא ל-request_input?

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

האיפוק הזה חשוב, כי שאלה עולה לאדם אותו קשב כמו משימה גמורה, וב-Weft היא נספרת באותה מגבלה. השאלה נוחתת ב-Inbox, עם התראת push בנייד, ולפריטים שמחכים 20 דקות או יותר גם תזכורת במייל. Weft אף פעם לא קורא בחזרה לסוכן: התשובה מגיעה ב-start_task או ב-get_my_work הבא שלו. כל עוד השאלה פתוחה, הסוכן מחזיק את המשימה 60 דקות; אחרי זה החכירה נופלת אבל השאלה נשארת.

מה נכנס לקריאה ל-complete_task?

תוצאה קצרה, ראיות ותיאור כן של הקצוות. הנה payload מציאותי לתיקון באג:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

ה-artifacts הם דברים שהאדם יכול לבדוק בלי לסמוך על המילה של הסוכן. ‏notDone ו-unknowns הם לא וידויים; הם מפרידים בין תוצאה שאפשר לסמוך עליה לבין תוצאה שבונים מחדש מה-diff. הקריאה אף פעם לא נכשלת בגלל ראיות חסרות, כי לאבד עבודה גמורה גרוע יותר מלרשום אותה בלי אימות. עוד על קריאת הקבלות האלה במה סוכן ה-AI שלי עשה.

במה זה שונה מהזזת כרטיס ופרסום תגובה?

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

כדי להיות הוגנים כלפי Hypertask: יש לה חכירות אמיתיות. התיעוד שלה מפרט נקודות קצה לתפיסת חכירה, לדופק ולשחרור, וטבלת Known limitations שלה אומרת שחכירות משימה, ראיות והסלמה הן נקודות קצה של REST בלבד, בכוונה (סקירת MCP של Hypertask). במדריך הכלים שלה אין כלי חכירה בין 21 כלי ה-MCP (מדריך הכלים). גם ה-CLI שלה יכול לתפוס, כפקודה אופציונלית (changelog, מדריך CLI). כך שסוכן מבוסס סקריפט ב-Hypertask יכול להחזיק חכירה; סוכן שעובד דרך MCP ב-Claude Code או ב-Cursor מקבל את גרסת הכרטיס-ותגובה, אלא אם מישהו מחבר את קריאות ה-REST.

אם הסוכנים שלכם רצים כסקריפטים ו-jobs של CI, ה-CLI וה-REST API של Hypertask הם יתרון אמיתי, וב-Weft אין אף אחד מהם: אין CLI, אין REST API ציבורי, אין webhooks. ‏Weft מיועד לסוכנים שחיים בתוך לקוח MCP וצריכים שהלולאה תחזיק שם.

מה האדם רואה?

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

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

• Accept: העבודה עומדת. אם הסוכן העביר nextStep, האדם רואה אותו מעל הכפתור (“אם תאשרו, הסוכן …”), והאישור מאשר בדיוק את הצעד הזה, לא יותר. האישור תקף ל-72 שעות וחוזר לסוכן דרך get_my_work או start_task.
• Rework: להחזיר, עם הערה שאומרת מה לא בסדר.
• Later: לא עכשיו. Drop: להפסיק לעבוד על זה.

ה-Inbox נמצא בגרסת הדפדפן, וכשמשהו נכנס אליו האדם מקבל גם התראת push באפליקציית Weft לנייד. לחיצת היד של nextStep מונעת מסוכן להתייחס ל“נראה בסדר” כרשות למזג, לפרוס ולשלוח: הוא רשאי לעשות את הצעד האחד שאושר, ואז להשלים את המשימה שוב.

למה הסוכן מקבל סירוב במקום להתחיל עוד עבודה?

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

Weft סופר מה מחכה לאנשים: משימות שמחכות לבדיקה ועוד שאלות פתוחות. כשזה מגיע ל-5 פריטים בסביבת עבודה של אדם אחד, ל-10 בצוות, או לכ-45 דקות של זמן בדיקה משוער — המוקדם מביניהם — ‏start_task מסרב עם attention_queue_full. המגבלה תלויה במספר האנשים בסביבת העבודה, לא בתוכנית.

הסירוב הוא הוראה, לא מבוי סתום. הוא מדווח את גודל התור, את הגיל של הפריט הוותיק ביותר ואת הקריאות שעדיין מותרות: report_progress, ‏get_my_work, ‏get_board_state ו-search. צעד שהאדם כבר אישר על אותו כרטיס פטור, כך ש-“merge PR #418” שאושר לא נחסם בגלל התור.

איך מגדירים את זה?

חברו את הלקוח שלכם והתחברו דרך הדפדפן; אין מפתח להעתיק. Weft מנפיק refresh tokens, כך שהלקוח מחדש את ההתחברות בעצמו. ב-Claude Code זו פקודה אחת, claude mcp add --transport http weft https://letsweft.com/api/mcp (עמוד הגדרה). ל-Cursor יש התקנה בלחיצה אחת (Cursor), ‏Codex צריך רשומת הגדרה ו-codex mcp login weft (Codex), ול-ChatGPT יש אפליקציית Weft שפורסמה בכל התוכניות כולל Free (ChatGPT). השרת מתאר את הלולאה לסוכן בעצמו, כך שלא צריך פרומפט של מחזור חיים.

להדרכה על Claude Code ראו לוח משימות ל-Claude Code. לכמה סוכנים על לוח אחד, שם חכירות ו-already_claimed חשובים במיוחד, ראו כמה סוכני AI, לוח אחד. הפרוטוקול עצמו מתועד ב-modelcontextprotocol.io, ולוחות MCP אחרים מושווים בעמוד מנהלי משימות עם MCP.

מה Weft לא עושה כאן?

• אין CLI, ‏REST API ציבורי או webhooks, כך ש-cron jobs ו-pipelines של CI לא יכולים להפעיל את הלולאה מחוץ ללקוח MCP.
• אין אינטגרציה עם GitHub או Slack. הראיות הן מה שהסוכן מקשר ב-artifacts.
• אין AI מובנה. החשיבה מתרחשת בלקוח ה-AI שלכם, וזו גם הסיבה ש-Weft לא צריך קרדיטים של AI.

Free כולל 50 משימות ו-200 קריאות AI בחודש. ‏Pro עולה $7 למשתמש לחודש או $60 למשתמש לשנה (תמחור).

פרומפט טוב לא מספיק כדי שסוכנים יעמדו בלולאה?

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

מה קורה אם הסוכן שלי קורס באמצע?

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

כל משימה גמורה מחכה שאבדוק אותה?

לא. כברירת מחדל משימה שהושלמה עוברת ישר ל-Done עם התוצאה והראיות שלה. היא נעצרת ב-Inbox שלכם ל-Accept, ‏Rework, ‏Later או Drop רק כשהמשימה דורשת בדיקה או כשבדיקת אימות נכשלת.

למה שארצה שהסוכן שלי יקבל סירוב לעבודה?

כי אחרת הוא ממשיך לייצר דברים שאין לכם זמן לבדוק. ברגע ש-5 פריטים (10 לצוות) או כ-45 דקות של בדיקה מחכים לאנשים, ‏start_task מחזיר attention_queue_full ומפנה את הסוכן למה שהוא עדיין יכול לעשות. פינוי התור משחרר אותו.

גם ל-Hypertask יש חכירות. למה MCP חשוב?

החכירות של Hypertask הן נקודות קצה של REST, לפי התיעוד שלה עצמה (סקירת MCP), וגם ה-CLI שלה יכול לתפוס. זה מתאים לסוכנים מבוססי סקריפט. סוכן שעובד דרך כלי MCP בעורך או בצ׳אט לא מקבל אותן שם, וב-Weft הוא כן מקבל: start_task, ‏report_progress ו-complete_task הם כלי MCP.