La domanda che mi fanno più spesso sugli agenti AI non è come funzionano. È: sì, ma in concreto cosa sanno fare?
È una domanda giusta, perché la distanza fra la demo e il lavoro vero, su questa tecnologia, è stata enorme per due anni. Qui la risposta passa per i compiti concreti, gli strumenti necessari a portarli a termine e i casi in cui gli agenti falliscono ancora.
Parlo di agenti dentro il browser, quelli che lavorano su una pagina aperta mentre la persona guarda. Non di sistemi che girano su un server per conto tuo.
Primo: comprare #
È il caso in cui la differenza si vede subito, perché il compito è noioso e ripetitivo e nessuno lo fa volentieri.
La spesa complicata. Una persona deve comprare gli addobbi per il compleanno di un figlio, tema spaziale, lista già scritta. Chiede al proprio agente di trovare i prezzi migliori su due o tre negozi vicini, di riempire la lista dei desideri e di segnalare cosa non si trova.
Sembra un compito solo, ma richiede tre strumenti diversi:
search_products()con parametri veri, tipoproductType="decorazioni-parete",category="pianeti",age="bambino". Non una ricerca testuale: una ricerca che sa che cos’è una categoria.refine_search(priceRange = "0-49.99")per quando la richiesta ha un tetto di spesa.add_to_wishlist()invece di aggiungere direttamente al carrello, così la persona rivede tutto prima di pagare.
Quel terzo punto è la scelta di progetto che conta. L’agente prepara, l’umano conferma. Un sito che lascia all’agente l’ultima parola sull’acquisto spaventa chi lo usa, e difficilmente verrà usato una seconda volta.
Il riacquisto. "Puoi riordinare i bastoncini di formaggio che ho preso il mese scorso?" Qui non serve un abbonamento, serve che l’agente possa guardare indietro:
get_order_history(startdate, enddate)che restituisce prodotto, data e stato della consegna.add_to_wishlist(productId, quantity).delivery(method="pickup").
E la risposta che l’utente riceve è "ho trovato il tuo ordine del 7 marzo, ne ho aggiunto una confezione al carrello, procedo?". Non un elenco di link.
Secondo: compilare moduli lunghi #
Questo è il caso meno vistoso e probabilmente il più redditizio, perché il problema esiste da vent’anni e non l’ha risolto nessuno.
Il riempimento automatico del browser, quando è implementato bene, abbassa l’abbandono dei moduli del 75%. Ma funziona solo sui campi standard: nome, indirizzo, carta. Su un modulo aziendale vero non arriva.
L’esempio della documentazione Chrome è un rapportino ore in uno studio legale, dove avvocati e fornitori esterni compilano lo stesso modulo con regole diverse, e la fatturazione dipende da chi ha messo cosa in quale categoria. Un agente che riceve "segna tre ore di sviluppo di ieri sul cliente Rossi" e sa dove metterle elimina un attrito che nessun riempimento automatico tocca.
Il vantaggio non è la velocità, è la correttezza: uno strumento dichiarato può distinguere se un campo vuole il nome completo oppure nome e cognome separati. Dedurlo guardando l’etichetta è esattamente il punto in cui gli agenti sbagliano.
Terzo: assistenza #
Il flusso di assistenza è il posto dove le persone si perdono di più, perché l’azienda lo ha progettato attorno alla propria organizzazione interna e non attorno al problema di chi scrive.
Uno strumento submit_application o create_support_request permette all’agente
di portare la persona sul modulo giusto e di riempirlo con quello che ha già
raccolto nella conversazione, invece di farle scegliere fra sette reparti di cui
non conosce i nomi.
Variante utile e poco ovvia: run_diagnostics in una pagina di impostazioni, così
un agente può attivare una correzione che oggi è sepolta sotto quattro menu.
Le regole che fanno la differenza #
Qui si trova la parte che separa un’implementazione che funziona da una che sembra funzionare nella demo. Sono poche e sono tutte controintuitive almeno in parte.
Uno strumento, un compito. Se due strumenti si sovrappongono, l’agente non sa quale scegliere e sbaglia. La domanda da farsi è: posso coprire più casi con la stessa funzione? Se la risposta è sì, allora sono uno strumento solo.
I nomi devono distinguere l’avvio dall’esecuzione. create-event crea un
evento subito. start-event-creation-process porta la persona su un modulo.
Chiamarli allo stesso modo è il modo più veloce per far compiere all’agente un’azione
irreversibile quando doveva solo aprire una schermata.
Le descrizioni si scrivono in positivo. "Questo strumento crea un evento in calendario a una data e un’ora precise" funziona. "Non usare questo strumento per il meteo" no: i limiti devono essere impliciti in una descrizione scritta bene. È lo stesso principio dei prompt, e vale anche qui.
Meno strumenti, non più. Un tetto massimo non esiste, ma ognuno occupa spazio nel contesto del modello e allunga i tempi. Più ne offri e più si somigliano, più diventa difficile scegliere quello giusto.
Registra e togli. Uno strumento va registrato quando serve nello stato attuale della pagina, e tolto quando non serve più. Detto questo, per la maggior parte dei siti la registrazione statica è la scelta giusta: la gestione dinamica è complessità che si paga.
Fidati dell’agente. Istruzioni rigide e passo passo peggiorano il risultato. Il modello capisce cosa serve per chiudere il compito; se lo costringi a una sequenza esatta, si rompe al primo caso che non avevi previsto.
Dove fallisce #
Tre limiti veri, dichiarati nella documentazione Chrome e non nascosti nelle note.
Serve una scheda aperta. Le chiamate girano in JavaScript dentro il documento, quindi serve un browser visibile. Niente lavoro in sottofondo, niente agente che opera di notte.
Le interfacce complesse costano. Se il tuo sito è un’applicazione vera, non ti basta annotare due moduli: devi rifattorizzare, gestire lo stato, decidere cosa esporre in quale schermata.
Nessuno sa che i tuoi strumenti esistono. Un client li scopre solo visitando la tua pagina. Non esiste un registro, né un file da mettere nella cartella principale. Quindi questa tecnologia non ti porta agenti: serve a servire meglio quelli che sono già arrivati.
E allora a chi serve, oggi #
A chi ha una superficie transazionale vera: un carrello, un catalogo con filtri, un flusso di prenotazione, un modulo lungo che le persone sbagliano, un’area di assistenza. Lì la differenza fra un agente che ci azzecca e uno che si perde si misura in ordini e in ticket.
A chi ha un sito fatto di pagine da leggere, no. E non per prudenza: perché non c’è niente da esporre. Un agente su un portfolio deve capire un testo, e capire i testi è ciò che i modelli fanno meglio.
Un principio però vale per tutti, e non richiede di scrivere una riga: gli
agenti se la cavano molto meglio su HTML scritto bene. Moduli che sono moduli,
campi con un name sensato, ogni controllo con la sua etichetta. È lo stesso
lavoro che rende un sito accessibile, e adesso ha un secondo motivo per essere
fatto.
Domande frequenti sugli agenti AI nel browser #
Cosa sa fare oggi un agente AI su un sito, in concreto? #
Tre famiglie di compiti: acquisti, dalla ricerca al riordino di qualcosa comprato mesi fa; compilazione di moduli lunghi con dati raccolti in conversazione; e navigazione di flussi di assistenza complessi. Tutti richiedono che il sito dichiari le proprie funzioni, altrimenti l’agente procede per tentativi.
Serve WebMCP perché un agente usi il mio sito? #
No. Un agente può usare qualsiasi sito simulando clic e digitazione. WebMCP serve a renderlo affidabile: dichiarando gli strumenti si passa dall’interpretazione a una chiamata prevedibile.
Quanti strumenti conviene esporre? #
Pochi e distinti. Nessun limite è fissato, ma ogni strumento occupa spazio nel contesto del modello e allunga i tempi, e strumenti che si somigliano rendono la scelta più difficile. Meglio cinque funzioni nette che quindici sovrapposte.
Un agente può comprare qualcosa senza che io lo confermi? #
Dipende da come è scritto lo strumento. Le azioni irreversibili vanno marcate con
consequentialHint: true, che obbliga il browser o l’agente a chiedere conferma
prima di eseguire. La buona pratica è comunque far preparare l’ordine all’agente
e lasciare la conferma alla persona.
Il mio sito è una vetrina. Devo fare qualcosa? #
Scrivere HTML semantico, che dovresti fare comunque. Moduli veri, campi con nomi sensati, etichette collegate. Non serve altro: senza una transazione da compiere, non esistono strumenti sensati da dichiarare.
Un agente può lavorare mentre il sito è chiuso? #
Non con gli strumenti che vivono nella pagina: quelli esistono solo a scheda aperta. Per le funzioni che devono valere sempre serve MCP, che vive sul server.
Fonti #
Casi d’uso di WebMCP, buone pratiche, sicurezza degli strumenti e API imperativa su developer.chrome.com, aggiornate al 1 settembre 2026.