Gli agenti sono sempre assunzioni di primo giorno. È ora di progettare per questo.

Entro il 2027, 74% delle aziende si prevede che utilizzeranno gli agenti in qualche capacità, secondo uno studio recente di Deloitte. Per anni, abbiamo progettato e costruito software per migliorare l’esperienza umana nella navigazione delle nostre app, siti web, sistemi operativi e documenti. Ora, l’utente non è più umano. Questo ha implicazioni più ampie oltre al semplice passaggio da dashboard e flussi di lavoro controllati che progettiamo per compiti umani. Siamo in un momento in cui dobbiamo progettare gli ambienti operativi degli agenti, mentre anche progettiamo i flussi di lavoro umani per guidare efficacemente l’esperienza dell’agente all’interno di questi ambienti.  

Siamo ancora agli inizi del nostro apprendimento su ciò di cui gli agenti hanno realmente bisogno da noi per essere ripetibilmente e affidabilmente di successo. L’istinto è trattare l’integrazione dell’agente esclusivamente come un problema di prompting o di interfaccia utente. Progettare un well-governed execution environment è un territorio nuovo per noi come cultura. Tuttavia, i principi fondamentali di un buon design e di una buona gestione non sono cambiati: dobbiamo agli agenti un contesto chiaro, una direzione inequivocabile e un intento esplicito.

Contesto: Perché la programmazione è venuta prima

Il contesto è probabilmente l’input più importante se vogliamo che gli agenti forniscano risultati ripetibili al livello che intendiamo. Lo sviluppo software ne ha registrato più di quasi ogni altro settore: repository, schemi API, le relazioni tra sistemi, revisioni del codice e discussioni della community. Ha quindi senso che i laboratori di frontiera dell’IA abbiano iniziato con la programmazione. È uno dei pochi ambiti in cui una buona quantità di contesto è già documentata. 

Ma, come ti dirà qualsiasi nuovo assunto in un team di sviluppo, anche con tutti questi dati, gli agenti mancheranno comunque della memoria istituzionale incorporata nelle regole non scritte che nessuno ha mai documentato. Quella lacuna è diffusa: Il 43% degli sviluppatori sono preoccupati che gli strumenti di IA manchino di un contesto sufficiente sul loro progetto o codice specifico. La conoscenza tacita copre tutto, dalle convenzioni quotidiane, come le librerie preferite per compiti specifici, ai fantasmi operativi ad alto rischio: una correzione notturna che persiste indefinitamente, o una colonna di database apparentemente vuota che segretamente sostiene un report di fatturato personalizzato. Questo contesto vive nella testa di un ingegnere senior, in una recente discussione su Slack, o in nessun luogo. Raramente si trova nel codice stesso.  

Se questo è vero nel software, uno dei campi più documentati, è facile capire perché gli agenti faticano a operare efficacemente fin dal primo giorno in molti altri settori. Nel settore sanitario e legale, gran parte della conoscenza istituzionale che plasma il lavoro quotidiano è appresa e interiorizzata. Vive nell’esperienza delle persone piuttosto che nella documentazione formale. Un agente legale potrebbe non conoscere la struttura, il tono o l’argomentazione preferita da un determinato partner per un brief, mentre un agente sanitario potrebbe non comprendere i flussi di lavoro locali e le pratiche di escalation che una clinica occupata utilizza per supportare il triage guidato dal clinico. La sola documentazione non può colmare quella lacuna, perché la sfida non è semplicemente l’accesso all’informazione; è il trasferimento del contesto. Per fornire agli agenti ciò di cui hanno bisogno per avere successo, dobbiamo integrarli come faremmo con un nuovo assunto.

Direzione: Perché l’osmosi non funziona

Integrare un nuovo collega richiede più del semplice fornire i materiali e l’accesso appropriati. Quando siamo investiti nel successo di chi ci circonda, forniamo una direzione solida su cosa fare con i nuovi materiali e l’accesso: aspettative, chiarezza su ciò che vogliamo raggiungere e feedback lungo il percorso. Porto lo stesso approccio nella progettazione per gli agenti. Do una direzione chiara e specifica (relativa al compito in corso). Questo vale per qualsiasi collega, indipendentemente dalla sua anzianità. Tuttavia, in uno scenario di nuovo assunto, la direzione deve andare oltre, poiché non possiedono ancora alcun contesto istituzionale.

Considera un agente come un nuovo assunto che non smette mai di essere nuovo. È entusiasta e capace (e, francamente, ha energia illimitata), ma non può apprendere e conservare tante regole non scritte come fa una persona nel tempo. Gli esseri umani apprendono tramite osmosi ed esperienza, mentre gli agenti apprendono dall’architettura costruita esplicitamente nel loro ambiente di lavoro.

Con un nuovo assunto, puoi colmare quella lacuna nel tempo con domande, feedback e nuove intuizioni che acquisisce sui processi e le preferenze dell’organizzazione lungo il percorso. Conversazioni letterali alla macchinetta del caffè o pranzi di squadra. Con un agente, devi build that gap-closing nella progettazione stessa. Questo può includere: 

