C’è una distinzione che conviene tenere ferma: costruire un agente è un progetto; rendere il proprio servizio agent-ready è un lavoro di manutenzione che riguarda i prodotti che abbiamo già in linea. Il secondo è più urgente del primo, perché sta già succedendo: browser agentici come ChatGPT Atlas e Perplexity Comet visitano i siti per conto degli utenti, senza chiedere il permesso a nessuno.
Un agente interagisce con un servizio in due modi. Nel migliore dei casi tramite dati strutturati e interfacce dichiarate; nel peggiore leggendo lo schermo, cioè interpretando la pagina come farebbe una persona miope e frettolosa. La qualità del secondo caso dipende quasi interamente da scelte tecniche e di design che si prendono adesso.
Effetto per le professionalità
- Front-end Developer — È il ruolo con la lista più lunga, ed è quasi tutta igiene già nota, applicata con più rigore. Markup semantico reale:
buttonche sono bottoni,formconlabelassociate, heading gerarchici — un agente che legge il DOM ricostruisce la funzione dagli elementi, non dall’aspetto. Stato esposto nel markup: se un campo è obbligatorio, disabilitato, in errore, deve dirlo (aria-required,aria-invalid,aria-disabled), non solo mostrarlo con un colore. Testo selezionabile: informazioni critiche — prezzi, disponibilità, condizioni — mai solo dentro immagini o canvas. Dati strutturati schema.org su prodotti, prezzi, orari, disponibilità: è il canale preferenziale, e riduce la necessità che l’agente indovini. Percorsi senza trappole: flussi che dipendono da hover, drag, CAPTCHA o timer sono vicoli ciechi per un agente. Selettori stabili e non generati casualmente a ogni build, altrimenti l’automazione si rompe a ogni deploy. Nuova pratica da introdurre: test automatizzati che verifichino che un agente navighi e completi i task principali, alla stregua dei test di regressione. Nuovo rischio da presidiare: i contenuti di pagina sono un potenziale vettore di prompt injection verso gli agenti che li visitano — testo nascosto, contenuti generati dagli utenti e campi non sanificati possono contenere istruzioni rivolte all’agente. OpenAI riconosce che l’agent mode “espande la superficie di minaccia” e che il problema difficilmente sarà mai completamente risolto: va trattato come si tratta l’XSS, con sanificazione e diffidenza verso l’input di terzi. - UI Designer — Gli elementi interattivi devono essere comprensibili anche da un agente che opera via riconoscimento immagine: un campo che non si dichiara tale è inutilizzabile. Concretamente: affordance esplicite invece che sottintese, etichette visibili invece di soli placeholder, icone accompagnate da testo, stati (attivo, selezionato, disabilitato) distinguibili anche fuori dal colore. Il tema si estende ai Design System, che devono diventare AI-readable: l’AI che genera interfacce interpreta male i componenti, li usa in modo incoerente o ne reinventa perché non riconosce quelli esistenti — componenti, template e documentazione vanno progettati per essere letti anche dalla macchina, con nomi espliciti e regole d’uso dichiarate.
- CRO / E-commerce Manager — Ottimizzare per un agente non è ottimizzare per un umano: urgenza, scarcity e social proof hanno effetto nullo o imprevedibile su un software che compara dati strutturati. Contano completezza e leggibilità machine-readable di prezzo, disponibilità, specifiche, condizioni di reso e spedizione — e la loro coerenza tra canali, perché un agente che trova due prezzi diversi sullo stesso prodotto sceglie il competitor. Nasce una agent experience da progettare e misurare, con un rischio strategico: nella mediazione dell’agente la marca rischia la commoditizzazione, perché l’agente confronta attributi, non brand. Contromisura possibile: rendere machine-readable anche ciò che differenzia (garanzia, assistenza, tempi reali di consegna), altrimenti resta solo il prezzo.
- Content Strategist / SEO — Le stesse logiche di estraibilità della GEO valgono per l’agente: informazione auto-contenuta, non dipendente dal contesto della pagina, e aggiornata. Un dato di prodotto obsoleto in una scheda è un errore che ora si propaga senza che nessuno lo veda — e i modelli raccomandano già oggi entità che non esistono più.
- Product Manager — Decisione da prendere esplicitamente, non per omissione: quali azioni un agente può compiere sul nostro servizio e per conto di chi. Consultare il catalogo, sì; modificare un ordine, forse; disdire un contratto, probabilmente no. Ne discendono requisiti di autenticazione, delega e limiti d’azione. Da decidere anche la politica di accesso:
robots.txt, rate limiting e condizioni d’uso per gli agenti automatici — bloccarli tutti è una scelta legittima, farlo senza saperlo no. - Digital / Web Analyst — Quando naviga un agente, le metriche comportamentali (sessioni, scroll, funnel) descrivono il software, non l’utente. Il traffico agentivo va identificato e segmentato: mescolarlo alle sessioni umane rende inservibili analytics ed esperimenti — un test A/B con dentro traffico agentivo misura il rumore. Servono metriche centrate sull’esito: task success dell’agente, completamento delle operazioni delegate, punti di fallimento.
- CDP / Martech Ops — Emerge il “machine customer”: un agente con delega dell’utente. Problema di identità a due livelli — chi è l’agente, per conto di chi agisce — con implicazioni su autenticazione, consenso, audit trail (lo standard UCP nasce per questo). Profilare l’agente come se fosse l’utente inquina il dato.
- Legal / Compliance — Se un agente compie azioni sul nostro servizio servono log delle azioni e delle deleghe, condizioni d’uso che disciplinino l’accesso automatizzato, e una posizione definita su chi risponde di un’operazione eseguita da un agente per conto di un utente (si veda Il perimetro normativo).