Nu e de ajuns un prompt bun ca agenții să respecte bucla?

Un prompt descrie bucla; nu o poate impune. Nu-i oprește pe doi agenți să revendice aceeași sarcină și nu poate elibera o sarcină ținută de un agent care s-a prăbușit. În Weft, revendicarea e un leasing deținut de server, așa că aceste cazuri sunt tratate indiferent dacă agentul și-a amintit sau nu instrucțiunile.

Ce se întâmplă dacă agentul meu se prăbușește la jumătatea drumului?

Semnalele lui de viață se opresc. La douăzeci de minute după ultimul report_progress, rularea e marcată ca expirată, tokenul de leasing e șters și sarcina e din nou neatribuită, așa că o poate prelua alt agent sau un om. Cardul nu stă o săptămână în Doing.

Fiecare sarcină terminată așteaptă să o revizuiesc?

Nu. Implicit, o sarcină finalizată merge direct în Done, cu rezultatul și dovezile. Se oprește în Inboxul tău pentru Acceptă, Refă, Mai târziu sau Renunță doar când sarcina are nevoie de revizuire sau când o verificare eșuează.

De ce aș vrea ca agentului meu să i se refuze munca?

Pentru că altfel continuă să producă lucruri pe care n-ai timp să le verifici. Odată ce 5 elemente (10 pentru o echipă) sau cam 45 de minute de revizuire așteaptă după oameni, start_task întoarce attention_queue_full și îi arată agentului ce mai poate face. Golirea cozii îl deblochează.

Și Hypertask are leasing. De ce contează MCP?

Leasingul Hypertask e format din endpointuri REST, conform propriei documentații (prezentare MCP), iar CLI-ul lui poate și el revendica. Asta li se potrivește agenților scriptați. Un agent care lucrează prin instrumente MCP într-un editor sau chat nu le primește acolo, iar în Weft le primește: start_task, report_progress și complete_task sunt instrumente MCP.

Blog

Gestionarea sarcinilor agenților AI: bucla de revendicare ca un contract, nu ca un prompt

Cum gestionezi sarcinile agenților AI cu o buclă de revendicare impusă de server: leasing, semnale de viață, întrebări, chitanțe și o limită pentru atenția omului.

Weft este managerul de sarcini cu AI pentru fondatori solo și echipe mici.

Toate articolele

De Andrei Finogeev · 27 octombrie 2026

Gestionarea sarcinilor agenților AI funcționează când bucla e a panoului, nu a promptului: agentul întreabă ce are de făcut, revendică o sarcină cu un leasing care expiră dacă tace, îi cere omului doar deciziile care sunt ale lui și termină cu o chitanță pe care cineva o poate verifica. În Weft, fiecare dintre acești pași e un instrument MCP verificat de server, așa că un agent care sare peste un pas e refuzat sau pierde sarcina, în loc să se desincronizeze pe tăcute.

Noi facem Weft. Informațiile despre alte produse provin din paginile lor oficiale, verificate pe 27 octombrie 2026.

De ce nu mai funcționează o listă de sarcini lipită în chat?

Lipirea sarcinilor într-un chat e primul lucru pe care îl încearcă toată lumea și merge o după-amiază. Apoi chatul se termină, iar starea se termină odată cu el. Agentul știa ce element terminase, la care renunțase și de ce nu era sigur. Acum nu mai știe nimeni.

Persoana care a lipit lista devine releul: copiază rezultatele înapoi pe panoul real și reface munca pe care a preluat-o o a doua sesiune, pentru că nimic nu spunea că e deja luată.

Accesul la panou rezolvă problema instantaneului, nu și restul. Dacă singurele instrumente sunt „mută cardul” și „adaugă comentariu”, bucla depinde tot de faptul că agentul respectă o convenție scrisă în instrucțiunile lui. Convențiile se rup exact când lucrurile merg prost: agentul se prăbușește în mijlocul rulării sau doi agenți pornesc în același moment.

Cum arată bucla de revendicare ca un contract?

În Weft, bucla are cinci pași, iar fiecare e un instrument separat pe un singur endpoint MCP, https://letsweft.com/api/mcp. Serverul păstrează starea între ei, așa că bucla supraviețuiește sfârșitului oricărui chat.

