Guida applicativaWeb pubblico

Se un agente può agire sul tuo sito, ogni azione deve avere confini chiari, stato visibile e approvazioni esplicite.

WebMCP cambia il modo in cui un sito viene usato dagli agenti: invece di interpretare il DOM o simulare clic, l’agente può invocare strumenti dichiarati in modo diretto. Questo rende il web più adatto al lavoro delegato, ma impone una progettazione molto più rigorosa. Il punto non è più capire se un agente riesce a completare un flusso. Il punto è progettare azioni come transazioni delimitate, con input comprensibili, avanzamento visibile, blocchi espliciti e momenti di approvazione umana ben definiti.

Fatti chiave

Cambio chiave: Si passa dalla simulazione di clic a strumenti dichiarati con input, output e vincoli espliciti.
Rischio principale: La delega diventa insicura quando il sito espone azioni senza confini chiari di approvazione e fallimento.
Unità di progetto: Ogni azione invocabile da un agente va trattata come una transazione, non come una scorciatoia nascosta della UI.
Esigenza utente: Le persone devono poter ispezionare, guidare, mettere in pausa, approvare o rifiutare il lavoro delegato.

Dal browser automation alle superfici operative dichiarate

Il web tradizionale presume un utente presente in ogni momento, capace di leggere, cliccare e correggere gli imprevisti strada facendo. Con gli agenti questa premessa salta. Un sistema delegato può cercare, confrontare, preparare opzioni e portare avanti attività in background, tornando dall’utente solo quando serve una decisione, una conferma o una gestione dell’eccezione. Applicare il Blueprint significa quindi progettare gli strumenti WebMCP come superfici operative: devono esprimere intenzione, vincoli e risultati in termini utili per la persona, rendere percepibile il lavoro in corso senza scaricare complessità interna, e segnalare in modo inequivocabile ogni passaggio di mano o confine di approvazione.

Perché l’approccio standard non funziona con le azioni agentiche sui siti pubblici?

Perché è stato progettato per la manipolazione diretta da parte di una persona attenta, non per l’esecuzione delegata da parte di un agente che opera su più passaggi e anche fuori dal focus dell’utente. Scraping del DOM, replay dei clic e interpretazione visiva permettono di imitare il comportamento umano, ma non di rendere chiari intenzione, responsabilità e confini decisionali.

Un singolo clic spesso concentra validazione, effetti collaterali e conferma finale in un unico punto opaco, quindi l’agente non ha un confine pulito per operare in sicurezza.

L’automazione del browser dipende dalla struttura della pagina e da indizi visivi, perciò il sistema sa imitare l’azione ma non spiegarla in termini rilevanti per l’utente.

Quando il lavoro prosegue in background, le pagine tradizionali comunicano male se l’agente sta cercando, aspettando, è bloccato o è pronto per una conferma.

L’utente fatica a verificare come è stato prodotto un risultato, e questo riduce la fiducia quando sono coinvolti pagamenti, identità, prenotazioni o invii formali.

La correzione arriva tardi perché il flusso è pensato per avviare un compito, non per governarlo mentre è in corso.

Quali modalità di fallimento strutturale devono aspettarsi i team quando espongono strumenti WebMCP?

I problemi principali emergono quando si espone una capacità senza esporre anche la struttura operativa che la governa. Se il sito pubblica strumenti ma non definisce stato, approvazioni, blocchi e punti di revisione, l’agente può agire tecnicamente ma l’utente non riesce davvero a controllare il lavoro.

Strumenti troppo ampi uniscono scoperta, selezione e conferma finale in una sola chiamata, rendendo ambiguo il confine tra preparazione e transazione vera e propria.

Le approvazioni implicite nascono quando preferenze salvate, sessioni attive o metodi di pagamento predefiniti permettono di oltrepassare un confine critico senza una conferma distinta.

I blocchi silenziosi compaiono quando stock, verifiche identitarie, regole di policy o dipendenze esterne fermano il processo ma vengono mostrati solo come errori generici.

Output poco ispezionabili restituiscono un risultato senza prove, contesto o motivazioni sufficienti per valutarne l’affidabilità.

