Blog

Cosa ha fatto il mio agente IA? Quattro domande a cui rispondere con le prove

Per ogni attività di un agente IA dovresti vedere chi l’ha fatta, cosa è cambiato, cosa è stato saltato e perché, con prove verificabili invece di un commento “fatto”.

Weft è il gestore di attività con IA per chi fonda da solo e i piccoli team.

Tutti gli articoli

Di Andrei Finogeev ·

Per sapere cosa ha fatto il tuo agente IA, non partire dal suo riepilogo. Controlla quattro cose: quale connessione ha fatto il lavoro, cosa è cambiato (mostrato da qualcosa che puoi aprire tu), cosa è rimasto da fare e cosa è stato deciso e perché. Se anche solo una delle quattro si regge sulla parola dell’agente, hai un racconto, non un registro.

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

Perché non basta un commento che dice “fatto”?

Un commento è l’agente che descrive il proprio lavoro. Può darsi che sia preciso, ma il commento non può dimostrarlo, perché l’autore è proprio la parte che stai cercando di controllare. Sapere che un agente ha toccato un’attività risponde a chi. Non risponde alla domanda se il lavoro è quello che pensi.

L’articolo di Hypertask sull’attribuzione del lavoro dell’IA fa un’osservazione giusta: il lavoro degli agenti dovrebbe finire sulla stessa bacheca del lavoro umano, non in un log del terminale che nessuno legge. Hypertask dà anche agli agenti un’identità propria come account di servizio, così le modifiche sono attribuite all’agente invece che a te, e ha prove e lease per le attività, anche se la sua documentazione dice che sono solo endpoint REST, non strumenti MCP, per scelta. Dove la pensiamo diversamente è su cosa dovrebbe contenere il registro. Un thread di commenti con l’output dell’agente è un log di ciò che l’agente ha detto. Noi vogliamo che il registro contenga delle prove.

In questa guida non ci sono numeri da sondaggi. Puoi provare le quattro domande sulla tua bacheca oggi pomeriggio, e ti dirà di più di una media di settore.

Quali sono le quattro domande?

Prendi un’attività qualsiasi che un agente ha finito la settimana scorsa. Dovresti riuscire a rispondere a ciascuna di queste in meno di un minuto, senza chiedere all’agente né aprire la sua chat:

  1. Chi l’ha fatta? Quale client, su quale connessione, ha preso in carico e finito l’attività.
  2. Cosa è cambiato? L’esito, più artifacts che puoi controllare senza fidarti dell’agente: l’hash di un commit, un URL, un file, l’id di un messaggio.
  3. Cosa non è stato fatto? Le parti che ha saltato e le cose su cui non era sicuro.
  4. Cosa è stato deciso, e perché? Ogni scelta fatta lungo il percorso, con le opzioni valutate, e ogni volta che hai rimandato indietro il lavoro.
DomandaRisposta debole: un commento che dice “fatto”Risposta forte: prove che puoi controllare
Chi l’ha fatta?“Agente” o il tuo nome su ogni modifica, perché tutti gli strumenti condividono una chiaveLa connessione che ha preso in carico e finito l’attività, con il nome con cui si è registrato il client, e ogni evento della cronologia marcato come persona o MCP con l’id del client
Cosa è cambiato?“Rifattorizzato il modulo di autenticazione, i test passano”L’hash di un commit, l’URL di una PR o di una pagina, un file con il suo sha256, l’id di un messaggio: qualcosa che apri tu
Cosa non è stato fatto?Non viene detto niente, quindi presumi che non sia stato saltato nienteUn elenco notDone (“non ho eseguito la migrazione su staging”) e un elenco unknowns (“non sono sicuro che il vecchio endpoint non abbia altri chiamanti”)
Cosa è stato deciso, e perché?Sepolto in una chat che nel frattempo è scivolata viaUn registro di decisione con le opzioni valutate e la condizione per riconsiderarla, più la cronologia delle decisioni sull’attività, compreso il motivo per cui è stata rimandata indietro

Come so quale agente l’ha fatta?

Weft si collega ai client IA tramite il Model Context Protocol su un unico endpoint, https://letsweft.com/api/mcp. Ogni client OAuth e ogni token di accesso personale è un attore a sé. Un’attività registra quale client l’ha creata, e la bacheca mostra il nome con cui quel client si è registrato all’accesso, più un’icona. Ogni evento nella cronologia dell’attività registra se viene da una persona o via MCP, e quale client l’ha inviato.

La cronologia completa (get_task_history in modalità full) mostra l’id grezzo del client per ogni evento: un id di client OAuth, oppure mcp-token seguito dall’id del token. Non è un nome leggibile, ma è esatto, e distingue due connessioni anche quando vengono dallo stesso prodotto.

