No n'hi ha prou amb una bona instrucció perquè els agents segueixin el cicle?

Una instrucció descriu el cicle; no el pot fer complir. No impedeix que dos agents reclamin la mateixa tasca, i no pot alliberar una tasca retinguda per un agent que ha caigut. A Weft la reclamació és un arrendament que gestiona el servidor, així que aquests casos es resolen tant si l'agent recorda les seves instruccions com si no.

Què passa si el meu agent cau a mitja feina?

Els seus senyals de vida s'aturen. Vint minuts després de l'últim report_progress, l'execució es marca com a caducada, el token de l'arrendament s'esborra i la tasca torna a quedar sense assignar, de manera que un altre agent o una persona la pot agafar. La targeta no es queda una setmana a Doing.

Totes les tasques acabades esperen que les revisi?

No. Per defecte, una tasca completada va directament a Done amb el resultat i les proves. Només s'atura a la teva safata d'entrada per a Accept, Rework, Later o Drop quan la tasca necessita revisió o falla una comprovació de verificació.

Per què voldria que el meu agent rebés negatives?

Perquè, si no, continua produint coses que no tens temps de revisar. Quan hi ha 5 elements (10 en un equip) o uns 45 minuts de revisió esperant les persones, start_task retorna attention_queue_full i indica a l'agent què pot fer encara. Buidar la cua el desbloqueja.

Hypertask també té arrendaments. Per què importa MCP?

Els arrendaments de Hypertask són endpoints REST, segons la seva pròpia documentació (MCP overview), i la seva CLI també pot reclamar. Això va bé per a agents amb scripts. Un agent que treballa amb eines MCP en un editor o un xat no els hi té, i a Weft sí: start_task, report_progress i complete_task són eines MCP.

Blog

Gestió de tasques d'agents d'IA: el cicle de reclamació com a contracte, no com a instrucció

Com gestionar les tasques dels agents d'IA amb un cicle de reclamació que fa complir el servidor: arrendaments, senyals de vida, preguntes, comprovants i un límit a l'atenció humana.

Weft és el gestor de tasques amb IA per a fundadors en solitari i equips petits.

Tots els articles

Per Andrei Finogeev · 27 d’octubre del 2026

La gestió de tasques d'agents d'IA funciona quan el cicle és cosa del tauler i no de la instrucció: l'agent pregunta què ha de fer, reclama una tasca amb un arrendament que caduca si deixa de donar senyals, només pregunta a la persona les decisions que li corresponen i acaba amb un comprovant que algú pot verificar. A Weft, cadascun d'aquests passos és una eina MCP que el servidor comprova, de manera que un agent que se salta un pas rep una negativa o perd la tasca, en lloc de desincronitzar-se en silenci.

Weft és nostre. Les dades sobre altres productes provenen de les seves pàgines oficials, consultades el 27 d'octubre de 2026.

Per què deixa de funcionar una llista de tasques enganxada al xat?

Enganxar tasques en un xat és el primer que prova tothom, i funciona una tarda. Després el xat s'acaba, i l'estat s'acaba amb ell. L'agent sabia quin element havia acabat, a quin havia renunciat i de què no estava segur. Ara no ho sap ningú.

La persona que va enganxar la llista es converteix en el pont: copia els resultats al tauler de veritat i torna a fer la feina que una segona sessió ha agafat perquè res no deia que ja estava presa.

Donar accés al tauler resol el problema de la foto fixa, però no la resta. Si les úniques eines són «moure targeta» i «afegir comentari», el cicle continua depenent que l'agent segueixi una convenció escrita a les seves instruccions. Les convencions fallen just quan les coses van malament: l'agent falla a mitja execució, o dos agents comencen en el mateix moment.

Com és el cicle de reclamació entès com a contracte?

A Weft el cicle té cinc passos, i cadascun és una eina diferent en un sol endpoint MCP, https://letsweft.com/api/mcp. El servidor guarda l'estat entre un pas i l'altre, de manera que el cicle sobreviu al final de qualsevol xat.

