Ogni task inviato a un agente in una stanza diventa una richiesta con un ID pubblico come R20260906-07 e uno di sette stati: pending, approved, running, done, failed, cancelled o expired. L'ID esiste affinché una persona in un thread di chat, una persona al telefono e il proprietario che osserva una scheda di approvazione stiano parlando tutti della stessa cosa. Resume significa continuare la stessa richiesta, con lo stesso ID, dopo un'interruzione.
È un lavoro di idraulica poco appariscente. È anche la differenza tra “l'agente sta facendo qualcosa” e “l'agente sta eseguendo R-07, richiesto da Sarah, approvato da te alle 14:02, completato al 60%”.
L'ID
R + la data UTC + un contatore giornaliero. Abbastanza breve da digitare da un telefono, abbastanza unico da fungere da link. Compare nella stanza, nell'audit log, nei thread delle piattaforme di chat e sulle schede di approvazione. Quando sono in uso i connettori Feishu o Slack, il thread per un task viene intitolato con esso. Consulta il design per Feishu.
Gli stati
Sette stati e le transizioni tra loro; il percorso tratteggiato in ambra rappresenta un resume.
Le richieste del proprietario saltano lo stato pending; passano direttamente ad approved.
Cancel, retry, resume
Cancel imposta un flag che il daemon controlla tra una chiamata di tool e l'altra. Una richiesta in esecuzione si interrompe al punto sicuro successivo; una in coda viene rimossa. Revocare l'autorizzazione di una persona o di una macchina cancella tutto ciò che era in coda per loro.
Retry crea una nuova richiesta con un nuovo ID che fa riferimento a quella precedente. La stanza mostra entrambe, così la cronologia rimane fedele.
Resume è diverso. Quando una macchina va in sospensione a metà esecuzione o il daemon si riavvia, la richiesta mantiene il suo ID e il riferimento alla sessione del runtime. Alla ripresa, il daemon prosegue la stessa sessione anziché rieseguire il prompt da zero. La timeline mostra un'interruzione temporale, non un duplicato. È questo che rende un laptop che si chiude alle 18:00 un posto ragionevole su cui eseguire un agente da cui dipendono altre persone.
Perché le code per agente sono seriali
Ogni agente elabora una richiesta alla volta, in ordine. Due persone che inviano una richiesta allo stesso agente contemporaneamente ricevono R-07 e R-08, e R-08 attende. Agenti diversi sulla stessa macchina vengono eseguiti in parallelo. La serialità per singolo agente mantiene coerente la working directory: due modifiche concorrenti allo stesso repository sono il modo perfetto per ritrovarsi in uno stato che nessuno voleva.
TTL di approvazione
Un'approvazione a cui nessuno risponde scade, di norma dopo 24 ore, e la richiesta passa a expired invece di essere eseguita un giorno dopo quando nessuno ne ricorda più il contesto. Chi ha effettuato la richiesta può ritentare; il proprietario vede la scadenza nell'audit log. Consulta cosa deve registrare un audit log.
Domande frequenti
Posso fare riferimento a una richiesta in una nuova? Sì. Menziona l'ID e l'agente riceverà il risultato di quella richiesta nel contesto. Fare riferimento a un messaggio, a un output o a una richiesta è il modo in cui un follow-up evita di dover rispiegare tutto da capo.
Cosa succede a una richiesta in esecuzione se revoco chi l'ha inviata? Viene completata e rimane nella cronologia; tutto ciò che era in coda da parte di quell'utente viene annullato. Interrompere a metà esecuzione può lasciare un repository in uno stato peggiore rispetto al portarla a termine.
Gli ID sono globali o per stanza?
Per proprietario, per giorno. Due proprietari possono entrambi avere un R20260906-01; all'interno di una stanza non c'è ambiguità.
Il resume funziona sia con Codex sia con Claude Code? Entrambi i runtime espongono un riferimento di sessione; il daemon lo memorizza con la richiesta e lo usa per il resume.
Dai un nome al lavoro e diventerà qualcosa di cui le persone possono parlare. Assegna una stanza al tuo agente.
Pubblicato il