Ce a făcut agentul meu AI? Patru întrebări la care să răspunzi cu dovezi
Pentru fiecare sarcină a unui agent AI ar trebui să vezi cine a făcut-o, ce s-a schimbat, ce a fost sărit și de ce, cu dovezi verificabile, nu un comentariu „gata”.
Weft este managerul de sarcini cu AI pentru fondatori solo și echipe mici.
De Andrei Finogeev ·
Ca să știi ce a făcut agentul tău AI, nu începe cu rezumatul lui. Verifică patru lucruri: ce conexiune a făcut munca, ce s-a schimbat (arătat de ceva ce poți deschide singur), ce a rămas nefăcut și ce s-a decis și de ce. Dacă oricare dintre cele patru se sprijină doar pe cuvântul agentului, ai o povestire, nu o evidență.
Noi facem Weft. Informațiile despre alte produse provin din paginile lor oficiale, verificate pe 27 octombrie 2026.
De ce nu e de ajuns un comentariu care spune „gata”?
Un comentariu e agentul care își descrie propria muncă. Poate fi foarte bine exact, dar comentariul nu poate arăta asta, pentru că autorul lui e chiar partea pe care încerci s-o verifici. Să știi că un agent a atins o sarcină răspunde la întrebarea cine. Nu răspunde la întrebarea dacă munca e ceea ce crezi tu că e.
Articolul Hypertask despre atribuirea muncii AI are un argument corect: munca agenților ar trebui să ajungă pe același panou ca munca oamenilor, nu într-un log de terminal pe care nu-l citește nimeni. Hypertask le dă agenților și propria identitate, ca conturi de serviciu, așa că modificările sunt atribuite agentului, nu ție, și are dovezi pentru sarcini și leasing, deși documentația lui spune că acestea sunt doar endpointuri REST, nu instrumente MCP, intenționat. Ne deosebim prin ce ar trebui să conțină evidența. Un fir de comentarii cu ieșirea agentului e un jurnal a ceea ce a spus agentul. Noi vrem ca evidența să conțină dovezi.
În ghidul acesta nu există cifre din sondaje. Poți testa cele patru întrebări pe propriul panou chiar în după-amiaza asta, iar asta îți spune mai mult decât o medie din industrie.
Care sunt cele patru întrebări?
Alege orice sarcină terminată de un agent săptămâna trecută. Ar trebui să poți răspunde la fiecare dintre acestea în mai puțin de un minut, fără să întrebi agentul sau să-i deschizi chatul:
- Cine a făcut-o? Ce client, pe ce conexiune, a revendicat și a terminat sarcina.
- Ce s-a schimbat? Rezultatul, plus artefacte pe care le poți verifica fără să te încrezi în agent: un hash de commit, un URL, un fișier, un id de mesaj.
- Ce nu s-a făcut? Părțile sărite și lucrurile de care nu era sigur.
- Ce s-a decis și de ce? Orice alegere făcută pe parcurs, cu variantele cântărite, și orice moment în care ai trimis munca înapoi.
| Întrebare | Răspuns slab: un comentariu care spune „gata” | Răspuns solid: dovezi pe care le poți verifica |
|---|---|---|
| Cine a făcut-o? | „Agent” sau propriul tău nume pe fiecare modificare, pentru că toate instrumentele împart o singură cheie | Conexiunea care a revendicat și a terminat sarcina, cu numele înregistrat de client, cu fiecare eveniment din jurnal marcat ca persoană sau MCP și cu id-ul clientului |
| Ce s-a schimbat? | „Am refactorizat modulul de autentificare, testele trec” | Un hash de commit, un URL de PR sau de pagină, un fișier cu sha256-ul lui, un id de mesaj: ceva ce deschizi singur |
| Ce nu s-a făcut? | Nu se spune nimic, așa că presupui că nu s-a sărit nimic | O listă notDone („n-am rulat migrarea pe staging”) și o listă unknowns („nu sunt sigur că vechiul endpoint nu mai are alți apelanți”) |
| Ce s-a decis și de ce? | Îngropat într-un chat care între timp a dispărut în sus | O evidență a deciziei, cu variantele cântărite și condiția de revizuire, plus istoricul deciziilor sarcinii, inclusiv de ce a fost trimisă înapoi |
Cum știu ce agent a făcut-o?
Weft se conectează la clienții AI prin Model Context Protocol, la un singur endpoint, https://letsweft.com/api/mcp. Fiecare client OAuth și fiecare token de acces personal e un actor separat. O sarcină înregistrează ce client a creat-o, iar panoul arată numele cu care s-a înregistrat clientul la autentificare, plus o pictogramă. Fiecare eveniment din jurnalul sarcinii păstrează dacă a venit de la o persoană sau prin MCP și ce client l-a trimis.
Jurnalul complet (get_task_history în modul full) arată id-ul brut al clientului pentru fiecare eveniment: un id de client OAuth sau mcp-token urmat de id-ul tokenului. Nu e un nume prietenos, dar e exact și separă două conexiuni chiar și când vin de la același produs.
Și proprietatea în timpul muncii e explicită. Un agent apelează start_task, care revendică sarcina cu un leasing de 20 de minute și o mută în Doing. report_progress reînnoiește leasingul. Un al doilea agent care încearcă aceeași sarcină primește already_claimed, iar un leasing expirat eliberează sarcina pentru altcineva. Ghidul buclei de revendicare descrie asta pas cu pas, iar rularea mai multor agenți pe un singur panou acoperă cazul cu mai mulți clienți.
O regulă practică: dă-i fiecărui instrument propria conexiune. Dacă doi clienți împart un singur token de acces, panoul vede un singur actor, iar întrebarea cine își pierde răspunsul.
Ce s-a schimbat și pot verifica fără să întreb agentul?
Când termină, un agent apelează complete_task. Doar id-ul sarcinii e obligatoriu; restul e opțional, iar apelul nu eșuează niciodată din lipsă de dovezi. E intenționat: a pierde munca terminată e mai rău decât a o înregistra neverificată. Ce poate conține o chitanță:
- outcome: până la 1.000 de caractere despre ce s-a făcut și unde se află rezultatul.
- artifacts: până la 20 de intrări, fiecare cu un tip (url, file, message, commit și așa mai departe), o locație și, opțional, un digest sha256.
- claims: ce afirmă agentul că a făcut, păstrate ca afirmații, nu ca fapte verificate.
- notDone și unknowns: descrise în secțiunea următoare.
- nextStep: ce ar face agentul în continuare dacă accepți.
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"
})Rândul outcome e tot o povestire. Artefactele sunt partea pe care o poți verifica. Un hash de commit fie există în repozitoriul tău, fie nu. Un URL se încarcă sau nu. Sha256-ul unui fișier se potrivește sau nu. Dacă o chitanță are un outcome și niciun artefact, trateaz-o ca muncă raportată de agent, pentru că exact asta e. Pe web, cardurile din Done arată dacă o sarcină e Verificată sau Conform agentului.
Ce nu a făcut agentul?
Aceasta e întrebarea pe care o sar cele mai multe evidențe și cea care te mușcă peste două săptămâni. complete_task are două liste pentru ea, fiecare cu până la 20 de intrări de 500 de caractere: notDone pentru ce a lăsat agentul deoparte intenționat și unknowns pentru ce nu e sigur. Chiar descrierea instrumentului le cere agenților să spună cu voce tare ce nu au făcut. Asta desparte un rezultat pe care te poți baza de unul pe care trebuie să-l reconstruiești.
Citește întâi aceste liste. „N-am rulat testele pe baza de date de staging” schimbă ce faci mai departe. O chitanță fără nicio intrare notDone pe o sarcină mare merită ea însăși o întrebare.
Ce s-a decis și de ce?
Deciziile luate în chat dispar când chatul se derulează mai departe. record_decision le păstrează în două feluri:
- O evidență de decizie de sine stătătoare: un titlu, rezultatul, contextul, variantele cântărite efectiv, consecințele și condiția în care trebuie revizuită. Evidențele sunt imuabile; a schimba una înseamnă a înregistra o decizie nouă care o înlocuiește, iar cea veche rămâne, marcată ca înlocuită.
- Un releu de verdict: când îi spui unui agent în conversație „acceptat”, „refă cu X”, „renunță” sau „nu acum”, el înregistrează verdictul pe sarcină, cu nota ta.
get_task_history le citește înapoi în trei moduri: summary (cardul, ultima lui chitanță și numărători), decisions (fiecare decizie despre sarcină, inclusiv de ce a fost trimisă înapoi, care rămâne chiar și după o acceptare ulterioară) și full (jurnalul brut, plafonat la 100 de evenimente). get_context îi dă următorului agent deciziile în vigoare, într-un buget de tokeni, așa că următoarea rulare pornește de la ce s-a decis, nu de la zero. Mai multe despre asta în de ce se pierd deciziile din chaturile cu AI.
Unde revizuiesc și pe ce dau clic?
Implicit, o sarcină finalizată merge direct în Done. Se oprește în Inboxul tău când are nevoie de revizuire sau când o verificare eșuează. Acolo vezi chitanța și patru butoane: Acceptă, Refă, Mai târziu și Renunță. Refă cere o notă, iar nota se întoarce la agent.
Dacă agentul a trimis un nextStep, acesta apare deasupra butonului Acceptă, iar acceptarea aprobă exact acel pas. Aprobarea e valabilă 72 de ore și se întoarce la agent prin get_my_work sau start_task ca singurul pas de făcut în continuare. Întrebările pe care un agent le pune cu request_input ajung în același Inbox, pe web și în aplicațiile iOS și Android, cu o notificare push pe mobil.
Inboxul are intenționat o limită: 5 elemente în așteptare pentru un spațiu de lucru de o persoană, 10 pentru o echipă sau 45 de minute de revizuire estimată, oricare vine primul. Când e plin, start_task refuză cu attention_queue_full, așa că agenții termină sau clarifică munca în loc să-ți adune și mai multe de verificat.
Ce dovezi să ceri în funcție de tipul sarcinii?
Scrie-le în descrierea sarcinii, ca agentul să știe ce dovadă aștepți:
- Cod: hashul commitului și URL-ul PR-ului ca artefacte. notDone ar trebui să numească testele nerulate, migrările neaplicate și fișierele lăsate intenționat neatinse.
- Conținut: URL-ul publicat sau fișierul ciornă cu sha256-ul lui, dacă nu e încă public. unknowns ar trebui să listeze faptele pe care agentul nu le-a putut confirma.
- Cercetare: un URL de sursă pentru fiecare afirmație importantă și fișierul cu notițe. unknowns ar trebui să despartă ce spune o sursă de ce a dedus agentul.
- Prospectare: id-ul fiecărui mesaj trimis și lista destinatarilor ca fișier. notDone ar trebui să listeze cine n-a fost contactat și de ce.
Cum controlez de la bun început ce poate face un agent?
Atribuirea de după fapt merge cel mai bine cu limite puse înainte. În Weft, fiecare conexiune OAuth are unul dintre trei niveluri de permisiuni, setat pe ecranul de consimțământ sau mai târziu în Setări, Clienți AI conectați:
- full (implicit): toate cele 32 de instrumente.
- write: totul în afară de cele trei instrumente distructive (trash_task, archive_done_tasks, complete_sprint).
- read: doar cele 11 instrumente de citire.
Verificarea rulează la fiecare apel. Deconectarea revocă refresh tokenurile conexiunii și refuză, la următorul apel, orice token emis înainte de tăietură. Tokenurile de acces personale, pentru clienții fără OAuth, nu au permisiuni restrânse: un token ajunge la toate cele 32 de instrumente, iar revocarea lui are efect de la următorul apel. Agenții pot muta sarcini într-un coș de 30 de zile, dar nu le pot șterge definitiv; restaurarea din coș e o funcție Pro.
Ce nu face Weft aici?
- Nu are integrare cu GitHub sau Slack, așa că Weft nu-ți caută singur commiturile sau mesajele. Tu deschizi artefactul.
- Nu are API REST public, webhookuri sau CLI prin care să împingă chitanțe în alte sisteme. Există un export JSON și Markdown.
- Nu urmărește pașii modelului. Instrumentele care loghează prompturi, tokeni și latență la nivelul modelului fac altă treabă și s-ar putea să vrei și unul dintre ele.
- Agenții își scriu singuri chitanțele. Weft face vizibilă distanța dintre afirmație și dovadă; nu poate face un agent onest.
Dacă vrei agenți gestionați ca conturi de serviciu printr-un API REST, un CLI pentru scripturi CI sau funcții AI integrate, precum scrierea sarcinilor și trierea, Hypertask se potrivește mai bine. Pagina noastră alternativă la Hypertask le compară una lângă alta.
- Nu e de ajuns istoricul git ca să știu ce a făcut agentul meu?
- Git arată ce s-a schimbat în cod. Nu arată ce a sărit agentul, de ce nu era sigur sau ce alegere a făcut între două variante. Folosește hashul commitului ca artefact pe sarcină și păstrează restul în chitanță și în evidența deciziei.
- Nu poate un agent să inventeze pur și simplu un artefact?
- Poate trimite orice șir de caractere. Rostul unui artefact e că îl poți deschide: un hash pe care îl poți căuta, un URL pe care îl poți încărca, un id de mesaj pe care îl poți găsi. Unul inventat pică în clipa în care verifici, lucru pe care un comentariu nu-l face niciodată. Când o sarcină are o verificare și o verificare blocantă eșuează, sarcina rămâne în afara Done.
- Fiecare sarcină terminată așteaptă revizuirea mea?
- Nu. Implicit, o sarcină finalizată merge în Done. Așteaptă în Inboxul tău pentru Acceptă, Refă, Mai târziu sau Renunță doar când are nevoie de revizuire sau când o verificare eșuează.
- Ce clienți AI pot scrie chitanțe în Weft?
- Orice client MCP. ChatGPT are Weft ca plugin publicat, pe orice plan, inclusiv Free. Claude Code se conectează cu
claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai și Claude Desktop folosesc un conector personalizat. Există pagini de configurare pentru 33 de clienți, precum Claude Code, ChatGPT, Cursor și Codex. - Cât costă?
- Free acoperă 50 de sarcini și 200 de apeluri AI pe lună. Pro costă 7,87 € pe loc pe lună sau 66,55 € pe loc pe an, cu TVA inclus. Weft nu are credite AI: gândirea se petrece în propriul tău client AI. Vezi prețurile.