Ogni azione web richiamabile da un agente è una transazione.
L'automazione browser nascosta rende non sicure le azioni sui siti pubblici. Le action surface WebMCP definiscono le quattro parti di ogni transazione sicura: input, stato, review, approvazione.
Aggiornato 21 aprile 2026
Fatti chiave
- Best fit
- Team di prodotto che progettano siti pubblici con azioni richiamabili da agenti, soprattutto in commerce, travel, assistenza, form e operazioni account
- Primary risk
- Commit opaco dell’azione: l’agente passa dalla preparazione all’esecuzione senza un confine di approvazione visibile
- Core shift
- Automazione browser nascosta → transazioni web esplicite con input, stati e regole di approvazione dichiarati
- Success signal
- Gli utenti vedono cosa ha preparato l’agente, cosa è bloccato, cosa richiede approvazione e cosa è stato eseguito
- Doctrine mapping
- P1, P7, P8, P9
In questa sezione
Dalla UI cliccabile alla progettazione di transazioni
Con WebMCP cambia il problema di design dei siti pubblici. Quando un agente può chiamare strumenti dichiarati invece di indovinare attraverso il DOM, le tue azioni non sono più scorciatoie dell’interfaccia: diventano contratti operativi. Una prenotazione, un invio modulo, un aggiornamento account, un pagamento o una modifica massiva hanno bisogno di un confine chiaro, di avanzamento visibile, di blocchi espliciti e di un momento di approvazione ben nominato. Se non progetti questi elementi in modo diretto, gli utenti delegano comunque il lavoro, ma lo fanno dentro un’automazione opaca, con poca fiducia e poco controllo. Written by the AI Design Blueprint editorial team. Doctrine grounded in the 10 Blueprint Principles.
Perché l’approccio standard alle azioni WebMCP fallisce?
Molti team partono dall’eredità sbagliata: un sito pensato per un umano attento, poi adattato in modo leggero per un agente. Da qui nascono failure mode ricorrenti.
Failure mode 1: Opaque Click Commit.
Una singola azione accorpa validazione, effetti collaterali e commit in un passaggio nascosto. L’agente può attivarla, ma l’utente non può ispezionare cosa cambierà prima che diventi reale. La conseguenza è esecuzione accidentale e scarsa accountability.
Failure mode 2: Background Drift.
Il sito permette all’agente di cercare, confrontare e mettere in coda attività in modo asincrono, ma mostra poco più di uno spinner o di un messaggio in chat. L’utente non capisce se l’agente stia aspettando, sia bloccato, stia ritentando o sia pronto per la revisione. Il risultato è abbandono e lavoro duplicato.
Failure mode 3: Auditless Automation.
Il sistema produce un esito senza una traccia leggibile di input, decisioni e blocchi. Quando una prenotazione fallisce o un’azione massiva tocca gli elementi sbagliati, il team non ha una superficie di ispezione utile per fare debug o giustificare il risultato.
Quali anti-pattern WebMCP devi sostituire?
Sostituisci questi errori con pattern Blueprint basati su P6 – Expose meaningful operational state, not internal complexity, P7 – Establish trust through inspectability e P9 – Represent delegated work as a system, not merely as a conversation.
Anti-pattern
Commit via replay dei click
Blueprint pattern
Transazione dichiarata con fasi separate di prepare, review e commit
Anti-pattern
Stato dedotto da screenshot o segnali indiretti
Blueprint pattern
Stati operativi nominati come In esecuzione, In attesa di approvazione o Bloccato
Anti-pattern
Approvazioni gestite solo in chat
Blueprint pattern
Superficie dedicata di approvazione con diff dei campi, evidenze e azioni esplicite di accetta o rifiuta
Anti-pattern
Errori grezzi di API o automazione
Blueprint pattern
Blocchi rilevanti per l’utente con causa, owner e prossima azione
Anti-pattern
Flusso one-shot di sola partenza
Blueprint pattern
Lavoro governabile con pausa, modifica vincoli, riprioritizzazione, retry e cancel
Che aspetto ha una prova reale in WebMCP?
Queste tracce mostrano in pratica P7 – Establish trust through inspectability e P8 – Make hand-offs, approvals, and blockers explicit.
FAQ sui confini di approvazione WebMCP
Le risposte qui sotto seguono P1 – Design for delegation rather than direct manipulation, P4 – Apply progressive disclosure to system agency e P8 – Make hand-offs, approvals, and blockers explicit.
Checklist iniziale per action surface WebMCP
Usa questa lista per applicare P1 – Design for delegation rather than direct manipulation e P8 – Make hand-offs, approvals, and blockers explicit.
Principi di riferimento