Co zrobił mój agent AI? Cztery pytania, na które trzeba odpowiedzieć dowodami

Żeby wiedzieć, co zrobił Twój agent AI, nie zaczynaj od jego podsumowania. Sprawdź cztery rzeczy: które połączenie wykonało pracę, co się zmieniło (pokazane czymś, co możesz sam otworzyć), co zostało niezrobione i co zdecydowano oraz dlaczego. Jeśli którakolwiek z tych czterech opiera się wyłącznie na słowie agenta, masz narrację, a nie zapis.

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

Dlaczego komentarz „gotowe” nie wystarcza?

Komentarz to agent opisujący własną pracę. Może być całkiem trafny, ale komentarz nie jest w stanie tego wykazać, bo jego autorem jest właśnie ta strona, którą próbujesz sprawdzić. Wiedza, że agent dotknął zadania, odpowiada na pytanie „kto”. Nie odpowiada na pytanie, czy praca jest tym, za co ją uważasz.

Artykuł Hypertask o przypisywaniu pracy AI ma rację w jednym: praca agentów powinna trafiać na tę samą tablicę co praca ludzi, a nie do logu terminala, którego nikt nie czyta. Hypertask daje też agentom własną tożsamość jako kontom usługowym, więc zapisy są przypisywane agentowi, a nie Tobie, i ma dowody oraz dzierżawy zadań — choć jego dokumentacja mówi, że to celowo wyłącznie endpointy REST, a nie narzędzia MCP. Różnimy się w tym, co powinien zawierać zapis. Wątek komentarzy z wynikiem agenta to log tego, co agent powiedział. My chcemy, żeby zapis zawierał dowody.

W tym przewodniku nie ma liczb z ankiet. Cztery pytania możesz przetestować na własnej tablicy jeszcze dziś po południu, a to powie Ci więcej niż średnia branżowa.

Jakie to cztery pytania?

Wybierz dowolne zadanie, które agent skończył w zeszłym tygodniu. Na każde z tych pytań powinieneś odpowiedzieć w niecałą minutę, nie pytając agenta i nie otwierając jego czatu:

1. Kto to zrobił? Który klient, przez które połączenie, przejął i zakończył zadanie.
2. Co się zmieniło? Wynik plus artefakty, które sprawdzisz bez ufania agentowi: hash commita, URL, plik, id wiadomości.
3. Czego nie zrobiono? Części, które pominął, i rzeczy, których nie był pewien.
4. Co zdecydowano i dlaczego? Każdy wybór dokonany po drodze, z rozważonymi wariantami, i każdy raz, gdy odesłałeś pracę z powrotem.

Skąd mam wiedzieć, który agent to zrobił?

Weft łączy się z klientami AI przez Model Context Protocol pod jednym endpointem, https://letsweft.com/api/mcp. Każdy klient OAuth i każdy osobisty token dostępu to osobny wykonawca. Zadanie zapisuje, który klient je utworzył, a tablica pokazuje nazwę, pod którą ten klient zarejestrował się przy logowaniu, plus ikonę. Każde zdarzenie w dzienniku zadania przechowuje informację, czy pochodzi od człowieka, czy przez MCP, i który klient je wysłał.

Pełny dziennik (get_task_history w trybie full) pokazuje surowe id klienta przy każdym zdarzeniu: id klienta OAuth albo mcp-token z id tokenu. To nie jest przyjazna nazwa, ale jest dokładna i rozróżnia dwa połączenia, nawet jeśli pochodzą z tego samego produktu.

Własność w trakcie pracy też jest jawna. Agent wywołuje start_task, które przejmuje zadanie z 20-minutową dzierżawą i przenosi je do Doing. report_progress odnawia dzierżawę. Drugi agent, który spróbuje wziąć to samo zadanie, dostaje already_claimed, a wygasła dzierżawa zwalnia zadanie dla kogoś innego. Przewodnik po pętli przejęcia opisuje to krok po kroku, a tekst o kilku agentach na jednej tablicy — przypadek wielu klientów.

Jedna praktyczna zasada: daj każdemu narzędziu własne połączenie. Jeśli dwóch klientów dzieli jeden token dostępu, tablica widzi jednego wykonawcę, a pytanie „kto” traci odpowiedź.

Co się zmieniło i czy mogę to sprawdzić bez pytania agenta?

Gdy agent kończy, wywołuje complete_task. Wymagane jest tylko id zadania; wszystko inne jest opcjonalne, a wywołanie nigdy nie zawodzi z powodu braku dowodów. To celowe: utrata skończonej pracy jest gorsza niż zapisanie jej bez weryfikacji. Co może zawierać pokwitowanie:

• outcome: do 1000 znaków o tym, co zrobiono i gdzie leży wynik.
• artifacts: do 20 wpisów, każdy z rodzajem (url, file, message, commit itd.), lokalizacją i opcjonalnie skrótem sha256.
• claims: to, co agent twierdzi, że zrobił, przechowywane jako deklaracje, a nie zweryfikowane fakty.
• notDone i unknowns: o nich w następnej sekcji.
• nextStep: co agent zrobiłby dalej, jeśli zaakceptujesz.

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

Linia z wynikiem to wciąż narracja. Artefakty to ta część, którą możesz sprawdzić. Hash commita albo istnieje w Twoim repozytorium, albo nie. URL się ładuje albo nie. sha256 pliku się zgadza albo nie. Jeśli pokwitowanie ma wynik, a nie ma artefaktów, traktuj je jako pracę zgłoszoną przez agenta, bo tym właśnie jest. W przeglądarce karty w Done pokazują, czy zadanie jest Zweryfikowane, czy Według agenta.

Czego agent nie zrobił?

To pytanie, które większość zapisów pomija, i to ono gryzie dwa tygodnie później. complete_task ma na nie dwie listy, każda do 20 wpisów po 500 znaków: notDone na to, co agent celowo pominął, i unknowns na to, czego nie jest pewien. Opis samego narzędzia prosi agentów, by głośno mówili, czego nie zrobili. To właśnie oddziela wynik, na którym można polegać, od takiego, który trzeba odtwarzać.

Czytaj te listy w pierwszej kolejności. „Nie uruchomiłem testów na bazie stagingowej” zmienia to, co zrobisz dalej. Pokwitowanie bez żadnych wpisów notDone przy dużym zadaniu samo w sobie zasługuje na pytanie.

Co zdecydowano i dlaczego?

Decyzje podjęte w czacie znikają, gdy czat odjedzie w górę. record_decision zachowuje je na dwa sposoby:

• Samodzielny zapis decyzji: tytuł, rozstrzygnięcie, kontekst, faktycznie rozważone warianty, konsekwencje i warunek, przy którym trzeba do niej wrócić. Zapisy są niezmienne; zmiana oznacza zapisanie nowej decyzji, która zastępuje poprzednią, a stara zostaje, oznaczona jako zastąpiona.
• Przekazanie werdyktu: gdy mówisz agentowi w rozmowie „akceptuję”, „zrób to jeszcze raz z X”, „porzuć to” albo „nie teraz”, zapisuje ten werdykt przy zadaniu, z Twoją notatką.

get_task_history odczytuje to w trzech trybach: summary (karta, jej ostatnie pokwitowanie i liczniki), decisions (każda decyzja dotycząca zadania, łącznie z tym, dlaczego zostało odesłane — to zostaje nawet po późniejszej akceptacji) i full (surowy dziennik, maksymalnie 100 zdarzeń). get_context przekazuje aktualne decyzje następnemu agentowi w ramach budżetu tokenów, więc kolejny przebieg zaczyna od tego, co zdecydowano, a nie od zera. Więcej o tym w tekście dlaczego decyzje z czatów z AI giną.

Gdzie to przeglądam i co klikam?

Domyślnie ukończone zadanie trafia prosto do Done. Zatrzymuje się w Twojej Skrzynce, gdy wymaga przeglądu albo gdy nie przejdzie kontrola weryfikacyjna. Tam widzisz pokwitowanie i cztery przyciski: Akceptuj, Do poprawki, Później i Odrzuć. Do poprawki wymaga notatki, a ta notatka wraca do agenta.

Jeśli agent przekazał nextStep, pojawia się on nad przyciskiem Akceptuj, a akceptacja zatwierdza dokładnie ten krok. Zatwierdzenie jest ważne 72 godziny i wraca do agenta przez get_my_work albo start_task jako jedyny krok do wykonania. Pytania, które agent zadaje przez request_input, trafiają do tej samej Skrzynki, w przeglądarce i w aplikacjach na iOS i Androida, z powiadomieniem push.

Skrzynka celowo ma limit: 5 czekających pozycji w jednoosobowej przestrzeni roboczej, 10 w zespole albo 45 minut szacowanego czasu przeglądania — co nastąpi pierwsze. Gdy jest pełna, start_task odmawia z attention_queue_full, więc agenci kończą lub doprecyzowują pracę, zamiast piętrzyć Ci kolejne rzeczy do sprawdzenia.

Jakich dowodów żądać w zależności od rodzaju zadania?

