Zarządzanie zadaniami agentów AI: pętla przejęcia jako umowa, a nie prompt

Zarządzanie zadaniami agentów AI działa wtedy, gdy pętlą rządzi tablica, a nie prompt: agent pyta, co robić, przejmuje jedno zadanie z dzierżawą, która wygasa, jeśli agent ucichnie, pyta człowieka tylko o decyzje, które należą do niego, i kończy pokwitowaniem, które ktoś może sprawdzić. W Weft każdy z tych kroków to narzędzie MCP sprawdzane przez serwer, więc agent, który pominie krok, dostaje odmowę albo traci zadanie, zamiast po cichu rozjechać się z rzeczywistością.

Weft robimy my. Fakty o innych produktach pochodzą z ich oficjalnych stron, sprawdzonych 27 października 2026 r.

Dlaczego lista zadań wklejona do czatu przestaje działać?

Wklejenie zadań do czatu to pierwsza rzecz, którą każdy próbuje, i przez jedno popołudnie to działa. Potem czat się kończy, a razem z nim stan. Agent wiedział, który punkt skończył, z którego zrezygnował i czego nie był pewien. Teraz nie wie nikt.

Osoba, która wkleiła listę, staje się przekaźnikiem: kopiuje wyniki z powrotem na prawdziwą tablicę i powtarza pracę, którą podjęła druga sesja, bo nic nie mówiło, że jest zajęta.

Dostęp do tablicy rozwiązuje problem migawki, ale nie resztę. Jeśli jedyne narzędzia to „przenieś kartę” i „dodaj komentarz”, pętla nadal zależy od tego, czy agent trzyma się konwencji zapisanej w instrukcjach. Konwencje pękają dokładnie wtedy, gdy coś idzie źle: agent pada w połowie pracy albo dwóch agentów startuje w tej samej chwili.

Jak wygląda pętla przejęcia jako umowa?

W Weft pętla ma pięć kroków, a każdy to osobne narzędzie na jednym endpoincie MCP, https://letsweft.com/api/mcp. Serwer przechowuje stan między nimi, więc pętla przeżywa koniec każdego czatu.

1. get_my_work: zapytaj, zanim wybierzesz. Odpowiedź obejmuje to, co ten klient już trzyma, co czeka na człowieka, co jest po terminie lub ma termin wkrótce i czy w ogóle jest miejsce, by cokolwiek zacząć.
2. start_task: przejmij z dzierżawą. Przejęcie trwa 20 minut i przenosi zadanie do Doing. Odpowiedź zawiera runId, leaseToken i renewEverySeconds: 300. Drugi klient próbujący wziąć to samo zadanie dostaje already_claimed i wskazówkę, by nie dublować pracy.
3. report_progress: sygnał życia. Każde wywołanie z id przebiegu i tokenem dzierżawy ją odnawia. Jeśli agent padnie, sygnały ustają, a 20 minut później przebieg zostaje oznaczony jako nieaktualny i zadanie wraca do stanu nieprzypisanego, by ktokolwiek mógł je podjąć. Utracona dzierżawa odpowiada lease_lost, więc agent wie, że praca już do niego nie należy.
4. request_input: tylko dla decyzji, które należą do człowieka. Pytanie do 500 znaków, z maksymalnie 10 wariantami. Przejęcie zostaje zachowane, gdy agent czeka.
5. complete_task: zakończ pokwitowaniem. outcome, artifacts (dowody, takie jak URL, commit czy hash pliku), notDone, unknowns i nextStep.

Dlaczego dzierżawa, a nie status? Bo cisza to jedyny sygnał, jaki może wysłać agent, który padł. Karta w Doing mówi, że ktoś kiedyś nad nią pracował. Dzierżawa mówi, że ktoś pracuje nad nią teraz — i sama przestaje to mówić, gdy przestaje to być prawdą.

Samo przejęcie to pojedynczy zapis w bazie danych chroniony unikalnym indeksem. Gdy dwóch agentów się ściga, o zwycięzcy decyduje baza, więc obaj nie mogą dostać zadania. Dwa komentarze „Przejęte” dodane w odstępie sekundy są natomiast oba poprawnymi komentarzami.

Kiedy agent powinien wywołać request_input?

Gdy dochodzi do czegoś, o czym może zdecydować tylko człowiek: do czegokolwiek nieodwracalnego, jak pieniądze, publikacja, produkcja czy sprawy prawne, albo do prawdziwego rozwidlenia bez rozsądnego domyślnego wyboru. Nie po to, by pytać o pozwolenie na dalszą pracę.