Una rappresentazione solo conversazionale appiattisce il lavoro multi-step in una sequenza di messaggi, nascondendo dipendenze, retry e decisioni in sospeso.

Qual è il modello sostitutivo proposto dal Blueprint per le superfici d’azione WebMCP?

Il modello corretto è trattare le capacità esposte al mondo agentico come superfici transazionali esplicite. Ogni superficie dovrebbe separare raccolta dell’intento, preparazione in background, risultato revisionabile e conferma finale. L’utente delega il lavoro, il sistema rende percepibile l’avanzamento, e le approvazioni vengono richieste solo nei punti in cui cambiano davvero autorità, rischio o irreversibilità.

Definisci gli strumenti attorno all’intento dell’utente, per esempio cercare, ottenere un preventivo, bloccare una disponibilità, preparare un checkout o creare una bozza.

Esponi stati significativi come preparazione opzioni, verifica identità richiesta, prezzo cambiato, pronto per approvazione, completato o fallito con azione necessaria.

Usa disclosure progressiva: di default mostra stato e conseguenza, mentre il dettaglio deve permettere di vedere input usati, strumenti invocati e prove raccolte.

Rendi espliciti i confini di approvazione separando la preparazione reversibile dalla conferma irreversibile, come acquisto, prenotazione, pubblicazione o invio regolamentato.

Supporta la guida in corso d’opera con controlli per affinare vincoli, sostituire opzioni, cambiare priorità, mettere in pausa o passare a un canale umano.

Come si implementano in pratica confini di approvazione e transazioni sicure?

Conviene partire classificando ogni azione invocabile da un agente in un livello di rischio e associando a ciascun livello un pattern di approvazione coerente. L’obiettivo non è bloccare l’automazione, ma fare in modo che il grado di autonomia sia proporzionato alle conseguenze dell’azione e alla possibilità dell’utente di ispezionare o intervenire.

Livello 1, basso rischio: ricerche, controlli di disponibilità, lookup informativi o preventivi possono avvenire senza approvazione, ma con stato visibile e contesto della fonte.

Livello 2, rischio medio: composizione carrello, hold di prenotazione, bozze di richiesta o modifiche account dovrebbero richiedere revisione prima della conferma finale e mostrare scadenze, assunzioni e dipendenze.

Livello 3, alto rischio: pagamento, prenotazione definitiva, invio regolamentato o modifiche legate all’identità devono richiedere un’approvazione esplicita riferita a quel riepilogo transazionale preciso.

Ogni schermata di approvazione deve chiarire cosa accadrà, cosa non sarà annullabile, quali dati verranno usati e cosa è cambiato dall’avvio del compito.

Quando il sistema è bloccato, restituisci un motivo azionabile come rifare l’autenticazione, confermare un nuovo prezzo, verificare l’età o scegliere un articolo alternativo, non un errore generico.

Quando bisogna passare da una semplice esposizione di tool a un vero sistema di transazioni agentiche?

Bisogna fare questo salto quando il lavoro delegato diventa multi-step, asincrono o abbastanza delicato da rendere insufficiente una semplice lista di strumenti. A quel punto il problema di design non è più solo l’accesso alle capability, ma l’orchestrazione del lavoro, la revisione e la governance di un sistema visibile.

Resta su un livello base quando gli strumenti sono in sola lettura, immediati e facilmente reversibili, come recupero contenuti o discovery semplice.

Aggiungi stato strutturato del job quando i compiti richiedono tempo, dipendono da sistemi esterni o producono output intermedi da rivedere.

Introduci code di approvazione e viste di audit quando più transazioni possono essere preparate in parallelo o quando l’utente deve confrontare alternative prima di decidere.

Aggiungi controlli organizzativi quando le azioni delegate coinvolgono team, budget condivisi, vincoli di policy o autorità basata sui ruoli.

Passa a piena ispezionabilità quando fiducia, compliance o gestione delle contestazioni dipendono dalla possibilità di vedere come l’agente è arrivato a una raccomandazione o ha preparato una transazione.

Leggi il Principio 1 Leggi il Principio 8