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.

Di ·

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

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.

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

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.

I failure mode tipici sono deriva dell’ambiente, ambiguità di stato, retry silenziosi e confusione sulle approvazioni. Non sono eccezioni. Sono proprietà normali del lavoro via GUI. Senza un modello di esecuzione visibile, gli utenti o si fidano troppo o sentono di dover controllare ogni clic.

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.

Questo applica direttamente P4 rendendo disponibile più dettaglio solo quando serve, P5 chiarendo capacità, limiti e dipendenze, e P8 rendendo espliciti stati di attesa, gate di policy e azioni necessarie per riprendere.

Come implementarlo

Starter brief copiabile

Brief di partenza

Task
Completa il workflow richiesto nell’applicazione indicata.
Scope
Usa solo account, record e sistemi di destinazione approvati.
Escalate when
lo stato di login è ambiguo, serve approvazione di policy o il flusso esce dal perimetro approvato.
Success signal
il workflow termina con checkpoint visibili ed evidenze ispezionabili.

Checklist passo-passo

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

Livelli di escalation e governance

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

Tier 1 — AutonomousNavigazione reversibile e raccolta informazioniBassoPre-approvato all’avvio
Tier 2 — SupervisedModifiche record, cambi cross-system, transizioni ambigueMedioCheckpoint review
Tier 3 — BlockedPagamenti, cancellazioni, messaggi esterni, azioni sensibiliAltoSign-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
Pattern Blueprint
Run view persistente con stato, checkpoint e blocchi
Anti-pattern
L’agente decide da solo quando serve approvazione
Pattern Blueprint
Livelli di approvazione definiti prima dell’esecuzione
Anti-pattern
Retry e loop invisibili
Pattern Blueprint
Stati di attesa, retry ed errore espliciti
Anti-pattern
Contesto account generico
Pattern Blueprint
Perimetro esplicito di app, account e ambiente
Anti-pattern
Messaggio finale senza traccia
Pattern Blueprint
Screenshot, checkpoint ed evidenze consultabili

Prova reale

Scenario illustrativo

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.
Valida l'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

Applicare la divulgazione progressiva all'agenzia del sistema

Leggi →Leggi il Principio 8

Rendere espliciti i passaggi, le approvazioni e i blocchi

Leggi →