Il problema arriva dopo, quando l’amministrazione chiede da quale documento sia stato letto l’indirizzo, perché non sia stata richiesta una verifica manuale e chi abbia autorizzato la modifica prima dell’emissione della prossima fattura: a quel punto, la risposta generata dall’agente è probabilmente l’aspetto meno interessante di tutta la vicenda.
Nel giro di pochi mesi gli agenti AI sono usciti dal notebook del team che si occupa di intelligenza artificiale e sono entrati in un lessico più scomodo, fatto di tool contract, tracing e human approval. Lo racconta bene LangChain nel suo State of Agent Engineering 2026, dove il 57,3% dei rispondenti dichiara di avere già agenti in produzione e, tra questi, il 94% dispone di una qualche forma di osservabilità, mentre il 71,5% applica un tracing dettagliato su step e tool call. È una fotografia parziale, ma dice qualcosa di preciso: non appena l’agente tocca un processo reale, qualcuno in azienda vuole vedere la ricevuta.
I limiti della metafora del “collega digitale”
La metafora del “collega digitale” ha avuto una sua utilità, perché aiuta a spiegare perché un agente possa leggere, cercare, decidere il passo successivo, usare strumenti e chiedere chiarimenti. In un team di prodotto, questa immagine rende più facile immaginare deleghe leggere come analizzare un ticket, preparare una bozza di risposta, cercare documentazione, aprire una pull request o riassumere una retrospettiva.
È una metafora calda, comprensibile e facile da comunicare, e porta con sé anche un merito tecnico non scontato: protegge dall’eccesso opposto, quello di ridurre ogni processo a un form con campi obbligatori e stati rigidi. Se il lavoro fosse già del tutto codificabile, in fondo basterebbe una funzione o un job schedulato: gli agenti servono proprio dove il contesto cambia, le fonti sono incomplete, il linguaggio naturale contiene segnali utili e la procedura aziendale vive in un misto di documenti, canali di messaggistica, memoria delle persone e ticket vecchi.
È qui, però, che la metafora si rompe: un collega può spiegarsi in corridoio, ricordare un’eccezione discussa a voce, prendersi una responsabilità personale, mentre un sistema software deve lasciare tracce. Il vero salto enterprise degli agenti passa da questo punto, ovvero dalla capacità di proceduralizzare il giudizio: non si tratta di eliminare l’ambiguità, che anzi è spesso il motivo per cui un agente serve, ma di trasformare alcuni passaggi ambigui in sequenze osservabili, interrompibili e migliorabili.
Quando un agente può restare semplice, e quando no
Un agente pensato per la ricerca interna può restare un agente singolo se il contesto è compatto: una domanda, un insieme di fonti, una risposta con citazioni e un livello di confidenza. In questo caso la reversibilità è alta, perché se sbaglia una sintesi è possibile correggerla, e il danno resta contenuto purché sia chiaro quali documenti abbia letto e quali abbia ignorato.
Un agente di customer support è già un oggetto diverso, perché può consultare ordini, policy commerciali, storico delle conversazioni e stato delle spedizioni. Se si limita a preparare una bozza, il rischio resta vicino a quello di un assistente redazionale, ma se invia la risposta, applica uno sconto o promette una sostituzione, il workflow entra direttamente nel bilancio aziendale e nella relazione con il cliente: la differenza, in questo caso, non è “più intelligenza artificiale”, ma un diverso permesso operativo.
Multi-agent: utile solo quando riduce davvero la complessità
Anche i framework più recenti si muovono in questa direzione: l’Agents SDK di OpenAI distingue pattern come agents as tools e handoff, dove nel primo caso un agente manager mantiene il controllo e chiama specialisti per i sotto-task, mentre nel secondo un agente di triage passa la conversazione a uno specialista che diventa attivo.
Questo non significa che ogni progetto debba trasformarsi in un sistema multi-agent: anzi, spesso il multi-agent è un modo costoso per spostare l’ambiguità da un’istruzione di prompt a un problema di coordinamento. Un agente “ricercatore”, uno “analista”, uno “revisore” e uno “writer” fanno una demo che funziona e una dashboard elegante, ma poi in produzione nessuno riesce a capire quale agente abbia introdotto l’errore o perché due specialisti abbiano letto fonti diverse.
Il multi-agent ha senso quando la specializzazione riduce davvero il rumore, per esempio nel knowledge management di un gruppo enterprise con policy legali, manuali tecnici e documentazione commerciale: un agente può recuperare le fonti tecniche, un altro può verificare i vincoli normativi, mentre un orchestratore decide se la risposta è pronta o se serve una revisione umana. In questo caso la divisione dei ruoli serve davvero a separare contratti, fonti e responsabilità.
Il ciclo planning, execution, review — e il ruolo dell’human-in-the-loop
Lo stesso principio vale per il ciclo di planning, execution e review, utile quando il piano produce un artefatto controllabile prima dell’azione, come nel caso di un agente che dichiara: “cercherò nei ticket chiusi degli ultimi 90 giorni, confronterò la policy aggiornata e proporrò una risposta senza inviarla”. Nel coding assistito questo passaggio può tradursi in una lista di file da modificare e test da eseguire, mentre nelle operations può diventare una runbook con checkpoint espliciti: leggere una metrica, consultare una dashboard, aprire un incident, chiedere conferma prima di un rollback.
In questa cornice, l’human-in-the-loop smette di essere il freno imposto da un’azienda prudente e diventa il punto in cui l’organizzazione, di fatto, firma. Non serve ovunque, ma serve dove l’azione è poco reversibile, dove cambia un diritto, dove produce un costo, dove comunica una promessa al cliente o dove apre un varco di sicurezza.
Il nostro approccio: i confini prima dei prompt
Per noi di Moku, prima dei prompt vengono i confini: quali strumenti esistono, con quali permessi, su quali dati e con quali log. Prima della personalità dell’agente viene il suo contratto operativo, e prima della demo viene la domanda che ogni CTO farà dopo il primo incidente, ovvero se sia possibile ricostruire cosa sia successo.
Questo porta con sé anche un effetto organizzativo meno visibile: gli agenti costringono a scrivere procedure che prima vivevano nei passaggi informali, come il messaggio privato al collega senior, la nota nel ticket o l’eccezione concessa “solo questa volta”. Quando codifichiamo un workflow agentico, stiamo di fatto decidendo quali parti del giudizio aziendale meritano una forma.
Il rischio dell’approccio a workflow è reale, perché irrigidire troppo un agente significa togliergli proprio la capacità di attraversare i casi non previsti; il rischio opposto, però, è più caro in produzione, perché un sistema che sembra flessibile finché nessuno deve spiegarne le decisioni a finance, legal o security diventa rapidamente un problema.
La prossima interfaccia gestionale, in molti processi, potrebbe non avere più schermate, ma avrà tool contract, policy, checkpoint e approvazioni: l’agente parlerà, e l’azienda dovrà comunque poter leggere il verbale.
