Що зробив мій ШІ-агент? Чотири запитання, на які треба відповідати з доказами

Щоб дізнатися, що зробив твій ШІ-агент, не починай з його підсумку. Перевір чотири речі: яке підключення виконало роботу, що змінилося (і це підтверджено чимось, що ти можеш відкрити сам), що лишилося незробленим і що було вирішено й чому. Якщо хоч одна з чотирьох тримається лише на слові агента, у тебе розповідь, а не запис.

Weft робимо ми. Факти про інші продукти взято з їхніх офіційних сторінок, перевірено 27 жовтня 2026 року.

Чому коментаря «готово» недостатньо?

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

Стаття Hypertask про атрибуцію роботи ШІ слушно зауважує: робота агентів має потрапляти на ту саму дошку, що й робота людей, а не в лог термінала, який ніхто не читає. Hypertask також дає агентам власну ідентичність як сервісним акаунтам, тож записи приписуються агенту, а не тобі, і в ньому є докази й оренди завдань, хоча його документація каже, що це навмисно лише REST-ендпоінти, а не MCP-інструменти. Розходимося ми в тому, що має містити запис. Тред коментарів із виводом агента — це лог того, що агент сказав. Ми хочемо, щоб запис містив докази.

У цьому посібнику немає цифр з опитувань. Ти можеш перевірити чотири запитання на власній дошці вже сьогодні, і це скаже тобі більше, ніж середнє по галузі.

Які це чотири запитання?

Візьми будь-яке завдання, яке агент завершив минулого тижня. Ти маєш відповісти на кожне з цих запитань менш ніж за хвилину, не питаючи агента і не відкриваючи його чат:

1. Хто це зробив? Який клієнт і через яке підключення захопив і завершив завдання.
2. Що змінилося? Результат плюс артефакти, які можна перевірити, не довіряючи агенту: хеш коміту, URL, файл, ідентифікатор повідомлення.
3. Що не зроблено? Частини, які він пропустив, і речі, в яких не був певен.
4. Що вирішено і чому? Будь-який вибір, зроблений по дорозі, зі зваженими варіантами, і кожен раз, коли ти повертав роботу.

Як дізнатися, який агент це зробив?

Weft підключається до ШІ-клієнтів через Model Context Protocol на одному ендпоінті — https://letsweft.com/api/mcp. Кожен OAuth-клієнт і кожен персональний токен доступу — окремий виконавець. Завдання записує, який клієнт його створив, а дошка показує ім’я, з яким цей клієнт зареєструвався під час входу, плюс іконку. Кожна подія в журналі завдання зберігає, чи прийшла вона від людини чи через MCP і який клієнт її надіслав.

Повний журнал (get_task_history у режимі full) показує сирий ідентифікатор клієнта для кожної події: OAuth client id або mcp-token, за яким іде ідентифікатор токена. Це не зручне ім’я, зате точне, і воно розрізняє два підключення, навіть якщо вони з того самого продукту.

Володіння під час роботи теж явне. Агент викликає start_task, який захоплює завдання з 20-хвилинною орендою і переносить його в Doing. report_progress продовжує оренду. Другий агент, який спробує взяти те саме завдання, отримає already_claimed, а оренда, що спливла, звільняє завдання для когось іншого. Посібник про цикл захоплення розбирає це крок за кроком, а стаття про кількох агентів на одній дошці — випадок із кількома клієнтами.

Одне практичне правило: дай кожному інструменту власне підключення. Якщо два клієнти ділять один токен доступу, дошка бачить одного виконавця, і питання «хто» лишається без відповіді.

Що змінилося і чи можна це перевірити, не питаючи агента?

Коли агент закінчує, він викликає complete_task. Обов’язковий лише ідентифікатор завдання; усе інше необов’язкове, і виклик ніколи не падає через брак доказів. Це свідомо: втратити завершену роботу гірше, ніж записати її неперевіреною. Що може містити звіт:

• outcome: до 1 000 символів про те, що зроблено і де лежить результат.
• artifacts: до 20 записів, кожен із типом (url, file, message, commit тощо), розташуванням і, за бажанням, дайджестом sha256.
• claims: що агент стверджує, ніби зробив, — зберігається як твердження, а не перевірені факти.
• notDone і unknowns: про них — у наступному розділі.
• nextStep: що агент зробить далі, якщо ти приймеш роботу.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

Рядок outcome — це все ще розповідь. Артефакти — частина, яку можна перевірити. Хеш коміту або є у твоєму репозиторії, або ні. URL або відкривається, або ні. sha256 файлу або збігається, або ні. Якщо у звіті є outcome і немає артефактів, вважай це роботою зі слів агента, бо саме нею вона і є. У вебі картки в Done показують, чи завдання Verified, чи Agent-reported.

Чого агент не зробив?

Це запитання, яке більшість записів пропускає, і саме воно кусає через два тижні. Для нього в complete_task є два списки, кожен до 20 записів по 500 символів: notDone — для того, що агент свідомо пропустив, і unknowns — для того, в чому він не впевнений. Власний опис інструмента просить агентів прямо казати, чого вони не зробили. Саме це відрізняє результат, на який можна покластися, від того, який доведеться відновлювати самому.

Читай ці списки першими. «Не запускав тести на staging-базі» змінює те, що ти робитимеш далі. Звіт без жодного пункту notDone для великого завдання сам по собі вартий запитання.

Що вирішено і чому?

Рішення, ухвалені в чаті, зникають, щойно чат прокручується. record_decision зберігає їх двома способами:

