Se una persona deve copiare ogni richiesta nel chatbot, aspettare la risposta e riportarla al team, l’agente AI non sta collaborando: ha solo creato un nuovo lavoro di passacarte. Il problema emerge appena l’automazione coinvolge più di una persona, per esempio tra commerciale, amministrazione e chi gestisce il sito WordPress.

Il problema è il passaggio di consegne, non il modello

Ando, piattaforma di messaggistica uscita dalla fase stealth il 24 settembre 2026, parte da un’idea utile anche a chi non userà il prodotto: agenti e persone dovrebbero lavorare nello stesso spazio operativo. Nella presentazione ufficiale, gli agenti sono membri riconoscibili del workspace, possono partecipare ai canali e prendere in carico attività. TechCrunch descrive il problema opposto: una persona diventa il tramite obbligato tra l’agente e il resto dell’azienda. Per una PMI questo passaggio costa più del tempo di copia-incolla. Toglie contesto, nasconde chi ha deciso cosa e rende difficile capire se l’output è stato controllato. Cambiare modello non risolve nulla. Serve un protocollo di handoff visibile al team. Nel canale condiviso, richiesta, correzioni e decisione finale restano consultabili senza ricostruire il lavoro a memoria.

La soluzione: un canale, un mandato e un’uscita verificabile

Apri un canale dedicato a un solo processo, non un generico “AI”. Per esempio, #preventivi-da-verificare oppure #contenuti-wordpress. Nel messaggio fissato scrivi quattro elementi: quali input può leggere l’agente, quali azioni può compiere, quale formato deve restituire e chi approva il risultato. Un incarico utile su WordPress potrebbe essere: analizzare una bozza, segnalare link rotti e metadati mancanti, poi restituire una checklist; la pubblicazione resta al responsabile umano. Il punto non è far parlare l’agente in chat. È rendere osservabile il percorso richiesta, lavoro, verifica ed esito. La regola deve stare nel canale, non nella memoria privata della persona che ha configurato l’automazione. Questo completa i controlli sui permessi: se l’agente può modificare dati o pubblicare, servono anche limiti e arresto esplicito, come nel mio approfondimento su kill switch e permessi per agenti AI.

I passaggi essenziali per provarlo senza cambiare piattaforma

Puoi testare il metodo in Slack, Teams o nella chat che usi già. Scegli un’attività ripetitiva e reversibile, poi assegna all’agente un’identità distinta: nome, ruolo e perimetro devono essere evidenti in ogni messaggio. Definisci un evento di ingresso, come una bozza spostata nella colonna “da controllare”, e un risultato standardizzato con stato PASS, FAIL o DA RIVEDERE. Aggiungi sempre la fonte dei dati usati e il collegamento all’artefatto prodotto. Infine, indica l’azione che richiede conferma umana: invio al cliente, modifica del database, pubblicazione o spesa. Esegui dieci casi reali e annota quante volte una persona deve ricostruire il contesto. Se succede spesso, non aggiungere altre istruzioni sparse: correggi il messaggio fissato o riduci il mandato. Il protocollo deve diventare più corto mentre migliora.

L’errore da evitare e la take finale

L’errore più comune è dare all’agente tutta la cronologia e accesso esteso “perché così capisce meglio”. Più contesto non equivale a contesto migliore: aumenta rumore, costo e superficie di rischio. Imposta invece un vincolo esplicito: l’agente non legge messaggi diretti o canali esterni al processo, salvo quando una persona inoltra il contesto necessario. Il canale operativo deve contenere solo ciò che serve a quel lavoro. La mia take è semplice. Prima di comprare una nuova piattaforma per agenti, prova il protocollo nel sistema attuale. Se mandato, output e approvazione non sono chiari, un software più moderno renderà il caos più veloce. Se invece il flusso regge, saprai esattamente quali funzioni cercare: identità separate, contesto selettivo, log visibile e checkpoint umano.