Wpisz je w opis zadania, żeby agent wiedział, jakiego dowodu oczekujesz:

• Kod: hash commita i URL PR-a jako artefakty. notDone powinno wymieniać nieuruchomione testy, niezastosowane migracje i pliki celowo nieruszane.
• Treści: opublikowany URL albo plik szkicu z jego sha256, jeśli jeszcze nie jest online. unknowns powinno wymieniać fakty, których agent nie mógł potwierdzić.
• Research: URL źródła dla każdego kluczowego twierdzenia i plik z notatkami. unknowns powinno oddzielać to, co mówi źródło, od tego, co agent wywnioskował.
• Outreach: id każdej wysłanej wiadomości i lista odbiorców jako plik. notDone powinno wymieniać, z kim się nie skontaktowano i dlaczego.

Jak w ogóle kontrolować, co agent może robić?

Przypisywanie po fakcie działa najlepiej z ograniczeniami przed nim. W Weft każde połączenie OAuth ma jeden z trzech poziomów uprawnień, ustawiany na ekranie zgody albo później w Ustawieniach, w sekcji Podłączeni klienci AI:

• pełny dostęp (domyślnie): wszystkie 32 narzędzia.
• zapis: wszystko poza trzema destrukcyjnymi narzędziami (trash_task, archive_done_tasks, complete_sprint).
• odczyt: tylko 11 narzędzi tylko do odczytu.

Kontrola działa przy każdym wywołaniu. Disconnect odwołuje tokeny odświeżania połączenia i przy następnym wywołaniu odrzuca każdy token wydany przed odcięciem. Osobiste tokeny dostępu, dla klientów bez OAuth, nie mają zakresów: jeden token sięga wszystkich 32 narzędzi, a jego odwołanie działa od następnego wywołania. Agenci mogą przenosić zadania do kosza na 30 dni, ale nie mogą usunąć ich na dobre; przywracanie z kosza to funkcja Pro.

Czego Weft tu nie robi?

• Nie ma integracji z GitHubem ani Slackiem, więc Weft nie sprawdzi za Ciebie commitów ani wiadomości. Artefakt otwierasz Ty.
• Nie ma publicznego REST API, webhooków ani CLI, by wypychać pokwitowania do innych systemów. Jest eksport do JSON i Markdown.
• Nie śledzi kroków modelu. Narzędzia, które logują prompty, tokeny i opóźnienia na warstwie modelu, robią coś innego i być może też chcesz takiego używać.
• Agenci piszą własne pokwitowania. Weft uwidacznia różnicę między deklaracją a dowodem; nie sprawi, że agent będzie uczciwy.

Jeśli chcesz agentów zarządzanych jako konta usługowe przez REST API, CLI do skryptów CI albo wbudowanych funkcji AI, jak pisanie zadań i segregowanie, lepiej pasuje Hypertask. Nasza strona alternatywa dla Hypertask porównuje oba narzędzia obok siebie.

Czy historia gita nie wystarczy, żeby wiedzieć, co zrobił mój agent?

Git pokazuje, co zmieniło się w kodzie. Nie pokazuje, co agent pominął, czego nie był pewien ani który z dwóch wariantów wybrał. Użyj hasha commita jako artefaktu przy zadaniu, a resztę trzymaj w pokwitowaniu i zapisie decyzji.

Czy agent nie może po prostu zmyślić artefaktu?

Może wysłać dowolny ciąg znaków. Sens artefaktu polega na tym, że możesz go otworzyć: hash, który da się wyszukać, URL, który da się załadować, id wiadomości, które da się znaleźć. Zmyślony nie przejdzie w chwili, gdy sprawdzisz — czego komentarz nigdy nie zrobi. Gdy zadanie ma kontrolę weryfikacyjną, a blokująca kontrola nie przejdzie, zadanie nie trafia do Done.

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

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

Którzy klienci AI mogą zapisywać pokwitowania w Weft?

Każdy klient MCP. ChatGPT ma Weft jako opublikowaną wtyczkę w każdym planie, także Darmowym. Claude Code łączy się poleceniem claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai i Claude Desktop używają własnego konektora. Są strony konfiguracji dla 33 klientów, takich jak Claude Code, ChatGPT, Cursor i Codex.

Ile to kosztuje?

Plan Darmowy obejmuje 50 zadań i 200 wywołań AI miesięcznie. Pro kosztuje $7 za stanowisko miesięcznie albo $60 za stanowisko rocznie. Weft nie ma kredytów AI: myślenie odbywa się w Twoim własnym kliencie AI. Zobacz cennik.