get_my_work: preguntar abans de triar. La resposta inclou què té ja aquest client, què està esperant la persona, què ha vençut o venç aviat, i si hi ha espai per començar res.
start_task: reclamar amb un arrendament. La reclamació dura 20 minuts i mou la tasca a Doing. La resposta porta un runId, un leaseToken i renewEverySeconds: 300. Un segon client que provi d'agafar la mateixa tasca rep already_claimed i un avís perquè no dupliqui la feina.
report_progress: el senyal de vida. Cada crida amb l'identificador de l'execució i el token de l'arrendament renova l'arrendament. Si l'agent cau, els senyals s'aturen i, 20 minuts després, l'execució es marca com a caducada i la tasca torna a quedar sense assignar perquè l'agafi qualsevol. Un arrendament perdut respon lease_lost, així l'agent sap que la feina ja no és seva.
request_input: només per a decisions que corresponen a la persona. Una pregunta de fins a 500 caràcters, amb fins a 10 opcions. La reclamació es manté mentre l'agent espera.
complete_task: acabar amb un comprovant. outcome, artifacts (proves com un URL, un commit o un hash de fitxer), notDone, unknowns i nextStep.

Per què un arrendament i no un estat? Perquè el silenci és l'únic senyal que pot enviar un agent que ha caigut. Una targeta a Doing diu que algú hi va treballar un dia. Un arrendament diu que algú hi està treballant ara, i deixa de dir-ho tot sol quan ja no és cert.

La reclamació en si és una sola inserció a la base de dades protegida per un índex únic. Quan dos agents competeixen, la base de dades decideix qui guanya, així que no poden aconseguir la tasca tots dos. En canvi, dos comentaris «Reclamada» publicats amb un segon de diferència són tots dos comentaris vàlids.

Quan hauria de cridar l'agent request_input?

Quan arriba a alguna cosa que només pot decidir la persona: qualsevol cosa irreversible, com diners, publicació, producció o temes legals, o una bifurcació real sense cap opció per defecte raonable. No per demanar permís per continuar.

Aquesta contenció és important perquè una pregunta costa a la persona la mateixa atenció que una tasca acabada, i a Weft compta per al mateix límit. La pregunta arriba a la safata d'entrada, amb una notificació push al mòbil i, per als elements que fa 20 minuts o més que esperen, un correu de recordatori. Weft no torna a cridar mai l'agent: la resposta li arriba al següent start_task o get_my_work. Mentre la pregunta és oberta, l'agent conserva la tasca durant 60 minuts; després l'arrendament cau, però la pregunta es manté.

Què va en una crida a complete_task?

Un resultat breu, proves i un relat honest dels límits. Aquí tens un contingut realista per a la correcció d'un error:

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

Els artefactes són coses que la persona pot comprovar sense haver de creure's l'agent. notDone i unknowns no són confessions; separen un resultat del qual et pots refiar d'un que has de reconstruir a partir del diff. La crida no falla mai per falta de proves, perquè perdre feina acabada és pitjor que registrar-la sense verificar. Més informació sobre com llegir aquests comprovants a què ha fet el meu agent d'IA.

En què es diferencia de moure una targeta i publicar un comentari?

La guia de Hypertask sobre el mateix cicle (reclamar, actualitzar, informar, tancar) descriu bé l'hàbit. La seva versió MCP d'una reclamació consisteix a carregar la tasca, moure-la a la secció de feina en curs i publicar un comentari de reclamació, seguint una instrucció que l'equip escriu a les instruccions de l'agent. Aquí tens el mateix cicle pas a pas:

Pas del cicle	Tauler només amb convencions (l'agent mou una targeta i comenta)	Què fa complir Weft, i amb quina eina MCP
Triar feina	L'agent llista les tasques i en tria una. Res no li diu que la persona ja està col·lapsada de revisions.	`get_my_work` retorna què té ja aquest client, què espera la persona, què ha vençut i si hi ha espai per començar res.
Reclamar	Moure la targeta a Doing i publicar «Reclamada». Dos agents poden fer-ho en el mateix moment i tots dos creure que és seva.	`start_task` pren un arrendament de 20 minuts en una sola escriptura a la base de dades protegida per un índex únic. Qui perd rep `already_claimed` amb l'identificador i el títol de la tasca.
Mantenir-se viu	Comentaris de progrés, si l'agent se'n recorda. Un agent que cau deixa una targeta a Doing indefinidament.	`report_progress` renova l'arrendament (a l'agent se li diu que ho faci cada 5 minuts). Després de 20 minuts de silenci, l'execució es marca com a caducada i la tasca torna a quedar lliure.
Preguntar	Un comentari «Bloquejada:». L'agent s'atura o endevina; és possible que la targeta encara sembli en curs.	`request_input` posa una pregunta amb fins a 10 opcions a la safata d'entrada de la persona i manté la reclamació (60 minuts mentre està aparcada). La resposta torna a través de `start_task` o `get_my_work`.
Informar	Un comentari final de text lliure. La forma que té depèn de com era de bona la instrucció.	`complete_task` rep camps amb nom: `outcome`, `artifacts`, `notDone`, `unknowns`, `nextStep`.
Tancar o revisar	L'agent mou la targeta a Review o a Done, segons el que digués la instrucció.	Per defecte, la tasca va a Done. S'atura a la safata d'entrada per a Accept / Rework / Later / Drop quan la tasca necessita revisió o falla una comprovació de verificació.
Sobrecàrrega	Res. Els agents continuen començant feina i la columna Review creix.	`start_task` es nega amb `attention_queue_full` quan hi ha 5 elements (una persona) o 10 (equip) esperant les persones, o 45 minuts de revisió.

Per ser justos amb Hypertask: sí que té arrendaments reals. La seva documentació llista endpoints per reclamar, mantenir viu i alliberar arrendaments, i la seva taula de Known limitations diu que els arrendaments de tasques, les proves i l'escalat són només endpoints REST, per disseny (Hypertask MCP overview). La seva referència d'eines no inclou cap eina d'arrendament entre les seves 21 eines MCP (tools reference). La seva CLI també pot reclamar, com a ordre opcional (changelog, CLI reference). Així, un agent amb scripts a Hypertask pot tenir un arrendament; un agent que treballa a través de MCP a Claude Code o Cursor es queda amb la versió de targeta i comentari, tret que algú hi connecti les crides REST.

Si els teus agents funcionen com a scripts i tasques de CI, la CLI i l'API REST de Hypertask són un avantatge real, i Weft no té ni l'una ni l'altra: ni CLI, ni API REST pública, ni webhooks. Weft és per a agents que viuen dins d'un client MCP i necessiten que el cicle s'hi aguanti.

Què veu la persona?

La major part del temps, una targeta a Done: per defecte, una tasca completada hi va directament amb el resultat i les proves adjuntes.

Una tasca s'atura a la safata d'entrada de la persona quan s'ha marcat com a pendent de revisió o quan falla una comprovació de verificació. Allà la persona tria una de quatre respostes:

Accept: la feina es dona per bona. Si l'agent ha indicat un nextStep, la persona el veu damunt del botó («Si acceptes, l'agent…»), i acceptar aprova exactament aquell pas, res més ampli. L'aprovació és vàlida durant 72 hores i torna a l'agent a través de get_my_work o start_task.
Rework: tornar-la enrere, amb una nota que digui què falla.
Later: ara no. Drop: deixar de treballar-hi.

La safata d'entrada és al web, i quan hi entra alguna cosa la persona també rep una notificació push a l'aplicació mòbil de Weft. L'encaixada del nextStep evita que un agent prengui un «sembla correcte» com a permís per fusionar, desplegar i enviar: pot fer l'únic pas aprovat i després tornar a completar la tasca.

Per què es nega feina a l'agent en lloc de deixar-lo començar-ne més?

Perquè el recurs escàs és l'atenció, no la feina. Un agent pot començar deu coses en el temps que una persona en revisa una.

