Guida applicativaAgenti GUI

Gli agenti che operano su schermo falliscono quando sembrano magia; funzionano quando il lavoro delegato è visibile, governabile e verificabile.

Gli agenti che usano il computer possono cliccare, scrivere, scorrere e navigare software attraverso l’interfaccia grafica, quindi sono preziosi dove mancano API affidabili, i sistemi legacy dominano o il lavoro attraversa strumenti fragili e incoerenti. Il problema di design, però, è immediato: se questa capacità viene presentata come un assistente che 'fa tutto da solo', l’utente perde orientamento, non capisce il rischio e interviene troppo tardi. La risposta del Blueprint è trattare il computer use come lavoro delegato: con obiettivi chiari, vincoli espliciti, stato operativo, punti di approvazione ed evidenze consultabili.

Fatti chiave

Contesto ideale: Strumenti legacy, flussi nel browser, dashboard interne e software senza API affidabili
Rischio principale: Catene di azioni invisibili generano errori, sfiducia o fiducia mal riposta
Cambio di paradigma: Dalla chat che impartisce comandi alla delega strutturata con stato e controlli
Esigenza critica: Rendere espliciti blocchi, approvazioni e ipotesi sull’ambiente operativo
Segnale di successo: L’utente può capire l’avanzamento, correggere la rotta e vedere perché il sistema si è fermato

Perché questo schema conta

Il classico schema conversazionale non basta, perché il lavoro su GUI non produce una singola risposta: attraversa osservazioni, decisioni, dipendenze, tentativi, attese e passaggi di mano in ambienti instabili. Le interfacce cambiano, le sessioni scadono, compaiono captcha, permessi e richieste di autenticazione, e lo stesso pulsante può avere effetti diversi a seconda del contesto. Per questo un buon prodotto non mostra solo una cronologia di messaggi: deve spiegare che cosa l’agente sta cercando di fare, in quale ambiente sta operando, a che punto si trova, dove c’è incertezza e quando serve l’intervento umano.

Perché l’approccio standard non funziona con gli agenti che usano il computer?

L’approccio standard tratta il computer use come una chat con un cursore remoto: l’utente chiede, il sistema esegue, e il flusso di messaggi dovrebbe bastare a spiegare tutto. In pratica non regge, perché il lavoro su interfaccia è contingente, asincrono e pieno di stato. Le persone devono poter delegare obiettivi e vincoli, non seguire ogni clic, ma hanno comunque bisogno di visibilità sufficiente per capire cosa sta succedendo e se sia ancora opportuno andare avanti.

Una conversazione nasconde la struttura operativa: non si vede bene quale passo è in corso, cosa è completato e cosa è bloccato.

Molte attività continuano in background, quindi una singola risposta non basta come segnale di avanzamento.

La stessa istruzione può portare a esiti diversi in base a login, layout, permessi, tempi di caricamento o account attivo.

Se i punti di revisione non sono espliciti, l’utente o controlla tutto in modo inefficiente oppure si fida troppo.

Quando qualcosa si rompe, un riassunto testuale raramente chiarisce il vero blocco e l’azione necessaria per sbloccarlo.

Quali failure mode strutturali bisogna aspettarsi?

Questi agenti falliscono più come un sistema operativo che come un motore di risposta. I problemi principali non sono solo risposte sbagliate, ma ambienti instabili, interfacce ambigue, sessioni interrotte e dipendenze nascoste. Per questo il design deve mostrare stato operativo significativo, non limitarsi a dire che l’agente sta 'pensando'.

Deriva dell’ambiente: layout, etichette e posizione degli elementi cambiano e rendono fragile il piano precedente.

Ambiguità di stato: l’agente può non sapere se è autenticato, nell’account corretto o nel record giusto.

Vuoti di permesso o approvazione: compaiono captcha, MFA, limiti di ruolo, policy interne o richieste di conferma.

Loop silenziosi: il sistema ripete tentativi simili senza produrre avanzamento visibile.

Perdita di evidenza: si vede il risultato finale ma non gli screenshot, le decisioni o i checkpoint che l’hanno generato.

Qual è il modello sostitutivo proposto dal Blueprint?

Il modello corretto è l’orchestrazione di lavoro delegato. L’utente assegna un risultato, definisce confini e controlla l’avanzamento attraverso una vista strutturata dell’esecuzione. Il sistema rappresenta il lavoro come insieme di obiettivi, passi, dipendenze, approvazioni e risultati, con dettagli ispezionabili quando servono. È un modello più fedele a come questi agenti operano davvero: sistemi multi-step che agiscono in ambienti incerti.

Si parte da intento, vincoli e criteri di successo: cosa fare, dove operare, cosa evitare e cosa richiede approvazione.

Il lavoro va mostrato come sistema vivo, non solo come chat: passo corrente, passi completati, blocchi e prossime azioni.

L’attività in background deve restare percepibile con segnali chiari come 'sta navigando', 'in attesa di login' o 'revisione richiesta'.

Serve disclosure progressiva: stato sintetico di default, ma accesso a screenshot, cronologia azioni e motivazioni quando necessario.

I passaggi di mano devono essere espliciti: se l’agente si ferma, deve dire perché, cosa è cambiato e cosa serve all’utente.

Come si traduce questo modello in scelte di prodotto?

In pratica bisogna separare avvio, esecuzione, revisione ed escalation. L’interfaccia deve aiutare l’utente a governare il lavoro mentre è in corso, non solo a farlo partire. Questo richiede confini chiari sull’ambiente, soglie di approvazione, checkpoint operativi e percorsi di recupero quando la GUI o il contesto cambiano.

Preparare un brief di esecuzione: applicazione target, perimetro dell’account, obiettivo, vincoli e regole di approvazione.

Usare un pannello persistente con stato, tempo trascorso, schermata corrente, ultimo checkpoint valido e blocco pendente.

Richiedere conferma per azioni irreversibili, economiche, legali o visibili all’esterno invece di nasconderle nei log.

Offrire controlli di steering durante l’esecuzione: pausa, ripresa, cambio priorità, salto di un passo, retry da checkpoint o takeover manuale.

Conservare evidenze consultabili per ogni run: screenshot, decisioni chiave, sintesi delle azioni e motivi dei blocchi.

Quali livelli di escalation sono più adatti nei flussi rischiosi o instabili?

L’escalation va progettata come un modello di controllo graduale, non come scelta secca tra autonomia totale e uso manuale. Task diversi richiedono soglie diverse in base a impatto, reversibilità e incertezza dell’ambiente.

Livello 1 — Solo osservazione: l’agente esplora l’interfaccia, individua i passi e propone un piano senza agire.

Livello 2 — Esecuzione sicura: l’agente naviga e raccoglie dati in modo reversibile, poi si ferma per revisione.

Livello 3 — Azione condizionata: l’agente può modificare o inviare dati solo entro limiti e checkpoint predefiniti.

Livello 4 — Approvazione obbligatoria: pagamenti, cancellazioni, messaggi esterni e azioni sensibili richiedono sempre conferma esplicita.

Livello 5 — Ritorno all’umano: in caso di ambiguità, errori ripetuti o rischio sull’account, il controllo torna all’utente con contesto completo.

Leggi il Principio 1 Leggi il Principio 9