Ta powściągliwość ma znaczenie, bo pytanie kosztuje człowieka tyle samo uwagi co skończone zadanie, a w Weft liczy się do tego samego limitu. Pytanie trafia do Skrzynki, z powiadomieniem push na telefon, a przy pozycjach czekających 20 minut lub dłużej — z przypomnieniem e-mailem. Weft nigdy nie oddzwania do agenta: odpowiedź dociera przy jego następnym start_task albo get_my_work. Gdy pytanie jest otwarte, agent trzyma zadanie przez 60 minut; potem dzierżawa wygasa, ale pytanie zostaje.

Co trafia do wywołania complete_task?

Krótki wynik, dowody i uczciwy opis granic. Oto realistyczny ładunek dla poprawki błędu:

{
  "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"
}

Artefakty to rzeczy, które człowiek może sprawdzić, nie wierząc agentowi na słowo. notDone i unknowns to nie przyznanie się do winy; oddzielają wynik, na którym można polegać, od takiego, który trzeba odtwarzać z diffa. Wywołanie nigdy nie zawodzi z powodu braku dowodów, bo utrata skończonej pracy jest gorsza niż zapisanie jej bez weryfikacji. Więcej o czytaniu takich pokwitowań w tekście co zrobił mój agent AI.

Czym to się różni od przeniesienia karty i dodania komentarza?

Poradnik Hypertask o tej samej pętli (przejmij, aktualizuj, raportuj, zamknij) dobrze opisuje sam nawyk. Jego wersja przejęcia przez MCP to załadowanie zadania, przeniesienie go do sekcji roboczej i dodanie komentarza o przejęciu, prowadzone promptem, który zespół wpisuje w instrukcje agenta. Oto ta sama pętla krok po kroku:

Uczciwie wobec Hypertask: ma prawdziwe dzierżawy. Jego dokumentacja wymienia endpointy do przejęcia, sygnału życia i zwolnienia dzierżawy, a tabela znanych ograniczeń mówi, że dzierżawy zadań, dowody i eskalacja są celowo dostępne tylko jako endpointy REST (przegląd MCP Hypertask). Lista narzędzi nie zawiera narzędzia do dzierżaw wśród 21 narzędzi MCP (lista narzędzi). Jego CLI też potrafi przejmować, jako opcjonalne polecenie (changelog, dokumentacja CLI). Agent oparty na skryptach w Hypertask może więc trzymać dzierżawę; agent pracujący przez MCP w Claude Code czy Cursorze dostaje wersję z kartą i komentarzem, chyba że ktoś podepnie wywołania REST.

Jeśli Twoi agenci działają jako skrypty i zadania CI, CLI i REST API Hypertask to realna przewaga, a Weft nie ma żadnego z nich: ani CLI, ani publicznego REST API, ani webhooków. Weft jest dla agentów, którzy żyją w kliencie MCP i potrzebują, by pętla trzymała się właśnie tam.

Co widzi człowiek?

Przez większość czasu kartę w Done: domyślnie ukończone zadanie trafia prosto tam, z dołączonym wynikiem i dowodami.

Zadanie zatrzymuje się w Skrzynce człowieka, gdy zostało oznaczone jako wymagające przeglądu albo gdy nie przejdzie kontrola weryfikacyjna. Tam człowiek wybiera jedną z czterech odpowiedzi:

• Akceptuj: praca zostaje. Jeśli agent przekazał nextStep, człowiek widzi go nad przyciskiem („Jeśli zaakceptujesz, agent …”), a akceptacja zatwierdza dokładnie ten krok, nic szerszego. Zatwierdzenie jest ważne 72 godziny i wraca do agenta przez get_my_work albo start_task.
• Do poprawki: odeślij, z notatką, co jest nie tak.
• Później: nie teraz. Odrzuć: przestań nad tym pracować.

Skrzynka jest w przeglądarce, a gdy coś do niej trafia, człowiek dostaje też powiadomienie push w aplikacji mobilnej Weft. Uzgodnienie przez nextStep nie pozwala agentowi potraktować „wygląda dobrze” jako zgody na merge, wdrożenie i wysyłkę: może wykonać ten jeden zatwierdzony krok, a potem ponownie zakończyć zadanie.

Dlaczego agent dostaje odmowę, zamiast zaczynać kolejną pracę?

Bo rzadkim zasobem jest uwaga, a nie praca. Agent może zacząć dziesięć rzeczy w czasie, w którym człowiek przejrzy jedną.

