Un ciclo operativo dell'agente è un percorso controllato che porta da una richiesta delimitata a un artefatto revisionato. Il ciclo assegna le responsabilità, registra gli input, limita strumenti e dati, annota azioni e prove, verifica il risultato, gestisce gli errori e termina in uno stato esplicito di accettazione, revisione o arresto.
Questa definizione è il modello di riferimento adottato nella guida. Combina le indicazioni attuali dei fornitori e della gestione del rischio con un contratto operativo pratico. Non è uno standard universale né la descrizione di un prodotto specifico.
Il ciclo è importante perché la dichiarazione di un agente di aver concluso il lavoro costituisce un solo tipo di evidenza. Un registro operativo utile distingue ciò che una fonte o un sistema ha osservato, ciò che il modello prescrive, ciò che l'agente afferma, ciò che un operatore responsabile ha deciso e ciò che resta ignoto.
Decidi prima se il lavoro richiede un agente
Non partire da uno strumento. Parti dall'attività, dal responsabile della decisione e dalle prove richieste alla fine.
Le indicazioni di Microsoft per la pianificazione aziendale degli agenti AI distinguono il lavoro prevedibile, che può essere gestito con codice tradizionale, le attività di reperimento statico di informazioni e il lavoro che richiede ragionamento dinamico o uso di strumenti. Anche la guida di Anthropic alla creazione di agenti efficaci distingue i flussi di lavoro predefiniti dagli agenti che dirigono autonomamente il proprio processo e l'uso degli strumenti, e raccomanda il modello meno complesso adatto all'attività. Sono ausili decisionali, non leggi tecniche assolute.
Usa un programma deterministico o un flusso di lavoro predefinito quando regole, sequenza dei passaggi, input e risultato atteso sono stabili e verificabili. Usa il reperimento di informazioni quando l'attività consiste nel trovare informazioni fondate in un insieme noto di documenti, senza sequenze dinamiche di strumenti. Mantieni il flusso di lavoro sotto responsabilità umana quando l'atto centrale riguarda politiche, responsabilità, giudizio o accettazione e l'esecuzione dinamica aggiunge poco.
Un agente è una scelta ragionevole quando il lavoro richiede decisioni contestuali su input non strutturati, sequenze variabili di strumenti o eccezioni, purché l'organizzazione possa comunque definire:
- il risultato e il responsabile chiamato a risponderne;
- gli input, gli strumenti, i dati e le destinazioni consentite;
- le azioni vietate e i punti di approvazione;
- le prove che un altro revisore può esaminare;
- un responsabile del recupero e uno stato di arresto sicuro;
- un test di accettazione per l'artefatto finale.
Se questi campi non possono essere compilati, l'aggiunta di un agente rende l'incertezza più difficile da vedere.
Usa cinque categorie di evidenza
Queste etichette impediscono che il resoconto di un agente venga trattato come una prova. Costituiscono il modello editoriale di questa guida.
| Categoria di evidenza | Significato | Cosa può dimostrare | Cosa non può dimostrare |
|---|---|---|---|
| Fatto della fonte | Un documento primario con data e ora, una risposta del sistema responsabile o un effetto osservato in modo indipendente. | Che il fatto dichiarato è stato osservato entro l'ambito registrato dalla fonte. | La completezza oltre tale ambito o un effetto collaterale non osservato. |
| Regola di progettazione documentata | Un contratto operativo con versione stabilisce che debbano esistere un ruolo, una fase, un'approvazione, una ricevuta o una regola di recupero. | Che l'organizzazione ha progettato e registrato la regola. | Che il software l'abbia applicata o che ogni esecuzione l'abbia rispettata. |
| Affermazione dell'agente | Un agente dichiara un'intenzione, un'interpretazione, un risultato o una causa. | Un'ipotesi o un risultato proposto da sottoporre a revisione. | L'esecuzione, la correttezza, l'approvazione o il completamento aziendale. |
| Decisione dell'operatore | Una persona responsabile o un sistema autorizzato approva, rifiuta, accetta, interrompe o sceglie un percorso di recupero. | Che la decisione è nota quando responsabile, ambito, prove, destinazione e momento sono vincolati. | Che l'azione approvata sia stata eseguita o abbia avuto successo. |
| Incognita irrisolta | Le prove disponibili non consentono di stabilire cosa sia accaduto o se il risultato sia valido. | Un motivo per fermarsi, riconciliare o raccogliere prove più solide. | Il permesso di ipotizzare, ritentare o dichiarare il successo. |
Un singolo evento può coinvolgere più categorie. Un agente può proporre di scrivere un file, un operatore può approvare una determinata destinazione e una checksum, e il sistema di destinazione può confermare in seguito la scrittura. Si tratta rispettivamente di un'affermazione dell'agente, una decisione dell'operatore e un fatto della fonte. Riunirle nella frase «l'agente ha completato il lavoro» nasconde le distinzioni necessarie a chi svolge la revisione.
Il ciclo operativo dell'agente in otto fasi
Ogni fase dovrebbe rendere visibili il responsabile, l'input, l'ambito consentito, l'azione, la decisione, l'output, la ricevuta, lo stato di errore, il responsabile del recupero e la condizione di uscita pertinenti a quel punto. I campi seguenti formano un unico contratto operativo, senza sostenere che ogni implementazione usi gli stessi nomi.
| Fase | Responsabilità e decisione | Input, strumenti, azione e passaggio | Output, prove, errore, recupero e uscita |
|---|---|---|---|
| 1. Delimitare la richiesta | Il responsabile del risultato definisce il risultato aziendale e decide se accettare la richiesta. | Registra l'ID del lavoro, l'attività, il pubblico, i non obiettivi, il limite di rischio e i criteri di accettazione. Non serve ancora alcuno strumento di esecuzione. | L'uscita richiede un ambito accettato. Una responsabilità ambigua o obiettivi in conflitto tornano al responsabile della richiesta. |
| 2. Registrare gli input | Il responsabile della fonte o un operatore conferma quali prove possono essere incluse nel lavoro. | Registra l'identità delle fonti, le date o le versioni, le checksum quando utili, i limiti di aggiornamento e le regole per i dati mancanti. Trasmette un manifest immutabile degli input. | L'uscita richiede una ricevuta degli input e incognite esplicite. La mancanza di prove determinanti interrompe o restringe il lavoro. |
| 3. Assegnare le responsabilità | Il responsabile del risultato nomina l'agente o il ruolo del flusso di lavoro, l'operatore, il revisore, il responsabile dell'approvazione e il responsabile del recupero. | Definisce chi può proporre, eseguire, approvare, revisionare, ritentare e fermare. Registra conflitti e ruoli non disponibili. | L'uscita richiede una mappa delle responsabilità. Una decisione senza responsabile resta un impedimento. |
| 4. Pianificare entro l'ambito | L'operatore o il responsabile delle politiche decide se il percorso proposto resta entro il contratto. | Registra passaggi, strumenti e dati consentiti, ambito delle destinazioni, azioni vietate, condizioni di approvazione, budget e limiti dei tentativi. Trasmette un piano revisionabile o un'istruzione deterministica. | L'uscita richiede un piano accettato. Un ampliamento dell'ambito torna al responsabile della decisione anziché essere dedotto. |
| 5. Eseguire e registrare | Il ruolo incaricato dell'esecuzione compie solo le azioni consentite; il responsabile dell'approvazione decide sulle azioni con conseguenze, quando richiesto. | Vincola l'azione a una destinazione e all'identità immutabile del payload. Registra data e ora, input e output degli strumenti, cambiamenti di stato, errori e ricevute degli effetti collaterali. | L'uscita richiede un risultato osservabile oppure il mantenimento dell'incertezza. Un timeout dopo una possibile scrittura avvia la riconciliazione, non un nuovo tentativo alla cieca. |
| 6. Revisionare l'artefatto | Un revisore nominato applica criteri di accettazione scritti. | Confronta l'output con la richiesta, le fonti, le politiche, le prove e i risultati vietati. Registra identità e tipo del revisore, incertezza e limitazioni. | L'uscita è ACCEPT, REVISE o HOLD. Il completamento tecnico, da solo, non dimostra utilità o correttezza. |
| 7. Recuperare o fermarsi | Il responsabile del recupero classifica l'errore e sceglie se ritentare, correggere, compensare, trasferire o fermarsi. | Riconcilia i possibili effetti collaterali, esamina la destinazione esatta, conserva il tentativo non riuscito e assegna a ogni successore una nuova identità di tentativo. | L'uscita è RECOVERED, un nuovo tentativo autorizzato oppure un'incognita terminale o un arresto. Il registro del tentativo fallito non viene mai cancellato. |
| 8. Chiudere e passare il lavoro | Il responsabile del risultato accetta lo stato finale e assegna la decisione successiva. | Raggruppa l'artefatto accettato, le prove, il verdetto di revisione, le incognite residue e il prossimo responsabile. Conserva solo le prove soggette a governance. | L'uscita richiede un artefatto vincolato a una ricevuta e uno stato successivo esplicito. «Fatto» senza un registro di accettazione non chiude il lavoro aziendale. |
Il ciclo è sequenziale come modello di responsabilità, ma l'implementazione può tornare a fasi precedenti. Nuove prove possono riportare una bozza alla registrazione degli input. Una revisione non superata può rinviarla alla pianificazione. Un recupero può creare un tentativo successivo. Il registro deve mostrare questi passaggi, non riscrivere lo stato precedente.
Esempio pratico: un dossier di ricerca sui fornitori
Questo esempio è ipotetico. Non descrive Toone, un'implementazione per un cliente o un'esecuzione di prodotto sottoposta a test.
Un team acquisti ha bisogno di un dossier di revisione su tre possibili fornitori di software. La richiesta è limitata a fonti primarie pubbliche. L'agente può redigere un solo dossier interno. Non può contattare i fornitori, creare account, accettare condizioni, modificare i registri degli acquisti o pubblicare il dossier.
1. Richiesta delimitata
Il responsabile delle operazioni di acquisto risponde del risultato. Il risultato accettato è un dossier che contiene, per ogni fornitore, la descrizione pubblica aggiornata del prodotto, la fonte dei prezzi se pubblicata, la documentazione sul trattamento dei dati, le domande irrisolte e le citazioni. Una raccomandazione d'acquisto è fuori ambito.
I criteri di accettazione richiedono collegamenti diretti alle fonti, date di osservazione, separazione tra fatti delle fonti e analisi e uno stato di incognita visibile per le prove mancanti.
2. Input registrati
L'operatore registra i domini dei tre fornitori, le aree della loro documentazione pubblica, la data della revisione e i tipi di fonte approvati. Il manifest degli input esclude recensioni degli utenti, riepiloghi generati privi di collegamenti primari, documenti privati e dati personali.
Ogni istantanea della fonte riceve una data e un riferimento stabile. Una fonte non accessibile resta un'incognita irrisolta. L'agente non è autorizzato a inventarne o dedurne il contenuto.
3. Mappa delle responsabilità
| Responsabilità | Responsabile ipotetico |
|---|---|
| Risultato aziendale | Responsabile delle operazioni di acquisto |
| Limite delle fonti | Analista degli acquisti |
| Ricerca e bozza | Agente di ricerca sui fornitori, versione example-v1 |
| Revisione dell'artefatto | Analista degli acquisti |
| Approvazione delle comunicazioni esterne | Responsabile delle operazioni di acquisto |
| Errore e recupero | Responsabile dei sistemi di acquisto |
I nomi descrivono ruoli nell'esempio fittizio. Non sono ruoli di Toone né prove di una revisione umana di questa guida.
4. Piano delimitato
L'agente propone quattro passaggi: raccogliere le fonti approvate, estrarre fatti corredati di data, redigere sezioni neutrali sui fornitori e assemblare il dossier interno. Può leggere pagine web pubbliche e usare una sola destinazione interna per la bozza. Qualsiasi scrittura esterna, messaggio, invio di modulo, azione sull'account o modifica di registri è vietato.
L'operatore accetta il piano e vincola una singola destinazione di output all'identità prevista del payload. L'approvazione è una decisione dell'operatore. Non dimostra che la bozza sia stata scritta.
5. Esecuzione ed effetto collaterale incerto
La raccolta delle fonti termina e produce un manifest delle fonti. L'agente propone il dossier e dichiara di aver scritto la bozza. Tale dichiarazione è un'affermazione dell'agente.
Lo strumento di redazione restituisce un timeout dopo che il servizio remoto potrebbe aver accettato la richiesta. La risposta di errore è un fatto della fonte. L'esistenza della bozza è un'incognita irrisolta. Un nuovo tentativo immediato potrebbe creare un duplicato o sovrascrivere un file già esistente.
6. La revisione non può ancora iniziare
Il revisore non dispone di un artefatto stabile da esaminare, quindi la revisione resta bloccata. Un'affermazione dell'agente e un timeout non soddisfano il requisito della ricevuta dell'artefatto.
7. Percorso di recupero
Il responsabile dei sistemi di acquisto controlla la destinazione esatta e l'hash previsto del payload prima di autorizzare qualsiasi nuovo tentativo.
- Se la bozza prevista esiste con l'hash approvato, registra
RECOVEREDe non ripete la scrittura. - Se la destinazione è ispezionabile e la bozza è assente, autorizza un nuovo tentativo con un nuovo ID.
- Se la destinazione non può essere ispezionata, registra
WRITE_UNCERTAINe si ferma. La mancanza di prove non autorizza un nuovo tentativo.
La scelta del recupero è una decisione dell'operatore. L'osservazione della destinazione che la giustifica è un fatto della fonte. La regola che impone la riconciliazione prima di un nuovo tentativo è una regola di progettazione documentata nel contratto operativo di questo esempio.
8. Revisione e chiusura
Supponiamo che la bozza corrispondente esista e venga recuperata. Il revisore confronta ogni affermazione materiale con il manifest delle fonti, segnala per la rimozione un confronto non supportato e restituisce REVISE. L'agente produce una bozza successiva con una nuova checksum dell'artefatto. Il revisore accetta quella versione.
La ricevuta di chiusura registra la checksum accettata, il manifest delle fonti, l'affermazione rimossa, la decisione del revisore, le incognite residue e il responsabile delle operazioni di acquisto come prossimo responsabile. Non dichiara che i fornitori siano stati approvati o contattati.
Perché le scritture incerte richiedono un percorso di recupero distinto
Un nuovo tentativo è appropriato solo quando l'errore e i suoi effetti collaterali rendono sicura la ripetizione. La guida pratica di OpenAI alla creazione di agenti raccomanda di valutare il rischio degli strumenti in base a fattori quali accesso in lettura o scrittura, reversibilità, autorizzazioni e impatto finanziario. Descrive inoltre l'intervento umano in caso di superamento delle soglie di errore e di azioni ad alto rischio o irreversibili.
NIST AI 600-1 include azioni di governance relative a ruoli definiti, supervisione umana, conservazione della cronologia delle valutazioni, disattivazione, risposta agli incidenti e soluzioni alternative per le dipendenze. NIST descrive il Generative AI Profile come una guida volontaria e intersettoriale, quindi tali azioni rappresentano indicazioni, non una certificazione, un obbligo legale o una prova sul prodotto.
Per una scrittura incerta, la domanda operativa non è «L'agente può riprovare?», ma «Il responsabile può stabilire se il primo effetto si è verificato?». La risposta determina il percorso:
| Stato osservato | Registro sicuro | Azione successiva |
|---|---|---|
| L'effetto previsto esiste e corrisponde alla destinazione e al payload approvati | RECOVERED | Mantieni l'effetto e prosegui con la revisione senza ripeterlo. |
| La destinazione è ispezionabile e l'effetto previsto è assente | RETRY_ELIGIBLE | Autorizza un nuovo tentativo con una nuova identità e con un ambito uguale o modificato. |
| L'effetto si è verificato ma non corrisponde all'approvazione | REMEDIATION_REQUIRED | Interrompi il normale lavoro, conserva le prove e assegna la correzione o la compensazione. |
| La destinazione non è ispezionabile o le prove sono in conflitto | WRITE_UNCERTAIN | Fermati. Non riprovare finché prove più solide non chiariscono l'effetto collaterale. |
Questa distinzione è necessaria anche quando un sistema di esecuzione segnala un errore. Una risposta non riuscita può coesistere con un effetto esterno completato.
Foglio di lavoro per il contratto operativo
Usa questo foglio prima di assegnare a un agente attività ricorrenti o con conseguenze rilevanti. Mantieni visibili i campi vuoti come lavoro irrisolto.
| Campo | Dato da registrare |
|---|---|
| 1. ID della richiesta o del lavoro | Identità stabile condivisa da richiesta, tentativi, artefatti e ricevute. |
| 2. Risultato previsto e responsabile | Il risultato aziendale, chi lo accetta e cosa tale accettazione non autorizza. |
| 3. Attività e non obiettivi | Lavoro incluso, lavoro escluso, risultati vietati e uso improprio prevedibile. |
| 4. Input e identità delle fonti | Responsabili delle fonti, versioni o date, limiti di aggiornamento, checksum quando utili e regola per i dati mancanti. |
| 5. Mappa delle responsabilità | Agente o ruolo del flusso di lavoro, operatore, responsabile dell'approvazione, revisore, responsabile del recupero e prossimo responsabile. |
| 6. Strumenti e dati consentiti | Ambito di lettura e scrittura, destinazioni consentite, classi di dati, limite delle credenziali e regola di conservazione. |
| 7. Azioni vietate | Scritture esterne, messaggi, acquisti, invii, modifiche alle autorizzazioni, pubblicazione o altri effetti esclusi. |
| 8. Criteri di ingresso e prove di uscita | Cosa deve essere vero prima dell'inizio del lavoro e quale ricevuta dimostra che la fase può chiudersi. |
| 9. Identità dell'azione con conseguenze | Destinazione esatta, hash immutabile del payload, classe di azione, ambito dell'approvazione e scadenza dell'approvazione. |
| 10. Condizione e responsabile dell'approvazione | Quale azione richiede una decisione, chi decide, quali prove esamina e come viene registrata la decisione. |
| 11. Ricevuta di esecuzione e degli effetti collaterali | ID del tentativo, data e ora, risultato dello strumento, osservazione della destinazione, checksum dell'artefatto ed eventuali prove in conflitto. |
| 12. Registro della revisione | Criteri di accettazione, identità e tipo del revisore, prove verificate, verdetto, incertezza e limitazioni. |
| 13. Errore e recupero | Classi di errore, ammissibilità di un nuovo tentativo, limite dei tentativi, metodo di riconciliazione, responsabile del recupero e percorso di compensazione. |
| 14. Incognite e ritiro | Fatti irrisolti, prove conservate, condizione di arresto, regola di disattivazione e data della revisione. |
| 15. Azione successiva e stato terminale | Artefatto accettato, prossimo responsabile, decisione successiva e indicazione se il lavoro è accettato, da revisionare, sospeso, interrotto o ritirato. |
Versione compatta da copiare
ID lavoro:
Responsabile del risultato:
Risultato:
Limite dell'attività:
Non obiettivi:
Input e versioni delle fonti:
Agente o ruolo del flusso di lavoro:
Operatore:
Revisore e tipo di revisore:
Responsabile del recupero:
Strumenti e dati consentiti:
Azioni vietate:
Criteri di ingresso:
Prove di uscita:
Identità della destinazione e del payload:
Condizione e responsabile dell'approvazione:
Ricevuta di esecuzione:
Criteri e verdetto della revisione:
Classi di errore:
Metodo di riconciliazione:
Limite dei tentativi:
Incognite:
Condizione di arresto o ritiro:
Azione e responsabile successivi:
Condizioni di arresto
Interrompi il lavoro o trasferisci il controllo quando si verifica una delle condizioni seguenti:
- un'azione ad alto rischio, sensibile o irreversibile richiede un'approvazione responsabile;
- l'attività esce dall'ambito accettato o richiede uno strumento, una fonte, una destinazione o un'autorizzazione non approvati;
- viene raggiunta la soglia di errore o il limite dei tentativi;
- un possibile effetto collaterale esterno non può essere riconciliato;
- una prova determinante è assente, obsoleta, contraddittoria o non può essere collegata all'artefatto;
- il revisore o il responsabile del recupero non è disponibile;
- l'output non soddisfa una condizione di accettazione vincolante;
- un flusso di lavoro deterministico può eseguire l'attività in modo più prevedibile e con minore necessità di giudizio;
- il valore atteso non giustifica più il costo, il ritardo o il rischio;
- questioni di politica, diritto, privacy, sicurezza o materia richiedono un responsabile qualificato al di fuori dell'autorità dell'agente.
L'arresto è un risultato valido quando conserva le prove e nomina il prossimo responsabile. Proseguire senza autorità non è un avanzamento.
Un contratto organizzativo documentato è una prova della progettazione
L'organizzazione SEO Growth esaminata offre un esempio di modello operativo documentato. Il manuale e i registri delle routine assegnano responsabili delle fasi, input, decisioni, output, blocchi, stati delle callback, checksum e ricevute. Il contratto documentato riserva inoltre le azioni esterne con conseguenze a un passaggio di approvazione in tempo reale.
Questi registri mostrano ciò che l'organizzazione ha progettato e documentato. Non dimostrano che Toone Desktop abbia applicato il contratto, eseguito ogni fase, conservato una cronologia completa, effettuato il recupero in modo automatico o prodotto un risultato aziendale. Questo articolo li usa solo per illustrare la differenza tra una regola di progettazione documentata e un fatto della fonte.
Scegli il prossimo responsabile in base alla domanda ancora aperta
Se la domanda irrisolta riguarda chi possa approvare un'azione o accettare il rischio residuo, consulta la pagina sulla governance degli agenti AI, in inglese. Se il team ha prima bisogno di un quadro della categoria, leggi la guida alle aziende AI-native, in inglese. Usa le presentazioni di casi, in inglese solo per le prove documentate in quelle pagine.
I riferimenti correlati per conoscenza organizzativa, organizzazioni di agenti, routine, valutazione e osservabilità dovranno essere collegati qui quando le rispettive rotte canoniche saranno attive. Questa bozza non tratta le rotte pianificate come prove attuali.
Informazioni sulla guida
Chi: Toone Content è l'autore organizzativo e Hexagonal.io è l'editore. L'agente Content Editor svolge il ruolo responsabile della revisione editoriale di questa bozza. Non si dichiara alcuna revisione umana, da parte del responsabile dell'ambito o da parte di specialisti del prodotto, dell'ingegneria, della sicurezza, della privacy, del diritto o della materia trattata.
Come: la guida è stata preparata sulla base di un brief approvato al G1 e di un dossier di affermazioni e fonti vincolato a una checksum. L'assistenza automatizzata ha contribuito a raccogliere, organizzare e sintetizzare indicazioni primarie aggiornate di Microsoft, OpenAI, Anthropic e NIST. Le cinque categorie di evidenza, il ciclo in otto fasi, l'esempio di errore e il foglio di lavoro sono una sintesi editoriale. L'esempio di ricerca sui fornitori è fittizio. L'articolo non si basa su test di prodotti Toone, implementazioni presso clienti, studi delle prestazioni o benchmark.
Perché: la guida intende aiutare operatori e responsabili di team a rendere ispezionabile il lavoro degli agenti dalla richiesta alla revisione, con autorità, prove, errori, recupero e stati di uscita chiari.
Limiti e correzioni: le esigenze operative variano in base all'attività, al rischio, alla giurisdizione e al sistema. Il lavoro legale, regolamentato, sensibile per la sicurezza, la privacy o la protezione e le altre attività ad alto impatto richiedono una revisione qualificata che va oltre questo modello editoriale. Consulta la politica editoriale, sulle fonti e sulle correzioni, in inglese. Usa la pagina di contatto di Toone, in inglese per domande generali. Invia le correzioni, indicando l'URL interessato e le prove a supporto, a hello@trytoone.com. Le correzioni sostanziali devono aggiornare la data della fonte e invalidare le versioni locali dipendenti fino al completamento della revisione.
Fonti primarie
- Microsoft Learn: piano aziendale per gli agenti AI, aggiornato il 2026-04-10.
- OpenAI: guida pratica alla creazione di agenti, consultata il 2026-08-13.
- Anthropic: creare agenti efficaci, pubblicato il 2024-12-19.
- NIST AI 600-1: Artificial Intelligence Risk Management Framework, Generative Artificial Intelligence Profile, pubblicato il 2024-07-26.