Vai al contenuto principaleVai al footer
Guida applicativaAgenti GUI

Il pilotaggio dello schermo è lavoro delegato, non magia invisibile.

Gli agenti computer-use lavorano in ambienti reali instabili. Progressive disclosure, approvazioni esplicite e modelli mentali chiari mantengono l'operatore in controllo di cosa fa lo screen-driver dopo.

Aggiornato 21 aprile 2026

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
Segnale di successo
L’utente può capire l’avanzamento, correggere la rotta e vedere perché il sistema si è fermato
Mappatura dottrinale
P4, P5, P8
Il pilotaggio dello schermo è lavoro delegato, non magia invisibile.

In questa sezione

Perché questo schema conta adesso

Gli agenti che usano il computer cliccano, scrivono, scorrono e navigano software attraverso l’interfaccia stessa, quindi sono utili dove mancano API stabili, i sistemi legacy dominano o il lavoro attraversa strumenti fragili. Il problema non è usare la GUI; il problema è presentare questo lavoro come un assistente magico che opera fuori scena. La risposta del Blueprint è trattare il computer use come lavoro operativo delegato con obiettivi, vincoli, stato, approvazioni ed evidenze esplicite. Scritto dal team editoriale di AI Design Blueprint. Dottrina fondata sui 10 Blueprint Principles.

Perché l’approccio standard fallisce

L’approccio chat-first fallisce perché comprime un workflow operativo ramificato in un flusso di messaggi. Una trascrizione non comunica in modo affidabile stato di login, ambito dell’account, checkpoint corrente, loop di retry, dipendenze rotte o il motivo esatto per cui l’esecuzione si è fermata.

Il modello sostitutivo del Blueprint

Il modello corretto è l’orchestrazione di lavoro delegato. L’utente assegna un risultato, definisce vincoli e controlla l’avanzamento attraverso una vista strutturata dell’esecuzione invece che attraverso un’illusione conversazionale.

Come implementarlo

Starter brief copiabile

Definisci applicazione target, ambito account e risultato richiesto.
Distingui azioni consentite, reversibili e soggette ad approvazione.
Mostra un pannello persistente con passo corrente, tempo trascorso e ultimo checkpoint.
Esplicita i blocchi con linguaggio semplice e una next action precisa.
Offri controlli di steering: pausa, retry, skip o takeover manuale.
Salva screenshot e sintesi azioni come evidenza ispezionabile.
Chiudi ogni run con stato chiaro: completato, bloccato o in attesa di approvazione.
Task: Completa il workflow richiesto nell’applicazione indicata.

Livelli di escalation e governance

Usa tre livelli di controllo, non un mix indefinito di autonomia e intervento umano.

Tier 1 — Autonomous

Navigazione reversibile e raccolta informazioni

Risk level: Basso
Required approval: Pre-approvato all’avvio

Tier 2 — Supervised

Modifiche record, cambi cross-system, transizioni ambigue

Risk level: Medio
Required approval: Checkpoint review

Tier 3 — Blocked

Pagamenti, cancellazioni, messaggi esterni, azioni sensibili

Risk level: Alto
Required approval: Sign-off umano esplicito

Anti-pattern vs. pattern Blueprint

La posizione progettuale deve essere leggibile anche in forma comparativa.

Anti-pattern

Trascrizione chat come unica vista di esecuzione

Blueprint pattern

Run view persistente con stato, checkpoint e blocchi

Anti-pattern

L’agente decide da solo quando serve approvazione

Blueprint pattern

Livelli di approvazione definiti prima dell’esecuzione

Anti-pattern

Retry e loop invisibili

Blueprint pattern

Stati di attesa, retry ed errore espliciti

Anti-pattern

Contesto account generico

Blueprint pattern

Perimetro esplicito di app, account e ambiente

Anti-pattern

Messaggio finale senza traccia

Blueprint pattern

Screenshot, checkpoint ed evidenze consultabili

Prova reale

“Un team ha usato un browser agent per aggiornare record partner in un portale legacy. L’agente ha tentato l’invio e si è fermato perché l’account attivo non corrispondeva più al perimetro approvato. Il sistema ha mostrato blocco, schermata corrente e approvazione richiesta invece di indovinare.”
“Un team ha usato un agente GUI per raccogliere dati di riconciliazione su due tool interni. Il sistema ha completato la navigazione Tier 1 in autonomia, si è fermato a un checkpoint Tier 2 prima di modificare record e ha allegato screenshot e sintesi azioni per la revisione.”

Checklist iniziale

Definisci risultato del workflow e perimetro applicativo.
Separa azioni reversibili da quelle soggette ad approvazione.
Aggiungi una execution surface visibile prima di spedire automazione.
Scrivi copy esplicita per login, permessi e blocchi di policy.
Registra screenshot e checkpoint come evidenza.
Testa retry e takeover su interfacce instabili.
Apri Blueprint per validare la tua architettura.

Domande frequenti

Domande comuni dei team che stanno progettando agenti GUI.

Per cosa sono più adatti questi agenti?

Per workflow che devono operare su interfacce reali perché le API sono assenti, incomplete o troppo fragili.

Perché la chat non basta?

Perché l’esecuzione GUI è piena di stato e biforcazioni. Serve un modello operativo visibile, non solo testo.

Quando serve approvazione?

Quando l’azione è irreversibile, esterna, economica, legale o sensibile rispetto a policy.

Cosa significa inspectability qui?

Che l’utente può rivedere screenshot, checkpoint, sintesi azioni e motivi dei blocchi quando fiducia o accountability contano.

Qual è la minima execution surface accettabile?

Passo corrente, tempo trascorso, ambiente o account attivo, ultimo checkpoint valido e blocco corrente.

Come dovrebbe fermarsi l’agente quando qualcosa va storto?

Con uno stato di blocco esplicito che dica cosa è cambiato, perché non può continuare e quale azione umana sblocca il flusso.

Principi di riferimento

Leggi il Principio 4

Apply progressive disclosure to system agency

Leggi →Leggi il Principio 8

Make hand offs approvals and blockers explicit

Leggi →