Anche la proprietà durante il lavoro è esplicita. Un agente chiama start_task, che prende in carico l’attività con un lease di 20 minuti e la sposta in Doing. report_progress rinnova il lease. Un secondo agente che prova la stessa attività riceve already_claimed, e un lease scaduto libera l’attività per qualcun altro. La guida al ciclo di presa in carico lo spiega passo per passo, e più agenti su una sola bacheca copre il caso con più client.

Una regola pratica: dai a ogni strumento la sua connessione. Se due client condividono un token di accesso, la bacheca vede un solo attore, e la domanda su chi perde la sua risposta.

Cosa è cambiato, e posso controllarlo senza chiederlo all’agente?

Quando un agente finisce, chiama complete_task. È obbligatorio solo l’id dell’attività; tutto il resto è facoltativo, e la chiamata non fallisce mai per mancanza di prove. È voluto: perdere lavoro finito è peggio che registrarlo non verificato. Cosa può contenere una ricevuta:

  • outcome: fino a 1.000 caratteri su cosa è stato fatto e dove si trova il risultato.
  • artifacts: fino a 20 voci, ognuna con un tipo (url, file, message, commit e così via), una posizione e, facoltativamente, un digest sha256.
  • claims: ciò che l’agente afferma di aver fatto, salvato come affermazione e non come fatto verificato.
  • notDone e unknowns: trattati nella sezione successiva.
  • nextStep: cosa farebbe l’agente dopo, se accetti.
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"
})

La riga dell’esito resta un racconto. Gli artifacts sono la parte che puoi controllare. L’hash di un commit o esiste nel tuo repository o no. Un URL si carica o no. Lo sha256 di un file corrisponde o no. Se una ricevuta ha un esito e nessun artifact, trattala come lavoro dichiarato dall’agente, perché è quello che è. Sul web, le schede in Done mostrano se un’attività è Verificata o Secondo l’agente.

Cosa non ha fatto l’agente?

È la domanda che la maggior parte dei registri salta, e quella che ti morde due settimane dopo. complete_task ha due elenchi per questo, ciascuno fino a 20 voci da 500 caratteri: notDone per ciò che l’agente ha tralasciato di proposito, e unknowns per ciò su cui non è sicuro. La descrizione stessa dello strumento chiede agli agenti di dire esplicitamente cosa non hanno fatto. È ciò che separa un risultato su cui puoi contare da uno che devi ricostruire.

Leggi prima questi elenchi. “Non ho eseguito i test sul database di staging” cambia quello che fai dopo. Una ricevuta senza voci in notDone su un’attività grande merita già di per sé una domanda.

Cosa è stato deciso, e perché?

Le decisioni prese in chat svaniscono quando la chat scorre via. record_decision le conserva in due modi:

  • Un registro di decisione autonomo: un titolo, l’esito, il contesto, le opzioni davvero valutate, le conseguenze e la condizione in cui riconsiderarla. I registri sono immutabili; cambiarne uno significa registrare una nuova decisione che lo sostituisce, e quello vecchio resta, marcato come sostituito.
  • Un verdetto riportato: quando in conversazione dici a un agente “accettato”, “rifallo con X”, “lascia perdere” o “non adesso”, lui registra quel verdetto sull’attività, con la tua nota.

get_task_history lo rilegge in tre modalità: summary (la scheda, la sua ultima ricevuta e i conteggi), decisions (ogni decisione sull’attività, compreso il motivo per cui è stata rimandata indietro, che resta anche dopo un’accettazione successiva) e full (la cronologia grezza, fino a 100 eventi). get_context passa le decisioni in vigore all’agente successivo entro un budget di token, così l’esecuzione successiva parte da ciò che è stato deciso invece che da zero. Di più in perché le decisioni prese in chat con l’IA si perdono.

Dove lo rivedo, e cosa clicco?

Per impostazione predefinita un’attività completata va direttamente in Done. Si ferma nella tua Inbox quando richiede una revisione o quando un controllo di verifica fallisce. Lì vedi la ricevuta e quattro pulsanti: Accetta, Rifai, Più tardi e Scarta. Rifai chiede una nota, e quella nota torna all’agente.

Se l’agente ha passato un nextStep, compare sopra il pulsante Accetta, e accettare approva esattamente quel passo. L’approvazione vale 72 ore e torna all’agente tramite get_my_work o start_task come l’unico passo da fare dopo. Le domande che un agente fa con request_input arrivano nella stessa Inbox, sul web e nelle app per iOS e Android, con una notifica push sul telefono.