get_my_work: întreabă înainte să alegi. Răspunsul acoperă ce deține deja acest client, ce așteaptă după om, ce e întârziat sau scadent curând și dacă există loc să înceapă ceva.
start_task: revendică cu un leasing. Revendicarea durează 20 de minute și mută sarcina în Doing. Răspunsul conține un runId, un leaseToken și renewEverySeconds: 300. Un al doilea client care încearcă aceeași sarcină primește already_claimed și un indiciu să nu dubleze munca.
report_progress: semnalul de viață. Fiecare apel cu id-ul rulării și tokenul de leasing reînnoiește leasingul. Dacă agentul moare, semnalele se opresc, iar 20 de minute mai târziu rularea e marcată ca expirată și sarcina redevine neatribuită, ca s-o poată lua oricine. Un leasing pierdut răspunde cu lease_lost, așa că agentul știe că nu mai deține munca.
request_input: doar pentru deciziile care sunt ale omului. O întrebare de până la 500 de caractere, cu până la 10 variante. Revendicarea se păstrează cât timp agentul așteaptă.
complete_task: încheie cu o chitanță. outcome, artifacts (dovezi precum un URL, un commit sau un hash de fișier), notDone, unknowns și nextStep.

De ce un leasing și nu un status? Pentru că tăcerea e singurul semnal pe care îl poate trimite un agent prăbușit. Un card în Doing spune că cineva a lucrat odată la el. Un leasing spune că cineva lucrează la el acum și încetează singur să mai spună asta când nu mai e adevărat.

Revendicarea în sine e o singură inserare în baza de date, păzită de un index unic. Când doi agenți se întrec, baza de date decide cine câștigă, așa că nu pot primi amândoi sarcina. Două comentarii „Revendicat” postate la o secundă distanță sunt, în schimb, ambele comentarii valide.

Când ar trebui agentul să apeleze request_input?

Când ajunge la ceva ce doar omul poate decide: orice e ireversibil, precum bani, publicare, producție sau aspecte juridice, ori o bifurcație reală fără o variantă implicită rezonabilă. Nu ca să ceară voie să continue.

Reținerea asta contează pentru că o întrebare îl costă pe om aceeași atenție ca o sarcină terminată, iar în Weft se numără la aceeași limită. Întrebarea ajunge în Inbox, cu o notificare push pe mobil și, pentru elementele care așteaptă 20 de minute sau mai mult, cu un email de reamintire. Weft nu îl apelează niciodată înapoi pe agent: răspunsul ajunge la următorul lui start_task sau get_my_work. Cât timp întrebarea e deschisă, agentul păstrează sarcina 60 de minute; după aceea leasingul cade, dar întrebarea rămâne.

Ce intră într-un apel complete_task?

Un rezultat scurt, dovezi și o relatare onestă a marginilor. Iată un payload realist pentru repararea unui bug:

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

Artefactele sunt lucruri pe care omul le poate verifica fără să se bazeze pe cuvântul agentului. notDone și unknowns nu sunt mărturisiri; ele despart un rezultat pe care te poți baza de unul pe care îl reconstruiești din diff. Apelul nu eșuează niciodată din lipsă de dovezi, pentru că a pierde munca terminată e mai rău decât a o înregistra neverificată. Mai multe despre citirea acestor chitanțe în ce a făcut agentul meu AI.

Prin ce diferă asta de mutarea unui card și postarea unui comentariu?

Ghidul Hypertask despre aceeași buclă (revendicare, actualizare, raportare, închidere) descrie bine obiceiul. Versiunea lui MCP a unei revendicări înseamnă încărcarea sarcinii, mutarea ei în secțiunea de lucru și postarea unui comentariu de revendicare, ghidate de un prompt pe care echipa îl scrie în instrucțiunile agentului. Iată aceeași buclă, pas cu pas:

Pasul buclei	Panou bazat doar pe convenții (agentul mută un card și comentează)	Ce impune Weft și cu ce instrument MCP
Alegerea muncii	Agentul listează sarcinile și alege. Nimic nu-i spune că omul e deja îngropat în revizuiri.	`get_my_work` întoarce ce deține deja acest client, ce așteaptă după om, ce e întârziat și dacă există loc să înceapă ceva.
Revendicarea	Mută cardul în Doing și postează „Revendicat”. Doi agenți pot face asta în același moment și amândoi cred că îl dețin.	`start_task` ia un leasing de 20 de minute printr-o singură scriere în baza de date, păzită de un index unic. Cel care pierde primește `already_claimed`, cu id-ul și titlul sarcinii.
Rămânerea în viață	Comentarii de progres, dacă agentul își amintește. Un agent prăbușit lasă un card în Doing pe termen nelimitat.	`report_progress` reînnoiește leasingul (agentului i se spune să facă asta la fiecare 5 minute). După 20 de minute de tăcere, rularea e marcată ca expirată și sarcina e din nou liberă.
Întrebarea	Un comentariu „Blocat:”. Agentul se oprește sau ghicește; cardul poate părea în continuare în lucru.	`request_input` pune o întrebare cu până la 10 variante în Inboxul omului și păstrează revendicarea (60 de minute cât e parcată). Răspunsul se întoarce prin `start_task` sau `get_my_work`.
Raportarea	Un comentariu final în text liber. Forma lui depinde de cât de bun a fost promptul.	`complete_task` primește câmpuri cu nume: `outcome`, `artifacts`, `notDone`, `unknowns`, `nextStep`.
Închiderea sau revizuirea	Agentul mută cardul în Review sau Done, după cum a spus promptul.	Implicit, sarcina merge în Done. Se oprește în Inbox pentru Acceptă / Refă / Mai târziu / Renunță când are nevoie de revizuire sau când o verificare eșuează.
Supraîncărcarea	Nimic. Agenții tot încep muncă, iar coloana Review crește.	`start_task` refuză cu `attention_queue_full` odată ce 5 elemente (o persoană) sau 10 (echipă) așteaptă după oameni, ori 45 de minute de revizuire.

Ca să fim corecți cu Hypertask: are leasing real. Documentația lui listează endpointuri pentru revendicarea leasingului, semnalul de viață și eliberare, iar tabelul Known limitations spune că leasingul sarcinilor, dovezile și escaladarea sunt doar endpointuri REST, intenționat (prezentarea MCP Hypertask). Referința instrumentelor nu are niciun instrument de leasing printre cele 21 de instrumente MCP (referința instrumentelor). Și CLI-ul poate revendica, ca o comandă opțională (changelog, referință CLI). Așadar, un agent scriptat pe Hypertask poate ține un leasing; un agent care lucrează prin MCP în Claude Code sau Cursor primește varianta cu card și comentariu, dacă nu leagă cineva apelurile REST.

Dacă agenții tăi rulează ca scripturi și joburi CI, CLI-ul și API-ul REST ale Hypertask sunt un avantaj real, iar Weft nu le are pe niciunul: nici CLI, nici API REST public, nici webhookuri. Weft e pentru agenți care trăiesc într-un client MCP și au nevoie ca bucla să țină acolo.

Ce vede omul?

De cele mai multe ori, un card în Done: implicit, o sarcină finalizată merge direct acolo, cu rezultatul și dovezile atașate.

O sarcină se oprește în Inboxul omului când a fost marcată ca având nevoie de revizuire sau când o verificare eșuează. Acolo omul alege unul dintre patru răspunsuri:

Acceptă: munca rămâne. Dacă agentul a trimis un nextStep, omul îl vede deasupra butonului („Dacă accepți, agentul va …”), iar acceptarea aprobă exact acel pas, nimic mai larg. Aprobarea e valabilă 72 de ore și se întoarce la agent prin get_my_work sau start_task.
Refă: trimite-o înapoi, cu o notă care spune ce e greșit.
Mai târziu: nu acum. Renunță: nu se mai lucrează la ea.

Inboxul e pe web, iar când ceva intră în el, omul primește și o notificare push în aplicația mobilă Weft. Schimbul de tip nextStep îl împiedică pe agent să trateze „arată bine” ca permisiune să facă merge, deploy și să trimită: poate face pasul aprobat, apoi finalizează din nou sarcina.

De ce e refuzat agentul în loc să înceapă mai multă muncă?

Pentru că atenția, nu munca, e resursa rară. Un agent poate începe zece lucruri în timpul în care un om revizuiește unul.

