Che cos’è l’uso del computer e perché è importante? L’uso del computer è un’idea semplice dalle ampie implicazioni: anziché chiedere ai modelli di rispondere a domande, chiediamo loro di usare software, navigando sui siti web, compilando moduli, avanzando nei flussi di lavoro con i clic e completando autonomamente le attività dall’inizio alla fine.
Questo rende possibile un’ampia categoria di attività reali oggi frammentate tra diverse interfacce, come prenotazioni complete, procedure di acquisto nell’e-commerce, pianificazione di viaggi in più fasi e flussi di back office privi di un equivalente API adeguato. Non sono problemi nuovi. La novità è la possibilità concreta di risolverli con modelli generalisti.
Sistemi recenti di Anthropic e OpenAI hanno dimostrato l’efficacia di agenti che non si limitano ad agire, ma ragionano sullo stato, recuperano dagli errori e creano al volo soluzioni specifiche per l’attività. In questo modo il browser diventa un ambiente di esecuzione generale per gli agenti, ma sorge subito una domanda progettuale: quanta parte di tale ambiente dobbiamo esporre al modello?
I primi sistemi hanno risposto racchiudendo il browser in un insieme fisso di azioni sicure e predefinite. Come sosteniamo in questo articolo, tale approccio sta raggiungendo i propri limiti.
Nello sviluppo di agenti per browser emerge un istinto ben noto: non fidarsi troppo del modello.
Perciò racchiudiamo il browser in un wrapper. Esponiamo strumenti predefiniti come click, type, scroll, select e read_text. Semplifichiamo il Document Object Model (DOM). Riduciamo lo spazio delle azioni. Cerchiamo di rendere il comportamento comprensibile e controllabile mediante astrazioni progettate da noi.
È un punto di partenza ragionevole. Ma, sempre più spesso, è anche l’architettura sbagliata nel lungo periodo.
Con il miglioramento dei modelli di frontiera, il limite non è più soltanto la mancanza di strumenti a disposizione del modello. Il problema è che lo costringiamo a operare attraverso astrazioni che eliminano troppi dettagli del sistema sottostante. Comprimiamo un ambiente caotico e dinamico in un’interfaccia di azioni fissa, quindi chiediamo al modello di funzionare bene nonostante questa perdita di informazioni.
Questo compromesso è sempre meno vantaggioso.
Il cambiamento che stiamo esplorando è semplice da descrivere, ma ha conseguenze rilevanti. Anziché considerare l’agente come un selettore di azioni predefinite, lo trattiamo come un sintetizzatore di programmi che opera all’interno di un runtime vincolato.
I modelli sono diventati davvero capaci e non hanno più bisogno di protezioni astratte: serve loro l’intero spazio delle azioni per progettare, eseguire e perfezionare l’attività finché non raggiungono l’obiettivo.
Questo articolo tratta tale passaggio, dall’automazione del browser ricca di astrazioni all’uso vincolato del computer, e ciò che cambia quando i sistemi vengono progettati in questo modo.
Il problema non è che le interfacce ad azioni fisse siano concettualmente sbagliate. È il web a non adattarsi a esse.
Le interfacce moderne sono basate su React, Vue e Angular, con aggiornamenti asincroni dello stato, sistemi di eventi sintetici e widget di terze parti incorporati in iframe cross-origin dotati di un proprio ciclo di vita. Un wrapper che ordina di «digitare in questo campo» funziona soltanto se la pagina condivide la sua definizione di digitazione. Molte pagine non lo fanno. L’impostazione diretta di un valore spesso aggira completamente il rilevamento delle modifiche del framework. Il campo appare compilato. La convalida non si attiva. Il modulo continua a non funzionare.
È possibile applicare una correzione. Si possono aggiungere casi speciali per i campi React, generare eventi blur dopo il focus e attendere che la rete sia inattiva prima di leggere lo stato. Ogni correzione è valida nel proprio contesto. Nel complesso, però, queste correzioni si accumulano in un sistema sempre più difficile da mantenere e sempre più specifico per i siti già incontrati.
Il problema più profondo è che il livello di astrazione codifica ipotesi sul funzionamento delle interazioni, per poi scontrarsi con le diverse convenzioni del web.
Consideriamo un modulo di pagamento Stripe o Adyen incorporato in un iframe cross-origin. Il wrapper non può raggiungerlo direttamente perché risiede in un’origine distinta. Lo strumento read_text non può osservarne lo stato interno. Lo strumento type non può accedere ai suoi campi. Qui un agente basato su wrapper si trova davanti a un ostacolo insormontabile. L’astrazione è stata progettata per il documento principale. L’attività effettiva si trova in un punto invisibile all’astrazione.
Una discrepanza simile emerge in flussi meno evidenti. Un menu a discesa controllato dal framework potrebbe non rispondere affatto ai clic diretti, perché l’elemento visibile non è il vero controllo. Potrebbe richiedere una sequenza di eventi da tastiera per attivare la transizione di stato sottostante. Dall’esterno, l’interfaccia utente sembra consentire il clic. L’astrazione dice «fai clic». Non succede nulla.
Oppure consideriamo un flusso modale in più fasi, in cui gli aggiornamenti del DOM visibile arrivano in ritardo rispetto alle modifiche dello stato interno. L’azione successiva corretta dipende da una transizione di stato che non è ancora riflessa negli elementi visibili al wrapper. Un agente basato su wrapper finisce per agire troppo presto o leggere uno stato obsoleto, perché opera su una visione incompleta del sistema.
In ogni caso, l’astrazione nasconde i segnali di cui l’agente ha realmente bisogno.
Un modello che opera a un livello inferiore, esaminando il DOM attivo, ragionando sui confini dei frame e sintetizzando la sequenza di interazione per quella specifica superficie, può gestire queste situazioni. Non perché il modello sia intrinsecamente più intelligente. Ma perché ha accesso alle informazioni che erano state eliminate.
Il cambiamento verso cui stiamo lavorando è semplice da descrivere: anziché chiedere al modello di scegliere tra azioni predefinite, gli forniamo una superficie di esecuzione di livello inferiore e la vincoliamo mediante politiche di runtime, non tramite la progettazione delle astrazioni.
Questa scelta progettuale nasce da un cambiamento più ampio nel settore, che sta iniziando a privilegiare strumenti primitivi di livello inferiore: strumenti che sfruttano la capacità innata dell’agente di correggersi durante l’esecuzione e produrre codice di alta qualità, anziché strumenti specifici codificati rigidamente che, pur essendo robusti, riducono la capacità del modello di adattarsi ad ambienti diversi.
Basti pensare al successo di Claude Code come strumento di riferimento per molti sviluppatori e alla più ampia evoluzione del settore verso gli agenti basati su terminale. Il maggiore vantaggio di Claude Code non è il modello in sé, ma l’infrastruttura di livello inferiore. Fornire al modello meno strumenti, ma più modulari e di livello inferiore, ossia il terminale, migliora l’uso degli strumenti soprattutto perché l’agente può ragionare e creare script personalizzati per l’attività corrente, anziché tentare di usare strumenti generalizzati che affollano la finestra di contesto.
In pratica, per l’automazione del browser ciò significa che il modello può esaminare direttamente lo stato attivo della pagina, attraversare i frame e creare codice di interazione su misura per l’interfaccia corrente, anziché ricondurre tutto a un insieme fisso di azioni predefinite.
Il modello si comporta meno come un selettore e più come un autore di logica eseguita durante il runtime. Esamina lo stato corrente, ragiona sull’interfaccia e sintetizza la logica di interazione per quella specifica situazione. Può costruire sequenze in più passaggi, adattarsi a flussi insoliti e convalidare i risultati prima di proseguire. Quando un’azione non riesce, il modello vede l’errore sottostante e si corregge autonomamente. È un approccio più potente e più rischioso, ma molto più vicino alla vera natura del problema.
È importante sottolineare che la rimozione del livello di astrazione non rende il sistema meno rigoroso. Sposta il rigore altrove.
Il lavoro prima concentrato nella progettazione dei wrapper e nella gestione dei casi limite si sposta in tre aree: il prompt, che diventa una forma di formazione operativa; il runtime, che applica vincoli quali l’ambito di navigazione, le azioni sensibili e il comportamento dei nuovi tentativi; il livello di valutazione, che stabilisce non solo se l’attività è riuscita, ma anche se i passaggi intermedi erano corretti. Meno astrazioni fragili. Sistemi circostanti più solidi.
Uno degli esiti di questo cambiamento è che spesso il codice del prodotto si semplifica, mentre il sistema nel suo complesso diventa più capace. Anziché codificare gli schemi di interazione come wrapper riutilizzabili, l’agente sintetizza il comportamento durante l’esecuzione. Si mantiene un insieme ridotto di primitive potenti e un ambiente di esecuzione vincolato, anziché una gamma crescente di strumenti specializzati e logica per i casi limite.
Questo cambia anche il modo in cui il sistema generalizza. Un agente basato su wrapper generalizza bene per le attività simili a quelle dei wrapper già realizzati. Un agente con runtime vincolato generalizza per le attività che condividono la stessa base di esecuzione, anche se l’interfaccia visibile è diversa.
Ad esempio, interagire con un modulo di ricerca, una procedura di prenotazione o una pagina delle impostazioni può apparire del tutto diverso a livello di interfaccia utente. Ma alla base condividono gli stessi schemi: lettura dello stato, attivazione di eventi, convalida dei risultati e gestione degli aggiornamenti asincroni. Un sistema che opera a quel livello si adatta più naturalmente ad attività diverse.
Il componente riutilizzabile non è l’elenco delle azioni, ma la capacità del modello di esaminare lo stato, agire in sicurezza e verificare i risultati.
La lezione più chiara di questo lavoro è che l’affidabilità non deriva dal fornire al modello più funzioni ausiliarie. Spesso deriva dal fornirgli meno primitive, ma più potenti, vincolandole nel modo giusto. Un’assistenza eccessiva incorpora nel codice ipotesi rigide su come svolgere un’attività. I vincoli definiscono confini operativi sicuri e consentono al modello di trovare soluzioni locali migliori.
Una superficie di esecuzione più potente richiede anche un modello di sicurezza più rigoroso. Quando l’agente non è più limitato a un piccolo insieme di azioni predefinite, di fatto opera direttamente su software reale. Questo modifica immediatamente il profilo di rischio.
La progettazione deve tenere conto di quattro aspetti:
Esposizione dei dati. Se l’agente interagisce con interfacce reali, spesso incontra informazioni sensibili. Serve quindi un approccio rigoroso all’occultamento dei dati e al controllo degli accessi. I dati devono essere rivelati solo quando necessari all’esecuzione, mentre log e tracce vanno gestiti con attenzione, affinché l’osservabilità non diventi la parte più sensibile del sistema.
Ambito di esecuzione. Un agente potente non deve poter operare arbitrariamente. In pratica, occorre limitare dove può navigare, a quali domini può accedere e con quali sistemi può interagire. Questi vincoli vanno applicati a livello di runtime, non lasciati come semplici convenzioni nel prompting.
Affidabilità dell’ambiente. Le interfacce moderne possono includere istruzioni, contenuti o flussi fuorvianti o persino ostili. L’iniezione di prompt attraverso i contenuti delle pagine costituisce una reale superficie di attacco. Il sistema deve disporre di una chiara gerarchia delle istruzioni, controlli di convalida e condizioni di arresto per impedire all’agente di seguire indicazioni indesiderate.
Spettro di autonomia. Non tutte le azioni devono essere completamente autonome. In molti ambienti di produzione è importante considerare l’autonomia come uno spettro. Il sistema può essere altamente agentico nell’esplorazione e nell’esecuzione, pur richiedendo l’approvazione per determinate categorie di azioni.
Il principio alla base è semplice: dare più potere al modello richiede di rafforzare il sistema che lo circonda. L’autonomia senza regole non è pronta per la produzione.
Abbiamo smesso di chiederci: quali azioni del browser è opportuno esporre?
Abbiamo iniziato a chiederci: come possiamo offrire al modello uno spazio delle azioni completo e definire al contempo politiche di runtime che lo mantengano sicuro?
Questa nuova prospettiva cambia le priorità. Le tassonomie delle azioni e la completezza dei wrapper diventano meno importanti. Acquistano invece importanza le politiche di runtime, l’osservabilità e la valutazione di ogni singolo passaggio. Le capacità del modello e la progettazione del sistema non sono intercambiabili. Con il miglioramento dei modelli, il lavoro svolto dal sistema diventa più importante, non meno.
Gli agenti per browser che funzionano nelle demo spesso riescono perché l’attività è circoscritta e l’ambiente è favorevole. I sistemi di produzione richiedono altro: esecuzione vincolata, comportamento strumentato e una valutazione capace di distinguere un risultato corretto da uno fortunato.
Meno progettazione di wrapper. Più ingegneria dei sistemi.
Sebbene ci siamo concentrati sugli agenti per browser, ciò suggerisce un modo più ampio di concepire l’uso del computer come disciplina sistemistica.