La Inbox ha un limite voluto: 5 elementi in attesa per uno spazio di lavoro di una persona, 10 per un team, oppure 45 minuti di revisione stimata, quale arriva prima. Quando è piena, start_task rifiuta con attention_queue_full, così gli agenti finiscono o chiariscono il lavoro invece di accumularne altro da farti controllare.

Quali prove chiedere a seconda del tipo di attività?

Scrivile nella descrizione dell’attività, così l’agente sa quali prove ti aspetti:

  • Codice: l’hash del commit e l’URL della PR come artifacts. notDone dovrebbe indicare i test non eseguiti, le migrazioni non applicate e i file lasciati stare di proposito.
  • Contenuti: l’URL pubblicato, o il file della bozza con il suo sha256 se non è ancora online. unknowns dovrebbe elencare i fatti che l’agente non ha potuto confermare.
  • Ricerca: un URL di fonte per ogni affermazione chiave, e il file degli appunti. unknowns dovrebbe separare ciò che dice una fonte da ciò che l’agente ha dedotto.
  • Outreach: l’id di ogni messaggio inviato, e l’elenco dei destinatari come file. notDone dovrebbe elencare chi non è stato contattato e perché.

Come controllo fin dall’inizio cosa può fare un agente?

L’attribuzione a posteriori funziona meglio con dei limiti a priori. In Weft, ogni connessione OAuth ha uno di tre livelli di permesso, impostato nella schermata di consenso o più tardi in Impostazioni, Client IA collegati:

  • completo (predefinito): tutti i 32 strumenti.
  • scrittura: tutto tranne i tre strumenti distruttivi (trash_task, archive_done_tasks, complete_sprint).
  • lettura: solo gli 11 strumenti di sola lettura.

Il controllo avviene a ogni chiamata. Scollega revoca i refresh token della connessione e rifiuta alla chiamata successiva qualsiasi token emesso prima del taglio. I token di accesso personali, per i client senza OAuth, non hanno permessi limitati: un token raggiunge tutti i 32 strumenti, e revocarlo ha effetto alla chiamata successiva. Gli agenti possono spostare le attività in un cestino di 30 giorni ma non eliminarle definitivamente; il ripristino dal cestino è una funzione Pro.

Cosa non fa Weft qui?

  • Non ha integrazioni con GitHub o Slack, quindi Weft non va a cercare per te i tuoi commit o messaggi. L’artifact lo apri tu.
  • Non ha un’API REST pubblica, webhook o una CLI per spingere le ricevute in altri sistemi. C’è un’esportazione in JSON e Markdown.
  • Non traccia i passaggi del modello. Gli strumenti che registrano prompt, token e latenza a livello di modello fanno un altro lavoro, e potresti volerne anche uno.
  • Le ricevute le scrivono gli agenti. Weft rende visibile la distanza tra affermazione e prova; non può rendere onesto un agente.

Se vuoi agenti gestiti come account di servizio tramite un’API REST, una CLI per gli script di CI o funzioni IA integrate come la scrittura e lo smistamento delle attività, Hypertask fa più al caso tuo. La nostra pagina alternativa a Hypertask confronta i due fianco a fianco.

La cronologia di git non basta per sapere cosa ha fatto il mio agente?
Git mostra cosa è cambiato nel codice. Non mostra cosa l’agente ha saltato, di cosa non era sicuro o quale scelta ha fatto tra due opzioni. Usa l’hash del commit come artifact sull’attività, e tieni il resto nella ricevuta e nel registro di decisione.
Un agente non può semplicemente inventarsi un artifact?
Può inviare qualsiasi stringa. Il senso di un artifact è che puoi aprirlo: un hash che puoi cercare, un URL che puoi caricare, l’id di un messaggio che puoi trovare. Uno inventato fallisce nel momento in cui lo controlli, cosa che un commento non fa mai. Quando un’attività ha un controllo di verifica e un controllo bloccante fallisce, l’attività resta fuori da Done.
Ogni attività finita aspetta la mia revisione?
No. Per impostazione predefinita un’attività completata va in Done. Aspetta nella tua Inbox per Accetta, Rifai, Più tardi o Scarta solo quando richiede una revisione o un controllo di verifica fallisce.
Quali client IA possono scrivere ricevute su Weft?
Qualsiasi client MCP. ChatGPT ha Weft come plugin pubblicato su ogni piano, gratuito compreso. Claude Code si collega con claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai e Claude Desktop usano un connettore personalizzato. Ci sono pagine di configurazione per 33 client, come Claude Code, ChatGPT, Cursor e Codex.
Quanto costa?
Il gratuito copre 50 attività e 200 chiamate IA al mese. Pro costa 7 $ per postazione al mese o 60 $ per postazione all’anno. Weft non ha crediti IA: il ragionamento avviene nel tuo client IA. Vedi i prezzi.