Gestione delle attività degli agenti IA: il ciclo di presa in carico come contratto, non come prompt

La gestione delle attività degli agenti IA funziona quando è la bacheca, non il prompt, a governare il ciclo: l’agente chiede cosa fare, prende in carico un’attività con un lease che scade se tace, chiede alla persona solo le decisioni che spettano a lei e finisce con una ricevuta che qualcuno può controllare. In Weft ognuno di questi passi è uno strumento MCP verificato dal server, quindi un agente che salta un passo viene rifiutato o perde l’attività invece di andare silenziosamente fuori sincronia.

Weft lo facciamo noi. Le informazioni sugli altri prodotti vengono dalle loro pagine ufficiali, verificate il 27 ottobre 2026.

Perché una lista di attività incollata in chat smette di funzionare?

Incollare le attività in una chat è la prima cosa che provano tutti, e per un pomeriggio funziona. Poi la chat finisce, e lo stato finisce con lei. L’agente sapeva quale elemento aveva finito, a quale aveva rinunciato e su cosa non era sicuro. Adesso non lo sa più nessuno.

Chi ha incollato la lista diventa il ripetitore, che ricopia i risultati sulla bacheca vera e rifà il lavoro che una seconda sessione aveva preso perché niente diceva che fosse già preso.

L’accesso alla bacheca risolve il problema dell’istantanea, non il resto. Se gli unici strumenti sono “sposta scheda” e “aggiungi commento”, il ciclo dipende ancora dal fatto che l’agente segua una convenzione scritta nelle sue istruzioni. Le convenzioni si rompono proprio quando le cose vanno storte: l’agente va in crash a metà, o due agenti partono nello stesso istante.

Com’è fatto il ciclo di presa in carico come contratto?

In Weft il ciclo ha cinque passi, e ognuno è uno strumento separato su un unico endpoint MCP, https://letsweft.com/api/mcp. Il server tiene lo stato tra un passo e l’altro, quindi il ciclo sopravvive alla fine di qualsiasi chat.

1. get_my_work: chiedi prima di scegliere. La risposta copre cosa ha già in mano questo client, cosa aspetta la persona, cosa è scaduto o in scadenza e se c’è spazio per iniziare qualcosa.
2. start_task: prendi in carico con un lease. La presa in carico dura 20 minuti e sposta l’attività in Doing. La risposta contiene un runId, un leaseToken e renewEverySeconds: 300. Un secondo client che prova la stessa attività riceve already_claimed e l’indicazione di non duplicare il lavoro.
3. report_progress: il segnale di vita. Ogni chiamata con l’id dell’esecuzione e il lease token rinnova il lease. Se l’agente muore, i segnali si fermano, e 20 minuti dopo l’esecuzione viene marcata come scaduta e l’attività torna non assegnata, a disposizione di chiunque. Un lease perso risponde lease_lost, così l’agente sa che il lavoro non è più suo.
4. request_input: solo per le decisioni che spettano alla persona. Una domanda fino a 500 caratteri, con un massimo di 10 opzioni. La presa in carico resta mentre l’agente aspetta.
5. complete_task: finisci con una ricevuta. outcome, artifacts (prove come un URL, un commit o un hash di file), notDone, unknowns e nextStep.

Perché un lease e non uno stato? Perché il silenzio è l’unico segnale che un agente in crash può mandare. Una scheda in Doing dice che qualcuno ci stava lavorando, una volta. Un lease dice che qualcuno ci sta lavorando adesso, e smette di dirlo da solo quando non è più vero.

La presa in carico in sé è un singolo inserimento nel database protetto da un indice univoco. Quando due agenti fanno a gara, decide il database chi vince, quindi non possono ottenere l’attività entrambi. Due commenti “Preso” pubblicati a un secondo di distanza, invece, sono entrambi commenti validi.

Quando dovrebbe chiamare request_input l’agente?

Quando arriva a qualcosa che solo la persona può decidere: tutto ciò che è irreversibile, come soldi, pubblicazione, produzione o questioni legali, o un vero bivio senza un’opzione predefinita ragionevole. Non per chiedere il permesso di andare avanti.