• Окремий запис рішення: назва, результат, контекст, варіанти, які справді зважували, наслідки й умова, за якої варто переглянути рішення. Записи незмінні; щоб змінити рішення, записують нове, яке його замінює, а старе лишається з позначкою superseded.
• Передача вердикту: коли ти кажеш агенту в розмові «прийнято», «переробити з X», «відкинути» чи «не зараз», він записує цей вердикт у завдання разом із твоєю приміткою.

get_task_history читає це у трьох режимах: summary (картка, її останній звіт і лічильники), decisions (кожне рішення щодо завдання, зокрема чому його повертали, — це зберігається навіть після пізнішого прийняття) і full (сирий журнал, до 100 подій). get_context передає чинні рішення наступному агенту в межах бюджету токенів, тож наступний запуск починається з ухваленого, а не з нуля. Більше про це — у статті «чому рішення з чатів зі ШІ губляться».

Де це переглядати і що натискати?

За замовчуванням завершене завдання одразу йде в Done. Воно зупиняється в твоєму Inbox, коли потребує рев’ю або коли перевірка не пройшла. Там ти бачиш звіт і чотири кнопки: Accept, Rework, Later і Drop. Rework просить примітку, і вона повертається до агента.

Якщо агент передав nextStep, він з’являється над кнопкою Accept, і прийняття погоджує саме цей крок. Погодження дійсне 72 години й повертається до агента через get_my_work або start_task як єдиний наступний крок. Запитання, які агент ставить через request_input, потрапляють у той самий Inbox — у вебі та в застосунках для iOS і Android, із push-сповіщенням.

Inbox навмисно має ліміт: 5 пунктів для робочого простору на одну людину, 10 для команди або 45 хвилин оціненого часу на рев’ю — залежно від того, що настане раніше. Коли він заповнений, start_task відмовляє з attention_queue_full, тож агенти завершують чи уточнюють роботу, а не накидають тобі нової на перевірку.

Які докази просити для різних типів завдань?

Пропиши це в описі завдання, щоб агент знав, яких доказів ти чекаєш:

• Код: хеш коміту і URL PR як артефакти. notDone має називати тести, які не запускали, міграції, які не застосовували, і файли, які свідомо не чіпали.
• Контент: URL публікації або файл чернетки з його sha256, якщо вона ще не опублікована. unknowns має перелічувати факти, які агент не зміг підтвердити.
• Дослідження: URL джерела для кожного ключового твердження і файл нотаток. unknowns має відокремлювати те, що каже джерело, від того, що агент вивів сам.
• Розсилки й аутріч: ідентифікатор кожного надісланого повідомлення і список отримувачів файлом. notDone має перелічувати, з ким не зв’язалися і чому.

Як узагалі контролювати, що може робити агент?

Атрибуція постфактум найкраще працює, коли перед нею є обмеження. У Weft кожне OAuth-підключення має один із трьох рівнів прав, який задається на екрані згоди або пізніше в Settings, Connected AI clients:

• full (за замовчуванням): усі 32 інструменти.
• write: усе, крім трьох деструктивних інструментів (trash_task, archive_done_tasks, complete_sprint).
• read: лише 11 інструментів для читання.

Перевірка виконується на кожному виклику. Disconnect відкликає refresh-токени підключення і на наступному виклику відхиляє будь-який токен, виданий до відключення. Персональні токени доступу для клієнтів без OAuth не мають обмежень прав: один токен відкриває всі 32 інструменти, а відкликання діє з наступного виклику. Агенти можуть переносити завдання в кошик на 30 днів, але не можуть видаляти їх назавжди; відновлення з кошика — функція Pro.

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

• У ньому немає інтеграції з GitHub чи Slack, тож Weft не шукає за тебе коміти чи повідомлення. Артефакт відкриваєш ти.
• У ньому немає публічного REST API, вебхуків чи CLI, щоб передавати звіти в інші системи. Є експорт у JSON і Markdown.
• Він не трасує кроки моделі. Інструменти, що логують промпти, токени й затримки на рівні моделі, виконують іншу роботу, і такий інструмент тобі теж може знадобитися.
• Агенти пишуть власні звіти. Weft робить видимим розрив між твердженням і доказом; зробити агента чесним він не може.

Якщо тобі потрібні агенти як сервісні акаунти через REST API, CLI для CI-скриптів або вбудовані ШІ-функції, як-от написання завдань і тріаж, краще підійде Hypertask. Наша сторінка альтернативи Hypertask порівнює їх пліч-о-пліч.

Хіба історії git не досить, щоб знати, що зробив мій агент?

Git показує, що змінилося в коді. Він не показує, що агент пропустив, у чому не був певен і який із двох варіантів обрав. Використовуй хеш коміту як артефакт у завданні, а решту тримай у звіті й записі рішення.

Хіба агент не може просто вигадати артефакт?

Він може надіслати будь-який рядок. Сенс артефакту в тому, що його можна відкрити: хеш, який можна знайти, URL, який можна завантажити, ідентифікатор повідомлення, яке можна знайти. Вигаданий артефакт провалюється в момент перевірки — чого коментар ніколи не робить. Коли завдання має перевірку і блокувальна перевірка не проходить, завдання не потрапляє в Done.

Чи кожне завершене завдання чекає на моє рев’ю?

Ні. За замовчуванням завершене завдання йде в Done. Воно чекає в твоєму Inbox на Accept, Rework, Later чи Drop лише тоді, коли потребує рев’ю або перевірка не пройшла.

Які ШІ-клієнти можуть записувати звіти у Weft?

Будь-який MCP-клієнт. У ChatGPT Weft — опублікований плагін на будь-якому тарифі, зокрема Free. Claude Code підключається командою claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai і Claude Desktop використовують кастомний конектор. Є сторінки налаштування для 33 клієнтів, як-от Claude Code, ChatGPT, Cursor і Codex.

Скільки це коштує?

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