• Fornire all’agente una finestra di contesto strutturata che separi regole durature, fatti specifici del compito e storico rilevante, invece di scaricare una pila di documenti sul suo grembo. 
• Definire in anticipo i suoi permessi e i limiti decisionali: ciò che può fare autonomamente, ciò che richiede approvazione e ciò a cui non deve mai accedere. 
• Incorporare alcuni esempi concreti di output di qualità direttamente nell’esperienza, così l’agente ha un modello chiaro su come dovrebbe essere svolto il lavoro.
• Condividere i vicoli ciechi precedenti che hai incontrato.

Progettare un ambiente per agenti ben governato non riguarda rendere il lavoro più facile per il modello. Si tratta di proteggere il team di ingegneria umano da debiti tecnici invisibili. Ma anche un agente ben indirizzato può seguire le istruzioni alla perfezione e comunque perdere il senso. La direzione gli dice cosa fare, ma non gli mostra cosa sia “buono”. Quella lacuna è colma dall’intento.

Intenzione: Perché gli agenti tendono al centro

È importante ricordare che gli agenti sono macchine di corrispondenza di pattern, addestrate su enormi quantità di conoscenza e naturalmente inclini a fornire la media statistica. Senza un intento chiaro ed esplicito, quell’output medio è esattamente ciò che un agente restituirà. Se chiedi a un agente di “aggiungere un endpoint di autenticazione utente”, genererà una rotta Express di testo con hashing di password di base. Funziona, ma ignora completamente il servizio di autenticazione personalizzato del tuo team, salta la telemetria richiesta e rompe il tuo formato di errore standardizzato. È una funzionalità adeguata sulla carta, ma a seconda del contesto, è un bug architetturale nella pratica. La facilità con cui si introducono “bug” come questo non può essere sottovalutata.

Per evitare ciò, la direzione deve essere abbinata a una verifica attiva dell’intento e a un logging. Le barriere di sicurezza non dovrebbero limitarsi a verificare se il codice compila, anche se è importante. Le barriere devono imporre esplicitamente gli standard soggettivi, le regole per casi limite e il contesto di dominio che elevano l’output generico a lavoro pronto per la produzione. Il logging è importante come indicatore di stato del sistema per noi umani. Questa tracciabilità è fondamentale per la fiducia. 

Nelle interazioni umane, c’è molto spazio per l’incertezza. Qualcuno può condividere con te una prima versione, e insieme potete discutere ciò che è solido e ciò che necessita di miglioramenti. Questo funziona perché non ci aspettiamo che i nostri colleghi umani siano macchine autonome. Per catturare davvero il potere e la promessa dei colleghi agentici (che dobbiamo far funzionare più autonomamente…), possiamo progettare molte di queste verifiche direzionali. Il dialogo di andata e ritorno deve comunque avvenire, ma non può ricadere interamente sul lavoro manuale. Caricando in anticipo criteri di accettazione chiari e regole di verifica, consenti all’agente di gestire i propri cicli di feedback interni. Progettare per la prevenzione degli errori è un altro solido principio UX che possiamo applicare in questo nuovo mondo: dare agli agenti la capacità di segnalare bassa confidenza prima di impegnarsi in un’azione, invece di ricorrere silenziosamente a una stima migliore.

Dove la metafora si rompe

Il quadro del nuovo assunto funziona, finché non smette di funzionare. Con un’assunzione umana, l’esperienza genera competenza che genera giudizio. Osservare il tuo nuovo assunto interiorizzare il “perché” dietro al contesto e alla direzione è ciò che costruisce fiducia nel tempo, e in generale, è cumulativo. Un agente non ha alcun luogo dove accumulare e conservare questa esperienza.
La prima settimana e la centesima settimana di un nuovo assunto sono diverse. Il primo compito e il millesimo di un agente sono identici, a meno che non progetti e costruisca qualcosa per differenziarli. Questa è la nostra nuova sfida di design.

La responsabilità dell’agente dipende dal design

Se la responsabilità non può risiedere nell’agente, deve risiedere nella struttura di supporto intorno a esso. Si riduce alle stesse tre domande che farei prima di affidare un lavoro a qualsiasi nuovo assunto: Quale contesto hanno? Quale direzione ho dato loro? Qual è il mio intento reale?

La prossima volta che assegni un compito a un agente, non limitarti a controllare l’output. Controlla prima i tuoi input. Gli hai fornito il contesto che un nuovo assunto avrebbe bisogno dal primo giorno? La tua direzione era sufficientemente specifica da resistere a un’interpretazione letterale? Il tuo intento era abbastanza chiaro da far sì che “la risposta mediana” non fosse la migliore possibile?

Con questa chiara guida in mano (in byte?), succede qualcosa di interessante: un agente non ha bisogno di una lunga pista di decollo per diventare affidabile. Il contesto, la direzione e la verifica che costruisci in anticipo definiscono come opera su ogni compito. Un nuovo assunto guadagna la tua fiducia nel tempo; un agente deve guadagnarla ogni volta attraverso il sistema che hai progettato. La responsabilità non è qualcosa in cui cresce, è integrata fin dall’inizio. La domanda non è quando il tuo agente sarà pronto per più responsabilità. È se lo hai progettato per guadagnare quella responsabilità su ogni singolo compito.