Questa misura conta perché una domanda costa alla persona la stessa attenzione di un’attività finita, e in Weft conta nello stesso limite. La domanda arriva nella Inbox, con una notifica push sul telefono e, per gli elementi in attesa da 20 minuti o più, un promemoria via email. Weft non richiama mai l’agente: la risposta arriva al suo start_task o get_my_work successivo. Finché la domanda è aperta, l’agente tiene l’attività per 60 minuti; dopo il lease cade, ma la domanda resta.

Cosa va in una chiamata a complete_task?

Un esito breve, delle prove e un resoconto onesto dei punti incerti. Ecco un payload realistico per la correzione di un 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"
}

Gli artifacts sono cose che la persona può controllare senza doversi fidare della parola dell’agente. notDone e unknowns non sono confessioni; separano un risultato su cui puoi contare da uno che devi ricostruire dal diff. La chiamata non fallisce mai per mancanza di prove, perché perdere lavoro finito è peggio che registrarlo non verificato. Di più su come leggere queste ricevute in cosa ha fatto il mio agente IA.

In cosa è diverso dallo spostare una scheda e scrivere un commento?

La guida di Hypertask allo stesso ciclo (prendere in carico, aggiornare, riferire, chiudere) descrive bene l’abitudine. La sua versione MCP della presa in carico consiste nel caricare l’attività, spostarla nella sezione di lavoro e scrivere un commento di presa in carico, seguendo un prompt che il team scrive nelle istruzioni dell’agente. Ecco lo stesso ciclo passo per passo:

Per essere onesti con Hypertask: i lease veri li ha. La sua documentazione elenca endpoint per prendere in carico, mantenere vivo e rilasciare un lease, e la sua tabella delle limitazioni note dice che lease delle attività, prove ed escalation sono solo endpoint REST, per scelta (panoramica MCP di Hypertask). Il suo riferimento strumenti non ha nessuno strumento per i lease tra i suoi 21 strumenti MCP (riferimento strumenti). Anche la sua CLI può prendere in carico, con un comando facoltativo (changelog, riferimento CLI). Quindi un agente scriptato su Hypertask può tenere un lease; un agente che lavora tramite MCP in Claude Code o Cursor ottiene la versione con scheda e commento, a meno che qualcuno non colleghi le chiamate REST.

Se i tuoi agenti girano come script e job di CI, la CLI e l’API REST di Hypertask sono un vantaggio reale, e Weft non ha né l’una né l’altra: niente CLI, niente API REST pubblica, niente webhook. Weft è per gli agenti che vivono dentro un client MCP e hanno bisogno che il ciclo tenga lì.

Cosa vede la persona?

Il più delle volte, una scheda in Done: per impostazione predefinita un’attività completata ci va direttamente, con esito e prove allegati.

Un’attività si ferma nella Inbox della persona quando è stata segnata come da rivedere, o quando un controllo di verifica fallisce. Lì la persona sceglie una di quattro risposte:

• Accetta: il lavoro regge. Se l’agente ha passato un nextStep, la persona lo vede sopra il pulsante (“Se accetti, l’agente farà questo”), e accettare approva esattamente quel passo, niente di più ampio. L’approvazione vale 72 ore e torna all’agente tramite get_my_work o start_task.
• Rifai: rimandala indietro, con una nota che dice cosa non va.
• Più tardi: non adesso. Scarta: smetti di lavorarci.

La Inbox è sul web, e quando ci entra qualcosa la persona riceve anche una notifica push sull’app mobile di Weft. Lo scambio sul nextStep impedisce a un agente di trattare un “sembra a posto” come permesso di fare merge, deploy e invio: può fare l’unico passo approvato, poi completare di nuovo l’attività.

Perché l’agente viene rifiutato invece di iniziare altro lavoro?

Perché la risorsa scarsa è l’attenzione, non il lavoro. Un agente può iniziare dieci cose nel tempo in cui una persona ne rivede una.

