A molti team tecnologici enterprise vengono oggi proposti soluzioni agentiche — autonome, instancabili, sul punto di trasformare tutto. Le proposte condividono una proprietà: descrivono ciò che gli agenti potrebbero diventare, non ciò che li fa funzionare. Intanto la domanda pratica resta senza risposta: per questo processo, in questa organizzazione, un agente è lo strumento giusto?
Cos’è davvero un agente
Avendo costruito e operato workflow agentici nella nostra stessa delivery quotidiana, la nostra posizione è specifica: gli agenti si guadagnano il loro posto su compiti delimitati con tool, permessi, observability e punti di approvazione definiti — e uno script deterministico è la risposta migliore più spesso di quanto il mercato ammetta.
Sotto la proposta commerciale, un agente è un loop: un modello che legge il contesto, sceglie tra i tool che gli sono stati dati, agisce, osserva il risultato e continua fino a una condizione di arresto. Quella definizione contiene tutto ciò che conta. L’agente è esattamente capace quanto i suoi tool, sicuro quanto i suoi permessi, affidabile quanto le sue condizioni di arresto e debuggabile quanto le sue tracce.
Non è un dipendente digitale. A un dipendente si può chiedere cos’è successo; a un agente senza tracce di esecuzione no. Un dipendente impara i confini dell’organizzazione; un agente ha precisamente i confini che qualcuno ha configurato, e nessun altro. Chiamarlo dipendente invita l’organizzazione a saltare l’ingegneria che lo rende sicuro.
Il test di idoneità
Quattro domande predicono se un processo si presta all’esecuzione agentica:
- Il compito è delimitato? Un lavoro definito con uno stato finale riconoscibile — smista questo ticket, prepara questa bozza, riconcilia questi record. I mandati aperti ("migliora la nostra documentazione") producono comportamenti aperti.
- La superficie dei tool è esplicita? Le azioni necessarie dovrebbero essere enumerabili: leggere questi sistemi, scrivere su questo, chiamare queste API. Se la lista onesta dei tool è "quello che si scoprirà servire", il processo non è capito abbastanza da essere automatizzato — con qualunque metodo.
- Le azioni sono reversibili — o presidiate? Bozze, suggerimenti e modifiche in staging costano poco da annullare. Pagamenti, cancellazioni, invii verso i clienti no; hanno bisogno di un passaggio di approvazione umana progettato dentro il workflow, non appiccicato dopo.
- Verificare costa meno che eseguire? Gli agenti hanno valore quando controllare l’output richiede minuti e produrlo richiedeva ore. Quando la verifica costa quanto fare il lavoro — giudizi sfumati, correttezza ad alta posta — l’agente non fa risparmiare nulla e aggiunge una modalità di guasto.
Un processo che supera tutte e quattro è un candidato. Se più criteri falliscono, un workflow deterministico o un processo manuale è di solito il punto di partenza più sicuro.
Dove aiutano
Gli schemi che superano il test nella pratica sono coerenti: smistamento e instradamento — leggere i ticket in ingresso, classificare, arricchire con contesto dai sistemi interni, instradare con una raccomandazione; bozze per revisione — documenti, risposte, analisi preparate per un umano che approva; ricerche multi-sistema — rispondere a domande le cui evidenze vivono tra repository, wiki e tracker; e workflow di engineering — supporto alla review, scaffolding dei test, manutenzione della documentazione, dove l’output è comunque verificato da CI e reviewer.
La forma condivisa: l’agente fa il lavoro di attraversamento e assemblaggio che consuma ore umane, e un umano — o un controllo automatico — possiede la decisione con conseguenze.
Dove no
Lo stesso test esclude i casi da vetrina: azioni irreversibili senza presidi — tutto ciò che tocca denaro, dati di produzione o clienti dove un passaggio di approvazione "rallenta la demo"; verifica sottile — output che nessuno può controllare in modo efficiente, che trasformano l’automazione in rischio rinviato; percorsi critici per la compliance — dove "oggi il modello ha scelto diversamente" è un rilievo di audit, il determinismo è il requisito, non un limite; e processi che nessuno sa specificare — un agente non sostituisce la comprensione del workflow. Automatizzare un processo che non sapete descrivere produce comportamento automatizzato che non sapete prevedere.
L’alternativa deterministica
Per una quota sorprendente dei casi d’uso proposti, la review architetturale onesta finisce con: questo è un motore di workflow e due integrazioni. Se i passi sono noti, i rami sono enumerabili e gli input sono strutturati, una pipeline deterministica costa meno da costruire, è in genere più prevedibile da operare e si comporta ogni volta allo stesso modo — cosa che auditor, operatori e sistemi a valle preferiscono tutti.
Lo schema pratico è ibrido: pipeline deterministica per il percorso noto, un agente per il passo che richiede davvero lettura e giudizio — classificazione di input disordinati, assemblaggio di contesto da fonti non strutturate — e presidi di approvazione dove i due si incontrano. Usate il modello dove l’input è disordinato; usate la pipeline dove il processo è noto.
La governance è l’architettura
Nell’uso enterprise, le questioni di governance non sono un sovrapprezzo di compliance aggiunto all’agente — sono l’architettura dell’agente: un’identità propria con accesso a privilegio minimo, mai una credenziale personale in prestito; un contratto dei tool esplicito e revocabile; tracce di ogni passo — cosa è stato letto, cosa invocato, cosa è tornato; punti di approvazione collocati dove le azioni diventano consequenziali; e un owner che rivede ciò che l’agente fa davvero e ne risponde.
Un agente con queste proprietà è infrastruttura. Senza, è un processo non auditato con accesso alla produzione — che non è una categoria di rischio nuova, solo una vecchia con un nome nuovo.
Guasti e ripristino
I workflow multi-step falliscono in volo: un tool va in timeout al passo sette di dodici, un modello restituisce qualcosa di inutilizzabile, un sistema esterno cambia forma. I sistemi agentici di produzione lo trattano come operatività normale — checkpoint dello stato perché i workflow riprendano invece di ripartire, passi idempotenti perché un retry sia sicuro, escalation definita perché un workflow bloccato arrivi a un umano, e osservazione dei pattern di guasto, perché un tasso di retry in crescita è il segnale precoce che qualcosa a monte è cambiato.
La demo non mostra mai i guasti al passo sette. La produzione è fatta di quelli.
Il test di idoneità per gli agenti
- Il compito è delimitato, con uno stato finale riconoscibile?
- La superficie dei tool è esplicita ed enumerabile?
- Le azioni sono reversibili o presidiate da un’approvazione umana?
- Verificare l’output costa meno che eseguirlo?