Agenti AI e operazioni duplicate: progettare azioni verificabili

Un agente AI che trova una risposta sbagliata può essere corretto. Un agente che registra due volte un ordine crea invece un problema operativo, anche se il testo finale è perfetto. Quando i modelli iniziano a usare strumenti che modificano dati, la qualità va misurata negli effetti prodotti. Una proprietà particolarmente utile è l'idempotenza: ripetere la stessa richiesta logica non deve moltiplicare l'operazione.

Perché un agente può ripetere un'azione

Immaginiamo che un agente invii una richiesta per aprire una pratica. Il server completa l'inserimento, ma la risposta si perde prima di arrivare al modello. Dal punto di vista dell'agente, l'esito è incerto. Riprovare alla cieca può aprire una seconda pratica; non riprovare può lasciare il lavoro apparentemente incompleto. Lo stesso problema esiste nei sistemi distribuiti tradizionali, ma un modello aggiunge ulteriori possibilità di reinterpretare il compito.

La guida tecnica Writing effective tools for agents, pubblicata da Anthropic l'11 settembre 2025, richiama l'importanza di strumenti chiari e valutazioni su compiti verificabili. È un'esperienza ingegneristica del fornitore, non una certificazione indipendente. Le scelte che seguono sono una proposta progettuale per il caso dei duplicati, non risultati misurati su un'installazione EL-AI.

Dare un'identità all'operazione

Un possibile progetto assegna un identificativo stabile alla richiesta aziendale. L'agente può riformulare le parole o ripetere la chiamata, ma l'intenzione di aprire quella pratica conserva la stessa identità. Il servizio registra l'identificativo insieme all'esito e, se riceve un nuovo tentativo equivalente, restituisce il risultato già prodotto. Il controllo deve vivere nel servizio che scrive i dati: un semplice invito nel prompt a non duplicare non offre la stessa garanzia.

È necessario anche verificare l'equivalenza. Se arriva lo stesso identificativo con dati differenti, il sistema non dovrebbe accettarlo silenziosamente. Deve segnalare un conflitto e mostrare lo stato registrato. Inoltre il periodo di conservazione degli identificativi deve coprire la finestra dei possibili tentativi. Una protezione che scade prima di una ripresa del lavoro può lasciare riapparire lo stesso problema.

Separare proposta, autorizzazione ed esito

Consideriamo uno scenario ipotetico di movimentazione materiale. L'agente può preparare una proposta indicando articolo, quantità, magazzino e commessa. Il servizio verifica i vincoli applicabili e l'autorizzazione prevista dal processo. Solo l'operazione confermata cambia lo stato. La risposta restituita deve distinguere tra proposta salvata, movimento registrato e operazione rifiutata. Un messaggio generico come «fatto» rende difficile capire cosa sia realmente accaduto.

Questa separazione non implica chiedere approvazione manuale per ogni passaggio. Le autorizzazioni possono essere già definite per certe classi di azioni. Il punto è applicarle attraverso il software e renderle coerenti con ruolo, contesto e dati correnti. Se l'utente ha autorizzato una quantità specifica, l'agente non dovrebbe poter trasformare autonomamente l'azione in un'altra operazione con effetti maggiori.

Verificare lo stato quando la risposta manca

Uno strumento di consultazione dell'esito permette di chiedere che cosa è successo a una richiesta. Deve distinguere almeno operazione sconosciuta, in corso, completata e fallita. Se l'esito è ancora incerto, il flusso può attendere o affidare la riconciliazione a un controllo successivo. Dichiarare successo perché la chiamata è stata inviata confonde intenzione ed effetto. Anche dichiarare fallimento definitivo dopo un semplice timeout può essere scorretto.

I test più informativi interrompono la comunicazione in punti precisi: prima dell'inserimento, dopo la scrittura e prima della risposta. Provano inoltre due tentativi simultanei e una ripartenza dopo l'arresto del processo. Il criterio di successo è osservabile nel sistema aziendale: esiste una sola operazione corretta, associata alla richiesta prevista. Non basta che l'agente racconti di avere gestito l'errore.

Il significato per EL-AI e i processi aziendali

EL-AI presenta ELAI Nexus come piattaforma per collegare commesse, materiali, documenti e approvazioni. Questi sono esempi di contesti nei quali un futuro agente operativo dovrebbe rispettare le regole del sistema. Non stiamo affermando che Nexus disponga già dell'agente o del meccanismo descritto. Il collegamento serve a chiarire che l'AI deve inserirsi in un processo affidabile, non aggirarlo.

Per una prima sperimentazione conviene scegliere un'azione limitata e reversibile, definire la sua identità e progettare il controllo dell'esito. Solo dopo ha senso ampliare gli strumenti disponibili. La capacità di dialogare rimane utile, ma il valore operativo nasce quando ogni azione può essere ricondotta a una richiesta e verificata nello stato reale dell'applicazione.

Articolo preparato con assistenza AI e verifica delle fonti indicate. Esempi applicativi ipotetici salvo diversa indicazione. Fonti consultate il 20 settembre 2026.

Copertina illustrativa generata con AI; non rappresenta persone, sedi o installazioni reali di EL-AI.