Mentre promuovo l'introduzione degli agenti AI in altri dipartimenti di Notion come parte del mio lavoro e fornisco supporto all'implementazione alle aziende che utilizzano l'approccio FDE, sono emersi alcuni schemi ricorrenti. Ho creato agenti per vendite, vendite interne, marketing, sviluppo prodotto, successo clienti e altro, ma incontrano tutti ostacoli comuni a livello operativo e barriere organizzative a livello aziendale. Entrambi sono inevitabili, e credo che la maggior parte delle aziende si blocchi sugli stessi punti.
▍Barriere sul Campo
① Il Problema degli Ambiti che Diventano Troppo Ristretti
Ho provato a creare un agente per le vendite che "ricercasse automaticamente quando arriva un lead". Immaginavo l'intero flusso di lavoro: quando un potenziale cliente entra nella lista, l'agente ricerca e analizza informazioni interne ed esterne, quindi crea una bozza di email. Ho iniziato costruendo la parte in cui ricerca informazioni quando una nuova voce arriva nel database dei lead. La mia intenzione era che, una volta pronta la base, automatizzare la creazione delle email sarebbe stato facile.
Tuttavia, dopo aver impostato la build iniziale e averne affidato la gestione al team operativo, le bozze delle email non erano state automatizzate nemmeno dopo diverse settimane. Quando li ho intervistati, hanno detto: "È già molto comodo solo per fare ricerche sui lead!" Il team non si era reso conto che si potesse arrivare fino alle bozze delle email, o l'idea di automatizzare così tanto non li aveva nemmeno sfiorati. Sembrava anche che fossero titubanti perché lo percepivano come difficile.
Questo è il primo schema in cui l'implementazione dell'agente si blocca: rendere l'ambito di lavoro troppo ristretto, con un utilizzo a basso rendimento nonostante l'agente sia stato costruito. Alla fine viene usato solo per funzioni isolate o compiti minori.
② Il Problema di Bloccarsi Perché è Troppo Grande
Il secondo problema è l'opposto: cercare di trasformare un processo aziendale complesso in un agente solo per rendersi conto che il processo stesso non è strutturato con un'alta risoluzione. Persone diverse lo fanno in modo diverso, oppure c'è troppa conoscenza tacita. Cercare di essere troppo approfonditi fa sì che il tempo si dissolva già durante i colloqui, senza mai arrivare alla fase di costruzione. Il numero di stakeholder aumenta e il costo per raggiungere il consenso si gonfia. L'entusiasmo iniziale gradualmente si affievolisce...
Questo è un problema di definizione dell'ambito nella gestione dei progetti. Cosa vuoi fare con l'agente? Quale risultato vuoi ottenere? Se il risultato è deciso, l'ambito necessario e sufficiente per l'agente è determinato. Puntare vagamente a "efficienza aziendale con gli agenti" porta nel fango.
③ Assenza di Titolarità
Anche se un promotore lo costruisce con slancio, se la responsabilità per miglioramenti o correzioni di bug è ambigua, l'utilizzo gradualmente svanisce. Anche il promotore si esaurisce. Idealmente, il team operativo dovrebbe prendersi cura dell'agente come se fosse proprio. Se questo manca, le cose vanno bene per i primi tre mesi, ma non riescono a scalare. Con l'aumentare del numero di stakeholder—specialmente quando l'ambito di lavoro cresce—la necessità di consenso e conferme aumenta, e il senso di responsabilità (chi lo possiede) gradualmente si assottiglia.
Questi tre problemi non sono indipendenti; sono tutti collegati. Se la progettazione dell'ambito è sbagliata, la titolarità non verrà stabilita, e se non c'è un proprietario, l'ambito non si espanderà.
▍Barriere Organizzative
Anche se si superano le barriere sul campo, in un'azienda esistono altre quattro barriere oltre al semplice "creare qualcosa che funzioni".
④ Trasparenza del Capitale Token
Anche se il consumo di token è visibile per reparto, spesso non è chiaro "che tipo di lavoro è stato svolto e quale risultato è stato ottenuto". Questo diventa un problema dal punto di vista del capitale token e della gestione dei token, rendendo impossibile giustificare il budget. Di conseguenza, il management vede i token solo come un costo di consumo, chiedendo: "Quindi, quanto costerà?"
⑤ Governance
Chi può creare agenti, chi può vederli e chi li gestisce? Se questo è ambiguo, l'organizzazione sarà invasa da "agenti vaganti" o "agenti zombie" che girano ma nessuno usa. Nessuno si prende la responsabilità, nessun budget viene stanziato, i token vengono consumati in modo dispendioso e i rischi per la sicurezza aumentano fino a quando tutto si ferma.
⑥ Osservabilità
Quante volte l'agente è stato eseguito, con che frequenza ha avuto successo e dove ha fallito? Questo è un requisito minimo per il funzionamento, eppure molti strumenti sono deboli in questo aspetto. Non si può migliorare ciò che non si vede. Solo con l'osservabilità è possibile costruire un ciclo di feedback per il miglioramento dell'agente.
⑦ Flessibilità nella Selezione del Modello
Affidarsi troppo pesantemente a uno specifico fornitore di LLM è un rischio. E se le prestazioni calassero temporaneamente? E se si fermasse a causa di un guasto? E se le restrizioni all'esportazione lo rendessero non disponibile? Se non puoi passare immediatamente a un altro fornitore, non puoi implementare agenti direttamente collegati alle operazioni aziendali. L'AI è diventata infrastruttura, eppure una dipendenza estrema è attualmente tollerata ciecamente.
Riepilogo
L'implementazione degli agenti sembra una discussione tecnica, ma in realtà riguarda la progettazione aziendale e la titolarità. Per assicurarsi che non finisca solo con "l'AI è fantastica", sono necessari prima i fondamenti per la governance e l'osservabilità.
Non troppo piccola, non troppo grande e curata da qualcuno con responsabilità. E un sistema per supportare tutto questo come organizzazione. Credo che gli agenti attecchiscano solo quando sia il campo che l'organizzazione sono allineati.