Weft numără ce așteaptă după oameni: sarcinile care așteaptă revizuire plus întrebările deschise. Când asta ajunge la 5 elemente într-un spațiu de lucru de o persoană, 10 într-o echipă sau cam 45 de minute de revizuire estimată, oricare vine primul, start_task refuză cu attention_queue_full. Limita depinde de câți oameni sunt în spațiul de lucru, nu de plan.

Refuzul e o instrucțiune, nu o fundătură. Raportează mărimea cozii, vechimea celui mai vechi element și apelurile încă permise: report_progress, get_my_work, get_board_state și search. Un pas pe care omul l-a aprobat deja pe acel card e exceptat, așa că un „merge PR #418” acceptat nu e blocat de coadă.

Cum configurez asta?

Conectează-ți clientul și autentifică-te prin browser; nu ai nicio cheie de copiat. Weft emite refresh tokenuri, așa că clientul își reînnoiește singur autentificarea. În Claude Code e o singură comandă, claude mcp add --transport http weft https://letsweft.com/api/mcp (pagina de configurare). Cursor are instalare cu un clic (Cursor), Codex are nevoie de o intrare de configurare și de codex mcp login weft (Codex), iar ChatGPT are o aplicație Weft publicată, pe orice plan, inclusiv Free (ChatGPT). Serverul îi descrie singur bucla agentului, așa că nu e nevoie de niciun prompt despre ciclul de viață.

Pentru un ghid pas cu pas în Claude Code, vezi un panou de sarcini pentru Claude Code. Pentru mai mulți agenți pe un singur panou, unde leasingul și already_claimed contează cel mai mult, vezi mai mulți agenți AI, un singur panou. Protocolul însuși e documentat la modelcontextprotocol.io, iar alte panouri MCP sunt comparate pe manageri de sarcini MCP.

Ce nu face Weft aici?

Nu are CLI, API REST public sau webhookuri, așa că joburile cron și pipelineurile CI nu pot conduce bucla în afara unui client MCP.
Nu are integrare cu GitHub sau Slack. Dovezile sunt ce leagă agentul în artifacts.
Nu are AI integrat. Gândirea se petrece în propriul tău client AI, și tot de aceea Weft nu are nevoie de credite AI.

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 (prețuri).

Nu e de ajuns un prompt bun ca agenții să respecte bucla?: Un prompt descrie bucla; nu o poate impune. Nu-i oprește pe doi agenți să revendice aceeași sarcină și nu poate elibera o sarcină ținută de un agent care s-a prăbușit. În Weft, revendicarea e un leasing deținut de server, așa că aceste cazuri sunt tratate indiferent dacă agentul și-a amintit sau nu instrucțiunile.
Ce se întâmplă dacă agentul meu se prăbușește la jumătatea drumului?: Semnalele lui de viață se opresc. La douăzeci de minute după ultimul report_progress, rularea e marcată ca expirată, tokenul de leasing e șters și sarcina e din nou neatribuită, așa că o poate prelua alt agent sau un om. Cardul nu stă o săptămână în Doing.
Fiecare sarcină terminată așteaptă să o revizuiesc?: Nu. Implicit, o sarcină finalizată merge direct în Done, cu rezultatul și dovezile. Se oprește în Inboxul tău pentru Acceptă, Refă, Mai târziu sau Renunță doar când sarcina are nevoie de revizuire sau când o verificare eșuează.
De ce aș vrea ca agentului meu să i se refuze munca?: Pentru că altfel continuă să producă lucruri pe care n-ai timp să le verifici. Odată ce 5 elemente (10 pentru o echipă) sau cam 45 de minute de revizuire așteaptă după oameni, start_task întoarce attention_queue_full și îi arată agentului ce mai poate face. Golirea cozii îl deblochează.
Și Hypertask are leasing. De ce contează MCP?: Leasingul Hypertask e format din endpointuri REST, conform propriei documentații (prezentare MCP), iar CLI-ul lui poate și el revendica. Asta li se potrivește agenților scriptați. Un agent care lucrează prin instrumente MCP într-un editor sau chat nu le primește acolo, iar în Weft le primește: start_task, report_progress și complete_task sunt instrumente MCP.