Weft liczy to, co czeka na ludzi: zadania czekające na przegląd plus otwarte pytania. Gdy to dojdzie do 5 pozycji w jednoosobowej przestrzeni roboczej, 10 w zespole albo około 45 minut szacowanego czasu przeglądania — co nastąpi pierwsze — start_task odmawia z attention_queue_full. Limit zależy od liczby osób w przestrzeni roboczej, a nie od planu.

Odmowa to instrukcja, a nie ślepa uliczka. Podaje wielkość kolejki, wiek najstarszej pozycji i wywołania, które wciąż są dozwolone: report_progress, get_my_work, get_board_state i search. Krok, który człowiek już zatwierdził na tej karcie, jest zwolniony z limitu, więc zaakceptowane „zmerguj PR #418” nie zostanie zablokowane przez kolejkę.

Jak to skonfigurować?

Podłącz klienta i zaloguj się w przeglądarce; nie ma klucza do kopiowania. Weft wydaje tokeny odświeżania, więc klient sam odnawia logowanie. W Claude Code to jedno polecenie, claude mcp add --transport http weft https://letsweft.com/api/mcp (strona konfiguracji). Cursor ma instalację jednym kliknięciem (Cursor), Codex potrzebuje wpisu w konfiguracji i codex mcp login weft (Codex), a ChatGPT ma opublikowaną aplikację Weft w każdym planie, także Darmowym (ChatGPT). Serwer sam opisuje agentowi pętlę, więc nie potrzeba promptu o cyklu życia zadania.

Przewodnik dla Claude Code znajdziesz w tekście o tablicy zadań dla Claude Code. O kilku agentach na jednej tablicy, gdzie dzierżawy i already_claimed mają największe znaczenie, przeczytasz w tekście wielu agentów AI, jedna tablica. Sam protokół jest udokumentowany na modelcontextprotocol.io, a inne tablice MCP porównujemy na stronie menedżerów zadań MCP.

Czego Weft tu nie robi?

• Brak CLI, publicznego REST API i webhooków, więc zadania cron i pipeline’y CI nie mogą sterować pętlą poza klientem MCP.
• Brak integracji z GitHubem i Slackiem. Dowodem jest to, co agent podlinkuje w artifacts.
• Brak wbudowanego AI. Myślenie odbywa się w Twoim własnym kliencie AI i dlatego Weft nie potrzebuje kredytów AI.

Plan Darmowy obejmuje 50 zadań i 200 wywołań AI miesięcznie. Pro kosztuje $7 za stanowisko miesięcznie albo $60 za stanowisko rocznie (cennik).

Czy dobry prompt nie wystarczy, żeby agenci trzymali się pętli?

Prompt opisuje pętlę; nie może jej wyegzekwować. Nie powstrzyma dwóch agentów przed przejęciem tego samego zadania i nie zwolni zadania trzymanego przez agenta, który padł. W Weft przejęcie to dzierżawa należąca do serwera, więc te przypadki są obsłużone niezależnie od tego, czy agent pamiętał swoje instrukcje.

Co się stanie, jeśli mój agent padnie w połowie?

Jego sygnały życia ustaną. Dwadzieścia minut po ostatnim report_progress przebieg zostaje oznaczony jako nieaktualny, token dzierżawy jest czyszczony, a zadanie znów jest nieprzypisane, więc może je podjąć inny agent albo człowiek. Karta nie leży w Doing przez tydzień.

Czy każde skończone zadanie czeka na mój przegląd?

Nie. Domyślnie ukończone zadanie trafia prosto do Done z wynikiem i dowodami. Zatrzymuje się w Twojej Skrzynce na Akceptuj, Do poprawki, Później albo Odrzuć tylko wtedy, gdy wymaga przeglądu albo nie przejdzie kontrola weryfikacyjna.

Po co mi agent, któremu odmawia się pracy?

Bo inaczej będzie produkował rzeczy, których nie masz czasu sprawdzić. Gdy na ludzi czeka 5 pozycji (10 w zespole) albo około 45 minut przeglądania, start_task zwraca attention_queue_full i wskazuje agentowi, co jeszcze może zrobić. Opróżnienie kolejki go odblokowuje.

Hypertask też ma dzierżawy. Dlaczego MCP ma znaczenie?

Dzierżawy Hypertask to endpointy REST, według jego własnej dokumentacji (przegląd MCP), a jego CLI też potrafi przejmować. To pasuje do agentów opartych na skryptach. Agent pracujący przez narzędzia MCP w edytorze czy czacie ich tam nie dostaje, a w Weft dostaje: start_task, report_progress i complete_task to narzędzia MCP.