Personal Agent Protocol: l'assistente AI che entra nel tuo sito al posto del cliente

Il 9 ottobre Sierra e Meta hanno pubblicato la bozza dello standard con cui gli assistenti personali trovano un'azienda, entrano con l'account del cliente e fanno le cose per lui. Cos'è, come funziona e cosa conviene fare adesso.

Personal Agent Protocol: l'assistente AI che entra nel tuo sito al posto del cliente

Finora la GEO ha misurato una cosa sola, cioè se un modello ti nomina quando qualcuno gli chiede un consiglio. È già tanto, ma si ferma sulla soglia: la persona legge la risposta, apre il sito e da lì in poi fa tutto da sola. Il 9 ottobre Sierra e Meta hanno pubblicato la bozza di uno standard che sposta il problema un passo più in là, perché a entrare nel sito non sarà più la persona ma il suo assistente.

Si chiama Personal Agent Protocol, in breve "Poppy". L'hanno annunciato il 6 ottobre insieme a Genesys, Instinct, Rocket, Shopify, Stripe e Walmart, e tre giorni dopo è uscita la prima bozza della specifica, la 0.1, con licenza Apache 2.0. Gli autori lo dicono chiaro: è un punto di partenza e cambierà, anche in modo non compatibile, prima di arrivare alla 1.0.

Cosa risolve

Oggi un assistente AI che vuole fare qualcosa per te su un sito ha due strade, entrambe brutte. O fa finta di essere un browser e clicca dove pensa che vadano i bottoni, o gli dai la tua password e speri bene. L'azienda dall'altra parte non sa chi è, non sa cosa può fare e non ha modo di fermarlo se esagera.

Il protocollo mette d'accordo i tre che sono coinvolti. La persona decide quanto accesso dare al suo assistente, l'azienda decide cosa l'assistente può fare, e tutti e due vedono cosa sta succedendo. L'idea, nelle parole di Sierra, è che un'azienda si colleghi una volta sola invece di costruire un'integrazione per ogni assistente che verrà.

Come funziona, senza gergo

Tutto parte da un file che l'azienda pubblica sul proprio dominio, all'indirizzo /.well-known/poppy.json. Ci sono scritti chi sei, come ci si identifica e da quali porte l'assistente può passare: una conversazione con l'agente dell'azienda, che se serve passa la mano a una persona del supporto, le API dell'azienda (in formato OpenAPI oppure come server MCP, lo stesso standard che usano già Claude e ChatGPT per gli strumenti esterni), oppure il sito stesso, aperto in una sessione del browser già autenticata.

L'assistente entra sempre come ospite. L'azienda lo riconosce con un identificativo che resta lo stesso nel tempo ma non dice niente della persona, e che cambia da un'azienda all'altra, così nessuno può incrociare i dati. Quando serve qualcosa di personale, tipo lo stato di un ordine o il cambio di un indirizzo di consegna, la persona entra con il suo account attraverso OAuth, che è lo stesso meccanismo del "accedi con Google", e sceglie se dare solo la lettura o anche la scrittura. L'accesso si può revocare in qualsiasi momento, e l'azienda decide quali modi di accesso accettare in base alla sicurezza che le serve.

Prima di fidarsi, l'assistente fa un controllo che a me piace molto: va a chiedere al server di login dell'azienda se quel dominio è davvero suo. Se il server non lo conferma, il file non vale niente. È un dettaglio, ma è quello che impedisce a chiunque di pubblicare un poppy.json che manda gli assistenti a fare login da un'altra parte.

Perché riguarda chi fa GEO

Un sito finora ha avuto due tipi di lettori, le persone e i crawler. Adesso ne arriva un terzo che non legge per citarti, legge per fare. Se un modello ti consiglia e poi l'assistente della persona non riesce a entrare, la raccomandazione si ferma lì, e l'acquisto lo fa chi ha la porta aperta. Per me la visibilità nelle risposte AI e l'accesso degli assistenti diventeranno la stessa voce di bilancio, perché misurano due pezzi dello stesso percorso.

Detto questo, la parte che un ufficio marketing taglierebbe: oggi è presto, e chi vi dice che va fatto entro venerdì vi sta vendendo qualcosa. Ho controllato il file su sierra.ai, walmart.com e shopify.com, e rispondono tutti 404, compresa Sierra che lo standard l'ha scritto. A una settimana dalla bozza è normale, e conviene usare questo tempo per arrivare pronti quando uscirà la versione stabile e gli assistenti inizieranno a cercarlo.

Cosa abbiamo fatto in GeoSuite

Da questa settimana l'audit di GeoSuite legge il /.well-known/poppy.json di ogni sito e fa gli stessi controlli che farebbe un assistente prima di usarlo: la versione del protocollo, il dominio dichiarato, le porte d'ingresso, l'indirizzo sicuro e la conferma del server di login. Se il file non c'è lo scriviamo come facoltativo e non togliamo punti, perché non avrebbe senso penalizzare un sito per uno standard nato da una settimana. Se invece c'è ma un assistente lo scarterebbe, diventa un'azione da fare con il motivo preciso, perché chi l'ha pubblicato è convinto di essere raggiungibile e non lo è.

Cosa conviene fare adesso

Leggere la bozza, che è corta e scritta bene, su personalagentprotocol.org. Se avete già delle API pubbliche o un server MCP siete più vicini di quanto sembra, perché il protocollo li usa così come sono e chiede soprattutto di dichiararli e di metterci davanti un login fatto bene. Sierra ha promesso un'implementazione di riferimento entro il mese prossimo, ed è il momento giusto per provarlo su un ambiente di test.

Se volete sapere cosa vede oggi un modello quando parla di voi, e da adesso anche se un assistente saprebbe dove bussare, l'audit gratuito su trygeosuite.it/audit-geo-gratuito ve lo dice in pochi minuti.

Want to apply these insights to your brand?

Talk with the GeoSuite team or go back to the latest articles to keep exploring the topic.