Weft compta què està esperant les persones: tasques pendents de revisió més preguntes obertes. Quan arriba a 5 elements en un espai de treball d'una persona, a 10 en un d'equip o a uns 45 minuts de temps de revisió estimat, el que passi primer, start_task es nega amb attention_queue_full. El límit depèn de quantes persones hi ha a l'espai de treball, no del pla.

La negativa és una instrucció, no un carreró sense sortida. Informa de la mida de la cua, de l'antiguitat de l'element més antic i de les crides que encara es permeten: report_progress, get_my_work, get_board_state i search. Un pas que la persona ja ha aprovat en aquella targeta n'està exempt, així que un «merge PR #418» acceptat no queda bloquejat per la cua.

Com ho configuro?

Connecta el teu client i inicia sessió pel navegador; no hi ha cap clau per copiar. Weft emet tokens de renovació, de manera que el client renova la sessió tot sol. A Claude Code és una sola ordre, claude mcp add --transport http weft https://letsweft.com/api/mcp (pàgina de configuració). Cursor té una instal·lació d'un clic (Cursor), Codex necessita una entrada de configuració i codex mcp login weft (Codex), i ChatGPT té una aplicació de Weft publicada en tots els plans, inclòs el Free (ChatGPT). El servidor mateix descriu el cicle a l'agent, així que no cal cap instrucció sobre el cicle de vida.

Per a un recorregut amb Claude Code, consulta un tauler de tasques per a Claude Code. Per a diversos agents en un mateix tauler, on els arrendaments i already_claimed són més importants, consulta diversos agents d'IA, un sol tauler. El protocol en si està documentat a modelcontextprotocol.io, i altres taulers MCP es comparen a gestors de tasques MCP.

Què no fa Weft en aquest cas?

No té CLI, API REST pública ni webhooks, així que les tasques cron i els pipelines de CI no poden portar el cicle fora d'un client MCP.
No té integració amb GitHub ni Slack. Les proves són el que l'agent enllaci als artefactes.
No té IA integrada. El raonament passa al teu propi client d'IA, i per això Weft tampoc no necessita crèdits d'IA.

El pla Free inclou 50 tasques i 200 crides d'IA al mes. Pro costa 7,87 € per persona al mes o 66,55 € per persona l'any (preus).

No n'hi ha prou amb una bona instrucció perquè els agents segueixin el cicle?: Una instrucció descriu el cicle; no el pot fer complir. No impedeix que dos agents reclamin la mateixa tasca, i no pot alliberar una tasca retinguda per un agent que ha caigut. A Weft la reclamació és un arrendament que gestiona el servidor, així que aquests casos es resolen tant si l'agent recorda les seves instruccions com si no.
Què passa si el meu agent cau a mitja feina?: Els seus senyals de vida s'aturen. Vint minuts després de l'últim report_progress, l'execució es marca com a caducada, el token de l'arrendament s'esborra i la tasca torna a quedar sense assignar, de manera que un altre agent o una persona la pot agafar. La targeta no es queda una setmana a Doing.
Totes les tasques acabades esperen que les revisi?: No. Per defecte, una tasca completada va directament a Done amb el resultat i les proves. Només s'atura a la teva safata d'entrada per a Accept, Rework, Later o Drop quan la tasca necessita revisió o falla una comprovació de verificació.
Per què voldria que el meu agent rebés negatives?: Perquè, si no, continua produint coses que no tens temps de revisar. Quan hi ha 5 elements (10 en un equip) o uns 45 minuts de revisió esperant les persones, start_task retorna attention_queue_full i indica a l'agent què pot fer encara. Buidar la cua el desbloqueja.
Hypertask també té arrendaments. Per què importa MCP?: Els arrendaments de Hypertask són endpoints REST, segons la seva pròpia documentació (MCP overview), i la seva CLI també pot reclamar. Això va bé per a agents amb scripts. Un agent que treballa amb eines MCP en un editor o un xat no els hi té, i a Weft sí: start_task, report_progress i complete_task són eines MCP.