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.
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
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.
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
- Pattern Blueprint
- Transazione dichiarata con fasi separate di prepare, review e commit
- Anti-pattern
- Stato dedotto da screenshot o segnali indiretti
- Pattern Blueprint
- Stati operativi nominati come In esecuzione, In attesa di approvazione o Bloccato
- Anti-pattern
- Approvazioni gestite solo in chat
- Pattern Blueprint
- Superficie dedicata di approvazione con diff dei campi, evidenze e azioni esplicite di accetta o rifiuta
- Anti-pattern
- Errori grezzi di API o automazione
- Pattern Blueprint
- Blocchi rilevanti per l’utente con causa, owner e prossima azione
- Anti-pattern
- Flusso one-shot di sola partenza
- Pattern Blueprint
- Lavoro governabile con pausa, modifica vincoli, riprioritizzazione, retry e cancel
Che aspetto ha una prova reale in WebMCP?
Scenario illustrativoQueste tracce mostrano in pratica P7 – Establish trust through inspectability e P8 – Make hand-offs, approvals, and blockers explicit.
Un team ha usato uno strumento pubblico per richieste di preventivo. L’agente ha provato a confrontare tre corrieri, precompilare i dati di spedizione e inviare la copertura assicurativa. Il sistema ha escalato prima del commit perché la transazione passava dalla semplice comparazione prezzi a una selezione assicurativa vincolante. Il pannello di review mostrava campi modificati, preventivi sorgente e il flag merci pericolose mancante, così l’operatore ha approvato una sola opzione.
Un team ha usato un portale resi con azioni WebMCP. L’agente ha tentato di generare etichette per 120 ordini e pianificare i ritiri in bulk. Il sistema ha bloccato l’esecuzione perché 18 ordini richiedevano dichiarazioni doganali e conferma del metodo di pagamento in base alla destinazione. Il sito ha mostrato il blocco come “Documentazione export mancante” invece di errori grezzi, e l’operatore ha deviato solo il batch interessato mentre il resto completava.
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.
- Elenca ogni azione del sito pubblico che un agente potrebbe chiamare direttamente.
- Segna dove ogni azione passa dalla preparazione all’impegno nel mondo reale.
- Assegna Tier 1, Tier 2 o Tier 3 a ciascuna action surface.
- Definisci stati operativi e messaggi di blocco comprensibili per l’utente.
- Aggiungi una superficie di review con evidenze, diff e controlli espliciti di approva o rifiuta.
- Strumenta i log in modo che il team possa ispezionare come sono stati prodotti gli esiti.
- Open Blueprint to validate your architecture
Principi di riferimento