Керування завданнями ШІ-агентів: цикл захоплення як контракт, а не промпт

Керування завданнями ШІ-агентів працює, коли цикл тримає дошка, а не промпт: агент питає, що робити, захоплює одне завдання з орендою, яка спливає, якщо він замовк, звертається до людини лише по рішення, які належать їй, і завершує роботу звітом, який можна перевірити. У 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: heartbeat. Кожен виклик з ідентифікатором запуску й токеном оренди продовжує оренду. Якщо агент падає, heartbeat припиняється, і через 20 хвилин запуск позначається як застарілий, а завдання знову стає непризначеним — його може взяти будь-хто. Втрачена оренда відповідає lease_lost, тож агент знає, що робота вже не його.
4. request_input: лише для рішень, які належать людині. Запитання до 500 символів, до 10 варіантів відповіді. Поки агент чекає, захоплення зберігається.
5. complete_task: завершення зі звітом. outcome, artifacts (докази: URL, коміт чи хеш файлу), notDone, unknowns і nextStep.

Чому оренда, а не статус? Бо мовчання — єдиний сигнал, який може подати агент, що впав. Картка в Doing каже, що колись над нею хтось працював. Оренда каже, що хтось працює над нею зараз, і сама перестає це казати, коли це вже неправда.

Саме захоплення — це один запис у базу даних, захищений унікальним індексом. Коли два агенти змагаються, переможця визначає база, тож отримати завдання обидва не можуть. А от два коментарі «Взято», опубліковані з різницею в секунду, — обидва цілком валідні коментарі.

Коли агенту викликати 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"
}

Артефакти — це те, що людина може перевірити, не вірячи агенту на слово. notDone і unknowns — не зізнання; саме вони відрізняють результат, на який можна покластися, від того, який доведеться відновлювати з диффу. Виклик ніколи не падає через брак доказів, бо втратити завершену роботу гірше, ніж записати її неперевіреною. Більше про те, як читати такі звіти, — у статті «що зробив мій ШІ-агент».

Чим це відрізняється від переміщення картки й коментаря?

Посібник Hypertask про той самий цикл (захопити, оновити, звітувати, закрити) добре описує саму звичку. Його MCP-версія захоплення — це завантажити завдання, перенести його в робочий розділ і написати коментар про захоплення, керуючись промптом, який команда прописує в інструкціях агента. Ось той самий цикл крок за кроком:

Справедливості заради: у Hypertask є справжні оренди. Його документація описує ендпоінти для захоплення оренди, heartbeat і звільнення, а таблиця Known limitations каже, що оренди завдань, докази й ескалація навмисно доступні лише як REST-ендпоінти (огляд MCP у Hypertask). У довіднику інструментів серед його 21 MCP-інструмента немає жодного для оренди (довідник інструментів). Його CLI теж уміє захоплювати завдання — як необов’язкова команда (changelog, довідник CLI). Отже, агент-скрипт на Hypertask може тримати оренду; агент, що працює через MCP у Claude Code чи Cursor, отримує версію з карткою й коментарем, якщо хтось не під’єднає REST-виклики.

Якщо твої агенти працюють як скрипти й CI-джоби, CLI і REST API у Hypertask — справжня перевага, а у Weft немає ні того, ні іншого: ні CLI, ні публічного REST API, ні вебхуків. 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-токени, тож клієнт сам поновлює вхід. У 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 важать найбільше, — у статті «кілька ШІ-агентів, одна дошка». Сам протокол задокументовано на modelcontextprotocol.io, а інші MCP-дошки порівняно на сторінці MCP-менеджерів завдань.

Чого Weft тут не робить?

• Немає CLI, публічного REST API чи вебхуків, тож cron-джоби й CI-пайплайни не можуть вести цикл поза MCP-клієнтом.
• Немає інтеграції з GitHub чи Slack. Доказами є те, на що агент посилається в artifacts.
• Немає вбудованого ШІ. Думання відбувається у твоєму власному ШІ-клієнті — і саме тому Weft не потребує ШІ-кредитів.

Безкоштовний тариф — це 50 завдань і 200 ШІ-викликів на місяць. Pro коштує $7 за місце на місяць або $60 за місце на рік (ціни).

Хіба доброго промпту не досить, щоб агенти дотримувалися циклу?

Промпт описує цикл, але не може його забезпечити. Він не завадить двом агентам захопити те саме завдання і не звільнить завдання, яке тримає агент, що впав. У Weft захоплення — це оренда, якою володіє сервер, тож ці випадки обробляються незалежно від того, чи пам’ятав агент свої інструкції.

Що буде, якщо мій агент упаде посеред роботи?

Його heartbeat припиниться. Через двадцять хвилин після останнього 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-інструменти.