Weft conta ciò che aspetta le persone: attività in attesa di revisione più domande aperte. Quando si arriva a 5 elementi in uno spazio di lavoro di una persona, 10 in un team, o circa 45 minuti di revisione stimata, quale arriva prima, start_task rifiuta con attention_queue_full. Il limite dipende da quante persone ci sono nello spazio di lavoro, non dal piano.

Il rifiuto è un’istruzione, non un vicolo cieco. Riporta la dimensione della coda, l’età dell’elemento più vecchio e le chiamate ancora permesse: report_progress, get_my_work, get_board_state e search. Un passo che la persona ha già approvato su quella scheda è esente, quindi un “fare il merge della PR #418” accettato non viene bloccato dalla coda.

Come lo configuro?

Collega il tuo client e accedi dal browser; non c’è nessuna chiave da copiare. Weft rilascia refresh token, quindi il client rinnova l’accesso da solo. In Claude Code basta un comando, claude mcp add --transport http weft https://letsweft.com/api/mcp (pagina di configurazione). Cursor si installa con un clic (Cursor), Codex richiede una voce di configurazione e codex mcp login weft (Codex), e ChatGPT ha un’app Weft pubblicata su ogni piano, gratuito compreso (ChatGPT). È il server stesso a descrivere il ciclo all’agente, quindi non serve nessun prompt sul ciclo di vita.

Per una guida passo passo con Claude Code vedi una bacheca di attività per Claude Code. Per più agenti su una bacheca, dove lease e already_claimed contano di più, vedi più agenti IA, una sola bacheca. Il protocollo stesso è documentato su modelcontextprotocol.io, e le altre bacheche MCP sono confrontate in task manager MCP.

Cosa non fa Weft qui?

• Niente CLI, API REST pubblica o webhook, quindi cron job e pipeline di CI non possono guidare il ciclo fuori da un client MCP.
• Nessuna integrazione con GitHub o Slack. Le prove sono ciò che l’agente collega negli artifacts.
• Nessuna IA integrata. Il ragionamento avviene nel tuo client IA, ed è anche per questo che Weft non ha bisogno di crediti IA.

Il gratuito copre 50 attività e 200 chiamate IA al mese. Pro costa 7 $ per postazione al mese o 60 $ per postazione all’anno (prezzi).

Un buon prompt non basta a far seguire il ciclo agli agenti?

Un prompt descrive il ciclo; non può imporlo. Non impedisce a due agenti di prendere la stessa attività, e non può liberare un’attività tenuta da un agente andato in crash. In Weft la presa in carico è un lease di proprietà del server, quindi questi casi sono gestiti che l’agente si ricordi o no le sue istruzioni.

Cosa succede se il mio agente va in crash a metà?

I suoi segnali di vita si fermano. Venti minuti dopo l’ultimo report_progress l’esecuzione viene marcata come scaduta, il lease token viene cancellato e l’attività torna non assegnata, così un altro agente o una persona può prenderla. La scheda non resta in Doing per una settimana.

Ogni attività finita aspetta che io la riveda?

No. Per impostazione predefinita un’attività completata va direttamente in Done con esito e prove. Si ferma nella tua Inbox per Accetta, Rifai, Più tardi o Scarta solo quando richiede una revisione o un controllo di verifica fallisce.

Perché dovrei volere che il mio agente venga rifiutato?

Perché altrimenti continua a produrre cose che non hai tempo di controllare. Quando 5 elementi (10 per un team) o circa 45 minuti di revisione aspettano le persone, start_task restituisce attention_queue_full e indica all’agente cosa può ancora fare. Svuotare la coda lo sblocca.

Anche Hypertask ha i lease. Perché conta MCP?

I lease di Hypertask sono endpoint REST, per sua stessa documentazione (panoramica MCP), e anche la sua CLI può prendere in carico. Va bene per gli agenti scriptati. Un agente che lavora con strumenti MCP in un editor o in una chat lì non li ottiene, in Weft sì: start_task, report_progress e complete_task sono strumenti MCP.